Комментарии 12
«Да кто вообще понаписал эту хрень?» — спрашивает технический директор. В
раздрае чувств он смотрит в git blame. Оказывается, это он и понаписал.
В голосину ;) А может оказаться, что это написал сотрудник, которого никто из нынешних сотрудников в галаза не видел (за 10 лет коллектив может пару раз обновиться полностью). Но если в message принято упоминать номер задачи в issue tracker'е, то не все так плохо.
А бывает еще на свой код наткнешься и так стыдно и больно...
А бывает еще на свой код наткнешься
"Меня заставили"! :)
Это ещё ничего. Работал я в одной компании. Пришёл туда молодым и горячим, ушел через пару лет на более хлебное место. Ещё через пару лет более хлебное место опостыло, и тут на старой работе появилась интересная вакансия. В общем, вернулся туда, но на новый проект.
Дело в том, что за полгода до первого увольнения я перешёл в другой проект. Там все делалось очень в спешке + первые два месяца я был единственным программистом в проекте. В общем, решил заглянуть через 2 года во что превратилась кодовая база, которую я растил с нуля :)
Моему удивлению не было предела. Во-первых, я увидел как архитектурные решения, которые я принимал, превратились в жутких монстров, тогда как два года назад они казались очень лаконичными :) Во-вторых, некоторые части кода были настолько плохи, что я понимал это еще при написании. Оставил огромные TODO, как это исправить. Но за 2 года никто и пальцем не пошевелил :) Так и висят там эпического масштаба костыли с моим именем на них :D
После этого я больше не удивляюсь откуда и почему в долгоживущих проектах появляются всякие нечистоты. Вся проблема почти всегда в двух вещах: отсутствие дисциплины и нехватка времени)
А бывает, что git blame указывает на тебя, т.к. ты в этих строчках заменил, например, табы на пробелы) надо всегда после блэйма историю ещё смотреть.
А однажды было так, что дурно пахнущий код указывал был в моём коммите. Но я точно помнил, что этого не писал. Залез в историю пул реквестов и увидел, что прежде, чем слить мой пулл реквест, тех лид залил в мою ветку ещё с десяток своих коммитов. Иногда сквош - зло)
Каждый раз, когда разбираю что-то головоломное мучительно пытаюсь понять - это фатальный недостаток и просто нужно привыкнуть или кот действительно плох и его стоило бы переписать.
Руководствуюсь всегда простым правилом: если встретил зубодробительное - после того, как разобрался - оставляю огромный обстоятельный комментарий поясняющий буквально все взаимосвязи в этом костыле. Иногда в функции на 10 строчек, легко может быть комментарий строчек на 20.
Так вот собственно правило такое: если получается написать внятный и четкий комментарий, который точно не устареет завтра - вероятно это фатальный недостаток, вытекающий из сложности системы. Если комментарий писать тяжело, если взаимосвязи очень шаткие и любое дуновение ветра в другом месте системы разрушит этот мегазабористый код - это точно надо переписать)
Иногда лучше дать новому сотруднику попробовать исправить ситуацию именно потому, что он еще не знает, почему тут ее считают неулучшаемой.
Legacy код в крупных компаниях для опытного специалиста - это ниша, залог стабильности и спокойствия.
Если условный Олег разбирается в этом, кхе кхе, ..вне, то он - ценный сотрудник.
И когда Олег прийдёт за повышением, для бизнеса гораздо выгоднее зп повысить, чем обучать нового сотрудника или, тем более, переписывать код.
Большой тех долг и/или куча легаси - это проблема бизнеса, из-за которых он может терять кучу денег. А хитрый разработчик не стремится это положение менять. Он стремится этот поток денег, так сказать, сконфигурировать в свою пользу.
А если, всё-таки, переписывать - то вот и возможность Олегу стать тимлидом команды, которая делает рефакторинг.
Этичная сторона тоже в порядке. Никто никого не обманывает, все всё понимают. Просто человек не стремится всеми силами лишать себя конкурентных преимуществ. Да и копаться в такой кодовой базе не очень приятно.
Это кто понаписал?