Цитаты из книг автора «Роберт Мартин»

Каждая из этих архитектур способствует созданию систем, обладающих следующими характеристиками:  Независимость от фреймворков. Архитектура не зависит от наличия какой-либо библиотеки. Это позволяет рассматривать фреймворки как инструменты, вместо того чтобы стараться втиснуть систему в их рамки.  Простота тестирования. Бизнес-правила можно тестировать без пользовательского интерфейса, базы данных, веб-сервера и любых других внешних элементов.  Независимость от пользовательского интерфейса. Пользовательский интерфейс можно легко изменять, не затрагивая остальную систему. Например, веб-интерфейс можно заменить консольным интерфейсом, не изменяя бизнес-правил.  Независимость от базы данных. Вы можете поменять Oracle или SQL Server на Mongo, BigTable, CouchDB или что-то еще. Бизнес-правила не привязаны к базе данных.  Независимость от любых внешних агентов. Ваши бизнес-правила ничего не знают об интерфейсах, ведущих во внешний мир.

Так оно и происходит. Несмотря на годы постоянных напоминаний о том, что каждая затребованная заказчиком функция всегда оказывается сложнее, чем кажется из его объяснений, вы соглашаетесь. Вы действительно верите, что на этот раз все будет сделано за две недели. Да! Мы справимся! На этот раз все будет иначе! Несколько графических изображений и обращение к службе для получения адреса магазина. XML! Запросто. Мы справимся. Поехали!

Когда прямо на вас мчится грузовой поезд и никто, кроме вас, его не видит, у вас есть выбор: либо молча отойти в сторону и посмотреть, как он задавит всех остальных, либо закричать: «Поезд! Немедленно уходите!»

Читайте книги, статьи, блоги, твиты. Посещайте конференции и собрания пользовательских групп. Участвуйте в работе исследовательских групп. Изучайте то, что лежит за пределами вашей привычной зоны. Если вы программист. NET – изучайте Java. Если вы программируете на Java – изучайте Ruby. Если вы программируете на C – изучайте Lisp. А если вам захочется серьезно поработать мозгами, изучайте Prolog и Forth!

Профессиональные разработчики настолько уверены в своем коде и тестах, что они с легкостью вносят случайные, спонтанные изменения. Они могут ни с того ни с сего переименовать класс. Заметив слишком длинный метод во время чтения модуля, они по ходу дела разбивают его на несколько меньших методов. Они преобразуют команду switch в полиморфную конструкцию или сворачивают иерархию наследования в линейную цепочку. Короче говоря, они относятся к коду так же, как скульптор относится к глине – они постоянно разминают его и придают новую форму.

Разработчикам ПО в начале работы требуется освоить целый ряд инструментов: • Хотя бы один язык программирования, а чаще больше. • Интегрированную среду разработки или текстовый редактор, подходящий программисту (vim, Emacs и т. д.). • Различные форматы данных (JSON, XML, YAML и т. д.) и языки разметки (в том числе HTML). • Командную строку и скрипты для взаимодействия с операционной системой. • Системы управления версиями (Git. Тут без вариантов). • Средства для непрерывной интеграции и сборки (Jenkins, TeamCity, GoCD и т. д.). • Средства развертывания и управления сервером (Docker, Kubernetes, Ansible, Chef, Puppet и т. д.). • Средства коммуникации (электронная почта, Slack, английский язык). • Инструменты тестирования (фреймворки для модульного тестирования, Cucumber, Selenium и т. д.).

Рефакторинг – это метод улучшения структуры кода без изменения его поведения, определенного тестами.

Поскольку вы сначала пишете тест, то естественным образом проектируете функцию так, чтобы ее легко было протестировать.

Права клиента У клиента есть следующие права: • Ознакомиться с общим планом, знать, что и когда можно получить и за какие деньги. • Получать наилучшую, насколько это возможно, отдачу от каждой итерации. • Отслеживать ход работ, назначать необходимые тесты, получить рабочее и многократно протестированное программное обеспечение. • Изменять решения, функциональность и приоритеты, не неся непомерных расходов. • Получать сведения о графике работ, изменениях сроков, чтобы вовремя принять решение о том, как сократить объем работ и успеть к нужному числу. Отменить проект в любое время и получить полезный рабочий код, который оправдывает текущие вложения средств. Права разработчика У разработчика есть следующие права: • Знать, что требуется от команды, а также иметь четкое представление о поставленных приоритетах. • Выполнять работу качественно, несмотря ни на какие обстоятельства. • Получать помощь от коллег, руководителей и самих клиентов. • Проводить оценку задачи и уточнять ее в зависимости от обстоятельств. • Брать на себя личную ответственность и не позволять возлагать на себя лишнее. Все эти утверждения звучат весьма громко. Давайте рассмотрим их по очереди.

В нашей сфере все быстро меняется. И мы должны быть способны меняться вместе с ней. Так что век живи – век учись!