Estas son algunas de mis observaciones en ingeniería de software de mis últimos 13 años en el campo de TI.
- La lectura del código fuente se considera una buena práctica, ya que permite al usuario tener una idea de la calidad del código (sangría, comentarios, estructura de la función). Pero mi observación es que muchos desarrolladores realmente no leen el código. De hecho, olvídate de leer el código fuente de otros, muchos ni siquiera leen su propio código fuente. Y no los culpo por completo, la mayoría del código escrito es de una calidad terrible, ya sea para comentar o hacer sangrado, puede ser una tarea difícil realmente pasar por alto eso.
- La documentación, una de las mejores prácticas que consigue un tratamiento materno paso a paso. Después de haber trabajado en proyectos de mantenimiento, la peor parte para mí fue pasar por la documentación mal escrita. En algunos casos no había ninguna documentación, y tuve que descubrir la cabeza y la cola yo solo. De hecho, muchos desarrolladores no siguen el principio fundamental de documentar su propio código fuente, olvídese de otros documentos, como el diseño o la especificación de requisitos.
- Estándares de código fuente, que a su vez se relaciona con los dos primeros puntos mencionados. Los desarrolladores recuerdan los estándares solo cuando hay alguna revisión de código o inspección en curso. Nuevamente, con los plazos muy ajustados, el enfoque está en lograr que el código se ejecute en primer lugar, y en ese apuro, a menudo se da un paso a los estándares.
- Las revisiones de código odiadas de manera uniforme por la mayoría de los desarrolladores e ingenieros de software, me refiero a quién querría escuchar los comentarios acerca de qué tan mal escrito está su código, y aún peor, volver a hacerlo.
- Pruebas, sí, todos los desarrolladores e ingenieros de software saben que esta fase es inevitable, pero aún así se detesta. Esto se debe a que, en primer lugar, se produce ese error que nunca supo que existía, o que a veces se siente orgulloso de haber corregido un error, y el equipo de pruebas informa que ha introducido dos nuevos, al mismo tiempo que corrige el anterior. Muy a menudo duele el ego, y los choques entre los desarrolladores y el equipo de control de calidad son bastante comunes.