Estoy planeando trabajar / comenzar en algunos proyectos personales que podrían terminar como mi trabajo diario. Me hizo pensar, ¿en qué dirección debería comenzar?

• Solo prototipo: escriba un código básico que funcione y que me pueda costar toneladas de tiempo optimizar y refactorizar para una fácil expansión.

• Escriba código limpio, optimizado y documentado desde el principio, teniendo en cuenta que si después de algún tiempo no será rentable, se eliminará.

Actualización: La combinación de YAGNI con sunpech y las respuestas de M.Sameer tiene mucho sentido para mí :) gracias a todos por su ayuda.

Hay una tercera opción ... escribir código limpio a través del desarrollo conducido por pruebas para implementar los requisitos que se necesitan hoy porque YAGNI.

La tentación de escribir código que no es necesario en este momento, pero que podría serlo en el futuro, tiene varias desventajas ... Usted no lo va a necesitar :

• El tiempo empleado se toma agregando, probando o mejorando la funcionalidad necesaria.
• Las nuevas funciones se deben depurar, documentar y admitir.
• Cualquier característica nueva impone restricciones sobre lo que se puede hacer en el futuro, por lo que una característica innecesaria ahora puede impedir la implementación de una característica necesaria más adelante.
• Hasta que la característica sea realmente necesaria, es difícil definir completamente lo que debe hacer y probarla. Si la nueva función no se define y prueba correctamente, es posible que no funcione correctamente, incluso si finalmente se necesita.
• Conduce a la hinchazón de código; El software se hace más grande y más complicado. A menos que haya especificaciones y algún tipo de control de revisión, la función puede no ser conocida por los programadores que podrían utilizarla.
• Agregar la nueva función puede sugerir otras funciones nuevas. Si estas nuevas características también se implementan, esto puede dar como resultado un efecto de bola de nieve hacia un movimiento lento.

Como resultado, no solo debe crear un prototipo ... ni debe escribir código limpio, optimizado y documentado desde el principio, teniendo en cuenta que si en algún momento no será rentable, se eliminará.

Escriba el código que necesita ahora sabiendo que podrá satisfacer mejor las necesidades de hoy y de mañana.

como siempre...

Depende

Si está creando prototipos para mitigar un riesgo o exponer un desconocido, solo codifíquelo y espere tirarlo cuando haya terminado

Si está creando prototipos para un refinamiento iterativo, solo codifíquelo y espere modificarlo y refactorizarlo con frecuencia

Si está comenzando a escribir el producto real pero lo llama prototipos para que pueda ser flojo , entonces no lo sea y escríbalo bien la primera vez

Si está creando prototipos, ¿por qué está pensando en código limpio? La idea misma de la creación de prototipos es que está destinada a probar un concepto o idea, y ser desechada después.

Voy a estar en desacuerdo con la mayoría de todos aquí diciendo que si ya está pensando en elegir entre escribir código limpio o hacer algo rápidamente para la creación de prototipos, elija el último. Especialmente cuando estás hablando del desarrollo de la etapa temprana. No digo que nunca escribas código limpio, digo que saques la idea, veas que es la dirección a seguir, luego regresa a limpiarlo, refactoriza.

Como desarrolladores de software, estamos tan atrapados en hacer las cosas bien y limpiar la primera vez, que no nos damos cuenta de que no se trata de código, sino de una solución a un problema .

Pienso en codificar como escribiría un artículo:

Cuando escribimos un artículo, comenzamos en alguna parte, esbozamos ideas, esquemas, etc. No contendrá todos los detalles ni tendrá un aspecto completo; es esencialmente un primer borrador, seguido de un segundo, y así sucesivamente. Mucho será reescrito, reemplazado y / o incluso eliminado en el camino a un papel más refinado y terminado. (Obviamente, esta analogía no va tan lejos como para decir que el código realmente se termina o finaliza como un documento).

Hay dos tipos de prototipos:

• Prototipo evolutivo que sigue evolucionando a través de mejoras y arreglos para convertirse en el producto final.
• Prototipo desechable que existe solo para hacer que la recopilación de requisitos y la retroalimentación del cliente sean más efectivas en las primeras etapas del proyecto y luego se eliminen por completo y el desarrollo del producto final comience desde cero.

Según Capers Jones, los prototipos evolutivos producen productos finales de baja calidad que requerirán mucho más esfuerzo y más tiempo para alcanzar la estabilidad.

