Не спеша, эффективно и правильно – путь разработки. Часть 3. Практика

Коллеги, вашему вниманию предлагается почти финальный вариант моей книжки. Была и остается идея издать это в бумажном варианте, но идея довольно зыбкая. К сожалению, имеются некоторые проблемы со здоровьем. Но очень хочется, чтобы труд не пропал, поэтому книжка отдается в открытый доступ. Можно публиковать где угодно, цитировать и так далее. Единственное условие — ничего в тексте не менять и указывать авторство. Автор текста — Никита Викторович Зайцев (также известный как WildHare).

Книжка повествует об эффективной разработке программного обеспечения. Можно сказать, что это дистиллят моей личной практики, наработанного опыта, знаний и умений.

Предыстория появления книжки в формате интервью порталу Инфостарт:

//infostart.ru/journal/news/mir-1s/nikita-zaytsev-ya-universalnyy-soldat-v-mire-1s_1250753/

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

Приятного чтения ;-)

Автор в естественной среде обитания — III

Стартовая площадка

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

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

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

Предположим, что это задача разработки.

Казалось бы, что может быть проще? Вот борщ, вот ложка, как получится, так и съешь. Но если присмотреться повнимательнее, можно рассмотреть множество мелких и важных деталей, влияющих на процесс. Например, как правильно держать ложку?

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

Но важнее всего, что такой подход помогает нам абстрагироваться от содержимого чашки. Там может быть что угодно — борщ, гороховый суп, окрошка, солянка, прекрасный испанский гаспачо, несъедобное тайское неизвестно-что из акульих плавников — манипуляции с чашкой, ложкой и собственными руками от этого не зависят. Понятно, что задача разработки несколько сложнее чашки борща, и никто в здравом уме не пишет трактатов о поедании супа. Но и в нашей с вами любимой отрасли есть свои чашки, плошки, тарелки, вилки, ложки, половники, ножи с плоским лезвием, ножи с зубчиками, ножи с крючочком, и еще огромная уйма всякой столовой утвари, с которой разработчику нужно уметь правильно обращаться. А это умение как раз и складывается из универсальных правил и методик, которые можно сформулировать, выведя саму задачу за скобки. И стоит взять обратно те слова, где трактат о поедании супа подвергается сомнению, в любом учебнике этикета обязательно найдется соответствующая глава. Хотя все суповые манипуляции, назовем их так, являются интуитивно понятными и должны быть усвоены человеком еще в детстве, достаточно зайти в любой ресторан хотя бы средней руки и внимательно присмотреться к соседям, чтобы понять — все эти главы были добавлены в учебники не просто для раздувания объема текста.

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

Прежде чем переходить к изложению третьей части, необходимо сделать несколько технических пояснений. Первое и оно же главное. Все изложенные далее правила и принципы являются обязательными к применению в повседневной деятельности разработчика, если разработчик не считает слово “эффективность” пустым. Само по себе знание правила или принципа не может принести никакого профита. Возвращаясь к нашей обеденной аналогии, всякий знает, что по утрам следует избегать тяжелой и жирной пищи, если только ты не занят на погрузке металлоконструкций или каким-то другим тяжелым физическим трудом на свежем зимнем воздухе. Тем не менее, руки по привычке сами тянутся заменить добротную порцию утренней овсянки или гречки парой свиных колбасок, обесценивая тем самым знания любых правил и принципов эффективного и правильного питания. Поэтому автор рекомендует читателю завести на рабочем столе пару фигурок, которые будут имперсонировать священных коров по имени Эффективность и Необходимость, и пусть они укоризненно глядят на читателя своими умными глазами.

Второе. Текст третьей части снабжен примерами кода, показанного на снимках экрана, весь этот иллюстративный материал подготовлен в Конфигураторе. Дело здесь не в какой-то личной неприязни автора к EDT и не в какой-то личной неспособности освоить этот инструмент. Дело в другом, на момент написания книги EDT все еще находится в статусе пускай уже и зрелого, но все еще экспериментального инструмента разработки. Автор подчеркивает: на момент написания книги.

Ну и третье. В третьей части лирических отступлений будет существенно меньше, а перерыв на кофе — и вовсе единственный. Мы переходим к практической работе, а практическая работа требует концентрации. Зато тех, кто внимательно дочитает до конца, ожидает маленькая десертная конфетка.

Приемы работы с кодом

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

Техническая ремарка: если в тексте правила явно не указаны исключения, это означает, что исключений из правила нет, и быть не может.

Другая техническая ремарка: статьи практической части в своем большинстве построены по единому шаблону. Сперва следует целеполагание, т. е. краткая формулировка целей, достижению которых служат правила; затем следует чеканная формулировка правила, как можно более короткая и емкая; ну а далее следует раскрытие целеполагания в свободной форме. Раскрывать целеполагание в ряде случаев придется через анти-примеры, это будет уместно там, где анти-пример оказывается нагляднее прямого примера. Завершая нашу обеденную аналогию, борщ может быть съеден посредством носа, но все же настоятельно рекомендуется и даже требуется заливать супы в другое отверстие, хотя при известной сноровке и через нос тоже получится.

Названия правил взяты автором в буквальном смысле с потолка, но такой способ представляется лучшим, чем безликая нумерация.

Правило первого экрана

Целеполагание: сделать код легкочитаемым, дефрагментировать сложную логику на простые элементы, не провоцировать нарушение принципа DRY/DIE.

Техническая ремарка: здесь и далее вместо громоздкого словосочетания “Процедура или функция” будет использоваться короткий и более ясный термин “Метод”. Никаких технических различий между процедурой и функцией встроенного языка нет, а термин “Метод”, как более лаконичный, повышает читаемость текста.

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

Исключения из правила: методы, которые возвращают тексты запросов или какие-либо другие объемные строковые фрагменты.

Раскроем целеполагание.

Первая цель — читаемость программного кода. Метод длинною в несколько экранов можно уподобить предложению общечеловеческого текста длинною в целую страницу. Когда читатель добирается до финала такого предложения, он только смутно представляет себе, что же было в середине, и наглухо забывает, с чего и для чего это все началось. Такая техника как нельзя лучше подходит, например, для индийских философских трактатов, авторы которых своей главной целью ставят затуманить мозг читателю. Но специалист, занятый задачами аудита и сопровождения вашего программного кода, вряд ли обрадуются, встретив посреди общего модуля пару глав “Бхагавад-гиты”.

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

И никаких расовых шуток, исключительно советский культурный код.

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

Читатель спросит: “А как же тексты запросов? Они же бывают длинною в километр”. Во-первых, текст каждого запроса должен быть оформлен отдельным методом. Это позволит снабдить запрос внятным комментарием в заголовке метода, а также задействовать один текст запроса в нескольких местах. И во-вторых, по поводу эффективности и производительности запросов длинною в километр рекомендуется побеседовать с опытным специалистом по эксплуатации нагруженных систем, только при беседе нужно иметь позади себя открытое пространство, пригодное для бегства.

Читатель также спросит: “А как же области? Что с ними не так?” С областями не так то, что они предназначены для разделения модуля на логические зоны, и что внедрение областей внутрь метода создает дополнительный и абсолютно лишний уровень гранулированности кода (модуль, метод, а теперь еще и область).

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

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

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

Узнали? Да, это именно она, большая миска спагетти с белорусским “пармезаном” и “майонезом” из соевых бобов.

