Soy programador con 1 año de experiencia, recientemente me di cuenta de que rara vez inicio un proyecto correctamente (la mayoría de mi proyecto paralelo), normalmente el ciclo del proyecto sigue

1. Comience con algunos casos de uso
2. Comience a codificar
3. Me doy cuenta de algunas cosas que no manejé bien y que no encajan bien en la base de código actual.
4. Reescribe la mayor parte del código

y esto podría pasar algunas veces

Entonces mis preguntas son

1. ¿Es común esta práctica o implica que no soy competente?
2. ¿Cómo puedo mejorar en este aspecto?

El ciclo que describe es normal. La forma de mejorar las cosas no es evitar este ciclo, sino simplificarlo. El primer paso es aceptar que:

1. Es casi imposible saber todo el primer día de un proyecto.
2. Incluso si de alguna manera lo sabes todo, para cuando hayas terminado el proyecto, algo (los requisitos del cliente, el mercado en el que se encuentra, la tecnología con la que estás trabajando, los deseos de sus clientes) habrá cambiado y hecho en menos parte de lo que sabías inválido o incorrecto.

Por lo tanto, es imposible planificar todo por adelantado, e incluso si pudieras, seguir ese plan te llevaría a construir algo imperfecto u obsoleto. Sabiendo esto, integramos el cambio en nuestra planificación. Veamos tus pasos:

1. Comience con algunos casos de uso
2. Comience a codificar
3. Me doy cuenta de algunas cosas que no manejé bien y que no encajan bien en la base de código actual.
4. Reescribe la mayor parte del código

Ese es realmente un gran punto de partida. Así es como lo abordaría:

1. Comience con algunos casos de uso

Bueno. Al decir "casos de uso", que está centrado en lo que el software es para . Al decir "algunos", no estás tratando de descubrirlo todo; te estás apegando a una cantidad manejable de trabajo. Todo lo que agregaría aquí es priorizarlos. Con su cliente o usuario final, calcule la respuesta a esta pregunta:

¿Cuál es el software más pequeño y simple que podría ofrecerle para mejorar su situación?

Este es su producto mínimo viable : cualquier cosa más pequeña que esto no es útil para su usuario, pero cualquier cosa más grande corre el riesgo de planificar demasiado pronto. Obtenga suficiente información para construir esto, luego continúe. Tenga en cuenta que no sabrá todo en este momento.

2. Comience a codificar.

Excelente. Te pones a trabajar lo antes posible. Hasta que haya escrito el código, sus clientes no han recibido ningún beneficio. Cuanto más tiempo dedique a planificar, más tiempo pasará el cliente esperando sin amortización.

Aquí, agregaría un recordatorio para escribir un buen código. Recuerde y siga los Principios SÓLIDOS , escriba pruebas unitarias decentes sobre cualquier cosa frágil o compleja, tome notas sobre cualquier cosa que pueda olvidar o que pueda causar problemas más adelante. Desea estructurar su código para que el cambio no cause problemas. Para hacer esto, cada vez que tomas la decisión de construir algo de esta manera, en lugar de hacerlo de esa manera, estructuras tu código para que esa decisión afecte la menor cantidad de código posible. En general, una buena forma de hacerlo es separar su código:

• use componentes simples y discretos (dependiendo de su idioma y situación, este componente puede ser una función, una clase, un ensamblaje, un módulo, un servicio, etc. También puede tener un componente grande que está construido a partir de otros más pequeños, como una clase con muchas funciones, o un ensamblaje con muchas clases).
• cada componente realiza un trabajo o trabajos relacionados con una cosa
• los cambios en la forma en que un componente realiza su funcionamiento interno no deberían causar que otros componentes tengan que cambiar
• componentes deben ser dadas las cosas que usan o dependen de, en lugar de ir a buscar o crear ellos
• los componentes deben proporcionar información a otros componentes y pedirles que hagan el trabajo, en lugar de buscar información y hacer el trabajo ellos mismos
• los componentes no deben acceder, usar o depender del funcionamiento interno de otros componentes, solo usar sus funciones de acceso público

Al hacer esto, está aislando los efectos de un cambio para que, en la mayoría de los casos, pueda solucionar un problema en un lugar y el resto del código no se dé cuenta.

3. Encuentra problemas o deficiencias en el diseño.

Esto va a pasar. Es inevitable. Acepta esto. Cuando encuentre uno de estos problemas, decida qué tipo de problema es.

Algunos problemas son problemas en su código o diseño que dificultan hacer lo que el software debería hacer. Para estos problemas, debe regresar y modificar su diseño para solucionar el problema.

Algunos problemas son causados ​​por no tener suficiente información o por tener algo en lo que no había pensado antes. Para estos problemas, debe volver a su usuario o cliente y preguntarles cómo les gustaría abordar el problema. Cuando tenga la respuesta, vaya y actualice su diseño para manejarlo.

