public class Employee {
public Money calculatePay()…
}
public class EmployeeReporter {
public String reportHours(Employee e)…
}
public class EmployeeRepository {
public void save(Employee e)…
}
Каждый класс можно поместить в отдельный компонент. Или, выражаясь точнее, все классы, создающие отчеты, поместить в компонент отчетов. Все классы, связанные с базами данных, можно поместить в компонент хранилища. А все бизнес-правила поместить в компонент бизнес-правил.
Внимательный читатель заметит, что в приведенном решении остаются зависимости. Другие классы по-прежнему зависят от Employee. Поэтому если Employee изменится, вполне возможно, что эти классы придется заново скомпилировать и развернуть. Таким образом, Employee невозможно модифицировать, а потом развернуть независимо. Однако другие классы можно модифицировать и независимо развернуть. Никакая их модификация не требует перекомпиляции и повторного развертывания остальных классов. Даже Employee можно независимо развернуть, если тщательно применить принцип инверсии зависимости (DIP, dependency inversion principle), но это уже тема для другой книги.[27]
Продуманное применение принципа единственной ответственности, то есть разделение тех сущностей, которые изменяются по разным причинам, является одной из основ создания архитектур со структурой независимо развертываемых компонентов.
Сначала скажите «да»Алекс Миллер
Недавно я был в продуктовом магазине и обыскался там эдамаме, зеленых соевых бобов (я лишь приблизительно догадывался, что это какие-то овощи). Я не знал, где мне искать этот продукт: в овощном отделе, в отделе замороженных продуктов или на полках с консервами? Наконец я сдался и обратился за помощью к сотруднице магазина. Она тоже не знала!
Сотрудница магазина могла отреагировать на мою просьбу по-разному. Она могла дать мне понять, что только дурак не знает, где это искать, или отделаться туманными намеками, или даже просто сказать, что у них нет такого товара. Но она посчитала возможным найти решение и помочь покупателю. Позвав других сотрудников, она уже через пару минут отвела меня к нужному товару. Эдамаме оказались в отделе замороженных продуктов.
В данной ситуации сотрудница выслушала просьбу и стала исходить из того, что проблема решится, и просьба будет удовлетворена. Она начала с того, что сказала да вместо нет.
Когда мне впервые пришлось занять должность технического руководителя, мне казалось, что главное в моей работе — защищать мои прекрасные программы от потока нелепых требований, исходившего от менеджеров по продукту и бизнес-аналитиков. В большинстве разговоров я рассматривал любую просьбу как атаку, требующую защитной реакции, а не положительного ответа.
В какой-то момент на меня снизошло прозрение, и я увидел, что возможен другой подход к работе, который отличается от моего всего лишь начальным да вместо начального нет. Я пришел к убеждению, что начинать разговор с положительного ответа — важнейшая часть работы технического руководителя.
Эта простая перемена радикально изменила мой подход к работе. Оказалось, существует много способов говорить. Когда слышишь: «Послушай, это приложение станет в сто раз круче, если мы сделаем все окна круглыми и прозрачными!», можно отвергнуть это предложение как нелепое. Но обычно лучше сначала спросить: «А почему?». Часто существует реальный и убедительный довод, почему этот человек требует круглые прозрачные окна. Например, ведутся переговоры с новым крупным клиентом, у которого комиссия по стандартизации требует эти самые круглые прозрачные окна.
Обычно, ознакомившись с контекстом просьбы, обнаруживаешь, что открываются новые возможности. Зачастую просьба может быть выполнена в рамках существующего продукта каким-то другим способом, что позволяет ответить да, нисколько не напрягаясь: «Собственно говоря, вы можете загрузить в пользовательских настройках «шкурку» (skin) с круглыми прозрачными окнами и активизировать ее».
Иногда у людей появляются идеи, которые кажутся несовместимыми с вашим видением продукта. Я обнаружил, что в этом случае обычно полезно обратиться с вопросом «почему» к самому себе. Порой сама попытка объяснить себе причину помогает понять ошибочность первой реакции. Если это не так, то можно облегчить ситуацию, включив в обсуждение других ответственных лиц. Помните, что цель всего этого — сказать да другому человеку и попытаться сделать так, чтобы все получилось, и не только ради него, но ради себя и всей своей команды.
Если вы сможете убедительно объяснить, почему предложенная функция не совместима с существующим продуктом, это даст возможность конструктивно обсудить, нужный ли продукт вы создаете. Независимо от результатов обсуждения каждый участник более четко осознает, чем продукт является, а чем не является.
Начинать с да — значит работать вместе со своими коллегами, а не против них.
Шаг назад. Теперь автоматизируй, автоматизируй, автоматизируй…Кэй Хорстман
Я работал с программистами, которые в ответ на просьбу посчитать количество строк кода в модуле открывали файлы в текстовом процессоре и пользовались функцией «счетчик строк». То же самое они повторяли через неделю. И еще через неделю. Это было ужасно.
Я участвовал в проекте с неуклюжей процедурой развертывания: требовалось подписать код, скопировать подписанный код на сервер, выполнить множество щелчков мышью. Кто-то автоматизировал процедуру, и этот сценарий запускался сотни раз во время финального тестирования — гораздо чаще, чем ожидалось. Это было замечательно.
Так почему же люди делают одну и ту же работу многократно, вместо того чтобы остановиться и потратить время на ее автоматизацию?
Распространенное заблуждение № 1: автоматизация нужна только для тестирования
Да, автоматизация тестирования — это классно, но зачем останавливаться на этом? Любой проект изобилует повторяющимися задачами: управление версиями, компиляция, сборка JAR-файлов, генерация документации, развертывание системы и составление отчетов. Для многих из перечисленных задач эффективнее использовать сценарий, а не указатель мыши. Выполнение рутинных задач ускоряется и становится надежным.
Распространенное заблуждение № 2: у меня есть IDE, поэтому мне не нужна автоматизация
Приходилось ли вам участвовать в спорах с коллегами на тему «А на моей машине все компилируется (все загружается из репозитория, все тесты проходят)»? Современные IDE предлагают тысячи настроек, и фактически невозможно гарантировать, что у всех участников команды настройки будут одинаковыми. Системы автоматизации сборки, такие как Ant или Autotools, обеспечивают контроль и повторяемость.
Распространенное заблуждение № 3: для автоматизации придется изучать экзотические инструменты
Можно успешно построить систему автоматизации на базе хорошего языка командной оболочки (например, bash или PowerShell). Если требуется взаимодействовать с веб-сайтами, воспользуйтесь такими инструментами, как iMacros или Selenium.
Распространенное заблуждение № 4: я не могу автоматизировать эту задачу, потому что не смогу работать с файлами этого формата
Если ваш процесс требует работы с документами Word, электронными таблицами или графикой, автоматизация действительно может стать сложной проблемой. Но так ли вам необходимы эти форматы? А нельзя ли использовать обычный текст? Значения, разделяемые запятой? XML? Средства генерации графики из текстовых файлов? Часто достаточно немного изменить процесс, чтобы получить хорошие результаты и резко сократить рутинные операции.
Распространенное заблуждение № 5: у меня нет времени со всем этим разбираться
Чтобы начать, вам не обязательно досконально изучать bash или Ant. Учитесь на ходу. Когда вы видите задачу, которую можно и нужно автоматизировать, изучите свои инструменты лишь настолько, насколько требуется в данный момент. И занимайтесь этим в самом начале проекта, когда обычно легче найти время. После первого удачного опыта вы (и ваш начальник) убедитесь, что автоматизация окупает потраченные усилия.
Пользуйтесь инструментами для анализа кодаСара Маунт
Важность тестирования вколачивают в головы разработчиков программного обеспечения, когда они делают свои первые шаги на этом поприще. Широко распространившиеся в последние годы модульное тестирование, разработка на основе тестирования и методы гибкого программирования свидетельствуют о росте интереса к максимально эффективному использованию тестирования на всех стадиях цикла разработки. Однако тестирование — лишь один из многочисленных инструментов, с помощью которых можно повысить качество кода.
В те далекие времена, когда язык C еще был молод, процессорное время и память всех видов обходились очень дорого. В первых компиляторах C это учитывалось, поэтому количество проходов по коду сокращалось за счет отказа от некоторых видов семантического анализа. В результате компилятор проверял лишь небольшую часть тех ошибок, которые можно было обнаружить на этапе компиляции.
Чтобы компенсировать этот недостаток, Стивен Джонсон написал инструмент под названием lint — для прочесывания кода на предмет блох, — и реализовал в нем некоторые методы статического анализа, исключенные из компилятора C. Однако средства статического анализа прославились тем, что давали большое количество ложных срабатываний и часто предупреждали о нарушении стилистических правил, следовать которым необязательно.