Pregunta:
¿Cómo puedo escribir funciones que sean reutilizables sin sacrificar el rendimiento? Repetidamente me encuentro con la situación en la que quiero escribir una función de una manera que la haga reutilizable (por ejemplo, no hace suposiciones sobre el entorno de datos) pero conociendo el flujo general del programa, sé que no es el más eficiente método. Por ejemplo, si quiero escribir una función que valide un código de existencias pero que sea reutilizable, no puedo simplemente asumir que el conjunto de registros está abierto. Sin embargo, si abro y cierro el conjunto de registros cada vez que se llama a la función, el impacto en el rendimiento al recorrer miles de filas podría ser enorme.
Entonces, para el rendimiento, podría tener:
Function IsValidStockRef(strStockRef, rstStockRecords)
rstStockRecords.Find ("stockref='" & strStockRef & "'")
IsValidStockRef = Not rstStockRecords.EOF
End Function
Pero para la reutilización necesitaría algo como lo siguiente:
Function IsValidStockRef(strStockRef)
Dim rstStockRecords As ADODB.Recordset
Set rstStockRecords = New ADODB.Recordset
rstStockRecords.Open strTable, gconnADO
rstStockRecords.Find ("stockref='" & strStockRef & "'")
IsValidStockRef = Not rstStockRecords.EOF
rstStockRecords.Close
Set rstStockRecords = Nothing
End Function
Me preocupa que el impacto en el rendimiento de abrir y cerrar ese conjunto de registros cuando se llama desde un bucle sobre miles de filas / registros sería severo, pero usar el primer método hace que la función sea menos reutilizable.
¿Qué tengo que hacer?
Respuesta:
Debe hacer todo lo que produzca un mayor valor comercial en esta situación.
Escribir software es siempre una compensación. Casi nunca todos los objetivos válidos (mantenibilidad, rendimiento, claridad, concisión, seguridad, etc., etc.) están completamente alineados. No caigas en la trampa de esas personas miopes que consideran una de estas dimensiones como primordial y te dicen que sacrifiques todo por ella.
En su lugar, comprenda qué riesgos y beneficios ofrece cada alternativa, cuantícelos y elija la que maximice el resultado. (No es necesario que haga estimaciones numéricas, por supuesto. Es suficiente sopesar factores como "usar esta clase significa encerrarnos en ese algoritmo hash, pero como no lo estamos usando para protegernos contra ataques maliciosos , solo para conveniencia, este es lo suficientemente bueno como para que podamos ignorar la posibilidad de 1: 1,000,000,000 de una colisión accidental ".)
Lo más importante es recordar que son compensaciones; Ningún principio único justifica todo para satisfacer, y ninguna decisión, una vez tomada, debe permanecer eternamente . Es posible que siempre tenga que revisar en retrospectiva cuando las circunstancias cambien de una manera que no previó. Eso es un dolor, pero no tan doloroso como tomar la misma decisión sin pensar en retrospectiva.