Prioridades de codificación:¿Rendimiento, mantenibilidad, reutilización?

Question

Esto se debió principalmente a las respuestas a preguntas de SQL.Las UDF y las subconsultas se omiten intencionalmente debido al rendimiento.No incluí la confiabilidad, no es que deba darse por sentado, pero el código tiene que funcionar.

¿El rendimiento siempre es lo primero?Se brindan muchas respuestas teniendo como principal prioridad el rendimiento.Mis usuarios parecen estar más preocupados por la rapidez con la que se puede modificar el código.Por lo tanto, un informe tarda 15 segundos en ejecutarse en lugar de 12.Pueden vivir con eso siempre y cuando no ponga excusas para no brindar soluciones.

Obviamente, si los 15 segundos se convierten en 15 minutos, hay un problema, pero los usuarios quieren la funcionalidad.Quieren que la aplicación se adapte a los cambios en las reglas comerciales y las solicitudes de mejora.Quiero poder ver el código dentro de 6 meses y poder hacer el cambio en un lugar fácilmente identificado y no perseguir todos esos lugares donde alguien copió y pegó el código porque pensó que llamar a otra función o subrutina o Udf lo haría. obstaculizar el desempeño.

Dicho todo esto, yo ordenaría:Mantenibilidad (el cambio es una realidad), rendimiento (a nadie le gusta mirar el reloj de arena), reutilización (es difícil determinar qué código debe usarse nuevamente).

Answer 1

1. Capacidad de mantenimiento: Si el código es no-legible que es inútil, no importa lo rápido que es. Y que sin duda no se puede volver a utilizar.

2. Reutilización: No todo el código es reutilizable, pero mucho de lo que es. Si puede, por todos los medios hacer su código más simple. Lo más fácil es dividir y conquistar. Por ejemplo, crear componentes sencillos que utilizará una y otra y otra vez. widgets de interfaz de usuario son los más comunes. Pero es lo mismo con los servicios públicos. A su vez, la creación de una estructura / marco de su código de ayuda. código de validación de errores, etc.

3. Rendimiento: En general, la mayoría del código es lo suficientemente performant. Y si no, utilizar un perfilador de código. Más a menudo que el cuello de botella superan con creces cualquier pequeñas optimizaciones de código que podría haber hecho a costa de cualquiera de legibilidad o re-usabilidad.

Answer 2

Creo que se ha perdido uno de la lista: fiabilidad;

así que mi orden es

• La fiabilidad y la precisión
• mantenibilidad
• Reutilización
• Rendimiento

No importa qué tan rápido es el código cuando no está bien, en primer lugar, el código tiene que ser fiable.

El rendimiento es en la parte inferior de la lista. Nunca optimizar demasiado pronto, y sólo mejorar el rendimiento cuando el rendimiento es un problema.

He trabajado en sistemas de tiempo real, incluyendo la simulación de vuelo, e incluso en que el rendimiento medio se toma en consideración, pero no es una preocupación primordial primordial ¹ .

Yo diría que en mi experiencia sólo he tenido que optimizar menos del 1% del código que he escrito.

---

¹ a veces algo no es lo suficientemente rápido, y por supuesto, el rendimiento se tiene en cuenta en el diseño y la codificación, simplemente no está en la cima de la lista.

Answer 3

La respuesta es, por supuesto, lechón, "depende".

En el caso de las aplicaciones de línea de negocio el tiempo de respuesta para la actividad involucrada necesidades a ser inversamente proporcional a la frecuencia con la que se ejecuta. Si se trata de una función que los usuarios necesitan acceder a 4 o 5 veces por hora más vale que sea más ágil de tirar de que el informe de fin de mes.

Creo que, hasta cierto punto, que haya respondido a su propia pregunta y ha proporcionado algunas razones muy válidas para ello. El único que ha faltado es la fiabilidad - y aquí es donde tha analogía NASA viene en Si va a escribir código para la NASA, o para una institución financiera, que tenía sangrienta, bueno mejor que sea robusto y fiable ... y. Creo que eso sería la primera prioridad.

Answer 4

Soy un contratista de la NASA y desarrollar y mantener el software principalmente para fines de administración tales como la elaboración de informes y el seguimiento de proyectos.

He estado trabajando allí durante aproximadamente 1,5 años, y creo que su principal preocupación es mantenimiento y qué tan rápido puede usted conseguir que la nueva función o módulo desplegados.

Al igual Guiness afirma en la pregunta, siempre y cuando el software no tiene una excepcional cantidad de tiempo, no parece a la mente.

