программный код нужно писать так, как если бы дальнейшим сопровождением занимался агрессивный социопат, который точно знает, где вы живете.
8 Ұнайды
Ловушка «все будет хорошо», как и ловушка выгодной цены, базируется на фатальных дефектах человеческой психики. «Выгодная цена» эксплуатирует жадность, а «все будет хорошо» — страх и лень. Мы не любим, когда случается что-то плохое, нам это неприятно. Думать о неприятном заранее — живот заболит. Да и незачем думать, ну вот что может случиться? Все будет хорошо, этой мысли достаточно.
5 Ұнайды
Подход посложнее — не приступать к написанию кода раньше времени, не пытаться сэкономить на ресурсах лишний грошик. Разработка даже самого простого механизма, самой элементарной, казалось бы, функции выстраивается в пять стадий.
1. Анализ. Изучение задачи, изучение текущего положения, выявление противоречий, уточнение неочевидных мест, допущений и ограничений.
2. Проектирование. Разработка «на бумаге». Принятие основных проектных решений (при необходимости с проверкой на быстром прототипе).
3. Кодирование. Собственно написание и отладка кода. Честно говоря, это не самое захватывающее занятие — если все продумано и правильно спроектировано, код является очевидным, и очень жаль, что сам себя он писать пока еще не способен.
4. Проверка. Прежде чем передавать какую-то разработку (даже на тестирование), разработчик обязан самостоятельно проверить, по крайней мере, основной поток событий и поток наиболее очевидных ошибок.
5. Документирование. Написание инструкций по развертыванию, эксплуатации, разрешению известных проблем. Фиксация «на бумаге» наиболее важных и/или сложных проектных решений.
1 Ұнайды
• конкретная задача должна выполняться одним и только одним способом, то есть на стороне потребителя не должно быть выбора между вариантами обращения к программному интерфейсу — для выполнения конкретной частной задачи правильный вариант должен быть единственным.
2. Полная обратная совместимость:
• никакие изменения и обновления в нашем программном коде не должны приводить к ошибкам и даже к изменению поведения на стороне потребителя — единожды где-то написанный вызов нашего программного интерфейса должен оставаться работоспособным и предсказуемым все время, пока соответствующий экспортный метод существует в нашем коде.
3. Полная и актуальная документация:
• каждый экспортный метод, включенный в состав программного интерфейса, должен быть подробно документирован прямо по месту;
• технический заголовок метода должен включать в себя подробное описание — для чего предназначен метод, существуют ли какие-либо технические особенности работы с ним (режим транзакции, перехват исключений и так далее) и подробное описание всех параметров метода;
• документация должна быть настолько полной, что на стороне потребителя при работе с методом не потребуется заглядывать в его реализацию.
4. Лаконичность и осмысленность имен:
• имена методов программного интерфейса должны как минимум полностью соответствовать требованиям, изложенным в стандарте #647 «Имена процедур и функций»61.
5. Логичность и компактность параметров:
• программный интерфейс каждого отдельно взятого экспортного метода, то есть состав и возможные комбинации параметров метода, должен соответствовать принципу соразмерности (см. раздел «Отдельно стоящий метод» выше в этой главе).
Резюмируем:
1) модуль формы управляет формой и вызывает логику через API;
2) логика реализует алгоритмы и манипулирует объектами;
3) объект внутри себя реализует только собственные потребности (проверки, защиты, сцепления с другими объектами и так далее).
• любую вспомогательную логику, если она имеет смысл только внутри формы и нигде более не требуется;
• вызовы программного интерфейса — как объекта, к которому принадлежит форма, так и других объектов/подсистем.
• Любая логика работы объектов данных должна располагаться вне формы и быть доступной через программный интерфейс, хотя бы и служебный:
• наиболее удобным местом для размещения такой логики является модуль менеджера нашего объекта;
• если бизнес-логика является общей для нескольких объектов метаданных, ее лучше разместить в общем модуле.
• Никаких компромиссов.
• Клиентские методы модуля формы могут содержать:
• логику управления элементами формы;
• логику взаимодействия с окружением клиента (локальная и файловая система, и так далее);
• какую-то вспомогательную логику (например, обращение куда-то вовне через HTTP-соединение);
• вызовы серверных методов этого же модуля.
• Серверные методы модуля формы могут содержать:
• логику управления элементами формы;
Разработка программного обеспечения — это искусство писать программу так, чтобы издержки на ее написание, на работу с ней, а также на ее сопровождение и развитие были минимальными.
Преимущества же работы по принципу «не спеша, эффективно и правильно» в том, что это позволяет исключить практически все недостатки разработки «быстро и криво»:
• система устойчива к любым входным данным;
• результат соответствует ожиданиям заказчика;
• код содержит минимальное количество ошибок (если и встречаются, то некритические);
• разработка вполне пригодна для сопровождения, а дальнейшее развитие не потребует переписывать все заново.
У разработки по принципу «не спеша, эффективно и правильно», разумеется, тоже имеются недостатки.
• От разработчика требуется не только мастерство в написании кода, но еще и способности к абстрактному мышлению.
• Также разработчику нужно понимать, что такое бизнес-анализ, и хотя бы мало-мальски уметь мысленно поставить себя на позицию пользователя. Никакой «работы по четкому ТЗ» здесь не будет, любое ТЗ придется потрошить в поисках противоречий и недосказанностей.
• Прямо завтра ничего не заработает. Как говорится, прежде чем поехать, какое-то время будем запрягать.
• Эффективная и вдумчивая разработка кажется значительно дороже быстрой и бездумной. Причем так кажется не какому-то воображаемому критику, а собственному руководству и представителям заказчика.