<rmcreative>

RSS

Не делайте из проекта хламовник

9 августа 2013

Иногда меня просят посмотреть код разных проектов и почти везде я замечаю одну и ту же ошибку. Выглядит она не сильно страшно, но отражается на проекте и настроении команды серьёзно.

Итак, хламовник, он же чулан, он же балкон в типичной русской квартире — всеми силами избегаемое место, где лежит куча всякой непонятной и совершенно не нужной дряни, которую по необъяснимым или нелогичным причинам жалко выкинуть. Именно в такое место частенько превращаются it-проекты. В них встречаются куски закомментированного кода, файлы вроде main.css_old, неиспользуемые методы, по пять версий jQuery, // TODO: и т.д.

Итак, почему это плохо и в то же время совершенно бесполезно:

  • Теория разбитых окон отлично работает в IT-проектах.
  • Частенько огромные закомментированные куски в CSS и JavaScript отдаются пользователю, увеличивая время загрузки страниц.
  • На чтение закомментированного уходит время.
  • Большое количество неиспользуемых файлов может на неделю ввести новичка на проекте в ступор.
  • Работать с таким проектом неприятно. Создаётся ощущение говнокода даже если код нормальный.
  • В компилируемых языках может существенно увеличится время компиляции.
  • Всё это и так хранятся в используемой вами системе контроля версий.

Отдельно стоит упомянуть //TODO:. В коде их вряд-ли кто-то будет воспринимать серьёзно и действительно к ним возвращаться. Если необходимо отложить что-то на потом, лучше завести задачку в трекере (ну или где там у вас хранятся задачи) и никаких //TODO: в самом коде не писать.

