¿Cómo paso de poder escribir código a ser un buen desarrollador?

Estoy frustrado por la falta de explicaciones concretas sobre cómo pasar de poder escribir (bash, awk) y escribir aplicaciones simples (c, php, python) para diseñar y desarrollar software más grande y complicado. Parece que por un lado hay libros de lenguaje de programación y por otro lado están los libros de ingeniería de software / gestión de proyectos diseñados para equipos de programadores.

He leído muchos de los dos. He leído los clásicos de XP / Agile y tengo una comprensión teórica decente del proceso de desarrollo de software. Me gusta leer el código de otras personas y puedo seguirlo bastante bien. Pero cuando tengo una idea para un proyecto o quiero pasar de "aquí está el problema / necesidad" a "aquí está la solución", mi mente se queda en blanco y no sé por dónde empezar.

¿Acabo de hackearlo? ¿Hay flujos de trabajo estructurados para desarrolladores individuales que no trabajan en equipo o para una gran casa de software? Realmente no tengo ningún deseo de obtener un PMP o trabajar para una compañía de software. Solo estoy buscando un flujo de trabajo efectivo, eficiente y práctico.

En mi opinión, te conviertes en un buen desarrollador al tener experiencia y trabajar con múltiples formas de hacer las cosas. Usted ha declarado que tiene un problema al pasar de "aquí está mi idea" a "aquí está mi solución". Eso es algo más hacia las metodologías de desarrollo de software, además de ser un desarrollador experimentado.

Usar una metodología de desarrollo de software es más que "simplemente hackear código", y estas metodologías proporcionan flujos de trabajo estructurados. La familia Agile proporciona una buena estructura para equipos de desarrollo más pequeños (o individuos) que puede seguir para ayudarlo a pasar de la fase de "idea" a la fase de "producto terminado".

Hay algunas cosas que he aprendido a lo largo de los años de otros y a través del trabajo en varios proyectos, como:

• Haga que todo sea comprobable, esto hará que su vida sea mucho más fácil;
• No puede esperar tener un diseño perfecto y poder diseñar aplicaciones empresariales / el próximo título de juego más grande / insertar más aquí, sin tener experiencia en hacerlo;
• Es difícil diseñar un buen software si no ha tenido experiencia en hacerlo y ha aprendido de otros;
• Nunca tendrá un diseño perfecto la primera vez, incluso como desarrollador experimentado: las cosas cambian y, por lo tanto; tu diseño también podría;
• Escriba las cosas: escribir / dibujar / pizarra / pintar / lo que sea con lo que se sienta cómodo, hace la vida más fácil si tiene las cosas escritas. Tales como diseños de GUI, diagramas de clases, etc. En mi experiencia, solo "piratear algo juntos" tiene el potencial de fallar catastróficamente;
• No reinvente la rueda, no debería tener que hacerlo. Si está tratando de implementar su propio HashMap, probablemente esté haciendo algo mal. Investiga cosas y piensa antes de escribir el código.

Espero que algo de eso ayude.

Bueno, en mi opinión, como en cualquier profesión, para ser un buen profesional, todo lo que se necesita, además de la formación teórica, es experiencia .

Como un médico no puede ser bueno solo con las clases tomadas en la escuela de medicina, o un abogado no puede conocer todo el aspecto político de ser un desvío con solo su título, ser un buen desarrollador necesita experiencia y tiempo.

La experiencia no viene al leer el código de terceros. Si obtiene un estudiante de medicina, él / ella podría señalar muchos procedimientos, enfermedades, medicamentos, etc., pero la aplicación real de estas cosas (cuándo aplicar un procedimiento, qué enfermedad diagnosticar, etc.) solo llega con supervisión y experiencia.

Dado que no desea trabajar para una gran empresa (o cualquier otra empresa), le sugiero que comience desarrollando pequeñas aplicaciones, paso a paso. Desarrollar software por ti mismo lleva mucho tiempo, créeme.

Otra cosa que le sugiero para que se convierta en un buen desarrollador / ingeniero de software es contribuir al software de código abierto. Muchos chicos han ganado una buena cantidad de dinero (y experiencia, por cierto) ayudando a desarrollar software de código abierto y dando consultas después. Se han hecho un nombre con sus contribuciones al código abierto.

De todos modos, creo que no hay un atajo para ganar experiencia, y debe buscarse con disciplina y paciencia .

Puede comenzar mejorando el código de otras personas. Tome algún proyecto que tenga y agréguele una característica. Tendrá que decidir qué va a hacer la función y cómo debe hacerlo. Trabajando dentro del marco del código existente, diseñe su solución.

Y no tengas miedo de hackear cosas. Se realizan muchos desarrollos nuevos mediante el refinado (o preferiblemente reescritura) de prototipos rápidos y sucios. Siga adelante y use todas las peores prácticas y antipatrones en el libro, simplemente haga algo que haga lo que quiera. Luego, regrese y diseñe correctamente. Por lo general, me encuentro pensando "Sabes, una mejor manera de hacer esto sería ..." mientras codifico algunos parámetros de configuración en mi monstruosidad de tres procedimientos de 800 líneas.