La otra preocupación principal parece que tienen es la usabilidad. La aplicación debe ser fácil y sencillo de usar.

En conclusión, el mantenimiento, la usabilidad, el rendimiento parece a las principales preocupaciones de la NASA para herramientas de reporte y seguimiento interno.

Answer 5

Hay que ser capaz de reorganizar estas prioridades en función del proyecto, y lo duro se puede cambiar el comportamiento rápidamente al cambiar de proyectos o incluso diferentes secciones de código. Yo trabajo en tres aplicaciones con perfiles muy diferentes.

1. Uno de ellos es en tiempo real y una gran cantidad de trabajo va a asegurarse de que su rendimiento es predecible, (no necesariamente un rayo rápido), pero el cambio no es un problema importante, sólo cambia significativamente cuando cambia el IETF / obsoletes el RFC y hay pocas señales de eso. (Dicho esto, estoy muy orgullosa de su nivel de mantenimiento).

   • Otra aplicación tiene a veces tomadas 16hrs para procesar datos de 1 día. Huelga decir que el rendimiento absoluto se convirtió rápidamente en la principal prioridad. Pero incluso dentro de esta aplicación la hacen hincapié en el rendimiento varía drásticamente, de 'no es importante' en el código por lotes a través por cliente de código, por tareas de código, por archivo de código, por registro de código, por -field de código hasta 'extremadamente importante' en el código de bytes per-view.

   • La aplicación final contiene gran parte de la lógica de negocio, el rendimiento nunca un problema, facilidad de mantenimiento y la agilidad son fundamentales son y esta aplicación es más se beneficia de todas las metodologías, sin embargo, cuando acaba de pasar semanas o meses de moda refactorización para un rendimiento que es muy difícil escribir "cadena1 + cadena2 + + string3 string4", incluso si esa es la más legible y el rendimiento es irrelevante.

Answer 6

Editado 2010-03-02 : La cuestión comenzó originalmente:

  

¿Funciona todo el mundo para la NASA? ¿Tiene el rendimiento siempre son lo primero? Tantas respuestas ...

No-la mayoría de nosotros no trabajan para la NASA.

No: fiabilidad y facilidad de mantenimiento tienen lugar antes de la actuación. Reutilización es bueno también.

Dentro de unos límites amplios, el rendimiento no es importante.

Answer 7

Esta es una pregunta interesante, y las respuestas son lo bastante interesante. La prioridad depende de la implementación. Me gustaría presentar uno de los ejemplos donde los usuarios no sacrificar el rendimiento para el mantenimiento o la reutilización. Si hay un factor de fiabilidad - no debe haber ningún fallo / error. Así que cuando comparamos mantenimiento, rendimiento y capacidad de reutilización.

Uno de nuestros clientes tenían sitio de comercio en línea. Bajo los picos de carga una transacción media tomaría algunos donde alrededor de 14 ms para completar a nivel de middleware. Algún tiempo este último el rendimiento de aplicación degradado (debido a algunas razones) y las transacciones de tiempo promedio aumentó a 24 ms. Ahora como desarrollador normales pensaríamos 10 ms no es tan alarmante crítico. Pero si pensamos desde la perspectiva de negocio, entonces es alarmante. ¿Cómo? Analicemos:

Vamos a suponer que, bajo los picos de carga, los recursos se utilicen plenamente y con 14ms hemos sido capaces de hacer 100 transacciones. Ahora, con la degradación en el rendimiento de las transacciones tienen 10 ms extra que es 71,42% de tiempo extra. Ahora bien, esto significaría sólo seremos capaces de servir 28,58 transacciones en lugar de 100 transacciones. Esto significa una grave pérdida de negocio.

De hecho hay gran cantidad de literatura sobre la importancia del rendimiento de las aplicaciones. Hay un muy buen libro "Enfoque Cuantitativo Arquitectura de Computadores" que explica cómo los factores de rendimiento, maintability, fiabilidad, avaliability se pueden cuantificar en términos de negocio / usuario.

No voy a especificar el orden de importancia según el mismo contexto específico.

Answer 8

  

que pensaban llamar a otra función o sub-rutina o Udf obstaculizarían el rendimiento

Eso es pensamiento erróneo.

  

Me gustaría pedir: Capacidad de mantenimiento, rendimiento, Reutilización

.

A veces (por lo general OMI) reutilización es de mantenimiento: es porque reutiliza algo que usted es "capaz de hacer el cambio en un punto fácilmente identificable y no persiguen por todos aquellos lugares soneone copiados y código pegado ".

Answer 9

doesnt't rendimiento son lo primero, incluso a la NASA! En la NASA, si el código no es correcto y fiable, las personas mueren.

