Thoughts about code review
Все-таки эффективность OTS aka Overview Through Shoulder оно же Peer Review, можно было бы значительно повысить, если бы документацию к обозреваемому коду должен был бы писать обозреватель. Традиционно считается, что документация - удел хозяина кода, хотя в таком случае она выходит далеко не блестящей, т.к. для хозяина слишком многое в коде очевидно и в документации не нуждается. В то же время, при классическом review добросовестность обозревателя ничем не обуславливается, кроме его личного интереса к предмету.
Обе эти трудности легко можно было бы устранить совместив review с документированием. Потому как, чтобы написать документацию к незнакомому коду, необходимо досконально вникнуть во все детали, а заодно и проверить, что все спроектировано оптимальным образом и не содержит трудно-пояснимых кусков, или наоборот, пропусков.
Единственный минус, что сложно найти такую сплоченную команду, которой перекрестное документирование придется по душе. Но если сроки не жмут, то проводить ревизию вместе с документированием может сам хозяин кода, просто выждав какое-то время, чтобы избавится от замыленности глаза.
P.S. Я недавно делала review и документацию к проекту годичной давности, - это действительно работает.
Обе эти трудности легко можно было бы устранить совместив review с документированием. Потому как, чтобы написать документацию к незнакомому коду, необходимо досконально вникнуть во все детали, а заодно и проверить, что все спроектировано оптимальным образом и не содержит трудно-пояснимых кусков, или наоборот, пропусков.
Единственный минус, что сложно найти такую сплоченную команду, которой перекрестное документирование придется по душе. Но если сроки не жмут, то проводить ревизию вместе с документированием может сам хозяин кода, просто выждав какое-то время, чтобы избавится от замыленности глаза.
P.S. Я недавно делала review и документацию к проекту годичной давности, - это действительно работает.