project management - software - Prioridades para escribir el código

project management software

Question

He estado siguiendo SO por un tiempo, y de vez en cuando veo gente preguntando sobre la forma más rápida de hacer algo. Ciertamente, reconozco que el código debe estar bien escrito e incluso ajustado de vez en cuando, pero en mi trabajo diario estoy mucho más preocupado por la capacidad de mantenimiento del código y solo ocasionalmente tengo que ajustar el código para que sea más rápido.

Por lo tanto, me gustaría saber qué prioridades están siguiendo otros al escribir el código. Entonces, en otras palabras: ¿Cuáles son los atributos más importantes del código? Y como preguntas de seguimiento, me gustaría saber quién tomó esta decisión (administración o desarrolladores).

Answer 1

Cuando se codifica:

1. Exactitud,
2. Legibilidad,
3. Eficiencia,
4. Sencillez

En ese orden.

Al diseñar:

1. Organización (muchas cosas, incluyendo OOP y preocupaciones de una sola tarea),
2. Limpieza (sin código redundante),
3. Testabilidad (incluida la separación de preocupaciones).

En ese orden.

Answer 2

El rendimiento generalmente no es un problema, excepto que tiene un procesamiento por lotes de miles de archivos de datos. Una buena parte del rendimiento viene con la simplicidad, que es una de mis prioridades. Vería mis prioridades más o menos en el siguiente orden:

1. Confiabilidad
2. Simplicidad (en algoritmos, interfaces, etc.)
3. Genericity (¿Puedo hacer que mi programa resuelva el problema de una manera más genérica para que los cambios futuros sean más fáciles?)
4. Robustez
5. Reusabilidad (¿puedo hacer que mi programa resuelva otros problemas también?)

Answer 3

Esto realmente depende de qué software está desarrollando y para quién es.

Si está escribiendo una aplicación web LOB para una empresa donde todos usan la misma versión de IE para toda la navegación web, entonces un error que cause que su aplicación se rompa de manera horrible en Fire Fox no es importante.

Si usted está desarrollando Google Gmail, entonces ese error se vuelve mucho más importante.

A veces, el rendimiento puede compensar la corrección. Por ejemplo, si tiene un error que afecta al 0.1% de sus clientes, y corregirlo requeriría que desacelere la aplicación considerablemente para el otro 99.9%, entonces el rendimiento se vuelve más importante.

Entonces, yo diría que realmente depende de tus circunstancias individuales.

Answer 4

La forma más rápida de desarrollar algo IME es haber acumulado tantas partes de soluciones que en su mayor parte se ensamblan fácilmente en el nuevo problema. Por ejemplo, tengo un motor de datos que siempre uso, tengo una clase base de servicios, un programador, funciones para copiar archivos y verificar sus hashes, etc. Normalmente puedo lanzar un programa bastante rápido solo porque tengo estos desarrollados previamente y el código probado a mano.

Answer 5

La separación de preocupaciones es muy importante para mí. Si cada clase tiene un número limitado de propósitos (con suerte uno), cada vez que se necesite mantener el código, tendrá menos lugares para buscar. Esto también evita la monstruosidad de múltiples miles de líneas que solo Bob puede arreglar o trabajar. En combinación con las pruebas unitarias correctas, se reduce el alcance de cada clase y prueba, garantizando que cada sección de código sea más fácil de comprender y diagnosticar.

Answer 6

Las pruebas encabezan mi lista de atributos importantes. Hace la vida mucho más fácil en el camino. Ha sido mi decisión hacer donde trabajo ya que nadie más hace TDD.

Answer 7

Mi prioridad número uno sobre todo lo demás es que los cambios en los requisitos, sin importar cuán grandes sean, solo requieren pequeños cambios en el código. No importa lo que piense, o lo que le digan, van a cambiar los requisitos. Y ninguno de ellos está a salvo.

• Asume que todo cambiará
• Parametrizar EVERYTHIN G.
• Eliminar dependencias.

Si un requisito cambia y tengo que cambiar el código en más de un lugar, siento que he fallado. Pero luego descubro cómo volver a escribir ese código para que cuando el requisito cambie por segunda vez (ya sabes que lo hará), pueda cambiarlo en un solo lugar.

Hay una razón por la cual las personas inventaron cosas como n-tier y MVC y otras técnicas de desacoplamiento.

-
bmb

Answer 8

Mis prioridades:

1. El código tiene que ser legible.

2. El código debería hacer algo útil.

3. En muchos casos, tiene que salir por la puerta rápidamente, en cuyo caso puedo comprometerme en lo siguiente.

4. El código debería descomponerse en módulos.

5. Debería ser lo suficientemente rápido.

La última vez que tuve un código que no era lo suficientemente rápido fue cuando estaba escribiendo un solucionador de ecuaciones y necesitaba convertir ecuaciones en código, lo que significaba reemplazar nombres de variables arbitrarios con identificadores de programa válidos. Resulta que una secuencia de 30 sustituciones individuales no fue muy inteligente, demasiada asignación. Hacer una sola sustitución de las 30 variables en una pasada salvó el día.

Answer 9

La calidad del software debe estar en la parte superior de cada lista de prioridad de escritura de código ...

• Mantenibilidad
• Flexibilidad
• Portabilidad
• Reusabilidad
• Legibilidad
• Testabilidad
• Comprensibilidad

Answer 10

El código debe realizar su tarea prevista en un período de tiempo lo suficientemente corto como para ser utilizable. Esto varía ampliamente entre las aplicaciones. Esfuércese por hacer que su código sea "rápido" cuando no comprenda qué tan rápido debe ser, es una pérdida de tiempo; al mismo tiempo, esforzarse por hacer que su código sea "sostenible" cuando no tiene una idea clara y de alto nivel de lo que su código debe lograr está condenado al fracaso. Por lo tanto, debe darse la máxima prioridad a la comprensión del problema que desea resolver; todo lo demás se sigue de esta comprensión.

Ver también: ¿ Cuándo es la optimización prematura?

Answer 11

Mis prioridades son LTFCE : L egible, T estable, F lexible, C ompliant y E conomical, en ese orden. Una discusión más detallada de estas prioridades se publica en una respuesta a esta pregunta .

Como puede ver, estoy de acuerdo con usted en que casi siempre la velocidad no está cerca de la principal preocupación.

Answer 12

La respuesta de mdbritt es bastante cercana a mi actitud, pero algunas otras cosas:

• Personalmente valoro la legibilidad sobre la corrección. Es más fácil (IME) pasar de un código legible pero incorrecto a un código legible y correcto que llegar desde un código correcto pero ilegible.
• Sé que suena como algo dado, pero creo que es muy importante comprender lo que realmente estás tratando de hacer antes de comenzar a codificar. No digo que deba saber todo sobre su aplicación completa antes de comenzar, y ciertamente puede mejorar el diseño de algunas áreas a medida que avanza; pero cuando se trata de una clase única, al menos debe saber qué resultados está buscando y por qué lo está haciendo.
• El rendimiento es importante para la arquitectura, pero mucho menos para la implementación. Si comienza mal la arquitectura para que no se escale, tiene problemas, pero si la arquitectura es correcta, puede corregir una implementación más adelante. Sé que es un dicho muy usado, pero realmente tiene sentido escribir primero el código de trabajo más simple, luego perfilar la aplicación y optimizar solo los cuellos de botella hasta que esté satisfecho. (Esto pone la simplicidad por encima de la eficiencia en mi versión de la respuesta de mdbritt, para la mayor parte del código).