Working Effectively with Legacy Code (Майкл Физерс, AgileDays-2008)

Короткая ссылка: 2008-12-12-working-with-legacy-code

Ссылки сюда (1) →

Доклад Майкла Физерса был «guest star» всего мероприятия, хотя стоит отметить, что не все смогли выдержать плотную конференцию до самого конца — слушателей было существенно меньше, чем в начале дня.

Но тема доклада всегда актуальна, Legacy Code это вечное проклятие невезучих программистов (т.е. тех, которых бросают на поддержку чужого кода), и legacy code вечен — да, старые информационные системы умирают, но проходит пару лет, и даже твой супер-крутой код становиться legacy… . Трудно удержаться и не процитировать соответствующие комиксы Дильберта:

На модельном примере класса «расписание» (Schedule), написанном на Java, Физер показал как сделать его тестопригодным. Основной прием свелся к N-кратному применению Dependency injection. Причем, на наш вкус с некоторым перебором: даже статические helper-методы определения является ли день выходным или рабочим были перенесены в нестатический класс, а в тесте было предложено их «заглушить», написав соответствующего наследника. ИМХО это уже другая крайность: когда тестируется функциональность ровно одного класса, а всё, что он использует, либо заглушено при помощи Stub-ов, либо эмулируется при помощи Mock-ов (см. http://martinfowler.com/articles/mocksArentStubs.html). Это так можно получить результат как в репризе Райкина «претензии к пуговицам есть — нет, пришиты намертво…»

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/25505404?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>

Видео в HD-качестве, смотрите в полноэкранном режиме.

HTML-код включения <iframe src="http://player.vimeo.com/video/25520076?byline=0&portrait=0" width="720" height="405" frameborder="0"></iframe>

А пока, мы рекомендуем заинтересованным темой, прочитать книгу «Рефакторинг с использованием шаблонов».

---

Внимание! Данная статья выбрана для репликации во внешнюю базу знаний компании. Пожалуйста, не допускайте в этой статье публикацию конфиденциальной информации, ведения обсуждений в теле статьи, и более ответственно относитесь к качеству самой статьи — проверяйте орфографию, пишите по-русски, избегайте непроверенной вами информации.