Комментарии RSS

  1. №8248
    Smile42RU
    Smile42RU 09.08.2013, 17:51:21

    С TODO не согласен - их можно централизованно собирать в какой нибудь генерации доков а-ля phpdoc и постоянно держать под контролем.

  2. №8249
    JustSamter
    JustSamter 09.08.2013, 18:09:52

    Саша, что то мне кажется с TODO ты слишком категоричен :)

  3. №8250
    Sam
    Sam 09.08.2013, 18:14:47

    Возможно, хотя ни разу не видел, чтобы они использовались по назначению, а не висели мёртвым грузом.

  4. №8251
    MpaK
    MpaK 09.08.2013, 18:19:03

    Два нюанса, порой почему оставляешь закомментированный код, потому, что иногда реально удается к нему вернуться. С CVS не всегда помнишь в какое время у тебя был этот код, через 3-ий десяток коммитов уже провал вспомнить что и где было, так-то помнишь, что делал, а вот где... уже нет... так что ничего страшного, но на стадии уже готового продукта конечно стоит пройтись и убрать все.

    По поводу # todo: Очень даже имеет место быть, NetBeans например собирал такие заметки в отдельное окошечко и можно было ориентироваться и видеть.

  5. №8252
    Sam
    Sam 09.08.2013, 18:25:10

    MpaK, про техническую возможность собирать TODO я знаю. Но вот чтобы ей хоть кто-то пользовался не видел.

    Если код, к которому когда-то потом возможно вернуться не сильно сложный, проще его удалить и потом написать заново. Тут прямая аналогия с балконом. Вроде коробки лежат на случай переезда, но, если подумать, то случится он не скоро а коробки легко, в случае чего, достать где-то ещё.

    Ну а в редких случаях, когда код реально сложный, в системах контроля версий есть именованные метки.

  6. №8253
    JustSamter
    JustSamter 09.08.2013, 18:25:13

    на счет TODO не скажу, что я им пользуюсь постоянно. но вот на днях открыл вкладку todo и там такая важная штука, про которую давным давно забыл. мое мнение - несомненно не очень часто востребованный инструмент,но и без него нельзя.

  7. №8254
    Sam
    Sam 09.08.2013, 18:26:22

    JustSamter, а вот если бы сделал сразу или закинул бы в трекер с сроком недели в две, не забыл бы.

  8. №8256
    Александр Кочетов
    Александр Кочетов 09.08.2013, 19:38:46

    Я в TODO размещаю некритические для проекта вещи, в которых написаны пожелания по архитектурным изменениям на будующее, внедрению новых принципов и конвептов и т.д., т.е. это те TODO которые если не сделать ничего страшного с проектом не случится.

  9. №8257
    kotchuprik
    kotchuprik 09.08.2013, 22:00:57

    Sam, а если задача в другом стоит? У меня в проекте на Yii есть места, где должна быть реализация и я знаю какая, поэтому для меня @TODO, что-то вроде флага, куда писать код, а не сидеть и вспоминать как должно все работать)

    P.S. соглашусь с генератором доков) P.P.S а еще, у вас в Yii, есть несколько @TODO, насколько я помню)

  10. №8258
    Sam
    Sam 09.08.2013, 23:44:10

    kotchuprik, ну разве что как временная штука, которая никогда не попадает в репозиторий.

    В Yii посмотрел. Действительно имеется парочка в тестах и даже несколько в коде... с 2008 года :)

  11. №8259
    vitalg
    vitalg 10.08.2013, 0:28:43
    • Иногда проблема в том, что "бизнес" меняет своё решение и приходится раскомментить код;
    • Бывает, что in production необходимо временно логировать результаты, и тогда очень помогает "TODO: Remove me in future";
    • про неиспользуемые файлы вообще отдельная история, в практике нет времени заниматься чисткой. Вообще как идея, у TODO необходимо expire time с нотификацией :) Конечно, это совсем другой подход с вытекающими... но это бы решало очень многое, особенно нотификации об устаревшем TODO :)
  12. №8260
    Денис Радченко
    Денис Радченко 10.08.2013, 9:22:00

    Все мы хотим, чтобы было идеально, но часто так не получается из-за коротких сроков или еще каких-нибудь причин. У меня есть проект, который был написан 3-4 года назад, я все хочу переписать, но на это просто не хватает времени - мне нужно бросить другую работу на 2 недели и заниматься только этим проектом

  13. №8261
    Максим
    Максим 10.08.2013, 14:15:29

    Полностью согласен с Александром, однако todo все же пишу в коде, а попутно дублирую в свой список задач. Так удобней. Имел большой опыт с хламовыми проектами, и, что самое обидное, даже фреймворк yii не помогает некоторым программистам писать хламокод. В текущем проекте приходится очень многое переделывать из-за того что накодили члены комманды, поэтому постояно слежу за качеством их кода чтоб не было хлама.

  14. №8262
    Sam
    Sam 11.08.2013, 23:22:27

    vitalg,

    Иногда проблема в том, что "бизнес" меняет своё решение и приходится раскомментить код;

    С таким же успехом можно откатить коммит где этот код был убран или его часть. При помощи того же git bisect нужный коммит находится очень легко даже если вы забыли, какой именно вам нужен.

    про неиспользуемые файлы вообще отдельная история, в практике нет времени заниматься чисткой

    Если чистить вовремя и показывать пример всей команде, это не будет занимать много времени.

    Денис Радченко, на переписать требуется значительное время. На уборку неиспользуемого тратится сравнительно немного.

  15. №8266
    Александр
    Александр 14.08.2013, 20:17:29

    Хорошая заметка, Александр! Спасибо. Я обычно делаю копии старых (временных) файлов в отдельную папку, после того как всё готово, просто удаляю эту временную папку.

  16. №8267
    Sam
    Sam 15.08.2013, 13:25:54

    Александр, опять же, лишнее действие, если используется система контроля версий.

  17. №8269
    Александр
    Александр 18.08.2013, 0:15:54

    Согласен, если использовать систему контроля версий, то этот шаг лишний.

  18. №8299
    Corpsee
    Corpsee 30.08.2013, 7:27:49

    C //TODO: дело вкуса. Я вот пользуюсь, например, активно. IDE их собирает в одну кучу, удобно просматривать, неактуальные я удаляю.

  19. №8506
    Alpha
    Alpha 24.10.2013, 19:18:50

    А если работаешь с коллегами и с переменных успехом сражается с говнокодом, балансируя между общим качеством продукта, функциональностью и соблюдением сроков?

  20. №8507
    Sam
    Sam 25.10.2013, 13:51:05

    Alpha, балансировать дальше и пытаться донести идею до коллег.

  21. №8830
    Аскар
    Аскар 22.02.2014, 23:19:47

    Я в первую очередь себя приучаю к упорядоченному коду, и учусь приёмам и методам сокращения хлама. А вот на счёт того чтобы повлиять на коллег, это отдельная тема, надо просто для себя облегчать и чистить код других, будут и противники, которые не понимают что надо уже учиться правильный кодить. Я до сих пор чищу свалку прежних программистов. Особенно не нравится когда пишут в одном контроллере то что можно было вынести ещё в несколько контроллеров, чтобы не дублировать и/или не захламлять один файл. Делая его нечитабельным. Встречал такие ужасы, когда засовывали всё в один beforeAction, под словом "всё" имеется ввиду код, который обслуживает почти все действия, с большой разветвлённостью условных операторов: удаление, редактирование, создание. В таком коде можно психопатом стать пока поймёшь что к чему.

  22. №8831
    Аскар
    Аскар 22.02.2014, 23:23:31

    забыл к последнему приписать: то что в beforeAction обслуживание засовывали обслуживание (CRUD) разных моделей. Идея то хорошая, для решения такой задачи есть другие методы, но то что я видел это тихий ужас...

  1. Почта опубликована не будет.

  2. Можно использовать синтаксис Markdown или HTML.

  3. Введите ответ в поле. Щёлкните, чтобы получить другую задачу.