В приведенном примере требуется расщепить метод как минимум на четыре: проверки, текст запроса, чтение и обработка данных, запись. И только второй из этой четверки имеет право измеряться многими сотнями строк. На замечание читателя о том, что крайне неудобно иметь текст запроса и обработку его результата в разных местах модуля, и что здесь уж точно никаких колесиков не напасешься, следует ответить тремя словами — “Режим разделения экрана”, горизонтальный или вертикальный, кому как удобнее.

И наконец третья цель — не провоцировать себя любимого на манкирование принципом DRY/DIE. Когда внутри одного метода смешано несколько разнородных действий, их невозможно выполнить поодиночке на других участках, и возникает очень большой соблазн “скопировать и чуть-чуть подправить, а потом уже переделать по-человечески”. Понятно, что при постоянной нехватке времени “Потом” тождественно “Никогда”. Если бы автор знал латынь, в этом месте был бы приведен девиз “Так формируется технический долг”.

Сухой остаток: одно действие — один метод — один экран. А если код длиною становится похож на портянку, следует задуматься, кем и с какой целью используются настоящие портянки.

Правило трех параметров

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

Формулировка правила: параметры всякого метода подразделяются на основные и дополнительные; основные параметры передаются классическим образом, как параметры, дополнительные параметры передаются в виде структуры. Количество основных параметров любого метода не должно превышать трех. Структура дополнительных параметров таким образом является четвертым параметром.

Раскроем целеполагание.

С легкостью чтения кода вопросов не возникает. Достаточно посмотреть на пару примеров:

Это авторский код тринадцатилетней, что ли, выдержки. Но есть и полезные стороны, наглядное анти-пособие можно без труда найти в собственном же архиве. Перефразируя одного из любимых футбольных тренеров, “Так кодировать не можно”.

Следует повториться, программный код не завершает свое существование после написания. Единожды написанный метод, внезапно, может быть вызван бессчетное количество раз в других местах конфигурации. Чем больше у метода параметров, тем более громоздким и менее понятным становится вызов метода. Именно поэтому в системе стандартов и методик разработки фирмы “1С” существуют стандарты 640 и 641, которые в частности рекомендуют следующее:

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

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

Когда и если количество основных методов перестает укладываться в тройку, наступает самое время подумать — возможно, метод спроектирован слишком сложным и его следует декомпозировать?

Что характерно, общее количество параметров метода этим правилом не ограничивается вообще никак, но проводится четкое разграничение: основная тройка параметров указывает на предмет воздействия метода (объекты данных), а дополнительные параметры регулируют особенности этого воздействия в каждом конкретном случае. Таким образом логика метода становится, если можно так выразиться, более выпуклой. Основная идея, заложенная в метод, оказывается на поверхности и не требует серьезных умственных усилий при беглом чтении кода.

Под третьей целью мы обозначили простую и легкую расширяемость программного кода. Здесь читателю в который уже раз следует обратить взор на маленькую статуэтку коренного жителя бескрайних северных просторов и в очередной раз услышать: “Существование кода не завершается его написанием”. Вселенная не стоит на месте, бизнес-схемы и законодательная база активно изменяются, с течением времени появляются новые требования, а уже написанная логика теряет актуальность. Сопровождение кода, как было показано выше, в первой и второй частях, является наиболее сложной разновидностью разработки. Единственно верным способом в большей части кейсов сопровождения является доработка посредством расширения. В данном конкретном случае расширение функциональности неизбежно потребует передачи в метод новых параметров. При обычном подходе количество параметров, изначально разумное, с каждой доработкой будет увеличиваться и в конечном итоге возможна откровенно гротескная ситуация вроде той, которая изображена на иллюстрации. Пример не умозрительный, взято из реального проекта (но этот код, слава дорогому мирозданию, все-таки принадлежит другому перу, не авторскому).

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

Дополнительной косвенной выгодой от внедрения правила можно считать довольно тонкую материю по имени “Дисциплинированность инженерного решения”, возникающую в умах разработчиков. Это как раз тот случай, когда полная свобода действий является пусть и небольшим, но все-таки отчетливо различимым злом, когда из изначального условия “Можно сделать как угодно” следует вывод “Можно сделать как угодно неряшливо”. Строгость правила может показаться избыточной, но следует учесть, что решается не только конкретная техническая задача, упростить код и его сопровождение, но также решается и задача психологической тренировки. Строгость правила при этом оборачивается строгостью мышления специалистов, применяющих правило в своей практике.

Вдумчивый читатель спросит: “Если дополнительных параметров будет действительно много, не будет ли это провоцировать на ошибки, не потребуются ли сложные громоздкие проверки или что-то в этом роде?” Если применить правильную технику работы с дополнительными параметрами — нет, проблем не будет. Правильная техника показана на иллюстрации и дополнительных объяснений, будем надеяться, не требует.

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

Правило обязательной полезной аннотации

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

Формулировка правила: каждый метод должен содержать текстовую аннотацию, раскрывающую назначение и особенности эксплуатации метода. Также в аннотации должны быть перечислены и описаны все параметры метода и все варианты возвращаемого значения, если метод технически является функцией. Формат аннотации должен строго соответствовать образцу, приведенному в стандарте 453 из системы стандартов и методик фирмы “1С”.

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

Раскроем целеполагание.

Прежде всего, это максимально легкая читаемость кода. В случае, когда мы имеем дело с чужим методом (собственный программный код, изготовленный более шести месяцев назад, можно смело относить к чужому, это писал совсем другой специалист), и когда этот метод снабжен правильной аннотацией, легкость чтения кода приближается к идеальной — читать код не требуется вообще. Аннотация должна быть написана так, чтобы переходить внутрь метода требовалось бы только в каких-то нештатных ситуациях, при возникновении проблем и ошибок.

Очень важный момент, который стоит отлития в гранитной формулировке:

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

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

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

Аннотация курильщика.

Аннотация здорового человека.

Читатель спросит: “Каким образом можно написать внятную и понятную аннотацию для крохотного и самоочевидного метода?” Очень просто.

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

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

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

Памятка заказчику. Хорошо бы сделать проверку наличия правильных аннотаций неотъемлемой частью приемки любых работ. С такой проверкой сможет справиться абсолютно любой сотрудник, квалификация даже начинающего разработчика для этого не требуется. И это делается не для того, чтобы как-то третировать подрядчика / исполнителя, и даже не в целях воспитания, интерес здесь совсем другой — четко и подробно специфицированный код гораздо проще передавать на развитие сопровождения другому исполнителю, чем когда каждый из модулей имперсонирует изделие вида “Молчаливый Боб”.

Правило кластерного индекса

Целеполагание: сделать код легкочитаемым.

Формулировка правила: везде, где каким-либо образом задействован перечень строковых величин, они должны располагаться в алфавитном порядке.

Раскроем целеполагание.

Для этого достаточно посмотреть на иллюстрацию ниже.

Теперь читателю предлагается простое упражнение — методом пристального взгляда, взяв в руки секундомер, определить, содержит ли описанная структура свойство ГруппаТомов. Получилось? А теперь предлагается повторить это же упражнение на второй иллюстрации.

Не будем приводить классическое определение кластерного индекса. Достаточно привести элементарный общечеловеческий пример: в любом словаре и любой энциклопедии словарные статьи расположены по алфавиту. То есть, индекс (элемент механики быстрого поиска) не хранится где-то отдельно, а заключается в самих хранимых данных, точнее в их взаимном расположении. При разработке программного кода правило кластерного индекса должно применяться ко всем ситуациям, где это только возможно: перечисление свойств и колонок; объекты и реквизиты в дереве метаданных; и даже методы внутри области модуля (да, это жестоко, но нет лучшего способа дисциплинировать ум, чем следование таким вот жестоким правилам). Если же правило не используется, чтение кода частенько обрастает дополнительной паразитарной геймификацией в стиле детской игры “Найди Вальдо”.