Por otra parte, en mi experiencia, aun cuando el rendimiento es valiosa, es hasta cierto punto; por lo general hay un nivel de rendimiento que hay poco o ningún valor adicional en superar. Por el contrario, hay un valor adicional en la mejora de la corrección no importa qué tan confiable es una pieza de código es; un fragmento de código en realidad no puede funcionar como se espera demasiado a menudo.

Para mí el orden sería:

• Capacidad de mantenimiento . Si no es fácil de cambiar, no va a permanecer por mucho tiempo correcto, incluso si es correcta ahora
• Reuseability . Reutilización mejora la productividad, y menos código es generalmente más fiable que más código
• Rendimiento : a veces cuestiones de rendimiento, pero usted se sorprendería de lo mucho código no es crítica de rendimiento, incluso en una aplicación crítica rendimiento. asuntos de optimización del rendimiento para los cuellos de botella solamente.

Answer 10

En una respuesta aislada, el rendimiento prácticamente siempre será lo primero.

No sabemos si va a acceder a este fragmento de código un millón de veces seguidas, por lo que el rendimiento es una preocupación de forma predeterminada.No sabemos si nuestro precioso fragmento de código se convertirá en el cuello de botella de su aplicación, ya que no sabemos cómo interactúa.(Lo mismo sucede al escribir código de biblioteca:No sé cómo se está usando esto.Una de las razones por las que la reutilización del código OMI no es simplemente "mover código similar a una entidad compartida").

Mantenibilidad Se ve aún más afectado por la forma en que el código interactúa con el código desconocido para nosotros.La respuesta resolverá el problema en el alcance que establezca:Puede solicitar o etiquetar como SQL, SQL Server o MySQL.El resto simplemente no lo sabemos:¿Cuántas rutas de código similares tienes?¿Con qué frecuencia cambiará este fragmento de código durante la vida del proyecto?¿Se apegará a esa versión particular del servidor de base de datos durante diez años o la actualizará con frecuencia?

Resolver la mantenibilidad es en gran medida su trabajo:¿La pregunta que usted hace es una entidad que debería aislarse?

Legibilidad Está casi hecho, el resto es tu trabajo.Al responder, normalmente nos interesa que comprenda la respuesta, por lo que debe ser legible al menos para usted.Si copia y pega ese fragmento en su código y le da una palmada // That weird query Coméntalo, ya no es mi problema.

Agregue a esto el hecho de que el rendimiento se entiende más fácilmente:De dos respuestas funcionalmente equivalentes, siempre elegirá la que dice "como la respuesta de Joe, pero un poco más rápida", a menos que cometa grandes errores en el departamento de M+R.

---

Al escribir esto ahora, parece que hay una razón por la que la optimización prematura es tentadora.Este es la prioridad equivocada por un par de razones.

Sin embargo, la baja prioridad para las optimizaciones tiene dos razones principales:

Answer 11

Corrección es más importante que el mantenimiento, la reutilización, o el rendimiento. Si usted tiene como objetivo la corrección, es muy probable que obtener los otros tres en la negociación.

• Escribir código de no más de lo necesario.
• bibliotecas estándar de apalancamiento.
• Prefiero transparencia a la inteligencia.
• Escribir funciones pequeñas, comprobables.

Answer 12

Estos son los resultados basado en Tag Count:

• Rendimiento - 952
• Reutilización (varias etiquetas relacionadas) - 43
• Capacidad de mantenimiento - 14

¿Qué quiere decir esto: El rendimiento debe ser importante? El rendimiento es más difícil, por lo que más se hacen preguntas. preguntas de desempeño son más específicas / approprate preguntar en este sitio?

Answer 13

hacer trabajo en la NASA. Sin embargo, no lo creo (en la actualidad de todos modos) mantener o desarrollar código en tiempo real o cualquier cosa que es todo lo que el rendimiento crítico. La mayoría del software hecho en la NASA probablemente no lo es. Después de haber visto algo de código horrible en mi día, yo también iré con la respuesta de Jonathan de fiabilidad y facilidad de mantenimiento seguido por el rendimiento y luego reutilización para la mayoría de aplicaciones.

Answer 14

Una de mis frases favoritas es de SICP ...

"Los programas de ordenador están diseñados para ser leído por los seres humanos y dicho sea de paso corrió por las computadoras."

I tarifa todos estos ascpects de mi trabajo; pero la legibilidad (algunos utilizan el término expresividad) de mi código y los que yo trabajo con encimeras mi lista de importancia.

Sólo mi 2c, tener un buen fin de semana!