Мне платят за то, что я возвращаю чужой технический долг. В своей работе я вижу много сложного в поддержке кода, и я снова и снова вижу много проблем, которых можно было избежать.
Я специализируюсь на отладке, исправлении, поддержке и расширении функциональности старого программного обеспечения. Мой типичный клиент имеет веб-сайт или приложение, которое более-менее работает, но автор которого недоступен. Бизнес-требования изменились, и ПО перестало им удовлетворять. Или у моего клиента есть что-то, что «уже закончено», но он расстался с разработчиком после исчерпания бюджета и сроков. Обычно такая ситуация сопровождается списком пропущенных фич и багов.
Мой типичный клиент обычно разговаривал с другими программистами, которые рекомендовали выбросить имеющееся и начать разработку с нуля. Большинство программистов не любит поддержку кода, и особенно, они не любят поддержку чужого кода.
При написании кода программисты часто задают неверные вопросы, когда говорят о дальнейшей поддержке кода — см. статью Matt DuVall’а «Миф поддержки», чтобы понять, как это случается. Ниже несколько практик, которым вам надо следовать в своих проектах, чтобы не оставить меня без работы:
Программисты могут спорить о простоте и элегантности кода, а затем резко разворачиваются и строят наиболее сложные и причудливые системы сборки и деплоймента. Это является одной из неотслеживаемых вещей, которые программисты делают без надзора клиента или ПМ'а (или без их понимания), поэтому это легко выходит из под контроля. Когда вы объединяете в цепочку восемь разных инструментов с различными языками сценариев, даже не думайте делать документацию.
Я специализируюсь на отладке, исправлении, поддержке и расширении функциональности старого программного обеспечения. Мой типичный клиент имеет веб-сайт или приложение, которое более-менее работает, но автор которого недоступен. Бизнес-требования изменились, и ПО перестало им удовлетворять. Или у моего клиента есть что-то, что «уже закончено», но он расстался с разработчиком после исчерпания бюджета и сроков. Обычно такая ситуация сопровождается списком пропущенных фич и багов.
Мой типичный клиент обычно разговаривал с другими программистами, которые рекомендовали выбросить имеющееся и начать разработку с нуля. Большинство программистов не любит поддержку кода, и особенно, они не любят поддержку чужого кода.
При написании кода программисты часто задают неверные вопросы, когда говорят о дальнейшей поддержке кода — см. статью Matt DuVall’а «Миф поддержки», чтобы понять, как это случается. Ниже несколько практик, которым вам надо следовать в своих проектах, чтобы не оставить меня без работы:
Не используйте системы контроля версий
Я всегда удивляюсь, когда сталкиваюсь с большими проектами, написанными в последние несколько лет без системы контроля версий. Когда вы не используете контроль версий, следующий программист должен будет выяснить, какие файлы являются частью текущей системы, а какие — устаревшими или бэкапами. Следующий программист не будет иметь ни единого коммит-сообщения или чэнжлога, чтобы получить историю кода. Я рассказывал, как не использовать системы контроля версий в моей статье «Введение в Ущербно-Ориентированное Программирование».Настраивайте свою среду разработки. Как можно сильнее.
Не облегчайте следующим разработчикам начало работы надо кодом. Требуйте специфичные версии языков и утилит, и не забудьте убедиться, что они конфликтуют с версиями, которые поставляются с операционной системой. Настраивайте Eclipse, или Visual Studio, или vim как безумный, затем пишите макросы и скрипты, которые работают только с этой средой. Не храните образ диска или сценарии для репликации вашей среды разработки, не беспокойтесь писать документацию — все и так будет интуитивно понятным.Создавайте максимально сложную систему сборки и развертывания
Для веб-сайта развертывание на тестовый или боевой сервер должно быть чем-то из этого:svn up
git pull
hg pull
Программисты могут спорить о простоте и элегантности кода, а затем резко разворачиваются и строят наиболее сложные и причудливые системы сборки и деплоймента. Это является одной из неотслеживаемых вещей, которые программисты делают без надзора клиента или ПМ'а (или без их понимания), поэтому это легко выходит из под контроля. Когда вы объединяете в цепочку восемь разных инструментов с различными языками сценариев, даже не думайте делать документацию.