Исключение из правила: те немногие ситуации, когда порядок объектов, реквизитов или литералов оказывает непосредственное влияние на бизнес-логику программного кода. Например, порядок следования измерений регистра. Менее удачный пример см. в Кофе-паузе #4 (перечисление “Месяц года”).

Сухой остаток: если что-то внутри кода можно отсортировать по алфавиту, необходимо сразу добавлять новый элемент в правильное место. И никак иначе.

Правило еловой табуретки

Целеполагание: сделать код легкочитаемым, снизить ошибкоемкость кода, уменьшить трудозатраты на отладку.

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

Раскроем целеполагание.

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

Если попробовать провести мысленный эксперимент и поставить себя на место писателя каждого из этих фрагментов и попробовать воссоздать поток сознания, который сопровождал разработку этого кода, получится что-то вроде классического голливудского:

1.  {вырезано цензурой} до чего же я хорош!!!

В самом деле, уместить непростую логическую или функциональную конструкцию в одну единственную строку программного кода — эта задача по силам только специалисту высокой квалификации. Проблема же заключается в том, что читать и сопровождать этот высококвалифицированный код с большой вероятностью будут специалисты, не владеющие техникой “Сожми пять строчек в одну”. Как следствие, трудозатраты на чтение кода и вероятность привнесения в него ошибок увеличатся примерно в той же пропорции, 1 к 5. Большая просьба к молодым и начинающим специалистам не принимать следующую ниже метафору за пренебрежение, это всего лишь метафора. А более опытным коллегам автор рекомендует очередное пополнение коллекции настольных фигурок.

В паре с представителем народов крайнего севера просто идеально будет смотреться изваяние олененка Бэмби. И представьте, что первый пишет, а второй читает.

Вот это и есть наш юный читатель. Симпатичный, правда?

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

В этом месте необходимо также пару слов посвятить отладке. Давайте посмотрим на столь любимую многими писателями фразу:

и представим себя, любимого, отладчиком. Да, здесь выполняется запрос, и возвращается только одна колонка результата, но если для целей отладки необходимо рассмотреть весь результат запроса? Необходимо выполнить запрос повторно и только потом двигаться выше по стеку. А если он выполняется 10 минут? А если целью нашей отладочной деятельности как раз и является выяснить, почему метод работает 10 минут, а вносить изменения в код нельзя? Писатель кода сэкономил три строки и показал умение правильно расставить кавычки, скобки и точки, абсолютно не думая о том, в какую копеечку может влететь впоследствии отладка его изделия и поиск в нем причин низкой производительности. Если же вспомнить, что наиболее простой и надежной инженерной конструкцией является трехногая еловая табуретка, код будет написан несколько иначе:

Сухой остаток: краткость, возможно, и является сестрой таланта, но только в драматургии, а драматические эффекты — это последнее, что требуется от программного кода. Будьте проще, и мир станет лучше.

Правило лестничных пролетов

Целеполагание: сделать код легкочитаемым, снизить ошибкоемкость кода, уменьшить трудозатраты на отладку.

Формулировка правила: следует всемерно избегать сложных многоуровневых логических выражений. Такие выражения следует декомпозировать на отдельно вычисляемые простые фрагменты.

Раскроем целеполагание.

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

Здесь можно увидеть уже описанные выше родовые травмы: такой код очень сложно читать, а еще сложнее сопровождать и модифицировать. Причем каждая модификация, добавление каждого нового условия делают код только хуже. Самым лучшим решением является такое проектирование кода, при котором необходимость записывать сложносочиненные условия в стиле Владимира Маяковского, полностью отсутствуют. Но если расположение звезд оказалось настолько неудачным, что без “лесенки” не обойтись, ее по крайней мере следует расчленить на относительно короткие и внятные лестничные пролеты. Это можно сделать, например, как показано на иллюстрации.

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

За мотивирующей частью правила читатель может отправиться выше по тексту, к метафоре, главным героем которой служит олененок Бэмби. Всякий раз, когда писатель кода запиливает между Иначе и Если очередные семь этажей, где-то в лесу слышен очередной грустный вздох этого милого зверька.

Сухой остаток: сила программного кода в его строгости и простоте. У программиста и поэта общей должна быть только первая буква названия профессии.

Правило горелой спички

Целеполагание: сделать код легкочитаемым, уменьшить трудозатраты на кодирование посредством исключения “лишних деталей”.

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

Раскроем целеполагание.

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

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

Примеры такого подхода попадаются на глаза не часто, но все-таки попадаются. Например, когда вместо индексированной таблицы значений используется сложносочиненная структура соответствий (“Так будет задействовано меньше памяти”). Другой пример, когда вместо прямого перебора относительно небольшой коллекции значений используется хитро вывернутый алгоритм формирования более короткой (“Так будет быстрее”). Самый, наверное, частый пример, когда вместо того же прямого перебора простой коллекции пишется избыточно сложный запрос (“Из СУБД сразу получаем готовое”). Или вот, любимое автором, когда для выполнения простой проверки или перерасчета данных на форме вместо того, чтобы выполнить серверный вызов и решить задачу одним простым вопросом, выстраивается многослойный клиентский кэш со сложной схемой, актуализацией и проверкой его валидности. Ну — и так далее.

Общее во всех этих примерах то, что код на ровном месте усложняется, становится хуже читаемым, менее понятным и более капризным. А вот профит от этого усложнения асимптотически приближается к нулевой отметке. Предположим, мы сэкономили тридцать два байта забираемой памяти на одной итерации цикла. Уменьшили время открытия формы на 0,005 секунды, сократили количество серверных вызовов при работе с формой с 72-х до 71-го. Но при этом затраты труда на кодирование повысили на пять процентов, затраты труда на отладку — на десять процентов, а вероятность возникновения ошибок в не совсем стандартных сценариях работы пользователя повысили почти вдвое (см. пример с многослойным клиентским кэшем). Закономерный вопрос — так мы победили или проиграли?

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

Сухой остаток: экономьте газ, а не спички. Тогда и суммы в квитанциях будут гуманнее, и пожаров будет поменьше.

Правило отрицания отрицания

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

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

Сперва следует пояснить разницу между стилями на примерах.

Раскроем целеполагание.

Единообразие стилистики условных выражений играет настолько же важную роль, как единообразие внешнего вида и поведения типичных интерфейсных элементов. Бытовая ситуация, с которой сталкивался, наверное, каждый — взаимное расположение кнопок “ОК”/“Отмена” (“Да”/“Нет”, “Принять”/“Отклонить”, “Записать”/“Закрыть”, etc.), особенно болезненным подобный стилистический разнобой выглядит в мобильных приложениях, где разработчики так до сих пор и не смогли определиться, размещать “зеленую кнопку” слева или справа? В отличие от морского и летного дела, где с красной и зеленой лампочками давным-давно все понятно, наша любимая отрасль в вопросах минимально необходимой стандартизации до сих пор находится где-то в Лилипутии, и остроконечники ведут священную войну с тупоконечниками.

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

И если с переменной-флагом дело обстоит еще не так скверно (хотя некоторые такие условия имеют вид перевода на встроенный язык “1С: Предприятия” третьего начала Гегелевской диалектики), то с методами-флагами все гораздо печальнее. Типичный пример этой печали приведен на иллюстрации:

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

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

