¿Deberían los métodos de desarrollo aplastar el individualismo de un desarrollador?

Estoy en mi último semestre de la universidad y estoy tomando un curso de ingeniería de software. En la clase aprendemos sobre varios métodos de desarrollo de software. En lo que nos centramos y en lo que desarrollamos nuestro proyecto fue en el método de cascada.

Siento que el instructor puede haberlo implementado mal. En nuestros diagramas de clases, tuvimos que enumerar TODAS las propiedades y métodos, incluidos los privados. He leído algunos libros, a saber, Clean Code, que dicen mantener las funciones lo más cortas y enfocadas posible. Parece tedioso enumerar cada pequeña función en nuestros diagramas si no ayudan a otros desarrolladores (son privados, nadie más los usará). Además, es posible que no piense en cada pequeña función al diseñar el programa, pueden aparecer al refactorizar.

¿El instructor nos dijo mal al pedirnos que enumeremos cada función? Y, ¿estos métodos de diseño aplastan el individualismo del desarrollador para escribir código de la mejor manera que puedan entenderlo?

¿Le preguntaste al instructor por qué tenías que enumerar todos los métodos?

Es posible que, al igual que gran parte de lo que se pide en un entorno de aula, la intención no fuera hacer que los diagramas de clase sean más útiles para los desarrolladores, sino ayudarlos a usted y a sus compañeros a pensar en cómo diseñarían sus clases. Cuando los estudiantes están aprendiendo cómo descomponer problemas más grandes en problemas más pequeños, probablemente les sea útil pensar qué métodos privados probablemente necesitarían. Y probablemente sea útil que el instructor tenga una mejor idea de qué métodos están pensando implementar los estudiantes para intervenir antes en el proceso si el diseño de alguien está mal pensado. La documentación en un entorno de clase suele ser mucho más complicada que la documentación en un entorno del mundo real porque el instructor '

Por supuesto, también es posible que el instructor crea que este nivel de documentación es útil en un proyecto real. Si ese es el caso, el instructor probablemente esté desactualizado o provenga de un nicho particular en el que este nivel de planificación y documentación sea apropiado. Si está construyendo el sistema de navegación para el transbordador espacial o diseñando dispositivos médicos, por ejemplo, generalmente es mucho más apropiado invertir mucho en el diseño por adelantado en lugar de refactorizar el código durante el desarrollo. Si está desarrollando un sitio de redes sociales, por otro lado, un enfoque más ágil es más apropiado.

No, el instructor tiene razón al decirle que enumere todas las propiedades y métodos por adelantado si está utilizando el método de cascada. Wikipedia señala una crítica a la cascada:

Muchos argumentan que el modelo de cascada es una mala idea en la práctica, ya que creen que es imposible para cualquier proyecto no trivial terminar perfectamente una fase del ciclo de vida de un producto de software antes de pasar a las siguientes fases y aprender de ellas. Por ejemplo, los clientes pueden no saber exactamente qué requisitos necesitan antes de revisar un prototipo en funcionamiento y comentarlo. Pueden cambiar sus requisitos constantemente. Los diseñadores y programadores pueden tener poco control sobre esto. Si los clientes cambian sus requisitos después de finalizar el diseño, el diseño debe modificarse para acomodar los nuevos requisitos. Esto significa efectivamente invalidar una buena cantidad de horas de trabajo, lo que significa un mayor costo, especialmente si una gran cantidad de los recursos del proyecto ya se han invertido en Big Design Up Front.

Estos métodos de diseño no aplastan al implementador del individualismo del diseño, ya que todavía hay partes para interpretar y formas de poner toques únicos en la estructura, por ejemplo, una imagen dada un esqueleto y agregar el músculo y otros tejidos para crear un animal preguntándose cuánto libertad tuviste que diseñar ese animal?

Usted ha encontrado una deficiencia de la cascada, sí, pero todo tiene sus puntos fuertes y débiles.

En la clase aprendemos sobre varios métodos de desarrollo de software. En lo que nos centramos y en lo que desarrollamos nuestro proyecto fue en el método de cascada.

Probablemente aprendió el modelo clásico de Waterfall, que la persona atribuida al introducirlo en el mundo del desarrollo de software declaró desde el principio que no era apropiado para desarrollar sistemas de software a gran escala. Probablemente le interese leer el documento de Winston Royce titulado Gestión del desarrollo de sistemas de software grandes para obtener más información sobre los problemas con lo que mucha gente considera el modelo de la cascada.

Sin embargo, el modelo Waterfall es bueno para enseñar el ciclo de vida del desarrollo de software a medida que avanza y puede pasar tiempo aprendiendo y realizando ingeniería de requisitos, diseño arquitectónico, diseño detallado, implementación, prueba y mantenimiento en fases muy claras y distintas.

En nuestros diagramas de clases, tuvimos que enumerar TODAS las propiedades y métodos, incluidos los privados. He leído algunos libros, a saber, Clean Code, que dicen mantener las funciones lo más cortas y enfocadas posible. Parece tedioso enumerar cada pequeña función en nuestros diagramas si no ayudan a otros desarrolladores (son privados, nadie más los usará). Además, es posible que no piense en cada pequeña función al diseñar el programa, pueden aparecer al refactorizar.

Todos estos son puntos muy válidos.

Enumerar todas las propiedades y métodos durante la fase de diseño, incluso cuando se utiliza Waterfall, probablemente sea exagerado. Definitivamente debe enumerar todo lo que es público, junto con las propiedades esenciales. En realidad, todo lo demás es un detalle de implementación que puede obtener mediante ingeniería inversa de su implementación en diagramas.

