¿Cómo evitas el exceso de ingeniería?

Lo primero es reconocer que estás sobre-diseñando algo. Si bien eso suena fácil, en realidad es mucho más difícil. En la fase de arquitectura, se puede detectar el exceso de ingeniería si los casos de uso que las direcciones de arquitectura no pueden explicarse claramente. Los argumentos generalmente giran en torno a algunos requisitos futuros, que ni siquiera se explican claramente. Si bien la arquitectura debe ser poco futurista, la noción de no realizar grandes cambios arquitectónicos y, por lo tanto, la necesidad de cubrir todo por adelantado no es correcta, en mi humilde opinión. En la fase de implementación, se puede detectar el exceso de ingeniería en función de la cantidad de recursos gastados en el desarrollo de la característica v / s su prioridad en el producto. Algunas veces, la forma en que se manejan ciertos casos de esquina puede resultar en una ingeniería excesiva de la característica. Si manejarlos afecta los casos de uso normales, entonces puede suponer que la solución fue diseñada en exceso.

Si está abierto a cambiar las instrucciones de diseño y refactorizar el código de vez en cuando, puede detectar el exceso de ingeniería temprano y administrarlo bien. Esto no significa que esté abriéndose para diseños e implementaciones pésimas, sino simplemente ignorando los requisitos probables en el futuro.

El mayor costo de desarrollo en mi humilde opinión no se trata tanto de la sobre ingeniería, sino de tratar cada característica de la misma manera. En proyectos grandes, dado que cada característica se trata con igual peso, los recursos de desarrollo y control de calidad no se gastan donde son más críticos. Por ejemplo, una interfaz de administración probablemente no necesita cumplir con los mismos criterios de rendimiento que el conjunto de características principales, por lo que su diseño puede simplificarse. Es difícil reequilibrar las características en grandes proyectos por razones ajenas al ámbito técnico, pero esto es algo que quizás desee observar.

Mucho de esto es honestamente instinto. Si alguna vez está escribiendo código y siente que se está volviendo complejo o complicado, especialmente en el manejo de casos especiales, probablemente lo esté haciendo mal. Respire hondo, retroceda para ver la imagen completa y vea la situación fresca. La mayoría de las veces se te presentará una solución mucho más simple. Si el camino hacia adelante no parece un flujo natural y siente que tiene que forzar las cosas, probablemente lo esté haciendo demasiado difícil.

Algunas otras cosas, tal vez un poco más concreto

  • YAGNI – No lo vas a necesitar. No escriba código para lo que percibe como necesidades futuras. Tenga en cuenta que es diferente de la arquitectura de escritura que escalará bien, pero que nunca se implementará en un futuro teórico
  • Valide sus datos: puede ahorrarse mucha complejidad simplemente asegurándose de que los datos que ingrese a su sistema sean buenos. Es mucho más fácil tratar en la puerta que dentro de la casa
  • Si funciona, deja de escribir código. Existe la broma de que los ingenieros piensan que “si no está roto, todavía no tiene suficientes características”. No seas ese tipo. Escriba la cantidad mínima de funciones que necesita para hacerlo
  • Escriba comentarios de bloque a medida que avanza. Si escribe encabezados en todos sus métodos a medida que los escribe, le garantizo que reconsiderará algunas cosas y volverá y simplificará
  • Nunca tengas miedo de tirar el trabajo. Si algo simplemente no es la solución correcta, deséchelo y vuelva a escribirlo. No importa si pasaste una hora o una semana en él, es mejor tirar el código equivocado que intentar hacer que una clavija cuadrada encaje en un agujero redondo