Сухой остаток: есть мнение, что разработчикам софта, включая UI-дизайнеров, следует наконец-то осознать — будущим морякам и авиаторам принцип “Правый/Зеленый” прошивают непосредственно в мозг на самых ранних стадиях обучения вовсе не из любви к соленым мнемоническим правилам.

Правило несъедобного исключения

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

Формулировка правила: механику исключений платформы необходимо использовать строго по прямому назначению, то есть для попыток выполнить небезопасный код таким образом, чтобы получить возможность обработать ошибку. Не допускается использование исключений для проверки типа или корректности значения переменных, не допускается использование исключений в качестве замены условным ветвлением кода. Ни при каких обстоятельствах не допускается “проглатывание” исключения, то есть использование оператора Попытка с пустым или нефункциональным блоком Исключение.

Раскроем целеполагание.

Механику исключений придумали очень умные люди, и было это давным-давно в одной далекой галактике. С тех пор ничего принципиально нового не появилось, она проста, как наша любимая инженерная конструкция. Если мы не доверяем какому-то фрагменту кода (что на практике почти всегда означает “не доверяем входящим параметрам или результатам вызова чужих методов”), мы заворачиваем этот фрагмент в операторные скобки Try-Catch. Физический смысл этой конструкции вовсе не в том, чтобы избежать этой ошибки, поскольку переход в блок Catch означает, что код уже упал, но в том, чтобы попытаться диагностировать ошибку и оставить какой-то посмертный след для тех, кто будет эту ошибку расследовать.

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

Про третью цель, достигаемую применением правила, охотно расскажет любой специалист, которому приходилось часами гонять отладчик в режиме “Останавливаться по ошибке”. Верным признаком того, что среди писателей кода конфигурации нашелся гражданин, ловкий настолько, чтобы банальную проверку существования чего-либо реализовать через TRY, служит высокая плотность восклицаний “<Вырезано цензурой!!!>”, выпускаемых в воздух соответствующим рабочим местом. Ты ожидаешь, когда же упадет твой собственный код, а вместо этого регулярно падает код какого-то умника, которому было лень проверить существование подсистемы или валидность строки, превращаемой в число. Элементарный пример такой ловкости приведен на иллюстрации.

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

Примечание. Размещение в блоке Catch записи в журнал регистрации с последующим продолжением потока исполнения кода ничем не отличается от просто пустого блока Catch.

Сухой остаток: исключения в программном коде подобны рыбным и куриным костям в обеденной тарелке, глотая — остерегайся. Кладбища полны памятниками таким вот глотателям.

Кофе-пауза #7

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

— 1С? Это та смешная штука, где код нужно писать на русском? Бу-га-га, лол.

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

Аргументы в стиле величайшего (без дураков, величайшего) европейского мыслителя Бенедикта Спинозы рассматривать всерьез как-то даже неловко: “Доказательство этой теоремы ясно само собой, в противном случае нам пришлось бы полагать ложное истинным, а это нелепо” (цитата по памяти, не дословная, но в “Этике” таких мест полна коробочка). С аргументами такого уровня уважаемым коллегам добро пожаловать в детский сад. Считать написание связного текста на великом и могучем русском языке посредством кириллического алфавита нелепым — верный путь признаться в том, что вместо уроков русского уважаемый коллега втихаря занимался обменом вкладышами от жевательной резинки “Love is” (ну или что там служит аналогом для битья баклуш у современных школьников), ну а с недоучками у нас разговор короткий:

Tell your story for marines, padre.

Следующий по внятности аргумент в буквальном смысле слова пропитан пылью веков: пишите программный код на языке основателей, на языке нашего Бога. На английском. Здесь с исходным посылом спорить трудно, леди Ада и мэтр Чарльз творили нашу вселенную при помощи английского языка, будучи, так уж вышло, природными англичанами. Но каким образом этот глубоко исторический факт получил привилегию диктовать нам, на каком языке писать программный код в первой четверти 21-го века? Если следовать принципу “почитай основателей своей отрасли и пиши на языке его”, бухгалтерские документы следовало бы оформлять на староитальянском, политические — издавать на французском, учебники алгебры — на греческом, ну и далее по списку, что характерно, одним из пунктов списка, причем не самым убойным, стала бы разработка уставов инженерных войск на ассирийском. Понятно, что любую идею можно довести до абсурда, но сама идея о том, что все программы следует писать на английском, как и была написана самая первая, уже является абсурдом уровня 82+.

Далее на очереди хрестоматийная ментальная ловушка под кодовым обозначением “английский язык гораздо более точен в терминах и определениях”. Чтобы далеко не ходить за доказательством, возьмем пару самых элементарных примеров. Возьмем вот эту фразу на русском:

Сервис быстрой регистрации, позволяющий максимально просто и быстро создать учетную запись абонента в облачном сервисе “1С: Предприятие через Интернет”, реализован посредством веб-сервиса.

Теперь мысленно переведем это на английский (и никаких онлайн переводчиков). В чем будет разница между “service”, “service”, “service”? Три одинаковых слова внутри одной фразы имеют принципиально разное значение. И где здесь, простите, точность в определениях? Еще более печальна судьба другого производного от глагола to serve — многострадального слова “server”.

Вот клиент, который стучится на фронт-сервер, который проксирует запрос клиента веб-серверу, который обращается к расширениям веб-сервера платформы 1С, которые адресуют запрос рабочему процессу в кластере серверов, которые трансформируют запрос в обращение к серверу СУБД, который развернут на виртуальном сервере, который развернут на физическом сервере в доме, который построил Беббидж.

Если не полениться и потратить пару вечеров на литературную обработку, взяв за образец творчество Самуила Яковлевича, выйдет прекрасный детский стишок, иллюстрирующий ту самую ментальную ловушку. Семь упоминаний слова “server”, каждое из которых вне контекста не имеет собственного смысла. Истинный рай для толкователей.

В сравнении с по-настоящему точными языками английский, да еще и айтишный диалект английского, не выдерживает абсолютно никакой критики. Сравнить хотя бы с медицинской, биологической или юридической латынью. Если мы встречаем в тексте “Yersinia pestis”, или “Ornithorhynchus anatinus”, или “Сasus omissus” — мы абсолютно точно знаем, на какое явление, предмет или организм указывают эти слова. А вот если мы встречаем в тексте “Web service” — о чем именно идет речь?

Да что там хирургически точная латынь, давайте сравним хотя бы с немецким. Вот, например, прекрасное немецкое слово (еще раз спасибо покойному Лурку за пример):

Donaudampfschiffahrtselektrizit?tenhauptbetriebswerkbauunterbeamtengesellschaft

Что означает: общество служащих младшего звена органа по надзору за строительством при главном управлении электрического обслуживания дунайского пароходства. Кто скажет, что это не идеальный образец точности языковой конструкции, пусть первым кинет в автора камень. Так что же, может, программный код стоит писать на немецком? Вместо языка, на котором понятия “запускать”, “убегать”, “руководить”, “вращаться”, “производить” (и еще десяток других) обозначаются одним словом из трех букв, средняя “у”?

Вопросы, понятное дело, риторические. Айтишный диалект английского по своей контекстуальности мало чем отличается от языка планеты “Марклар” (если вы поклонник “Южного парка”), планеты “Сквонч” (если вы поклонник “Рика и Морти”), планеты “Плюк” (если вы, как и автор, представляете старую школу), ну и так далее.