El consejo de Clean Code (nunca lo he leído, solo sigo lo que publicaste) parece ser justo y aplicable incluso cuando utilizo la metodología Waterfall. Puede diseñar sus clases y métodos con respecto al Principio de responsabilidad única , la separación de preocupaciones y otros principios de SOLID . Waterfall no te dice cómo diseñar, justo cuando necesitas hacerlo. Dicho esto, es más difícil por adelantado a medida que aprende y piensa en mejores formas de hacerlo durante la implementación.

Creo que esto señala el hecho de que debe haber una iteración entre el diseño y la implementación muy claramente, un problema que Waterfall tradicional no tiene en cuenta.

Parece tedioso enumerar cada pequeña función en nuestros diagramas si no ayudan a otros desarrolladores (son privados, nadie más los usará).

Si cree que esto es tedioso, espere hasta obtener una programación de trabajo real. Considere, por un momento, que el software puede no ser una carrera viable para usted.

Además, es posible que no piense en cada pequeña función al diseñar el programa, pueden aparecer al refactorizar.

¿Entonces?

¿Nos dijo mal el instructor al pedirnos que enumeremos cada función?

No. Es un requisito común.

Y, ¿estos métodos de diseño aplastan al implementador del individualismo de diseño (el desarrollador) para escribir código de la mejor manera que puedan entenderlo?

Si. La destrucción de las personas es una parte importante del desarrollo de software. Toda individualidad será eliminada de todos los programadores en todo momento de todas las formas posibles. Dice que en algún lugar de las "Reglas de programación de Dios" transmitidas de alguna montaña a algún profeta.

No. Solo te estás resistiendo al tedio. Supéralo y vuelve al trabajo.

La programación es el arte de trabajar dentro de las limitaciones. La CPU proporciona un conjunto de instrucciones limitado; IO está limitado por el diseño del hardware; Las API del sistema operativo se crean para fomentar ciertos comportamientos y restringir otros; Los lenguajes de alto nivel a menudo están diseñados para promover un conjunto de modismos sobre otros ...

Y las metodologías también están diseñadas para restringir.

Su desafío, en todos los aspectos del proceso de desarrollo, es realizar su visión dentro de esas limitaciones. ¿Te golpearás la cabeza contra cada pared levantada por hardware, lenguaje, API y metodología? ¿O encontrará una manera de armonizar lo que desea lograr con lo que está permitido y alentado?

¿ Realmente crees que tu instructor desea leer interminables páginas de minucias? Luego pruebe esa teoría: divida un programa y documente cada átomo. Cuando su escritorio se hunde bajo el peso, sospecho que descubrirá que su verdadero deseo es algo diferente de lo que espera.

O prepare la documentación como mejor le parezca. Que quede claro, que sea comprensible, que se lea como una novela de Dashiell Hammett. Y luego siéntate y habla con él, muéstrale lo que has hecho, convencerlo de su mérito.

Creo que el instructor es brillante por hacerte hacer este proyecto, y por lo tanto, enseñarte los pros y los contras (en su mayoría) del desarrollo de Waterfall.

Una simple regla general para medir la complejidad del análisis del proyecto es "¿Puede el desarrollador o la empresa para la que trabaja puede ser responsable de que ocurra algo bastante dramático (que generalmente incluye la muerte o una gran cantidad de dinero perdido) con el software creado?".

Tuve la misma experiencia que tú en algunos de mis cursos. Las personas que tenían experiencia en la industria militar nos enseñarían análisis. Y eso sería un análisis completo y exhaustivo, planeando todo el curso del proyecto, incluso en los detalles más pequeños. No puede permitirse muchas iteraciones con este tipo de proyecto (también la explosión de bombas puede estar bien, la explosión de presupuesto no lo está), por lo que no hay lugar para la creatividad aquí, debe seguir el plan.

Por otro lado, si has leído un poco, ciertamente has leído sobre metodologías ágiles. Generalmente hay menos documentación y más espacio para que el desarrollador use su creatividad mientras desarrolla una solución al problema que encuentra.

En conclusión, cuanta más experiencia obtenga, mejor, y lo que su instructor le muestre se aplica en alguna parte de la industria. Solo tenga en cuenta que ciertamente hay tantas formas de administrar y diseñar un proyecto como codificarlos. Y encontrarás defensores y críticos para todos ellos. Pruébalos mientras estudias y elige el que más te guste.

Algunas clases de ingeniería de software, como la que tuve, se imparten en un estilo extraño donde 'el fracaso es el éxito', el éxito es una oportunidad desperdiciada para aprender del fracaso, y más es menos y menos es más. Si este es uno de esos, simplemente quédese con las tareas y disfrute de la rareza.

Creo que tu instructor está fuera de contacto. El software comercial rara vez se diseña o documenta hasta ese punto. Es demasiado costoso y la documentación resultante no se puede mantener sin más gastos. En mi opinión, tales prácticas son un legado de los días en que la codificación a menudo se realizaba en lenguaje ensamblador. Habría gastado mejor su tiempo probando prácticas más ágiles: desarrollo basado en pruebas, programación de pares, refactorización continua.

¿El instructor "te dijo mal"?

Creo que sí.

Asignar trabajo aburrido a los trabajadores de propiedad intelectual es un desperdicio. En la escuela, el trabajo aburrido tiene poco o ningún valor pedagógico, excepto tal vez para atraer a los estudiantes al trabajo aburrido. Dichos ejercicios tienen consecuencias negativas, tanto para los estudiantes como para la industria. Los estudiantes se ven perjudicados porque pierden su tiempo. La industria se ve perjudicada porque algunos estudiantes pueden concluir que dicho tedio es necesario y útil. No es ninguno. En treinta años en software, el único trabajo que puedo pensar que fue aburrido y útil fue cambiar las cintas de respaldo. Había robots que podían hacer eso, pero eran prohibitivamente caros.