Мне платят за то, что я возвращаю чужой технический долг. В своей работе я вижу много сложного в поддержке кода, и я снова и снова вижу много проблем, которых можно было избежать.
Я специализируюсь на отладке, исправлении, поддержке и расширении функциональности старого программного обеспечения. Мой типичный клиент имеет веб-сайт или приложение, которое более-менее работает, но автор которого недоступен. Бизнес-требования изменились, и ПО перестало им удовлетворять. Или у моего клиента есть что-то, что «уже закончено», но он расстался с разработчиком после исчерпания бюджета и сроков. Обычно такая ситуация сопровождается списком пропущенных фич и багов.
Мой типичный клиент обычно разговаривал с другими программистами, которые рекомендовали выбросить имеющееся и начать разработку с нуля. Большинство программистов не любит поддержку кода, и особенно, они не любят поддержку чужого кода.
При написании кода программисты часто задают неверные вопросы, когда говорят о дальнейшей поддержке кода — см. статью Matt DuVall’а «Миф поддержки», чтобы понять, как это случается. Ниже несколько практик, которым вам надо следовать в своих проектах, чтобы не оставить меня без работы:
Не используйте системы контроля версий
Я всегда удивляюсь, когда сталкиваюсь с большими проектами, написанными в последние несколько лет без системы контроля версий. Когда вы не используете контроль версий, следующий программист должен будет выяснить, какие файлы являются частью текущей системы, а какие — устаревшими или бэкапами. Следующий программист не будет иметь ни единого коммит-сообщения или чэнжлога, чтобы получить историю кода. Я рассказывал, как не использовать системы контроля версий в моей статье «Введение в Несчастно-Ориентированное Программирование».
Настраивайте свою среду разработки. Как можно сильнее.
Не облегчайте следующим разработчикам начало работы надо кодом. Требуйте специфичные версии языков и утилит, и не забудьте убедиться, что они конфликтуют с версиями, которые поставляются с операционной системой. Настраивайте Eclipse, или Visual Studio, или vim как безумный, затем пишите макросы и скрипты, которые работают только с этой средой. Не храните образ диска или сценарии для репликации вашей среды разработки, не беспокойтесь писать документацию — все и так будет интуитивно понятным.
Создавайте максимально сложную систему сборки и развертывания
Для веб-сайта развертывание на тестовый или боевой сервер должно быть чем-то из этого:
svn up
git pull
hg pull
Программисты могут спорить о простоте и элегантности кода, а затем резко разворачиваются и строят наиболее сложные и причудливые системы сборки и деплоймента. Это является одной из неотслеживаемых вещей, которые программисты делают без надзора клиента или ПМ'а (или без их понимания), поэтому это легко выходит из под контроля. Когда вы объединяете в цепочку восемь разных инструментов с различными языками сценариев, даже не думайте делать документацию.
Не разворачивайте тестовые/промежуточные системы
Изменение на боевой системе — это захватывающе! Не думайте о тестовом/промежуточном сервере. Вместо этого используете секретные логины и тайные URL для тестирования новых фич. Смешивайте тестовые данные с реальными в своих БД. Раз уж вы не используете контроль кода, то сохраняйте копии предыдущих версий на всякий случай. Не встраивайте логгирование в код. Не отключайте исходящие е-мэйлы, авторизацию по кредитным картам, итд во время тестирования.
Пишите все с нуля
Не связывайтесь с хорошо известными фреймворками вроде Django, Rails или CakePHP. Вы можее написать лучший шаблонизатор, ORM, алгоритм сортировки или хэширования. Я чешу затылок каждый раз, когда вижу комментарии вида «быстрее, чем нативный метод» или «замена библиотечной функции PHP, потому что порядок параметров — отстой».
Добавляйте зависимости от определенных версий библиотек и ресурсов...
Добавляйте столько стороннего кода, сколько можете. Линкуйте столько динамических библиотек, сколько вам нужно. Я видел код, зависящий от огромных внешних библиотек, только чтобы получить доступ к одной функции. Изменяйте исходный код сторонних библиотек, чтобы они не могли автоматически обновляться до свежих версий, но не беспокойтесь о ветвлении или сохранении ваших модифицированных версий под системой контроля версий. Я смогу сравнить вашу версию с оригинальной и разобраться с этим.
… Но не защищайте и не документируйте эти зависимости.
Я получаю важных звонков из-за обновлений и модернизаций больше, чем по какой-либо причине. Выглядящие безобидными обновления WordPress'а, апдейт линукса или новый релиз jQuery вызывают цепную реакцию сбоев. Не делайте в своем коде проверку на специфичную версию или модифицированную версию ваших внешних ресурсов или сторонних библиотек. Даже не добавляйте комментарий, чтобы напомнить себе.
Используйте кучу разных языков программирования и оставайтесь ультрасовременными
Каждый день HackerNews и Reddit жужжат о новых крутых языках. Попробуйте их за счет клиента. Любой приличный программист может выучить новый язык в мгновение ока, так что если следующий программист, который будет работать с вашим кодом, окажется нубом, то это не ваша проблема. Различия между языками, несовместимые API и форматы данных, различные требования к серверной конфигурации — это веселые приключения и посты на StackOverflow. Я действительно видел веб-сайты на PHP c вставками на Ruby, потому что каждый знает, что Ruby — круто, а PHP — отстой. Полувымученное кэширование, обрезанные проекты на Rails и Node.js и, особенно, NoSQL-решения («Они лучше масштабируются!») — это мой хлеб с маслом.
Где же программистские советы?
Не так заметно, если ваш код прекрасно объектно-ориентирован или блестящ и функционален — ведь программисты почти всегда видят спагетти-код, который им надо поддерживать. Я хорош в использовании diff, grep и Ctags, трассировке кода, рефакторинге и отладке. Я понимаю код. С самым прекрасным, элегантным кодом все еще сложно работать, если нет системы контроля версий, если слишком много зависимостей и настроек, если нет тестовой/промежуточной системы. Это как найти одну чистую и мило украшенную комнату в доме «Hoarders».
Автор: vovochkin