Рассматривать шовинистические аргументы вида “возможность писать код на русском снижает порог вхождения в профессию до уровня примерно плинтуса” мы попросту не будем, как раз для этого случая возражение Бенедикта Спинозы является идеально точным. Признать такую точку зрения означало бы почитать истинное ложным, а это нелепо.

Что же остается в арсенале яростных противников программного кода на русском языке? Пожалуй, единственный по-настоящему действенный аргумент должен звучать так: английский язык, при всем его несовершенстве и при всей его бедности, используется для решения айтишных задач уже настолько давно, что на нем наработан огромный массив терминов и понятий, про которые можно сказать “это всем известно и объяснения не требует”. И поэтому передать мысль одного айтишника другому во многих случаях проще и быстрее на английском, чем на их родном языке. И с этим аргументом спорить даже не нужно, он абсолютно верен. В самом деле, попробуйте адекватно перевести на русский хотя бы что-то очень простое, например, коммит, форк, ассерт, деплой, тысячи их. Все верно, подобрать русский аналог для “overhead” есть такая же бессмысленная и неблагодарная задача, как в футбольном комментарии превратить “болбой” в “мальчик, подающий мячи”.

И вот здесь мы подходим к моменту, который является ключевым. Да, адекватно перевести на русский “overhead” вряд ли возможно. Но вот попробуйте в качестве встречного упражнения с ходу адекватно перевести на английский “изменение в алгоритме расчета себестоимости производства по схеме переработки давальческого сырья при ее использовании для закрытия функциональных разрывов в учете гарантийных ремонтов”. Да так, чтобы это было понятно даже олененку Бемби, чье знакомство с английским ограничивается одноголосым закадровым переводом “Теории большого взрыва”. На немецком, возможно, получится сказать это одним словом, а как насчет языка айтишного бога, английского?

В сухом остатке у нас — обычные аптекарские весы. На одну чашу положим возможность относительно точно выразить энное количество устоявшихся айтишных терминов, по большей части узко специальных, а на другой чаше у нас окажется самодокументируемый и самокомментируемый в терминах прикладных предметных областей программный код, поддержанный всей мощью и образностью великого и могучего русского языка. Какая чаша перевесит? Есть мнение, что ответ слегка очевиден.

Базовые методы проектирования

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

Как мы уже выяснили в теоретической части настоящей работы, проектирование, пусть даже умозрительное, является фундаментальной стадией разработки. И если уж мы беремся закладывать фундамент нашего программного кода, то лучше сразу делать это в той же парадигме, в которой код будет написан — не спеша, эффективно, правильно и в соответствии с лучшими практиками.

Почему автор имеет смелость относить некоторые из своих практики к лучшим? В качестве ответа можно привести два основательно затертых, но ничуть при этом не потускневших, афоризма: во-первых, критерием истины всегда является практика; и во-вторых, ложная скромность почти всегда порождает некомпетентность.

Разумеется, вселенная бизнес-анализа и проектирования огромна и разнообразна. В рамках настоящей работы мы пройдемся только по самому краешку, но именно с этого краешка и рекомендуется заходить тем разработчикам программного обеспечения, которые еще не созрели для размещения в своем резюме термина “Системный архитектор”.

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

Примат целеполагания

Проблематика:

Проектирование является совместной задачей специалистов класса “Аналитик” и “Разработчик”, и часто получается так, что до разработчика доходит не исходная задача, а уже вполне конкретный вариант ее реализации. Следствием такого положения дел является существенный объем трудозатрат на реализацию неоптимальных, а зачастую и неработоспособных вариантов, не соответствующих исходной бизнес-задаче и не отвечающих ожиданиям заказчика. Как производное следствие, возникает необходимость в переделках и доработках, а иногда и полном замещении уже реализованного варианта.

Формулировка метода:

Нулевой стадией работы над любой задачей является целеполагание. В техническом плане это означает, что прежде всего следует получить точную и ясную формулировку цели, достижению которой послужит решение задачи. Цель должна быть поставлена на уровне бизнес-требований и сформулирована в терминах предметной области. Сформулированная таким образом цель называется “темой” задачи. К теме задачи предъявляется требование сжатости, не более трех предложений. Без такой формулировки приступать к фазе проектирования ни при каких обстоятельствах нельзя.

Раскроем проблематику.

Элементарный пример из повседневной практики. Разработчик получает техническое задание, в котором сказано примерно следующее:

В документ Командировка необходимо добавить табличную часть Непредвиденные расходы. Состав табличной части — Статья расходов, Сумма. При заполнении табличной части подбор статей расхода должен быть ограничен теми статьями, которые содержатся в документах Авансовый отчет, имеющих документом-основанием данный документ Командировка.

Вроде бы, задача ясна и понятна. Но уже при анализе задачи возникает проблема консистентности данных в связанных документах. Предположим, табличная часть документа Командировка уже заполнена, а после этого какой-то из Авансовых отчетов будет помечен на удаление. Требуется ли какой-либо контроль, а если требуется, как он должен быть организован? Что нужно делать в ситуации, когда в Авансовом отчете изменили статью расходов, эта статья уже была добавлена в табличную часть Командировки, пользователь открыл форму и вызовет повторный выбор уже выбранной статьи расходов, той самой, которой в связанном авансовом отчете уже нет? Чтобы ответить на эти вопросы, потребуются переговоры разработчика с аналитиком, аналитика с ключевым специалистом заказчика, и то же самое в обратную сторону. Потребуется написать существенный объем не самого простого кода, отладить его и протестировать. Трудозатраты, и еще раз трудозатраты.

Теперь попробуем применить к ситуации описанный выше метод и зададим вопрос, какую собственно бизнес-задачу мы решаем? Каким именно образом эта новая табличная часть будет задействована в бизнес-логике приложения? И получим следующий ответ: в бизнес-логике эти данные не будут задействованы никак, а будут использоваться просто как справочные для просматривания глазами. Тогда возникает следующий вопрос, а зачем вообще нужна табличная часть в документе Командировка? Не проще ли будет добавить флаг Непредвиденные расходы в уже существующую табличную часть документа Авансовый отчет, а на форму документа Командировка просто вывести табличку, полученную элементарным запросом к связанным Авансовым отчетам? При таком варианте реализации разработчик получает очень существенную экономию трудозатрат, а заказчик получает более удобный, простой и надежный инструмент. И весь этот профит обе стороны получили от заданного в нужный момент правильного вопроса.

Примат целеполагания является безусловным и не зависит ни от объема, ни от сложности, ни от прикладной специфики. Эту методику также можно визуализировать посредством настольной фигурки, автор рекомендовал бы небольшого угольно-черного дракона, единственной задачей которого будет преграждать доступ аналитиков и постановщиков к телу разработчика, а пройти этого стража можно будет только с правильным ответом на вопрос “Коллеги, а какую именно задачу мы решаем?”.

Еще раз: и какую задачу мы решаем?

Сухой остаток: “Чтобы что?” — это не тонкий троллинг коллег и представителей заказчика, а взрослая игра с ненулевой суммой, в которой выиграть могут все стороны. Не стесняйтесь в нее играть.

Безальтернативность многовариантности

Проблематика:

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

Формулировка метода:

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

Важное дополнение. У абсолютно любой задачи всегда есть альтернативный вариант “Не делать вообще” (см. принцип YAGNI).

Раскроем проблематику.

Между процессами “Ищу решение” и “Ищу варианты решения” есть фундаментальная разница, в первую очередь психологическая. Эту разницу можно определить через жутковатое словосочетание “Направленность вектора мышления”.