Entonces, si está pensando en la creación de prototipos para que el cliente pueda ver algo lo más rápido posible para ayudarlo a obtener una mejor idea y más detalles sobre los requisitos, es mejor ser un prototipo desechable y tener el desarrollo hecho en código limpio más adelante. Si no puede permitirse eso, escriba un código limpio desde el principio y manténgalo con cuidado, pero como han sugerido otros, no optimice en exceso y no agregue elementos hasta que los necesite.

Soy reacio a disculpar la codificación sucia por cualquier motivo. En mi experiencia, las personas que afirman ser rápidas y sucias como excusa para la creación de prototipos tienen esa actitud hacia cualquier código, incluida la producción. Si alguien crea un prototipo desordenado, crea desorden en cualquier código. La creación de prototipos no significa una codificación sucia, significa suposiciones simplificadas para probar los casos de uso más importantes. Es posible que el código no se pruebe formalmente o se ocupe de todos los detalles, pero aún debe estar bien diseñado y bien implementado. La limpieza es un signo de competencia, los programadores competentes sienten disgusto natural hacia el código desordenado, sin importar su propósito.

Escriba código limpio, optimizado y documentado desde el principio. Soy incapaz de hacerlo yo mismo y es un problema real. No soy un programador, pero he trabajado para compañías de desarrollo de software en roles de gestión orientados al cliente, y dado que me dan muchas buenas ideas, ocasionalmente construyo un prototipo para algo. Casi cada vez que ese prototipo fue entregado a un desarrollador que lo "limpió" y lo convirtió en un producto de envío. Cuando revise la fuente, seguirá siendo el 80-90% de mi código basura.

Un colega mío respalda con entusiasmo los prototipos repetidos, con la advertencia de que uno debe tener la disciplina suficiente para tirar cada prototipo y volver a escribir desde cero, y no solo eso, asegúrese de que uno no esté influenciado por los detalles de implementación decididos la última vez , como lo que uno termina haciendo es escribir el mismo prototipo en un estilo trivialmente diferente varias veces. Él sugirió en serio que si realmente estuvieras conectado a algún código brillante que no pudieras descartar, que lo imprimas, elimines el repositorio de control de origen y publiques la copia impresa para ti mismo, desaparecerá el tiempo suficiente para que no pueda infiltrarse en la próxima iteración.

Siempre puede comenzar haciéndolo funcionar (en absoluto), luego revisarlo para que quede limpio, y luego hacerlo rápido / pequeño si tiene sentido desde el punto de vista económico. Comenzaría con algunos experimentos que tiras, y luego vuelvo a crearlos cuando tienes una idea de lo que funciona.

Ambos son buenos. Los dos me gustan. No se contradicen entre sí.

Me gusta hacer prototipos. La creación de prototipos está desarrollando mis habilidades creativas. Estoy probando muchas soluciones posibles. Hacerlo rápido me da la posibilidad de probar muchas formas posibles de resolver un problema.

Me gusta escribir código limpio y bien probado. Desarrolla mis habilidades básicas. Por lo general, elijo uno de los prototipos, y lo mejoro o lo reescribo desde cero.

Pero nunca debe confundir el prototipo con el código de producción. El prototipo nunca debe entrar en producción. Siempre debe estar marcado como prototipo. En el mejor de los casos, realice todos los prototipos en su propia rama.

Tiendo a decir que los extremos son casi siempre malos.

Aconsejo mantener el equilibrio entre limpio, bien documentado y creación de prototipos. Cuando desarrollas para una biblioteca o plataforma con la que no tienes experiencia, voy más en la dirección de creación de prototipos. Eso es especialmente cierto al principio y para plataformas, por ejemplo, Android o contenedores, que lo ponen en su corsé. Eso significa que implementas sus interfaces y te llaman.

Según mi propia experiencia, la mayor parte del código no dura mucho. Dicho esto, ponte en marcha rápidamente implementando tu función. Cuando tarde o temprano (la mayoría de las veces antes) necesite reelaborar / refactorizar su código existente debido a la siguiente característica que arregla especialmente las partes con las que es complicado trabajar. Preste atención para tener pruebas automatizadas adecuadas para hacer posible la refactorización sin problemas. Perteneciente a las plataformas mencionadas anteriormente como Android: a menudo hacen que las pruebas automatizadas no sean tan fáciles debido al acoplamiento estrecho y a la falta de diseño para la prueba. Luego puede elevar su base de pruebas a un nivel superior, por ejemplo, pruebas de integración.

Escribí un artículo que podría dar algunas pistas sobre cómo comenzar: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d