Максим затронул важную тему модульного тестирования, являющуюся краеугольным камнем всех гибких методик: если изначально неизвестно, что выстроится в итоге, дом или коровник, то подпорки у его стен должны быть в любом случае.
Излишне религиозная атмосфера превратила вполне здравую и работающую с 1970-х годов технологию модульных тестов в настоящий карго-культ. Подобно жителям островов Меланезии, старательно строящих соломенные аэропланы для привлечения сбрасывающих груз транспортных самолётов, адепты 100 % покрытия кода модульными тестами считают, что это обеспечит успех проекту.
Разработка модульных тестов – это тоже разработка. Для 100 % покрытия потребуется примерно столько же времени, сколько и на основную работу. А может, и больше, смотря как подойти к делу. По моим наблюдениям, соотношение объёмов рабочего и тестирующего кода примерно 1 к 2.
...
В отличие от тестов функциональных, завязанных на интерфейсы подсистем, модульные тесты требуют переработки одновременно с рефакторингом рабочего кода. Это увеличивает время на внесение изменений и ограничивает их масштаб, приучая разработчика минимизировать реструктуризацию , заменяя её надстройкой, быстро трансформирующей архитектуру в Ад Паттернов.
Модульные тесты тоже бывают сложными, а значит, с высокой вероятностью могут содержать ошибки. Тогда возникает дилемма: оставить всё как есть или перейти к мета-тестированию, то есть создавать тест для теста.
Наконец, модульный тест – это самый нижний уровень проверок. Прохождение серии модульных тестов вовсе не гарантирует, что пройдут функциональные тесты.
Практические выводы. Соизмеряйте затраты на создание и поддержу автоматизированных модульных тестов с бюджетом проекта и располагаемым временем. Тем более плохо фанатично навязывать разработку «от тестов», умалчивая о названных особенностях и не учитывая другие возможности. Например, код, генерируемый по моделям, вообще не требует модульных тестов.
Говорящие изменения в MSF и выключатель
Мне с давних пор импонирует подход, описанный в MSF [122] . Прежде всего масштабируемостью, относительной логичностью, разумными ограничениями на совмещение ролей в проекте. Но целью написания этих строк вовсе не является продвижение технологий известной всем корпорации, думаю, и без меня для этих целей найдутся хорошо оплачиваемые консультанты.
Интерес представляет следующий факт: в своей текущей редакции MSF 4.0 была разделена на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement.
CMMI, или Capability Maturity Model Integration, – модель зрелости процессов организации вообще и софтостроения в частности. Ключевое слово здесь именно «зрелость», описываемая в CMMI несколькими уровнями организации: от хаоса до системы качества.
Соответственно, одно из нынешних направлений MSF предназначено для достижения зрелости процессов софтостроения или дальнейшего улучшения процессов уже более-менее зрелых организаций. А второе… для гибкой разработки.
В завершение темы было бы непростительно не вспомнить о производственной системе Toyota, которую почему-то считают основой того же скрама. Ключевой особенностью системы в Тойоте является принцип «дзидока» ( jidoka ), означающий самостоятельность людей в управлении автоматизированной производственной линией. Если рабочий видит нарушение качества продукции или хода процесса, он имеет право, повернув соответствующий рубильник, остановить всю линию до установления причин дефектов и их устранения.
Внедрение таких методик вполне возможно и вне рамок японского общества. New United Motor Manufacturing Inc (NUMMI) – знаменитое совместное предприятие Toyota и General Motors, ещё в 1970-х годах вошло в «кейсы» бизнес-школ как пример повышения эффективности и качества через смену культуры работы.
Качество программного продукта – многозначное и сложное понятие. Производственная культура – ещё более сложное. В одном можно быть уверенным: ни о какой культуре софтостроения не может идти и речи, если любой программист из коллектива не способен остановить бессмысленный циклический процесс для выяснения, какого же рожна по историям заказчика потребовалось обобщать четырёхногих коров и обеденные столы.
Приключения с TFS
Как вы заметили, я стараюсь перемежать темы, несколько напрягающие мыслительные органы, с занимательными зарисовками из жизни. Продолжим традицию историей о совместимости компонентов сложной тиражируемой системы.
К концу одной недели установка системы под названием MS Team Foundation Server 2008 на виртуальном сервере с Windows 2008 и SQL Server 2005 ещё не завершилась, но пользоваться репозиторием уже было можно.
Все началось в предшествующую пятницу. В процессе было задействовано несколько человек и от клиента, и от нашей команды, включая меня по части установки компонентов СУБД. На неделю практически парализована всякая деятельность, ещё не возобновившаяся в полной мере, до сих пор работает только базовый функционал.
Заклинания, «гугление», помощь консультантов по TFS и даже переписка с Microsoft применялись многократно. Моё осторожное предложение «установить за пару часов SVN для небольшой бригады», высказанное перед началом этой «операции «Ы», не встретило понимания. Тогда как использовать систему предполагалось практически только для работы с исходниками, то есть функционал управления задачами не востребован.
Заказчик, в лице своих администраторов, кстати позитивно отнёсшийся к установке SVN – крупная корпорация национального уровня со своей сложившейся внутренней инфраструктурой и несколькими уровнями бюрократии в эксплуатационном секторе, что означает: все решения принимаются медленно и проходят длительные согласования. Но команда привыкла работать в TFS.
Второе отступление по поводу требуемых компонентов. Собственно, TFS 2008, как выяснилось, требует для себя:
• SQL Server 2005 или выше;
• Reporting Services 2005 или выше;
• Analysis Services 2005 или выше;
• Sharepoint Services не ниже 3 SP1;
• Internet Information Server 6 или выше;
•.NET 3.5 SP1;
• ещё что-то по мелочи вроде конкретных хотфиксов.
По мере изучения сего списка я постепенно впадал в прострацию, сравнивая с ничего не требующим пакетом SVN.
Версия MS SQL Server 2005, поскольку 2008 клиентом не эксплуатируется и даже ещё не куплена. Гетерогенная сеть хоть и интегрируется с Active Directory, но не до конца: интегрированная безопасность ( integrated security ) для клиентов не работает, так как они входят в сеть под профилем NetWare. Ну, и ладно бы с этим, ведь создать регистрации на небольшую группу в TFS несложно, как и в SVN. Плохо другое, доступ с компьютера либо в Интернет с аутентификацией через прокси, либо в локальную сеть к серверам. То есть работать в режиме переключения с терминала на Интернет в браузере с обычного рабочего места нельзя, эта опция доступна только с компьютеров администраторов в отделе поддержки. В итоге все манипуляции проходят именно там в паре с сотрудниками компании.
Изначально под TFS был выделен виртуальный сервер с Win 2008, но базы данных необходимо располагать на другом сервере в обслуживаемом поддержкой кластере.
Предлагаю использовать виртуальный сервер с Win 2003, чтобы избежать возможных проблем с 2005-ми версиями программ. Снова не встречаю понимания, так как скопировать образ – лениво, да и вообще надо переходить на новые технологии.
Через полтора дня ко мне обращаются за консультацией по этому поводу. Устанавливаем службу отчётов ( Reporting Service ). У 2005-й версии Reporting Services на 2008 сервере есть проблемы с Internet Information Server 7. Дополнительно устанавливаем совместимость с IIS 6. Базу данных на удалённом сервере программа установки создаёт. Танцуем с бубном вокруг создания Identity, но кроме как в Default Application Pool сервис не ставится. Танцы через несколько часов прекращаем, остаёмся в этом пуле.