В случае поиска единственного решения мысль проектировщика движется по направлению “Отбросить все неподходящее, а то что останется и будет решением”, то есть пространство возможных решений методически сужается, если не сказать вырождается. Если же мы идем путем поиска различных вариантов, направление мысли строго противоположное — “А как еще это можно реализовать?”, наше интеллектуальное усилие при этом направлено на расширение пространства возможных решений.

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

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

Сухой остаток: если для задачи нашелся только один вариант решения, значит поиск был некачественным. Ищите лучше. Если понадобится — с фонарями и собаками. Другие варианты всегда есть.

Геоцентрический метод черного ящика

Проблематика:

В идеально устроенном мире процессу проектирования предшествуют процессы сбора, анализа, формализации и согласования функциональных требований. Проектировщик получает в руки четкую и полную спецификацию “как должна выглядеть и вести себя создаваемая система, какими функциями она должна обладать и какие ограничения допустимы”. Имея такую спецификацию можно переходить к проектированию по классическим методикам. Проблема заключается в том, что: а) идеального мира не существует; б) как показывает практика, в общем случае реальный мир настолько далек от идеального, что словосочетание “Приближаться асимптотически” выглядит ненаучной фантастикой. В реальном мире проектировщику обычно выдается задача вида “Нужно спроектировать систему XXX, которая сделает все как надо, формальных требований нет, задавайте ваши вопросы”. Переложив проблемы в практическую плоскость, мы получаем две задачи — какие именно вопросы задать и в какой форме записать ответы.

Формулировка метода:

Необходимо представить функциональность неизвестной пока системы через взаимодействие с этой системой всех известных акторов. Причем в обязательном порядке требуется графическое представление, то есть визуализация. Базой для визуализации является модель солнечной системы имени товарища Птолемея. Та самая, где Земля являлась центром вселенной. Берется лист бумаги (или чистый файл MS Visio/DRAW.IO, кому как удобнее), в самом центре изображается небольшая черная коробочка, которая и будет символизировать создаваемую нами систему. Далее в модель последовательно добавляются акторы, для них можно использовать любые визуальные метафоры, и чем нагляднее — тем лучше. После добавления очередного актора в модели прописываются связи, каждая из которых символизирует определенную форму взаимодействия. Формальной нотации нет, но разумным представляется как цветовое, так и морфологическое кодирование. Например, толстая красная стрелка может указывать на поток данных высокой плотности, про который точно известно только то, что про него ничего точно не известно. Бледно-серая тонкая пунктирная стрелка неплохо подойдет для взаимодействия “редко и нерегулярно запрашиваются отчетные данные, без которых актор вполне может и обойтись”. Ну — и так далее, главное, чтобы использованные в модели визуальные метафоры были понятны и легко читаемы участниками процесса проектирования. Важный момент. В модели необходимо отобразить не только взаимодействие акторов и системы, но и взаимодействие акторов друг с другом. Это позволит точно установить, какие именно функции в системе не требуются. После того, как картина мира будет выписана хотя бы в первом приближении, можно приступать к следующей стадии процесса — пошаговому преобразованию элементов визуальной модели во фрагменты функциональной спецификации, которая после согласования с заказчиком получит статус тех самых недостающих формальных требований.

Раскроем проблематику.

Возможно, это будет самый короткий абзац во всей главе. Собственно, проблематика раскрывает себя сама.

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

Сухой остаток: если в поставленной задаче проектирования отсутствует общая картина мира, ничто не мешает написать эту картину самостоятельно.

Хронометрический метод черного ящика

Проблематика:

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

Формулировка метода:

Для растягивания черного ящика по оси времени используется почти полный аналог диаграммы последовательности (она же “Secuence Diagram”), заимствованной из мира методологий, базирующихся на графическом языке UML. Нет необходимости изобретать что-то свое, когда необходимый инструмент уже изобретен, но ничто не мешает слегка упростить или модифицировать существующую методику — в нашей желтой вселенной мы привыкли подстраивать инструментарий под бизнес-процесс, а не наоборот. Принцип “Инструмент прогибается под процесс” изначально является киллер-фичей нашей любимой технологической платформы, и мы не стесняемся задействовать его где только возможно.

Диаграмма последовательности строится следующим образом:

• Рабочей плоскостью представляется подобие бассейна с плавательными дорожками, размещенными параллельно друг другу.
• На условных стартовых тумбах сверху диаграммы размещаются пиктограммы/наименования акторов, вовлеченных во взаимодействие с проектируемой системой.
• Сама диаграмма выстраивается по образу и подобию обычной блок-схемы, с той только разницей, что активности (включая ветвления и прочее) располагаются строго в границах дорожки соответствующего актора.
• Ось времени направлена сверху вниз.
• Изображенный таким образом процесс имеет единственную стартовую точку, ее предпочтительно расположить в левом верхнем углу.
• Завершающих точек может быть несколько, причем завершение процесса может быть штатным, а может представлять собой ошибку.
• Те элементы диаграммы, которые пока что отсутствуют в ландшафте и являются частями проектируемой системы, отображаются как фрагменты растянутого во времени черного ящика (в буквальном смысле, графическим кодированием “белый текст на черном фоне”).

Раскроем проблематику:

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

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

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

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

Первородство спецификации

Проблематика:

Если вдумчиво изучить достаточно большое количество тиражных решений на нашей любимой технологической платформе, можно обнаружить довольно плотное присутствие, назовем его так, феномена недосказанности. Он заключается в том, что даже требуемые стандартом разработки описания экспортных методов программного интерфейса той или иной подсистемы являются в лучшем случае скудными, в худшем случае скопированными у какого-то другого метода, а в самом пиковом — отсутствуют вовсе. Заводить речь о заголовках методов даже служебного программного интерфейса, не говоря о сугубо внутренних методах, и вовсе считается неприличным, эти заголовки обычно отсутствуют чуть менее, чем полностью. (Отметим, что все же далеко не все тиражные решения тотально подвержены этой болезни, но, к сожалению, многие и многие). Как следствие, разработчик, не имевший отношения к созданию конкретной подсистемы (либо имевший, но когда-то, и все сроки давности уже вышли) вынужден в любой сколь-нибудь сложной ситуации разбирать программный код метода, вместо того, чтобы просто прочитать описание. Грустный взгляд нашей любимой священной коровы по имени Эффективность, будем надеяться, читатель уже научился в необходимых местах представлять себе сам.

Те самые грустные глаза.

Формулировка метода:

Прежде чем приступить к разработке процедурного, назовем его так, содержимого подсистемы (обработки, модули и так далее) необходимо специфицировать это содержимое хотя бы в первом приближении. Что имеется в виду? Например, перед тем, как написать тело метода, необходимо написать его заголовок, причем не традиционным (“На отцепись”, sorry my French) образом, когда заголовок просто пересказывает название слегка другими словами, а по-настоящему — заголовок, как и любой комментарий, при эффективной разработке не пересказывает, а поясняет, раскрывает суть. В заголовке необходимо описать назначение метода, особенности его применения, ну и, разумеется, входные и выходные параметры. Только после того, как заголовок записан, можно приступать к собственно кодированию метода. Это первое приближение. Иными словами, программному коду всегда должна предшествовать его относительно полная спецификация. Второе приближение — когда мы специфицируем не один конкретный метод, а все основные методы, которые запланированы к разработке в ближнесрочной перспективе. Фактически, мы вводим понятие нулевого цикла разработки, когда собственно программного кода еще нет, но он уже структурирован, декомпозирован, описано назначение отдельных деталей и выверены спецификации входа и выхода. Действует четкое правило: если для метода не получается подобрать краткую и внятную формулировку его предназначения на техническом русском, метод либо спроектирован неправильно, либо вообще не нужен. Под “Первородством” в названии принципа понимается первичность идеи, плана перед технической реализацией.