En ambos casos, debe prestar atención a qué partes de su código tuvieron que cambiar, y a medida que escribe más código, debe pensar qué partes pueden cambiar en el futuro. Esto facilita la tarea de determinar qué partes pueden estar demasiado interconectadas y qué partes deben estar más aisladas.

4. Reescribe parte del código

Una vez que haya identificado cómo necesita cambiar el código, puede ir y hacer el cambio. Si ha estructurado bien su código, esto generalmente implicará cambiar solo un componente, pero en algunos casos también podría incluir agregar algunos componentes. Si descubre que tiene que cambiar muchas cosas en muchos lugares, piense por qué es así. ¿Podría agregar un componente que mantenga todo este código dentro de sí mismo y luego hacer que todos estos lugares solo usen ese componente? Si puede, hágalo, y la próxima vez que tenga que cambiar esta función, podrá hacerlo en un solo lugar.

5. Prueba

Una causa común de problemas en el software es no conocer los requisitos lo suficientemente bien. Esto a menudo no es culpa de los desarrolladores; a menudo, el usuario tampoco está seguro de lo que necesita. La forma más fácil de resolver esto es revertir la pregunta. En lugar de preguntar "¿qué necesitas que haga el software?", Cada vez que sigas estos pasos, dale al usuario lo que has construido hasta ahora y pregúntale "Construí esto, ¿hace lo que necesitas?". Si dicen que sí, entonces has creado algo que resuelve su problema, ¡y puedes dejar de trabajar! Si dicen que no, podrán decirle en términos más específicos qué hay de malo en su software, y usted puede mejorar esa cosa específica y volver para obtener más comentarios.

6. Aprende

A medida que avanza en este ciclo, preste atención a los problemas que está encontrando y los cambios que está realizando. ¿Hay patrones? Puedes mejorar

Algunos ejemplos:

• Si sigue descubriendo que ha pasado por alto el punto de vista de cierto usuario, ¿podría lograr que ese usuario se involucre más en la fase de diseño?
• Si sigue teniendo que cambiar las cosas para ser compatible con una tecnología, ¿podría construir algo para interactuar entre su código y esa tecnología para que solo tenga que cambiar la interfaz?
• Si el usuario sigue cambiando de opinión sobre las palabras, los colores, las imágenes u otras cosas en la interfaz de usuario, ¿podría crear un componente que proporcione al resto de la aplicación esos para que estén todos en un solo lugar?
• Si encuentra que muchos de sus cambios están en el mismo componente, ¿está seguro de que ese componente se queda en un solo trabajo? ¿Podrías dividirlo en algunas piezas más pequeñas? ¿Puedes cambiar este componente sin tener que tocar ningún otro?

Ser ágil

Lo que está avanzando hacia aquí es un estilo de trabajo conocido como Agile. Agile no es una metodología, es una familia de metodologías que incorporan una gran cantidad de cosas (Scrum, XP, Kanban, por nombrar algunas), pero lo que todos tienen en común es la idea de que las cosas cambian, y como desarrolladores de software, debe planear adaptarse a los cambios en lugar de evitarlos o ignorarlos. Algunos de sus principios básicos, en particular los que son relevantes para su situación, son los siguientes:

• No planifique con más anticipación de lo que puede predecir con confianza.
• Tenga en cuenta que las cosas cambien a medida que avanza
• En lugar de construir algo grande de una vez, construya algo pequeño y luego increméntelo gradualmente
• Mantenga al usuario final involucrado en el proceso y obtenga comentarios rápidos y regulares
• Examina tu propio trabajo y progreso, y aprende de tus errores

Esto es normal.

Puede tomar uno de dos enfoques:

1. Bienvenido Cambio

Si supone que se equivocará, debe crear una base de código que esté abierta a cambios. Principalmente, esto implica tomar el código al final de un libro sobre refactorización y construir su código de esa manera desde el principio (descomponibilidad, buena cobertura de prueba, ...).

2. Evitar el cambio

En este caso, debe hacer un BDUF (diseño grande por adelantado). Tienes que hacer muchos prototipos en papel, discutir ideas con usuarios potenciales o tú mismo, esquivando el caucho, probando varias cosas en prototipos o maquetas, escribiendo una especificación completa y solo una vez que sientes que has logrado la solución, finalmente finalmente puede comenzar a codificar. Hacer todo lo que realmente no elimina el cambio inesperado, solo lo reduce un poco, el primer año más o menos. Entonces, aún tiene que construir su código para que sea fácil de cambiar.

Entonces, básicamente, el cambio es un hecho. Suponga que sucederá. Construye tu código en consecuencia. En la práctica, puede encontrar un punto medio entre los enfoques de diseño inicial y codificación de inicio que evita el cambio gratuito sin atascarse en la parálisis del análisis. Solo se necesita un poco de experiencia.

