применять в отношении структуры, логики, процесса или функции, он служит базовым руководством для разработчиков программного обеспечения и способствует созданию более простых, легких в сопровождении и более качественных программ. Но хотя и существуют ситуации, в которых повторение оказывается необходимым для достижения нужной производительности или выполнения других требований (например, денормализация данных в базе данных), применять повторение следует только для решения реальных, а не воображаемых проблем.

Этот код не трогать!

Кэл Эванс

С каждым из нас такое когда-нибудь да случалось. Ваш код загружен на промежуточный (staging) сервер для системного тестирования, и руководитель отдела тестирования сообщает вам, что есть проблема. Вы сразу готовы ответить: «Дайте-ка я быстро все исправлю: я знаю, в чем дело».

Однако в более широком смысле проблема в том, что вы как разработчик считаете, что вам должен быть предоставлен доступ к серверу, где осуществляется тестирование.

В большинстве случаев, если речь идет о веб-разработке, архитектуру можно разбить на следующие части:

• Локальная разработка и модульное тестирование на машине разработчика

• Сервер разработки, где проводится автоматическое или ручное интеграционное тестирование

• Промежуточный (staging) сервер, где команда контроля качества и пользователи осуществляют приемочное тестирование

• Боевой (production) сервер

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

После сохранения кода в репозиторий, будь то вручную или автоматически, код должен быть развернут на сервере разработки, где его можно протестировать и при необходимости подправить, чтобы убедиться, что он корректно работает в этой среде. И начиная с этого момента разработчику остается только наблюдать за процессом.

Администратору промежуточного сервера следует упаковать и перенести код на промежуточный сервер, где с ним будет работать группа контроля качества. Подобно тому как разработчики не должны иметь доступ за пределы сервера разработки, группа контроля качества и пользователи не должны выходить за пределы среды тестирования. Если версия готова к приемочному тестированию, собирайте версию и выкатывайте ее: не предлагайте пользователям «по-быстрому глянуть вот на это» на сервере разработки. Помните, за исключением ситуаций «один воин в поле», на сервере есть код и других авторов, которые могут быть не готовы к показу его пользователям. Ответственный за выпуск версий — единственный человек, у которого должен быть доступ к обоим серверам.

Ни в коем случае — ни при каких обстоятельствах — разработчик не должен быть допущен к боевому серверу. Если возникнут проблемы, команда поддержки должна либо справиться с ними сама, либо предложить вам внести исправления. Когда вы сохраните исправление в репозиторий, команда поддержки возьмет «заплатку» оттуда. Кое-какие ужаснейшие осложнения на проектах с моим участием возникали из-за того, что кое-кто (догадайтесь, кто) нарушил это правило. Если приложение сломалось, боевой сервер — не место для внесения исправлений.

Инкапсулируйте поведение, а не только состояние

Эйнар Ландре

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

Модули и пакеты решают задачи инкапсуляции крупного масштаба, в то время как классы, подпрограммы и функции призваны решать те же задачи на более низком уровне. За годы работы я обнаружил, что из всех видов инкапсуляции тяжелее всего программистам дается инкапсуляция в классах. Нередко встречается класс, единственный метод main которого имеет 3000 строк, или же класс, в котором есть только методы set и get для его элементарных атрибутов. Такие примеры показывают, что разработчики этих классов не вполне освоили объектно-ориентированное мышление и не умеют воспользоваться мощью объектов как моделирующих конструкций. Для тех, кто знаком с терминами POJO (Plain Old Java Object — простой Java-объект в старом стиле) и POCO (Plain Old C# Object или Plain Old CLR Object), замечу: изначально они выражали возврат к основам ООП как парадигмы моделирования — понятным и простым, но не тупым объектам.

Объект инкапсулирует как состояние, так и поведение, причем поведение определяется фактическим состоянием. Возьмем объект «дверь». У него четыре состояния: открыта, закрыта, открывается, закрывается. Он предоставляет две операции: «открыть», «закрыть». В зависимости от состояния операции «открыть» и «закрыть» ведут себя по-разному. Это неотъемлемое свойство объекта делает процесс проектирования концептуально простым. Все сводится к двум простым задачам: назначению и делегированию обязанностей различных объектов, включая и протоколы межобъектного взаимодействия.

Лучше всего показать, как это работает, на примере. Допустим, у нас есть три класса: Customer (Покупатель), Order (Корзина) и Item (Товар). Объект Customer — естественный источник правил проверки платежеспособности и определения максимальной суммы, доступной для списания. Объект Order знает, какой Customer с ним связан, так что операция addItem (добавитьТовар) делегирует фактическую проверку платежеспособности методу customer.validateCredit(item.price()) (покупатель.проверитьПлатежеспособность(товар.цена())). Если постусловие метода не выполнено, можно сгенерировать исключение и отменить покупку.

Менее опытные в ООП разработчики иногда решают обернуть все бизнес-правила в один объект, который часто называют OrderManager (МенеджерЗаказов) или OrderService (СлужбаЗаказов). В такой архитектуре объекты Order, Customer и Item, по сути, служат табличными типами. Вся логика выводится из классов и увязывается в одном большом процедурном методе, содержащем множество конструкций if-then-else. В методы такого рода легко вкрадываются ошибки, и сопровождать их почти невозможно. Почему? Потому что инкапсуляция нарушена.

Заключение напоследок: не нарушайте инкапсуляцию и используйте мощь своего языка программирования, чтобы ее поддерживать.

Числа с плавающей запятой недействительны

Чак Эллисон

Числа с плавающей запятой не являются «действительными числами» в математическом смысле, хотя в некоторых языках программирования, например в Pascal и Fortran, носят название таковых (real). Действительные числа имеют бесконечную точность, и потому они непрерывны и не подвержены искажениям. Числа с плавающей запятой имеют ограниченную точность, а потому конечны и похожи на «непослушные» целые, так как неравномерно распределены по всему своему диапазону.

Чтобы проиллюстрировать это, попробуйте присвоить 2147483647 (самое большое 32-разрядное целое со знаком) 32-разрядной переменной типа float (скажем, x), а потом напечатайте