Раскроем проблематику.

Лучшей аналогией для рассмотрения правильного и неправильного подходов к разработке программного кода в свете декларируемого принципа является градостроение. Старые города, назовем их так, формировались стихийно, без генерального плана. Здесь был тракт, а там река и, соответственно, мельница. Затем возле тракта возник трактир, мельница обросла складами, образовался рынок, со всех сторон прилепились жилые бараки, ну и пошло-поехало. В современных европейских городах исходная конфигурация сохранилась даже в названиях улиц и районов. Иное дело новые города, построенные в соответствии с планом. Каждый элемент городской инфраструктуры расположен там, где задумал архитектор. План может быть хорошим или плохим, может пересматриваться по ходу строительства, но он есть, и нельзя сказать, что даже в градостроительстве тщательно продуманный и грамотно реализованный генеральный план уступит в красоте и архитектурном величии скромному обаянию стихийного старого города. Понятно, что о вкусах не спорят, но инженерный взор автора стройные линии васильевского острова радуют куда больше, чем узкие кривые и непонятно куда ведущие улочки Vana Tallinn. В разработке программного обеспечения разница между принципами “Так уж создатель на душу положил” и “Смотри генеральный план, пятый том, вторая глава” является фундаментальной. Программный код, написанный по спецификации, в абсолютном большинстве случаев будет более компактным, понятным, эффективным и предсказуемым, нежели написанный по наитию в порыве вдохновения. Если, конечно, писатель кода не является безусловным гением, умеющим держать генеральный план в голове в течение многих дней, причем под воздействием множества внешних раздражителей. Поскольку крайние случаи мы не рассматриваем, такого рода гениальность остается за бортом, идеал прекрасен, но в суровой реальности встречается крайне редко.

Второй по перечислению, но не по важности киллер-фичей обязательного специфицирования является почти бесплатная (в плане накладных расходов труда) поддержка модели “Синьор + Джуниор”. Сценарий взаимодействия выстраивается максимально простым и эффективным образом — ведущий разработчик отвечает за декомпозицию и специфицирование программного кода, а также за аудит, приемку и сборку отдельных частей в единое целое. Младшие разработчики получают конкретные и относительно простые задачи в рамках уже разработанного генерального плана, он же спецификация. Техническим средством взаимодействия (и это подтверждено многолетней практикой) в такой команде может служить непосредственно конфигуратор. Ведущий расставляет в соответствующих местах спецификации пометки определенного формата, указывающие, кому поручена реализация того или иного фрагмента. Ну а рабочий день младшего разработчика начинается с загрузки изменений хранилища и глобального поиска по сигнатуре вида “to do –> Иванов”.

Еще одним преимуществом из категории “мелочь, но приятно” является возможность распределить работу над программным кодом во времени таким образом, чтобы сначала в реализацию передавались “функции критического пути” (то есть такие методы, без которых не будет работать функциональность категории major), а уже затем обслуживающие и вспомогательные. Предварительное специфицирование позволяет: а) разделить участки кода на major и minor и б) не забыть о том, какие именно minor-функции были намечены к реализации, но еще не реализованы.

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

Стратегия работы над ошибками

Сама по себе проблематика ошибок в программном коде и борьбы с ними неисчерпаема, словно мощь атомного распада или вечные вопросы из разряда “Сколько ангелов помещается на острие игры?”, “Кто во всем виноват?”, “Что сегодня надеть?” и так далее. Когда поднимается эта тема, у любого автора возникает искушение налить в текст десяток страниц тяжелой метафизической воды, обильно приправленной тонким сарказмом. Но мы предоставим читателю припомнить и перебрать все аргументы самостоятельно, а главный вывод отгрузим сухим пайком. Вот он:

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

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

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

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

Выход из окружения

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

Считается, что для полноценной проверки разработанного программного кода обязательно требуется тестовое окружение, максимально приближенное к продуктивному. Но это утверждение верно только отчасти. Как подсказывает нам наша добрая фея Аналогия из мира прекрасного, давайте посмотрим на военный парад. Чтобы провести полноценную репетицию нужен по крайней мере полноразмерный макет соответствующей городской площади, а лучше всего — сама эта площадь в нерабочее время. Но для того, чтобы тренировать парадную маршировку у отдельно взятой коробочки-подразделения, подойдет любая ровная поверхность, которая может располагаться где угодно. В нашей отрасли дело обстоит точно так же. Для полноценного нагрузочного тестирования требуется полноценный же аналог продуктивного окружения. Для расследования конкретных ошибок и проблем эксплуатации также требуется воссоздать условия “как было”. Но для функциональной проверки свеженаписанного программного кода разработчику достаточно собственными силами организовать где-нибудь в уголке подобие обычного армейского плаца.

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

Но на самом деле, нужда в тестовой зоне очень сильно преувеличена. Что происходит, когда смежная система вызывает наш веб-сервис? На нашей стороне вызывается какой-то метод внутреннего программного интерфейса. Вопрос — а что мешает нам вызвать этот же самый метод не через цепочку “веб-сервис, публикация, расширение платформы для веб-сервера, веб-сервер, вызов извне”, а непосредственно из самой нашей инфобазы через примитивную обработку и “Файл — Открыть — Выполнить”? Да, потребуются какие-то входящие данные, но кто мешает подготовить пару простых, но характерных синтетических примеров при помощи встроенного механизма “собственный руки™”. Это потребует небольшого кусочка рабочего времени, но полностью исключит зависимость от сложного и капризного тестового окружения на этапах отладки и альфа-тестирования.

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

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

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

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

Памятка руководителю. Если разработчик либо коллектив разработчиков в лице старшего по званию на четкий вопрос “когда?” с честными васильковыми глазами отвечает в том смысле, что все уже давно готово, но требуется проверить, для чего нужна тестовая зона, а тестовую зону смежный отдел (партнер, субподрядчик, IT-отдел заказчика — недостающее вписать, нужное подчеркнуть) еще не подготовил, так что мячик на их стороне — с большой долей вероятности речь идет о разыгрывании IRL старой инженерной шутки про торжественный пробный пуск ракеты, обратный отсчет, игру нервов и финальное “Вот видите, товарищ конструктор? Пуск был сорван по вине наших уважаемых смежников”. Вовсе не обязательно дело обстоит именно так, но негласная проверка ей богу лишним не будет.

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

Встречно-ответный удар

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

В обычном случае разработчик в рамках альфа-тестирования проверяет только основной поток событий, причем в наиболее простых сценариях. Затем разработка передается на тестирование, а разработчик в ожидании баг-репортов переключается на другие задачи. Такую тактику можно назвать “линейной”.

Ответно-встречная тактика предполагает более плотное участие разработчика в процессе тестирования. Это значит, что после изменения статуса задач с “в работе” на “проверка”, разработчик не устраняется, а продолжает альфа-тестирование, но теперь проверке принадлежат альтернативные потоки событий, а сценарии задействуются более затейливые.

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

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

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

И во-вторых, разработчик при таком подходе прокачивает пусть и базовые, но все же вполне взрослые навыки тестирования, тем самым расширяя свой кругозор и повышая общую квалификацию. Узкий специалист по меткому выражению Козьма Прутков действительно подобен флюсу, и вряд ли разумно спорить с тем, что продуктивная ценность специалиста со спецификацией “Разработка, базовое тестирование” для работодателя интереснее, чем “Только разработка и ничего кроме”.

