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