Continuamente me siento abrumado por grandes proyectos, una vez que alcanzan un cierto nivel de complejidad. Una vez que llego a un cierto punto en un proyecto, mi progreso se ralentiza y me encuentro constantemente volviendo sobre mis pasos y resolviendo todo tipo de confusión.

Me he vuelto muy bueno refactorizando debido a esta debilidad mía. Y siempre trato de descomponer mis objetos en otros más pequeños y manejables. Esta debilidad también probablemente me ha llevado a prestar demasiada atención al diseño de las cosas correctamente.

Sé que si puedo dividir mis problemas en otros más pequeños, podré lograrlo sin problemas. Una estrategia que viene a la mente es el desarrollo basado en pruebas. ¿Que más puedo hacer?

deja de pensar en el código

empiece a pensar en capas, características, módulos, servicios y otras abstracciones de nivel superior

te estás abrumando porque estás pensando en un nivel demasiado bajo

Hacer lo complejo simple es fácil ; espera, piensa que es al revés.

Todos luchan con esto, no existe una solución directa que tenga una eficacia extrema.

Como no mencionó esto en sus preguntas, mi sugerencia sería:

Centrarse en la cohesión funcional a través de:

El principio de responsabilidad única establece que cada objeto debe tener una responsabilidad única, y que la responsabilidad debe estar completamente encapsulada por la clase. Todos sus servicios deben estar estrechamente alineados con esa responsabilidad.

Si lo buscas en Google entre los resultados de la primera página, encontrarás dos excelentes recursos:

• " Principio de responsabilidad única " de Robert C. Martin (febrero / 2002): Este principio analiza la necesidad de colocar cosas que cambian por diferentes razones en diferentes clases.
• " Ley de Curly: hacer una cosa " por Jeff Atwood (Mar / 2007): El Principio de Responsabilidad Única dice que una clase debe tener una, y solo una, razón para cambiar.

¿Qué es la cohesión en informática?

Cohesión es una medida de cuán fuertemente relacionadas o enfocadas están las responsabilidades de un solo módulo. Según se aplica a la programación orientada a objetos, si los métodos que sirven a la clase dada tienden a ser similares en muchos aspectos, entonces se dice que la clase tiene una alta cohesión. En un sistema altamente cohesivo, aumenta la legibilidad del código y la probabilidad de reutilización, mientras que la complejidad se mantiene manejable.

La cohesión disminuye si : - Las funcionalidades integradas en una clase, a las que se accede a través de sus métodos, tienen poco en común. - Los métodos llevan a cabo muchas actividades variadas, a menudo utilizando conjuntos de datos de grano grueso o no relacionados.

Las desventajas de la baja cohesión (o “cohesión débil”) son: - Mayor dificultad para comprender los módulos. - Mayor dificultad para mantener un sistema, porque los cambios lógicos en el dominio afectan a múltiples módulos y porque los cambios en un módulo requieren cambios en los módulos relacionados. - Mayor dificultad para reutilizar un módulo porque la mayoría de las aplicaciones no necesitarán el conjunto aleatorio de operaciones proporcionadas por un módulo.

Si usted tiene alguna pregunta, hágamelo saber.

Descomponga las características en el elemento más pequeño posible. Por ejemplo, un solo campo en un formulario. Elija el más arriesgado o de alta prioridad y avance como si fuera una simple corrección de errores, no un gran proyecto. Es cierto que terminarás refactorizando más adelante, pero al menos seguirás adelante.

Según mi experiencia, ha respondido su propia pregunta con el comentario sobre TDD. Para mí, a menudo sentí lo mismo que usted, el éxito rápido y rápido se convirtió en un obstáculo en los detalles menores una vez que el sistema alcanzó un cierto tamaño. Descubrí que con TDD me ayudó porque podía abordar cada parte del sistema como pequeños fragmentos, sabiendo que el resto del sistema debería o debería continuar funcionando como lo dejó. También creo que con TDD ayuda a garantizar que su sistema esté claramente dividido en trozos más pequeños que se pueden probar de forma independiente.