El desarrollo de software se ha descrito como una serie de problemas inherentemente "perversos" .

Horst Rittel y Melvin Webber definieron un problema "perverso" como uno que podría definirse claramente solo resolviéndolo o resolviendo parte de él *. Esta paradoja implica, esencialmente, que debe "resolver" el problema una vez para definirlo claramente y luego resolverlo nuevamente para crear una solución que funcione. Este proceso ha sido la maternidad y el pastel de manzana en el desarrollo de software durante décadas.

Esto describe perfectamente el problema que enfrenta. Básicamente, lo que hacemos es difícil . Si hay una parte que podría describirse como "rutina", con el tiempo la aislamos y automatizamos. Entonces, todo lo que queda es lo nuevo o lo difícil.

Hay otras formas de superar problemas como este; Algunas personas pasan mucho tiempo considerando los problemas de antemano y no escriben código hasta que se sienten cómodos con el diseño. Otros buscan orientación de personas que ya se han ocupado de problemas como este, ya sea a través de la programación de pares o solo en sitios como este.

Pero ciertamente su enfoque no sugiere incompetencia. El único problema podría ser si, cuando vuelves, no estás reflexionando sobre por qué elegiste hacer las cosas de esta manera para empezar, y si podrías haber podido ver la "mejor" forma sin el volver a escribir.

En muchos casos, hubo, y puede incorporarlo en su proceso de diseño para la próxima vez. En algunos casos, no existía (o el costo habría sido tan alto o más alto que el costo de su otro enfoque), y puede dejar pasar su preocupación.

1. Sí, esto es común, excepto quizás por la parte "reescribir la mayor parte del código". Nunca obtendrá todos los requisitos desde el principio, por lo que es importante lidiar bien con el cambio. De eso se trata el concepto de "mantenibilidad de código". Por supuesto, también ayuda dedicar más tiempo a cumplir con los requisitos y el diseño correctos.
2. Primero, piense en los cambios que se requirieron en proyectos anteriores y cómo podría haberlos previsto o preparado para ellos mejor. Al comienzo de un proyecto, piense más en los detalles de los casos de uso. Realice un diseño abstracto (cuáles son los componentes principales del código y cómo se comunican, cuáles son sus API) antes de comenzar a implementar. Lo más importante, trate de mantener el código tan simple y fácil de cambiar como sea posible, lea conceptos como SOLID, DRY, KISS y YAGNI.

¿Es común esta práctica o implica que no soy competente?

Esos no son mutuamente excluyentes. El patrón podría ser común y aún podría ser incompetente. Su competencia se puede determinar midiendo su desempeño con sus objetivos. ¿Estás cumpliendo tus objetivos?

¿Es común este patrón? Por desgracia sí. Muchas personas se sumergen en proyectos sin una idea clara de qué problema están resolviendo, cómo diseñarán una solución correcta y qué métricas constituirán un éxito.

¿Cómo puedo mejorar en este aspecto?

Si decidiste ir a algún lugar y comenzaste a caminar, y luego descubriste un día en el que lo que realmente necesitabas hacer era transportar un elefante de Ciudad del Cabo a la ciudad de Nueva York, todo el tiempo que pasaste caminando fue desperdiciado. Averigua lo que estás haciendo antes de comenzar a hacerlo.

Una vez que comience a hacerlo, considere: ¿cómo se ve el código que no tiene que reescribirse ? Ese código:

• Hace una cosa útil.
• Lo hace correctamente
• Lo hace con suficiente rendimiento.

Entonces: cuanto más código escriba donde ese código haga una cosa útil, correctamente, con un buen rendimiento, menos código tendrá que volver a escribir.

Creo que es seguro decir que no estás tan lejos de una mejor manera de trabajar, y que no eres el único en este barco.

Lo que creo que te estás perdiendo es que, aunque determinas lo que quieres, no te detienes para hacer el mismo proceso de cómo lo harás.

Este paso de detenerse y pensar en cómo abordar el problema en general se llama diseño, es el paso que le hace pasar un tiempo desarrollando la estructura o arquitectura del sistema para que todo lo que haga de ellos contribuya a la solución final, como encajar piezas en un rompecabezas una vez que haya resuelto los bordes.

Mucha gente no hace este paso, pero cuando comencé a codificar era obligatorio. Creo que la diferencia está en las herramientas de desarrollo, mientras que comencé con un editor de texto, ahora tienes todo tipo de características que te permiten saltar y escribir.