Каких-то наглядных примеров к этой главе не прилагается, методика неплохо иллюстрирует себя сама.

Сухой остаток: классическая линейная тактика коммуникаций при тестировании вполне работоспособна, но привнесение в нее элементов ответно-встречной схемы взаимодействия позволит повысить не только эффективность, но и профессиональный уровень участников.

Спящая агентурная сеть

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

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

Либо режим отладки включить можно, но физического и даже дистанционного доступа к продуктивной зоне нет. Конечно, всегда можно попробовать объяснить местным админам, что именно нужно делать, но продуктивность такого взаимодействия на практике всегда обратно пропорциональна риску вызвать серьезную аварию.

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

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

Что означает эта аналогия для нас в практическом плане? При работе над программным кодом мы заранее определяем участки, на которых может потребоваться применение отладчика, снятие каких-то телеметрических параметров, ну или что-нибудь другое в этом же роде. На таких участках заранее еще при разработке устанавливаются закладки.

Следует пояснить, что сам по себе термин “Программная закладка” вовсе не обязательно относит описываемую сущность к темной стороне информационных технологий. Закладка — это всего лишь “спящий программный код”, который активизируется либо при определенных условиях, либо при поступлении какой-то внешней команды. И если такая закладка служит благой цели сбора отладочной информации или купирования аварийной ситуации, ни о каких темных сторонах речи идти не может.

Приведем пример из столь любимого автором класса интеграционных задач. Классика жанра — сопряженная система, веб-сервисы, слабая связность. От эксплуатанта смежной системы поступает сигнал: “У вас опять ничего не работает, возвращается пятисотка” (500 — самый ненавистный для разработчиков подобной механики ответный код HTTP-состояния, но это долгая история).

Что делать в такой ситуации? Отладчик в продуктиве недоступен, а если бы и был доступен, синхронизировать деятельность двух территориально разнесенных специалистов: “ты дерни, а я остановлю/посмотрю”, на фоне штатной рабочей нагрузки — дело, мягко говоря, нетривиальное.

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

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

А вот что делать, если спящая агентурная сеть отсутствует в местах постоянной дислокации, и телеметрию записать некому? Видимо, взять большой лист бумаги и тысячу раз написать: “Я больше никогда не буду пренебрегать альтернативными методами отладки на тех участках, где они могут потребоваться”. Других вариантов нет.

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

Послесловие

Третья часть получилась чуть длиннее, чем вторая или первая, но о какой-либо полноте говорить не приходится. Собственно, такая цель — изготовить относительно полный сборник практических приемов, принципов и методик эффективной разработки - изначально и не ставилась.

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

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

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

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

Автор выражает своим читателям огромную благодарность за внимание и уделенное время.

Ну а теперь — зал “Вечерний Космос”, неформальное общение, танцы.

Бонус-трек

По старой доброй традиции, всякое обучающее или презентационное мероприятие должно завершаться банкетом. Наше мероприятие себя уважает, так что вот и обещанная производственная самодеятельность. Если даже поиск ошибок можно превратить в развеселую игру-охоту за пасхальными яичками и назвать этот порнопроцесс веселеньким словом “геймификация”, то что же нам помешает изложить базовые принципы разработки в формате задушевного эстрадного номера? Производство без производственной самодеятельности вряд ли может считаться полноценным.

Итак. Эстрадный номер цельнотянут у Леонида Осиповича Утесова, спасибо ему огромное. В оригинале это называлось “Гоп со смыком”, ну а у нас будет, соответственно, “Код со смыком”. Текст, где это было возможно, приведен в максимальное соответствие с оригиналом. И перед тем как приступить, необходимо сделать пару пояснений.

Первое. “Гоп со смыком” в оригинале не имеет ничего общего с гоп-стопом, и уж тем более с современными нам гопниками. На староодесском жаргоне так называли скрипачей, “смык” — это смычок. Но еще “Гоп со смыком” — это кличка очень известного и дерзкого вора-домушника, который под видом музыканта являлся в богатые дома на свадьбы и похороны, с известной целью.

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

Исполняется на корпоративах. Главное действующее лицо — Артист, выходит на эстраду хромающей походкой, кургузый пиджачок, тросточка, шляпа-котелок, солнечные очки Джон Леннон -style. Исполнение требует той адской смеси диалекта и акцентов, принятых в одесском фольклоре (см. исполнение этого номера Аркадием Северным). Второстепенный персонаж — Голос из зала, его не видно, но кричит он громко. Музыкальное сопровождение — классический Утесовский джаз.

На эстраду выходит Артист, развязная походка, небрежные жесты тросточкой.

Артист: Эй! Коллеги! Ша! На полтона ниже!

Голос из зала: А ты кто такой?

Артист: Не признали? Я же этот… код со смыком!

Вступает музыка.

Артист:

- Жил был на Семерке Код со смыком.

- Славился своим особым шиком.

- Он в рекурсиях вращался,

- Через точку обращался,

- А отлаживался страшным криком.

Голос (страшный крик): ИДЭДЭКУДЭ!!!

- Код со смыком, это буду я.

Голос: Врешь!

- Ja, Ja!

- Код писать — профессия моя.

- Ремеслом избрал я кодить,

- Чтобы гроши этим зробить.

- Вы, коллеги, слушайте меня.

Голос: Ууу.

- Код со смыком был с рожденья глух,

- И резистивен к испрямленью рук.

- У него одна забота

- Код хреначить пулеметом.

- А стандарты кодеру не друг.

Голос: А за производительность?

- Шпарит код, как паровой каток.

- Тестировщик, ты держись, браток.

- В коде багов как на кухне,

- В паутине мухи тухнут.

- Все пофиксим, дайте сдвинуть срок.

Голос: А за качество?

- Тут тимлид задвинул аудит.

Голос: Собака зеленая!

- В ректуме теперь слегка свербит.

- Код в капусту порубили,

- Светлый замысел убили,

- Разложили байт на восемь бит.

Голос: А за мотивацию?

- Мрачен код со смыком, вот опять

- Гений не желают признавать.

- Может дерзко и отважно

- Кодера обидеть каждый,

- Но не каждый сможет убежать.

Голос: А за планирование?

- Догорает костерком техплан.

- В коде обнаружился изъян.

Голос: Фатальный!

- Но гроши нужно до зарезу,

- В типовые я залезу,

- Инфостарт почищу в дребодан.

Голос: А за управление рисками?

- А если дело будет очень скверно,

- То уволят же меня, наверно.

- Кодеры не унывают,

- На headhunter попадают,

- Нас же там с руками отрывают.

Голос: А за развитие?

- И вот так идет за годом год.

- Парни мы же просто пишем код.

- Менеджерам и тимлидам

- Не понять нашей планиды,

- В их вселенной все наоборот.

Голос: А за упокой?

- Родился на Семерке, там и сдохну.

- Буду помирать, все базы грохну.

- Только нужно не забыться

- Перед смертью сохраниться,

- А не то, как Legacy засохну.

- Код со смыком — это буду я.

- Вы, коллеги, слушайте меня.

- Что нам альфа, что омега,

- Катит старая телега,

- Принцип кодера у вечности храня.

Аплодисменты, Артист раскланивается, Голос из темноты зала улюлюкает.

Занавес.

Часть 1. Парадигма

Часть 2. Теория

Статья на Google Docs.