¿La mejor manera de descomponer el código abrumador en partes manejables?

13

Una vez que alcanzan un cierto nivel de complejidad, me siento continuamente abrumado por los grandes proyectos. Una vez que alcanzo un cierto punto en un proyecto, mi progreso se ralentiza y me encuentro constantemente repitiendo 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 objetos más pequeños y manejables. Es probable que esta debilidad también haya provocado que preste demasiada atención a diseñar 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. ¿Qué más puedo hacer?

    
pregunta pup 08.06.2011 - 21:52

7 respuestas

13

deja de pensar en el código

comience 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

    
respondido por el Steven A. Lowe 08.06.2011 - 22:52
9

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

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

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

Concéntrese en cohesión funcional a través de:

  

Principio de responsabilidad única   que cada objeto debe tener una sola   responsabilidad, y que   la responsabilidad debe ser enteramente   encapsulado por la clase. Todo su   los servicios deben estar estrechamente alineados   con esa responsabilidad.

Si Google it entre los resultados de la primera página, encontrará dos excelentes recursos:

  • " Principio de Responsabilidad Única " por Robert C. Martin (febrero / 2002): Este principio trata la necesidad de colocar cosas que cambian por diferentes motivos en diferentes clases.
  • " Curly's Law: Do One Thing "por Jeff Atwood (marzo de 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?

  

Cohesion es una medida de cómo   fuertemente relacionado o enfocado al   responsabilidades de un solo módulo   son. Aplicado a objetos orientados.   Programación, si los métodos que sirven.   La clase dada tiende a ser similar en   Muchos aspectos, entonces se dice la clase.   Tener alta cohesión. en un   sistema altamente cohesivo, codigo   legibilidad y la probabilidad de   La reutilización aumenta, mientras que la complejidad.   se mantiene manejable.

     

La cohesión disminuye si :     - Las funcionalidades integradas en una clase, accedidas 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 grano grueso o no relacionados   datos.

     

Las desventajas de la baja cohesión (o "cohesión débil") son:     - Mayor dificultad en la comprensión de los módulos.     - Mayor dificultad para mantener un sistema, porque lógico.   Los cambios en el dominio afectan a múltiples   Módulos, y porque los cambios en uno.   módulo requiere cambios en relacionados   módulos     - Mayor dificultad para reutilizar un módulo porque la mayoría de las aplicaciones no   necesita el conjunto aleatorio de operaciones   proporcionado por un módulo.

Si tiene alguna pregunta, hágamelo saber.

    
respondido por el blunders 08.06.2011 - 22:14
1

Descomponer 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 mayor prioridad y avance como si fuera una simple corrección de errores, no un gran proyecto. Es cierto que terminará con una refactorización más adelante, pero al menos estará avanzando.

    
respondido por el bethlakshmi 08.06.2011 - 22:02
1

Por mi experiencia, has respondido tu propia pregunta con el comentario sobre TDD. Para mí, a menudo sentí lo mismo que tú, el éxito rápido inicial se convirtió rápidamente en problemas menores una vez que el sistema alcanzó cierto tamaño. Encontré que con TDD me ayudó porque podía abordar cada parte del sistema como partes pequeñas, sabiendo que el resto del sistema debería o debería continuar funcionando cuando lo dejó. También creo que, con TDD, ayuda a garantizar que su sistema se divide claramente en partes más pequeñas que se pueden probar de forma independiente.

    
respondido por el Paul Hadfield 08.06.2011 - 22:03
0

Algunas personas son buenas para diseñar programas modulares, fácilmente comprensibles, pero la mayoría de los programadores carecen de esta facilidad, 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 lotes de experiencia. Pero ni siquiera estoy seguro de eso.

La conclusión es que la mayoría de los programadores tendrán dificultades para superar lo mediocre, algunos pocos lograrán estar bien (que es donde yo me ubicaría y tal vez el 50% de los programadores profesionales en (digamos) la industria del IB), y una minoría muy pequeña será excelente. Debo decir que nunca en mi larga carrera he conocido uno de estos excelentes :-)

    
respondido por el Neil Butterworth 08.06.2011 - 22:16
0

Creo que mucha gente intenta sobre-diseñar soluciones. Toman el enfoque de "Adán y Eva" cuando solo un poco más Una práctica simplificaría mucho las cosas.

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

Muchos programadores, en mi opinión, no entienden esto y No hay ningún libro que yo sepa que aclare esto.

Otra cosa que ciertamente ayuda es TDD, que te permite entienda "cómo" utilizará la clase en la práctica y puede en muchos casos salvan el día, porque muestra problemas / limitaciones eventuales temprano en el día.

Por último, otra cosa MUY importante que buscaría si fuera usted son los patrones de diseño. Los patrones de diseño son cómo las personas más inteligentes que usted o yo resuelven los problemas de programación. La idea detrás de los patrones, ¿adivinen qué ?, es que no deben usarse como libros de cocina, Recetas que acaba de cerrar allí, pero cuidadosamente y entendiendo su dominio de la aplicación en primer lugar.

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

Una biblioteca de patrones de buen diseño diseñada alrededor de sus propias necesidades, será invaluable. Veamos un ejemplo muy simple para poner las cosas en contexto:

imagina que tienes un formulario donde, cuando se presiona un botón, se deben actualizar otros formularios sí mismos. Este es un patrón típico de "observador". Tienes un tema y varios Los observadores, que se inscriben con el sujeto. ¿Por qué necesitas implementar una interfaz? Simplemente puede agregar los métodos, o mejor aún, use una interfaz para los observadores y una lista genérica para el tema. Ahora tienes lo mejor de ambos mundos: independencia para los observadores y no cosas confusas sobre el tema.

Espero que tenga sentido para ti!

Andrea

    
respondido por el Andrea Raimondi 08.06.2011 - 22:30
0

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

Algunos pasos simples que me han ayudado

  • Use el analizador de similitudes (como Simian) para encontrar bloques de código duplicados en la base del código. Muchos códigos duplicados significan menos abstracción.
  • Supervise 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.
  • Las pruebas de unidad / integración son obligatorias, le da la confianza de refactorizar y también actúa como una especificación.
  • Una retrospectiva quincenal con la empresa para comprender si los términos técnicos / de negocios / de dominio que utilizan se reflejan en los nombres de las clases. Esto ayuda a comprender y obtener nombres para colecciones de primera clase en lugar de representar conjuntos y listas simples. Algunas abstracciones en las que nunca pensamos también surgirán cuando nos sentemos con la gente de negocios.
respondido por el Vinod R 09.06.2011 - 07:57