(assumindo código de produção)
Eu tendem a ir um pouco mais longe. Eu escrevi sobre tornar os programas "à prova de idiotas", mas nem sempre qualifico isso: escrevo muito código que outras pessoas não verão ou trabalham (pelo menos, essa é a expectativa quando é escrita). Eusou o idiota do qual estou tentando me defender nesse caso. É uma coisa boa quando o seu programa detecta problemas para você, e o problema foi tão simplificado que é bastante óbvio que há um erro e sua origem. A verdade é que os detalhes da implementação são óbvios quando você escreve um programa (a menos que esteja implementando prematuramente), mas eles devem ser abstraídos e resistentes a erros para os clientes (mesmo quando existe a localização do módulo). A razão é que os programas se tornam muito complexos. Às vezes, você pode separar problemas, mas não o tempo todo. Se você mantiver seus componentes muito rígidos, simples, bem encapsulados e à prova de idiotas, eles tendem a escalar bem e a maioria dos defeitos é detectada antes do envio. É mais fácil reutilizar, e você tem mais confiança e facilita a reutilização dos programas. Além disso, esses programas complexos que você escreve apenas se tornam mais complexos (mesmo para você) depois de algum tempo fora do programa. Quando você o lê em 6 meses, pode levar uma quantidade absurda de tempo para entender e depurar em comparação com a versão à prova de idiotas. Se um componente introduzir uma alteração de ruptura, ele poderá não ser detectado por um longo tempo, caso contrário. Programas são complexos; você não pode escapar dessa realidade, mas pode torná-la à prova de idiota, o que tornará sua vida muito mais fácil quando algo der errado ou quando precisar ser reutilizado ou alterado. Portanto, a abordagem à prova de idiotas significa que seu software pode ser entendido, reutilizado ou mantido por seus juniores ou por pessoas mais novas da equipe (não apenas alguém tão bom / experiente quanto você). A substituição é uma preocupação separada: se as pessoas adoram trabalhar com seus programas, você está fazendo um bom trabalho - não não se preocupe com a substituição. Claro, eu poderia criar cenários em que programas ininteligíveis poderiam salvar seu trabalho, mas escrever um bom programa que outros possam usar e manter é claramente o mal menor (veja as resenhas dos outros). Se me pego escrevendo algo que não é à prova de idiotas, tento consertar isso.
Além do cenário, em que você precisa de alguma documentação para continuar um projeto após 6 meses de pausa, parece haver um claro conflito de interesses entre o desenvolvedor e a empresa de software.
Você realmente não tem ideia do que estava pensando algumas vezes ao revisitar implementações inativas. Quando você é realmente experiente, o problema é mais simples, porque você pode confiar mais em metodologias ou abordagens estabelecidas que você usa. Isso, no entanto, também pressupõe que essas metodologias sejam invariantes. Embora a documentação possa relaxar, você ainda precisa ser defensivo em suas implementações (por exemplo, você sabe que não deve passar NULL nesse cenário - teste essa condição).
Portanto, como programador, você deve realmente escrever uma excelente documentação e um código facilmente legível para todos; ou você deve escrever código e documentação de uma maneira que ele faça o trabalho e você possa entendê-lo, mas outra pessoa pode ter problemas para entendê-lo?
Eu recomendo a abordagem à prova de idiotas, que é ainda mais clara e mais resistente a erros do que a abordagem de fator de barramento. Escreva seus programas e documentação para que seja facilmente entendido por alguém externo ao projeto - isso também é bom para você. Isso aumentará seu valor para sua empresa e equipe; eles não desejarão substituí-lo.