Para escribir código bien diseñado de manera eficiente, ¿qué debe hacer antes de comenzar a codificar? ¿Qué parte de la implementación decide de antemano?

Answer 1

Depende de qué tan grande sea el programa. Para un proyecto grande, pasaré mucho tiempo escribiendo diagramas en pizarras, hablando con mis compañeros de trabajo e iterando sobre documentos de diseño. El punto aquí no es hacer todo bien, el objetivo es cometer errores iniciales a bajo precio. Especialmente pasaremos mucho tiempo averiguando cuáles deberían ser las salidas de los módulos clave y cuáles son las interfaces entre ellos.

Después de eso, generalmente escribiré las firmas de tipo de todas las funciones involucradas, luego desarrollaré los tipos mismos. Esto también implicará mucha iteración, ya que descubro qué partes del plan de alto nivel no funcionan del todo.

Luego implementaré las partes de mayor riesgo del sistema, por ejemplo, partes donde estoy usando tecnologías no probadas, probando sobre la marcha. Por lo general, pruebo después de escribir el código en lugar de antes, pero YMMV. Cada vez que las iteraciones son lentas, generalmente me tomaré un tiempo para hacerlas más rápidas.

Una vez que se implementen las partes de mayor riesgo, intentaré configurar un prototipo de extremo a extremo lo más rápido posible (para descubrir otros problemas), y luego solucionar esos problemas y escalarlo.

Realmente nunca dejo de refactorizar, eso es solo parte del proceso. Pero trato de hacer mucho antes de escribir el código.

Answer 2

Mi proceso de pensamiento es algo como esto:

1. ¿Sé exactamente lo que tiene que hacer este programa y entiendo completamente el entorno operativo? En caso afirmativo, pase a 8
2. Bien … somos ágiles. ¿Alguien está dispuesto a decirme algo sobre lo que piensan que tiene que hacer este programa y el entorno operativo en el que podría ejecutarse? En caso afirmativo, pase a 4
3. Pregunta por requisitos y goto 1
4. Revisa los requisitos sueltos; son razonables? Si es así, vaya a 6
5. Negocie los requisitos, por ejemplo, “Puedo hacer esto por la mitad del costo y cubrir el 90% de sus casos de uso” o “Hay demasiadas funciones aquí. ¿Puede especificar las funciones MVP, R2 y R3?”
6. Construir una aproximación del producto; centrarse en la funcionalidad básica, no en la calidad; muéstresela a la persona que le dio los requisitos. ¿Lo aman? Si no, acepta sus comentarios y pasa a 6
7. Ellos lo aman. Lo que he construido no es el producto, es una especificación ejecutable para el producto. Ahora construya una versión lista para producción y envíela.
8. Bien … somos una cascada. Diseñe las fases del proyecto con algo de relleno. Una de las fases es escribir una especificación técnica detallada, otra es realizar un diseño formal estructurado u orientado a objetos. Cuando terminen, sé exactamente qué construir y cómo. Ahora construya una versión lista para producción y envíela.

No hay nada de malo en un enfoque basado en borradores y refactorización. La alternativa es hacer especificaciones formales y diseños formales, y luego codificarlos.

Answer 3

Le llevará alrededor de 10 años de experiencia en desarrollo profesional antes de que pueda escribir software complicado correctamente la primera vez.

La refactorización total en medio de un esfuerzo de desarrollo es una marca de alto potencial para un ingeniero de nivel de entrada. Significa que estás pensando críticamente en lo que estás haciendo.

Answer 4

Probablemente refactorice mucho porque usa la descomposición funcional como paradigma de diseño para representar su problema o sistema en código. Uno de los problemas con la descomposición funcional conocida durante décadas, es la necesidad de reorganizar constantemente la jerarquía a medida que cambian los requisitos y se descubren nuevos.

Considere aprender y usar otro paradigma de diseño cuando sea apropiado.

Answer 5

Si cree que el proyecto será complejo, un buen punto de partida es escribir un documento de diseño que describa la estructura de alto nivel: módulos principales ( por ejemplo, clases) del programa, las responsabilidades de cada módulo y las interfaces a lo largo qué módulos se comunican con otros ( p. ej., métodos públicos). El documento de diseño puede ser revisado por un líder tecnológico u otro miembro de alto rango que pueda usar su experiencia para sugerir mejoras. Una vez que tenga una versión con la que todos estén contentos, puede comenzar la implementación.

Por supuesto, a veces, tanto usted como su líder tecnológico pueden no darse cuenta de lo complejo que será el proyecto, y tal vez no escribirán un documento de diseño. Oh bueno, solo tendrás que refactorizar. Sucede. No es nada de lo que avergonzarse.

Answer 6

La refactorización es una parte normal y saludable del desarrollo de software.

¿Qué parte de la implementación decido antes de escribirla?

¿De una función de software? Básicamente todo. Del software en su conjunto, probablemente solo los huesos del mismo, y desarrollarlo a medida que avanzo.

La realidad es que el software puede necesitar ser rediseñado, rediseñado, a lo largo del desarrollo, especialmente las cosas de la interfaz de usuario, a veces las cosas simplemente no se sienten bien, un elemento de la interfaz de usuario puede parecer torpe y hay que volver a pensar eso.

Soy un gran defensor de solo escribir código, puede ayudar a enderezar una idea en su cabeza, ayudarlo a darle sentido, puede parecer ineficiente, pero creo que en realidad puede ser más eficiente, puede acelerar su comprensión de un problema y conducen a un resultado más rápido que la “planificación” sola.

Answer 7

1. Define el problema
2. Diseña la solución
3. Prueba la solución
4. Integra la solución
5. Optimizar la solución
6. Vaya al # 3 si es necesario
7. Comience a escribir código

Answer 8

Antes de comenzar a escribir cualquier código, comienzo con un diagrama (Petri Net) de la lógica de la aplicación que estoy creando. Para los prototipos, habría decidido gran parte de los detalles de implementación antes de comenzar a escribir código también.