Не делайте из проекта хламовник
9 августа 2013
Иногда меня просят посмотреть код разных проектов и почти везде я замечаю одну и ту же ошибку. Выглядит она не сильно страшно, но отражается на проекте и настроении команды серьёзно.
Итак, хламовник, он же чулан, он же балкон в типичной русской квартире — всеми силами избегаемое место, где лежит куча всякой непонятной и совершенно не нужной дряни, которую по необъяснимым или нелогичным причинам жалко выкинуть. Именно в такое место частенько превращаются it-проекты. В них встречаются куски закомментированного кода, файлы вроде main.css_old
, неиспользуемые методы, по пять версий jQuery, // TODO:
и т.д.
Итак, почему это плохо и в то же время совершенно бесполезно:
- Теория разбитых окон отлично работает в IT-проектах.
- Частенько огромные закомментированные куски в CSS и JavaScript отдаются пользователю, увеличивая время загрузки страниц.
- На чтение закомментированного уходит время.
- Большое количество неиспользуемых файлов может на неделю ввести новичка на проекте в ступор.
- Работать с таким проектом неприятно. Создаётся ощущение говнокода даже если код нормальный.
- В компилируемых языках может существенно увеличится время компиляции.
- Всё это и так хранятся в используемой вами системе контроля версий.
Отдельно стоит упомянуть //TODO:
. В коде их вряд-ли кто-то будет воспринимать серьёзно и действительно к ним возвращаться. Если необходимо отложить что-то на потом, лучше завести задачку в трекере (ну или где там у вас хранятся задачи) и никаких //TODO:
в самом коде не писать.
Комментарии RSS по email OK
С TODO не согласен - их можно централизованно собирать в какой нибудь генерации доков а-ля phpdoc и постоянно держать под контролем.
Саша, что то мне кажется с TODO ты слишком категоричен :)
Возможно, хотя ни разу не видел, чтобы они использовались по назначению, а не висели мёртвым грузом.
Два нюанса, порой почему оставляешь закомментированный код, потому, что иногда реально удается к нему вернуться. С CVS не всегда помнишь в какое время у тебя был этот код, через 3-ий десяток коммитов уже провал вспомнить что и где было, так-то помнишь, что делал, а вот где... уже нет... так что ничего страшного, но на стадии уже готового продукта конечно стоит пройтись и убрать все.
По поводу # todo: Очень даже имеет место быть, NetBeans например собирал такие заметки в отдельное окошечко и можно было ориентироваться и видеть.
MpaK, про техническую возможность собирать TODO я знаю. Но вот чтобы ей хоть кто-то пользовался не видел.
Если код, к которому когда-то потом возможно вернуться, не сильно сложный, проще его удалить и потом написать заново. Тут прямая аналогия с балконом. Вроде коробки лежат на случай переезда, но, если подумать, то случится он не скоро а коробки легко, в случае чего, достать где-то ещё.
Ну а в редких случаях, когда код реально сложный, в системах контроля версий есть именованные метки.
на счет TODO не скажу, что я им пользуюсь постоянно. но вот на днях открыл вкладку todo и там такая важная штука, про которую давным давно забыл. мое мнение - несомненно не очень часто востребованный инструмент,но и без него нельзя.
JustSamter, а вот если бы сделал сразу или закинул бы в трекер с сроком недели в две, не забыл бы.
Я в TODO размещаю некритические для проекта вещи, в которых написаны пожелания по архитектурным изменениям на будующее, внедрению новых принципов и конвептов и т.д., т.е. это те TODO которые если не сделать ничего страшного с проектом не случится.
Sam, а если задача в другом стоит? У меня в проекте на Yii есть места, где должна быть реализация и я знаю какая, поэтому для меня @TODO, что-то вроде флага, куда писать код, а не сидеть и вспоминать как должно все работать)
P.S. соглашусь с генератором доков) P.P.S а еще, у вас в Yii, есть несколько @TODO, насколько я помню)
kotchuprik, ну разве что как временная штука, которая никогда не попадает в репозиторий.
В Yii посмотрел. Действительно имеется парочка в тестах и даже несколько в коде... с 2008 года :)
Все мы хотим, чтобы было идеально, но часто так не получается из-за коротких сроков или еще каких-нибудь причин. У меня есть проект, который был написан 3-4 года назад, я все хочу переписать, но на это просто не хватает времени - мне нужно бросить другую работу на 2 недели и заниматься только этим проектом
Полностью согласен с Александром, однако todo все же пишу в коде, а попутно дублирую в свой список задач. Так удобней. Имел большой опыт с хламовыми проектами, и, что самое обидное, даже фреймворк yii не помогает некоторым программистам писать хламокод. В текущем проекте приходится очень многое переделывать из-за того что накодили члены комманды, поэтому постояно слежу за качеством их кода чтоб не было хлама.
vitalg,
С таким же успехом можно откатить коммит где этот код был убран или его часть. При помощи того же
git bisect
нужный коммит находится очень легко даже если вы забыли, какой именно вам нужен.Если чистить вовремя и показывать пример всей команде, это не будет занимать много времени.
Денис Радченко, на переписать требуется значительное время. На уборку неиспользуемого тратится сравнительно немного.
Хорошая заметка, Александр! Спасибо. Я обычно делаю копии старых (временных) файлов в отдельную папку, после того как всё готово, просто удаляю эту временную папку.
Александр, опять же, лишнее действие, если используется система контроля версий.
Согласен, если использовать систему контроля версий, то этот шаг лишний.
C //TODO: дело вкуса. Я вот пользуюсь, например, активно. IDE их собирает в одну кучу, удобно просматривать, неактуальные я удаляю.
А если работаешь с коллегами и с переменных успехом сражается с говнокодом, балансируя между общим качеством продукта, функциональностью и соблюдением сроков?
Alpha, балансировать дальше и пытаться донести идею до коллег.
Я в первую очередь себя приучаю к упорядоченному коду, и учусь приёмам и методам сокращения хлама. А вот на счёт того чтобы повлиять на коллег, это отдельная тема, надо просто для себя облегчать и чистить код других, будут и противники, которые не понимают что надо уже учиться правильный кодить. Я до сих пор чищу свалку прежних программистов. Особенно не нравится когда пишут в одном контроллере то что можно было вынести ещё в несколько контроллеров, чтобы не дублировать и/или не захламлять один файл. Делая его нечитабельным. Встречал такие ужасы, когда засовывали всё в один beforeAction, под словом "всё" имеется ввиду код, который обслуживает почти все действия, с большой разветвлённостью условных операторов: удаление, редактирование, создание. В таком коде можно психопатом стать пока поймёшь что к чему.
забыл к последнему приписать: то что в beforeAction обслуживание засовывали обслуживание (CRUD) разных моделей. Идея то хорошая, для решения такой задачи есть другие методы, но то что я видел это тихий ужас...