Por lo tanto, tómese un tiempo para descubrir las áreas amplias, los componentes y la interoperabilidad entre ellos, y defina los objetos que comprenderán su solución antes de comenzar a codificar. No tiene que estar en detalles inmensos, y entender que no lo entenderás perfectamente desde el principio, por lo que evolucionará con el tiempo, pero lo que esto hace es ayudarte a evitar que pierdas el esfuerzo revisando cosas que no deberían No necesita ser cambiado mucho.

Ya tiene algunas respuestas excelentes, pero su pregunta le recuerda algunas cosas que pensé que trataría de mencionar.

1. Como notó encontrarse con cambios en el futuro, le sugiero que piense en cómo las cosas afectaron su proyecto y cómo podría haber minimizado el impacto con las opciones de diseño / codificación y al mismo tiempo generar un mapa mental de dónde las personas a menudo hacen cambios tardíos. Con experiencia, puede anticipar y codificar con cierta flexibilidad las cosas que sabe que serán importantes, aunque existe un desacuerdo sobre este concepto en la industria, ya que algunos contrarrestarán su esfuerzo de inversión en un área no solicitada específicamente, per se .

2. En el frente de las pruebas, lanzar un prototipo para la parte interesada de su proyecto puede ser una excelente manera de refinar los requisitos. Sin embargo, durante el desarrollo puede buscar formas de "ver" lo que está sucediendo en su código sin causar mucho desorden o complejidad. Ciertamente, hay herramientas disponibles para ayudar, pero también puede hacer mucho sin ellas si lo desea. De cualquier manera, salir del código para ver lo que está sucediendo con ojo crítico puede proporcionar varios tipos de información.

3. Busca actividades comunes. Te encontrarás manejando los mismos problemas una y otra vez. Después de un tiempo, debe descubrir las deficiencias o compensaciones de varias opciones y concentrarse en una metodología que lo ayude a evitarlas. Por supuesto, si está trabajando en un marco, algunos de estos problemas pueden estar envueltos en las herramientas que ya está utilizando.

4. Si está trabajando dentro de un marco, dedique tiempo, si puede, a considerar cómo hacer las cosas desde cero. Por ejemplo, puede armar fácilmente un mensaje de solicitud, abrir un socket y emitir una solicitud GET o POST manualmente. Si lo desea, puede analizar manualmente los mensajes XML. Hagas lo que hagas, las preguntas que generes y las respuestas que encuentres aumentarán tus habilidades. Por supuesto, puede elegir qué tipos de problemas subyacentes son importantes o de interés. Consideraría este desarrollo personal y no esperaría pasar mucho tiempo aquí.

5. Las balas de plata, las metodologías y los problemas de alto factor de ruido están en todas partes. Básicamente, las realidades subyacentes de trabajar con información no están cambiando tan rápidamente. Tome nota de si el marco, el conjunto de herramientas o la metodología implementada es una ayuda o un obstáculo en diversas situaciones. En grandes empresas, he visto muchas metodologías intentadas, aunque la empresa no pudo ejecutarlas de manera efectiva. Al igual que los marcos, las metodologías no son una forma segura de funcionar a un alto nivel, incluso si se basan en las prácticas de algunos equipos altamente funcionales.

Es difícil reducir la experiencia y tenerla accesible. Supongo que una forma breve de expresar todo esto es mantener los ojos abiertos, pensar en lo que ves y nunca dejar de aprender.

Me gustaría agregar algunos consejos

1) Personalmente, me pareció increíblemente útil comenzar con la visualización de cosas. Dibuja cuadros, flechas, líneas ... No importa el lenguaje de modelado que uses. En primer lugar, lo estás haciendo POR TI MISMO. Debería ayudar a tu flujo de pensamientos.

2) Encuentre un compañero de entrenamiento : tome un café y el rotafolio / diagrama, etc. de arriba y vaya a la ciudad. En mi humilde opinión, es aún mejor si no tienes habilidades tecnológicas equivalentes. Rebota de un lado a otro las ideas para implementar el caso de uso. Encuentras un callejón sin salida o dos, encuentras una solución. Con una mente ágil, a menudo pasa menos tiempo en esta etapa que si escribes código, no funciona y tienes que matar trozos de tu trabajo o rehacerlos

3) Encuentre un jefe que pueda entender que probablemente nunca haya terminado de mejorar su software escrito. Si siempre conecta las nuevas características / requisitos que se dejan en su escritorio y nunca se preocupa por su software, le devolverá los errores, la falta de amabilidad en el mantenimiento y una gran cantidad de vello en los próximos años. Obtenga este tiempo de mantenimiento de software / presupuesto asignado! Mi buen número mágico es aproximadamente el 20% del tiempo necesario para desarrollar el software que se necesita por año para mantenerlo en forma durante el transcurso de su vida útil.

4) ¡Este proceso de aprendizaje incremental nunca se detiene (y no debería)! Mirarás hacia atrás en 10 años y sonreirás.

Espero que esto ayude un poco y buena suerte!