Как писать код, чтобы коллеги тебя не материли

Представьте себе одну единственную вещь, которая сделает ваш код более понятным, а так же поможет вам намного легче разбираться в чужом коде и вы будете меньше «обсирать» чужой код, который был написан еще до того, как вы пришли в компанию. А самое лучшее вы всегда будете понимать, стоить ли его изменять или лучше не прикасаться к нему. Представили?!

Слишком многообещающее начало и вы уже почувствовали какой-то развод.

А теперь серьезно.

Я пишу код и для себя над своим собственным проектом и в компании, где программирую не один. И я стал замечать, что даже, когда работаю один и возвращаюсь к старому участку кода, то бывают мысли: «А почему я вообще так тут написал, ведь это неправильно?». И вдруг, если я захочу поменять, то может возникнуть ситуация, что теперь, что-то работает не так и то решение, которое я тогда принял, когда писал тот старый код было оптимальным.

Так вот важно писать в комментариях «Почему», «Почему я принял то решение, когда программировал?», «Почему из всех вариантов я выбрал именно ту реализацию, на которой остановился?». Особенно если работаешь в команде. У меня была ситуация, что участок кода, который написал другой человек, полностью не реализует, то что мне нужно и теперь у меня возникает логичный вопрос: «Почему он так сделал?», но мы не можем все помнить и логично получил ответ: «Не помню почему именно так. Что-то там не срасталось». И ты оказываешься в патовой ситуации тебе не подходит вариант, который сейчас есть и с другой стороны боишься начать переписывать, потому что не знаешь откуда появится проблема, может быть ты столкнешься с той же неразрешимой проблемой, с которой столкнулся коллега, а может и не столкнешься. Кто теперь это знает?! И это приводит к тому, что некоторые участки кода становятся «неприкасаемые», ты их боишься тронуть.

Так вот я считаю, что писать причину выбора варианта дает определенные бонусы.

1. Даже когда ты работаешь один, то зная причину можешь сразу понять ты просто тупанул, когда писал этот код или это адекватный код, учитывая контекст.
2. Ты растешь как программист и то решение, которое когда-то принял по неопытности, можешь изменить, ведь ты знаешь из-за чего оно тут такое.
3. Со временем сама причина, по которой написан именно такой код может «кануть в Лету» и теперь видя это, ты понимаешь, что со спокойной душой можешь с ним расстаться, если же это это не писать, то тогда он так и будет оставаться тут, боясь что-то повредить.
4. Можно по новому смотреть на старый код, написанный до вас. Если раньше с надменным взглядом только обсирал его, то теперь понимаешь, что в той ситуации, в которой оказались программисты до тебя это было очень даже правильным решением.
5. Спасает от ситуации, когда ты убираешь, то костыльное решение, которое было до тебя, и тут оказывается, что ты открыл ящик пандоры, ведь только этот костыль сдерживал от всеобщей гибели.
6. Когда ты пишешь почему, то другой разработчик, который увидит это сможет переписать, зная как решить ту проблему, которую ты решал более эффективно.

В заключение, хочу сказать. Код остается напечатанным надолго, а вот мысли и причины людей, который в конкретный момент в конкретной ситуации его принимали испаряются на следующий день.