(asumiendo código de producción)
Tiendo a ir un poco más lejos. He escrito sobre cómo hacer que los programas sean "a prueba de idiotas", pero no siempre lo califico: escribo muchos códigos que otras personas no verán ni trabajarán (al menos, esa es la expectativa cuando se escribe). Yo soy el idiota del que estoy tratando de defenderme en ese caso. Es bueno que su programa detecte problemas para usted, y el problema se ha simplificado tanto que es bastante obvio que hay un error y su origen. La verdad es que los detalles de la implementación son obvios cuando escribes un programa (a menos que lo estés implementando prematuramente), pero deben ser abstractos y resistentes a los errores para los clientes (incluso cuando existe la localidad del módulo). La razón es que los programas se vuelven muy complejos. A veces puedes separar los problemas, pero no todo el tiempo. Si mantiene sus componentes muy estrictos, simples, bien encapsulados y a prueba de idiotas, tienden a escalarse bien y la mayoría de los defectos se detectan antes de ser enviados. Es más fácil de reutilizar, y tiene más confianza y un tiempo más fácil para reutilizar los programas. Además, esos programas complejos que escribe solo se vuelven más complejos (incluso para usted) después de un tiempo alejado del programa. Cuando lo lees en 6 meses, puede llevarte una cantidad absurda de tiempo entenderlo y depurarlo en comparación con la versión de prueba de idiotas. Si un componente introduce un cambio de ruptura, puede pasar desapercibido durante mucho tiempo de lo contrario. Los programas son complejos; no puedes escapar de esa realidad, pero puedes hacerla a prueba de idiotas, lo que hará tu vida mucho más fácil cuando algo salga mal o cuando deba reutilizarse o modificarse. Por lo tanto, el enfoque a prueba de idiotas significa que su software puede ser comprendido, reutilizado o mantenido por sus juniors o personas más nuevas en el equipo también (no solo alguien tan bueno / experimentado como usted). El reemplazo es una preocupación aparte: si a la gente le encanta trabajar con sus programas, está haciendo un buen trabajo, no se preocupe por el reemplazo. Claro, podría llegar a escenarios en los que los programas ininteligibles puedan salvar su trabajo, pero escribir un buen programa que otros puedan usar y mantener es claramente el mal menor (vea las respuestas de los demás). Si me sorprendo escribiendo algo que no es una prueba de idiotas, trato de arreglarlo.
Aparte del escenario, donde necesita algo de documentación para continuar un proyecto después de 6 meses de pausa, parece haber un claro conflicto de intereses entre el desarrollador y la compañía de software.
Realmente no tienes idea de lo que pensabas en algunas ocasiones cuando revisabas las implementaciones inactivas. Cuando tiene experiencia con realmente , entonces el problema es más sencillo porque puede confiar más en las metodologías o enfoques establecidos que utiliza. Eso, sin embargo, también asume que estas metodologías son invariantes. A pesar de que la documentación puede ser laxa, aún tiene que estar a la defensiva en sus implementaciones (por ejemplo, sabe que es mejor pasar NULL en este escenario: pruebe esa condición).
Entonces, como programador, si realmente escribe una excelente documentación y un código fácil de leer para todos; o ¿debería escribir código y documentación de manera que haga el trabajo y usted mismo pueda entenderlo, pero otra persona puede tener problemas para entenderlo?
Recomiendo el enfoque a prueba de idiotas, que es aún más claro y más resistente a los errores que el enfoque de factor de bus. Escriba sus programas y documentación de manera que sea fácil de entender para alguien externo al proyecto, también es bueno para usted. Si lo hace, aumentará su valor para su empresa y su equipo, no querrán reemplazarlo.