Sé que actualmente está fuera de moda, pero las técnicas de análisis estructurado realmente me ayudaron a manejar el diseño de software. Juega creando algunos gráficos de burbujas y DFD para tener una idea de los problemas de descomposición y el diseño de diferentes partes de un sistema para que funcionen juntos.

Como otros han dicho, la experiencia proviene de escribir código. Pero también debe hacer que otra persona revise su código si es posible. Un programador más experimentado puede señalar problemas en su código y mostrarle mejores formas de hacer las cosas. Contribuir a un proyecto de código abierto le dará la oportunidad de hacer ambas cosas.

Para mí, ayuda dividir una pieza de software más grande en trozos más pequeños. Y luego rompa esos trozos en partes aún más pequeñas y así sucesivamente. Cada programa de software es una colección de pequeñas piezas de lógica.

Considere un blog, por ejemplo. Desea poder crear y editar publicaciones que otros puedan leer. Inmediatamente puede dividir el proyecto en secciones administrativas y públicas. Como mínimo, el administrador requerirá usuarios administradores, una página de inicio de sesión y una sección para administrar el blog. La sección para administrar el blog se puede dividir en una interfaz CRUD (Crear, Leer, Actualizar, Eliminar). La creación de una nueva publicación de blog requerirá una verificación para asegurarse de que el usuario administrador tenga los privilegios correctos, un formulario, un formulario de validación y la capacidad de guardar en la base de datos. Y así.

Cuanto más desgloses un problema o una característica, más manejable se vuelve. Es dividir y conquistar. Una vez que haya podido mapear su software de esta manera, puede ver cómo interactúan las diferentes partes entre sí. ¿Dónde podrías repetir el código? ¿Qué se puede abstraer? Este debería ser un proceso iterativo tanto como planificas como cuando escribes el código.

Recomendaría averiguar cuál es su conjunto mínimo de características para comenzar e implementarlo antes de agregarle otras piezas. Querrá codificar a la defensiva para que los cambios futuros no sean demasiado difíciles, pero al mismo tiempo, no desea implementar medias características que tal vez nunca se completen. Es una línea difícil caminar entre mantenerse flexible y estar dispuesto a matar sin piedad a sus seres queridos, pedir prestada una referencia literaria. Ser bueno en ese acto de equilibrio en particular solo proviene de la experiencia.

Y a eso se reduce, como han mencionado las otras respuestas: experiencia. La única forma de obtenerlo es simplemente comenzar. No se preocupe tanto por hacerlo perfecto desde el principio. Primero haga que el código funcione, luego hágalo hermoso, luego hágalo rápido.

Además, a diferencia de este párrafo, no agregue seguridad al final como una ocurrencia tardía. Debería tener una idea sobre las formas en que su software podría verse comprometido, pero, para empezar, nunca confíe en las aportaciones de los usuarios.

Sé que dices que no quieres trabajar para una compañía de software, pero ese es un buen lugar para obtener la experiencia de la que hablan muchas de las otras respuestas. Y si desea o no trabajar en grandes proyectos, la exposición al trabajo y los estilos de trabajo de otras personas es algo bueno.

No puede probar la programación de pares usted mismo, por ejemplo. Y si estás emparejado con alguien más inteligente que tú, obtienes el beneficio adicional de obtener mejores prácticas de ellos mientras obtienes experiencia en esa metodología.

Por cierto, he hecho mi práctica tratar de trabajar con grupos donde siento que estoy por debajo del promedio en experiencia, habilidad y cosas similares. Aumenta enormemente mi juego. Es mucho más difícil hacerlo solo o donde eres el tipo "experimentado".

Lo que estás buscando son habilidades para resolver problemas . Me di cuenta de que se supone que el desarrollador ya puede hacer esto, lo cual es una tontería. Afortunadamente, la resolución de problemas es una habilidad general, utilizada en matemáticas, investigación, vida cotidiana, etc.

Principalmente, debes terminar siguiendo el método científico, con algunos lujos.

1. Tiene un problema (use herramientas y técnicas para ayudar a definir esto)
2. Hipotetiza una solución (patrones y experiencia de ayuda)
3. Prueba de hipótesis (es posible que ni siquiera tenga código aquí)
4. Repita los pasos 2 y 3 hasta que se cumpla la hipótesis. Ahora tiene una teoría (programa de trabajo para resolver problemas)
5. Desarrolle un experimento para enfatizar la teoría, buscando agujeros (¡casos de prueba!)
6. Si los casos de prueba se mantienen, ¡tiene una solución! De lo contrario, enjuague y repita

Tenga en cuenta que este es un nivel bastante alto. Cada paso generalmente implica varios subpasos, como determinar cuál es realmente el problema. Como ejemplo, mira resolver problemas de palabras en matemáticas. Recopila hechos (una herramienta) y determina lo que realmente se desea. Luego, examina sus hechos, intentando mapearlos a la solución.

Esto termina convirtiéndose en subproblemas del problema principal. Entonces, siga los pasos nuevamente. Necesitamos un elemento intermedio para obtener el resultado final, por lo que se convierte en nuestro nuevo problema. Esto descompone el problema en secciones pequeñas y fáciles de entender. A medida que se resuelve cada pieza, la solución se reconstruye.