¿Cuáles son los principios de una buena ingeniería de software?

En lugar de surgir sobre el principio de la complejidad irreducible (con el ejemplo obligatorio de la trampa para ratones) y otros conceptos similares, para ser independientes del lenguaje y el paradigma, esta pregunta se responde mejor analizando qué resultados cuando NO se utilizan principios sólidos de ingeniería. El resultado es algo que la gente conoce tácitamente como “mal diseño”. Los programadores son conocidos por usar diferentes criterios para evaluar un buen diseño, pero, por experiencia, tiendo a estar de acuerdo con Bob Martin y Martin Fowler, quienes han dicho que hay un conjunto de criterios en los que los ingenieros suelen estar de acuerdo …

Una pieza de software que cumple con sus requisitos y, sin embargo, exhibe cualquiera o todos los siguientes rasgos puede considerarse que tiene un “mal diseño”:

Rigidez : es muy difícil hacer cambios porque cada cambio afecta a muchas otras partes del sistema .

Fragilidad : cuando realiza un cambio, se rompen partes inesperadas del sistema.

Inmovilidad : es difícil reutilizar un fragmento de código en otro lugar porque no se puede separar de su aplicación / uso actual.

Viscosidad : es difícil hacer “lo correcto” para que los desarrolladores tomen acciones alternativas .

[Hay otros pero los estoy omitiendo por brevedad]

Estos “olores de diseño” encapsulan muy bien las cosas que realmente desea evitar, y la mayoría de los principios que las personas arrojan: SÓLIDO, modularidad, reutilización, compostibilidad, SECO, BESO, patrones de diseño moderno, etc., son solo algunas de las pautas para evitar yendo a la casa de mal diseño.

Entonces, ¿por qué huele la conferencia sobre mal diseño? Debido a que no puede reconocer un buen diseño hasta que sepa lo que es un mal diseño , y una vez que sepa qué debe evitar el buen diseño, puede juzgar fácilmente si dicho principio de ingeniería tiene algún mérito o es solo un error esperando distraerlo de su objetivo real de crear software que sea ÚTIL para las personas .

En resumen … si NO está produciendo código con olores de diseño, es más que probable que esté siguiendo, o sin saberlo, buenos principios de ingeniería.

Escribir código con invariantes. Honra a los invariantes.

Programación por contrato (lo aprendí en un libro sobre Eiffel).

Usa la abstracción. Ocultar cosas No te metas en las abstracciones de otras personas.

===

Escribir pruebas unitarias y otras pruebas.

Ejecute pruebas unitarias y otras pruebas.

Solucione los errores reportados por sus pruebas. También arregle las pruebas ellos mismos cuando estén rotas. Ambas cosas son más importantes que el trabajo nuevo.

===

Ley de murphy. Murphy siempre está ahí, buscándote cosas.

Si está haciendo OO (programación orientada a objetos), le recomiendo encarecidamente – SOLIDO
S – Responsabilidad individual
O – Principio de apertura / cierre
L – Principio de sustitución de Liskov
I – Principio de segregación de interfaz
D – No te repitas
Para más detalles – SÓLIDO (diseño orientado a objetos)

(1) Usted diseña y su código son las descripciones elocuentes de qué es el sistema y cómo funciona. Las personas que lo leen entienden exactamente lo que está haciendo, aprecian la claridad y elegancia de su diseño, y la belleza de la ingeniería de software en general.

(2) También hace lo que sea lo suficientemente rápido sin fallar.

(Nota: todas las demás cualidades como la estabilidad, la reutilización, etc. vienen naturalmente como parte de (1)).

Posiblemente comenzaría con este clásico de Parnas … “Sobre los criterios que se utilizarán para descomponer los sistemas en módulos” … http://sunnyday.mit.edu/16.355/p …

Este principio es útil en la programación por cualquier razón.
BESO (¡Mantenlo simple, estúpido!)