Mi formación es ingeniería eléctrica, DSP para ser más preciso. La compañía para la que trabajo actualmente realiza muchos proyectos diversos, en su mayoría construyendo hardware analógico. Al estar un poco más cerca de las computadoras que todos los demás, a menudo soy el que escribe el código tanto para los dispositivos integrados (con los que estoy perfectamente bien) como para el sistema operativo Windows o Linux. Es lo último que es territorio extranjero para mí.
Puedo codificar, y conozco algunos lenguajes (C / C ++, Java, algunos VB.NET), pero solo los utilicé para simulaciones de algoritmos en el procesamiento de señales e imágenes, redes neuronales y otras aplicaciones similares. Para mí, la programación ha sido una herramienta computacional más que cualquier otra cosa. Sin embargo, obtengo más y más proyectos en los que tengo que escribir un software completo adecuado, y realmente no sé cómo hacerlo, porque nunca tuve que hacerlo y nunca me interesó lo suficiente. Yo mismo he visto bastantes ingenieros que se convirtieron en codificadores en cierto grado debido a las demandas de trabajo, y la mayoría de ellos no fueron tan buenos en lo que hicieron. Estoy seguro de que muchas personas han encontrado lo mismo.
Si tuviera que aprender a escribir un software adecuado con una buena interfaz de usuario, una buena arquitectura interna, etc., ¿cómo lo hago? No tenemos a nadie en el trabajo que pueda decirme qué es una buena práctica y qué no. Dado que puedo escribir código en el sentido más crudo de la palabra, ¿qué más hay que saber sobre cómo escribir un buen software y cómo llego allí por mi cuenta?
fuente
Respuestas:
Hay algunos libros que te ayudarán mucho. Sugiero tener siempre a tu lado Code Complete . Es una referencia invaluable. En una compañía anterior donde trabajé, este también fue el libro que le dimos a todos los programadores junior después de ser contratados.
El programador pragmático también es un recurso realmente útil y es bastante corto, pero le sugiero que lo lea después de completar el código.
Estos libros lo ayudarán a comenzar, luego codifique, codifique, codifique y codifique más ... pero sepa cuándo detenerse, su software nunca será perfecto.
fuente
Mi empresa hace esto todo el tiempo ... y me vuelve loco.
"Soy desarrollador de software, ¿cómo me convierto en EE?"
Bueno, creo que la respuesta es bastante obvia. Se necesita mucho tiempo y mucho trabajo. Y, por supuesto, los materiales de aprendizaje adecuados. Los antecedentes de ingeniería ayudan, en mi universidad las escuelas de informática y de ingeniería estaban en el mismo edificio con mucha superposición. Los algoritmos y los fundamentos matemáticos están ahí.
Un error que veo que cometen la mayoría de los recién llegados es morder mucho más de lo que pueden masticar. Materiales de aprendizaje en la interfaz de usuario, arquitecturas, código de calidad ... eso es mucho terreno . Algo que lleva años realmente y que a menudo lo hacen equipos de diferentes expertos en compañías de software.
No quiere decir que no puedes ser bastante decente por tu cuenta, si pones el tiempo. Simplemente reconozca la magnitud de los materiales para no abrumarse y A. Salir o B. Construir una gran deuda técnica en sus aplicaciones tomando atajos importantes en su proceso de aprendizaje.
Debido a todo esto, no hay una "trampa general" para convertirse en un desarrollador increíble con este libro. Le recomiendo que comience eligiendo un libro bien calificado en su idioma más utilizado y también participando en la comunidad de Stack, especialmente para las revisiones de códigos.
Prueba Amazon.com, tienen buenas críticas de libros.
fuente
Libros : Lo principal es leer (buenos) libros en el idioma que elija. Una vez que conozca el idioma de su elección, puede obtener " Mejores prácticas de X más efectivas " o "Y", y así sucesivamente. Creo que los libros de cocina son muy buenos para cerrar las brechas que pueda tener. Entonces, supongo que son al menos tres libros los que debes conseguir. Una cosa: hacer ejercicios y codificar kata para mejorar tu comprensión del idioma. Por supuesto, necesitas un buen patrón xUnit .
Los algoritmos son particularmente importantes y debe elegir un libro que los detalle, nuevamente, en el idioma que elija. Vale la pena conocer los patrones de diseño y antipatrones en cualquier idioma.
En pocas palabras: lleva tiempo. No se apresure.
fuente
Apestas en la codificación. Sí.
Pero, esto no significa que no pueda entregar software, eso hace feliz a la gente;)
Se humilde. Escribir el "negocio" lógica, que se necesita. Use el código de la biblioteca para todo lo demás. No intente escribir algoritmos fundamentales (como la ordenación de matrices ), no utilice "trucos sofisticados", respete alguna convención de código draconiana .
Use buen IDE. Esto es esencial, ya que le ayudará a formatear su código y rastrear errores tipográficos / simples.
Lea libros como " Code Complete " y " Pragmatic Programmer ", intente forzarse y aprender OOP (es simple y lo ayudará a mantener su código más fácil de mantener).
Use SVN , comprométase con frecuencia, para que pueda revertir sus cambios (cuando arruinará algo).
Encuentre a alguien, que sea un verdadero programador , con antecedentes académicos, si es posible. Así podrás hablar con él compartiendo tus problemas de novato y obteniendo respuestas esclarecedoras.
Y, por supuesto, lo más importante es también seguir codificando, codificando, codificando .
pd: si puedes escribir código C ++ que funciona y escribes redes neuronales (!), entonces tu cerebro es muy adecuado para la programación;) ¡Buena suerte!
fuente
Hay buenas respuestas aquí.
Un gran giro a tu favor es el simple hecho de que quieres saber.
Gran parte de la ingeniería de software (que debe tomar con escepticismo saludable, por supuesto) se trata de cómo hacerlo de maneras que no se arrepentirá más adelante. Un ejemplo es el uso de un sistema de control de versión de código fuente. Otro es dividir el código en archivos para que sea más fácil trabajarlo poco a poco. Otra es ser muy estricto con el orden : el formato del código y las convenciones de nomenclatura. Las convenciones exactas no importan tanto como ser consistentes al respecto.
De esa manera, cuando vuelvas al código en un año o más, no pensarás "¿Quién hizo este desastre?" Podrá encontrar cosas y cambiarlas sin demasiado riesgo de rotura. **
Una buena manera de comenzar es encontrar varios programas de ejemplo y trabajar a través de ellos. Luego puede adaptarlos a sus necesidades.
** Uno de mis mayores dolores de cabeza es tratar de trabajar con código escrito por personas que no creían que el formato o el nombre fueran importantes.
fuente
Si bien hay muchísimos buenos recursos sobre cómo hacer y no hacer cosas, al final lo más importante es ver mucho código y trabajar con él y ver qué fácil o complicado es mantenerlo.
Una buena manera de aprender es tener a alguien con experiencia para hacer el diseño inicial y luego revisar su código y mostrarle técnicas útiles como las ha utilizado. Entonces, si por casualidad logra convencer a sus jefes de que contraten al menos un ingeniero de software con experiencia en proyectos de software (pequeños) líderes y en el diseño de software para liderar los proyectos, creo que sería la mejor opción.
Si no puedes conseguir que nadie te acueste, en estos días hay un fuerte movimiento de código abierto. Tal vez use algunas herramientas de código abierto en su trabajo, así que trate de corregir los errores en ellas o agregue funciones simples que haya utilizado y discuta cómo hacer esas cosas con la comunidad respectiva. Es un ejercicio de aprendizaje práctico poco útil aprender a aplicar las reglas generales que encontrará en los libros sobre problemas prácticos reales.
fuente
Una cosa que realmente recomendaría para aprender codificación de calidad y preocupaciones de arquitectura serían las enseñanzas del "Tío Bob" (Robert Martin). Tiene algunos videos de $ 1 que son del tamaño de un bocado, aunque quizás demasiado caprichoso, así como algunos buenos libros.
fuente