Algunas personas son buenas para diseñar programas modulares, fácilmente comprensibles, pero la mayoría de los programadores carecen de esta instalación, en mayor o menor medida. No conozco ningún libro, procedimiento o práctica que pueda convertir a uno de los primeros programadores en el segundo, excepto posiblemente por mucha experiencia. Pero ni siquiera estoy seguro de eso.

La conclusión es que la mayoría de los programadores tendrán dificultades para elevarse por encima de los mediocres, algunos pocos lograrán estar bien (que es donde me ubicaría yo mismo y quizás el 50% de los programadores profesionales en (digamos) la industria del IB), y muy La pequeña minoría será excelente. Debo decir que nunca en mi larga carrera conocí a uno de estos excelentes :-)

Creo que mucha gente trata de diseñar soluciones en exceso. Adoptan el enfoque de "Adán y Eva" cuando un poco más práctico simplificaría mucho las cosas.

Las clases especializadas no son malas, son la consecuencia natural del diseño de software de sonido.

Muchos programadores, en mi opinión, no entienden esto y no hay ningún libro que conozca que lo deje claro.

Otra cosa que sin duda ayuda es TDD, que le permite comprender "cómo" utilizará la clase en la práctica y, en muchos casos, puede salvar el día, ya que muestra posibles problemas / limitaciones al principio del día.

Por último, otra cosa MUY importante que buscaría si fuera usted es el diseño de patrones. Los patrones de diseño son cómo las personas más inteligentes que tú o yo resolvemos problemas de programación. La idea detrás de los patrones, ¿adivina qué ?, es que no se deben usar como libros de cocina, recetas que simplemente se cierran allí, sino que reflexionan y comprenden el dominio de su aplicación en primer lugar.

Un uso racional del patrón reducirá en gran medida la cantidad de detalles que debe administrar.

Una buena biblioteca de patrones de diseño diseñada para satisfacer sus propias necesidades resultará invaluable. Veamos un ejemplo muy simple solo para poner las cosas en contexto:

imagine que tiene un formulario donde, cuando se presiona un botón, otros formularios tienen que actualizarse. Este es un patrón típico de "observador". Tienes un sujeto y varios observadores, que se registran con el sujeto. ¿Por qué necesitas implementar una interfaz? Simplemente puede agregar los métodos, o mejor aún, usar una interfaz para los observadores y una lista genérica para el tema. Ahora obtuviste lo mejor de ambos mundos: independencia para los observadores y nada de chismes sobre el tema.

Espero que tenga sentido para ti!

Andrea

El problema de la velocidad de desarrollo y la legibilidad puede surgir cuando pasamos por alto la necesidad de abstracción. En algunas de las grandes bases de código que he trabajado, el enemigo más común fue la innumerable cantidad de clases especializadas que tienen funcionalidades muy similares que hacen que el código se hinche. Si damos un paso atrás y entendemos los requisitos como un todo, no como partes de la aplicación, entonces se nos ocurrirán muchas abstracciones.

Algunos pasos simples que me han ayudado

• Use el analizador de similitud (como Simian) para encontrar bloques de código duplicados en la base de código. Un montón de código duplicado significa menos abstracción.
• Monitoree el tamaño de las clases y los métodos, las clases y los métodos grandes significan que pocos servicios o controladores se convierten en dioses.
• Hacer que las pruebas de unidad / integración sean obligatorias, le da la confianza para refactorizar y también actúa como una especificación.
• Retrospectiva quincenal con la empresa para comprender si los términos técnicos / comerciales / de dominio que utilizan se reflejan en los nombres de clase. Esto ayuda a comprender y obtener nombres para colecciones de primera clase en lugar de representarlos como conjuntos y listas simples. Algunas abstracciones en las que nunca pensamos también aparecerán cuando nos sentemos con la gente de negocios.