Вы когда-нибудь спрашивали товарища по команде о быстром и грязном коде, который он сделал, и ответ был «это всегда делалось так» или «я знаю, что это не оптимально, но я только использование устаревшего кода» или даже «действительно ли это меняет что-то по сравнению с тем, что было раньше? это уже беспорядок». Бьюсь об заклад, у вас есть.
Вы видели, как на летних концертах под открытым небом люди бросали мусор в определенные места, потому что он был «уже грязным»? Держу пари, у тебя тоже.
Это подводит нас к интересной теории под названием Теория разбитого окна.
По википедии:
Теория утверждает, что поддержание и мониторинг городской среды для предотвращения мелких преступлений, таких как вандализм, пьянство в общественных местах и прыжки через турникеты, помогает создать атмосферу порядка и законности, тем самым предотвращая более серьезные преступления.
Другими словами, если вы не заботитесь о том, чтобы оставить после себя чистую окружающую среду, если вы не заботитесь о ее поддержании, не ждите, что другие улучшат ее, потому что, скорее всего, она станет еще хуже.
Теория разбитых окон теория прекрасно применима к разработке программного обеспечения.
Настаивать на написании кода наилучшего качества никогда не следует считать необязательным.
В этой Классной статье рассказывается о некоторых вредных привычках и вещах, которые считаются разбитыми окнами. Я позволил себе прокомментировать каждый из них:
- Устаревшая документация. Представьте себе последствия использования вашего API другой командой!
- Мертвый код: вы тратите часы и часы, пытаясь понять код, чтобы, наконец, узнать, что он МЕРТВ.
- Игнорируемые тесты. Серьезно, прекратите это делать!
- Несколько зависимостей для выполнения одного и того же действия. В .Net это называется синдромом Nuget.
- Непоследовательное форматирование кода. Потому что лучше потратить силы на что-то другое, чем на поиск закрывающей скобки.
- Недостаточное покрытие кода: бомба замедленного действия.
- Ручные действия при развертывании: когда развертывание больше похоже на древнее волшебство, чем на разработку программного обеспечения.
- Неиспользуемые импорты/зависимости. Затем вы удивляетесь, почему ваша сборка занимает три часа.
- Непонятная стратегия Git: если что-то было отправлено, оно отправлено, кого волнуют журналы обвинений и истории?
- Грязный код: корень всего ЗЛА
Поэтому, умоляю вас, в следующий раз, когда вы будете выполнять задание, попробуйте вместо этого применить Правило бойскаута и «оставить его лучше, чем вы его нашли». Также помните, что стоимость технического обслуживания обратно пропорциональна его частоте.
