Obtuve mis puntos de vista del negocio diario como programador, así como de entrevistas con posibles nuevas contrataciones. Así que esta es mi lista de cosas que enfrenté en los últimos años.
- Desarrollando algo sin entender el problema detrás. Creo que es obvio cuál es el resultado de eso. Se desarrolla un software que nadie puede usar realmente, ya que no cumple con los casos de uso correctos. Al comienzo de mi carrera, esto fue algo que hice yo mismo hasta que obtuve la experiencia requerida en ese campo. Entonces, aprenda de mis errores y comprenda realmente lo que los clientes o usuarios realmente quieren. Y si no lo sabes, pregunta los 5 por qué (5 por qué)
- Desarrolle la característica correcta sin comprender cómo resolverla correctamente. Actualmente estoy trabajando en un proyecto que se inició hace unos 15 meses. Esto es mucho tiempo Tiene que resolver algún problema matemático y dentro del equipo inicial había otro matemático incluido. Una vez participé en el proceso de encontrar un modelo matemático para resolver el problema con este otro tipo, pero no participé en este proyecto después de este trabajo teórico. El punto era que este tipo no entendía los requisitos de la solución encontrada. Como resultado, ya que participo en estos proyectos, encontré algunos problemas de diseño realmente malos. En algunos casos, el algoritmo crea resultados terriblemente incorrectos ya que no se aseguraron las condiciones previas de ese algoritmo. Entonces, si no comprende el algoritmo que necesita implementar, no lo implemente.
- Ingeniería excesiva: todos queremos escribir un gran código, excelentes funciones y software que puedan resolver nuestros problemas. Pero a veces los desarrolladores intentan crear soluciones que van mucho más allá de los requisitos. ¿Por qué es esto malo? La solución de su problema inicial, tal vez fácil, se vuelve muy compleja. Cuanto más compleja es una solución, más difícil es mantenerla, más probable es que ocurra un error, más tiempo se tarda en enviar su aplicación a los clientes. Una vez tuvimos un equipo que necesitaba crear una aplicación muy simple. Pero crearon un monstruo que era tan complejo que se volvió increíblemente lento, complejo y al final ni siquiera cumplía con el caso de uso correcto. Así que, sobre todo, fue un gran fracaso. Y el código no pudo ser rescatado, ya que nadie podría entender lo que está sucediendo en esta gran bola de barro.
- No entender el paradigma de un lenguaje. Durante todas las entrevistas de trabajo que hice, conocí a muchos desarrolladores que trabajan principalmente con lenguajes orientados a objetos que no tenían idea de cómo escribir código en estos idiomas. Mi cita favorita de estas entrevistas fue la siguiente: pregunté cómo debería ser una buena clase. La respuesta de los candidatos fue: “Si puedes heredar de ella”. Estaba esperando que continuara con cualquier cosa, pero esa fue su respuesta completa. Lo sentimos, pero escribir código en algunos lenguajes orientados a objetos no significa que tenga que usar la herencia en todas partes. Este paradigma trata sobre la encapsulación de código. La herencia es solo una fracción de ella.
- Falta de diligencia. Al escribir una aplicación, debe asegurarse de que haga lo que se supone que debe hacer. ¿Cómo se asegura eso? Derecha. Al probarlo. Las pruebas unitarias y las pruebas de integración son importantes. Si refactoriza algo, las pruebas aseguran que nada se rompa sin la intención de que se rompa. Aparte de eso, un buen programador debe asegurarse de que el código esté limpio y al grano. Eso puede requerir un poco de tiempo para pensar en el diseño, pero al final vale la pena. Trabajar en un código incorrecto siempre lleva más tiempo que trabajar en un buen código.
- Falta de comunicación. Cuando trabajas en un equipo, debes saber lo que hacen los demás y ellos deben saber lo que haces. ¿Suena obvio? A veces no, a veces trabajé en un equipo en el que algunos miembros codificaban algo y tú no sabías lo que estaban haciendo, porque no dijeron el resto. Como resultado, arreglaste algo que alguien más ya arregló. Lo reconoce cuando tiene el conflicto de fusión correspondiente. Entonces podría haber pasado su tiempo mucho más productivo.
- Permanecer en una herramienta que no se ajusta a la tarea. Muchos desarrolladores rezan su idioma favorito. No hay nada de malo en tener un idioma favorito, pero un desarrollador siempre debe saber cuándo una herramienta es una mala herramienta. No uses Ruby en tareas matemáticamente pesadas. No use C cuando solo necesita una breve prueba de concepto. No use Python cuando la velocidad realmente importa.