Качество кода *

Сегодня на ежедневном Stand-up'е я произнёс перед командой очень проникновенную речь о том, что мы пишем софт для людей и никого не интересует, насколько красиво код будет выглядеть изнутри, если пользователю будет неудобно с ним работать.

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

И, конечно же, я сразу же вспомнил концепцию о достаточно хорошем (good enough) ПО. Итак, вот её основной постулат: мы не стремимся сделать идеально, мы не пишем как попало, мы делаем достаточно хороший продукт.

Понятно, что напрашивающийся (и правильный) ответ — «Потому что код приходится не только писать, а и читать». Едва ли этот ответ стоит целого поста, но автор им не ограничивается.

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

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

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

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

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

  #ruby
  puts 'What is your name?'
  name = gets
  process_name(name)
  puts 'What is your quest?'
  quest = gets
  process_quest(quest)

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

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

  require 'tk'
  root = TkRoot.new()
  name_label = TkLabel.new() {text "What is Your Name?"}
  name_label.pack
  name = TkEntry.new(root).pack
  name.bind("FocusOut") {process_name(name)}
  quest_label = TkLabel.new() {text "What is Your Quest?"}
  quest_label.pack
  quest = TkEntry.new(root).pack
  quest.bind("FocusOut") {process_quest(quest)}
  Tk.mainloop()

Теперь между этими двумя программами большая разница в потоке управления — в частности, в управлении временем, когда вызываются методы process_name и process_quest. В примере с коммандной строкой я контролирую, когда эти методы вызываются, но в примере с оконным приложением нет. Вместо этого я передаю контроль оконной системе (команда Tk.mainloop). Далее она решает, когда вызвать мои методы, основываясь на связях, которые я настроил при создании формы. Управление инвертировано — управляют мной, а не я управляю фреймворком. Это явление и называется инверсией управления (также известно как Принцип Голливуда — «Не звони нам, мы сами позвоним тебе» — Hollywood Principle — «Don't call us, we'll call you»).

Преамбула

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

И вот, вы, принимая пост, знакомитесь с командой: вроде бы есть потенциально сильные разработчики с опытом, есть несколько подающих надежды юниоров. Но что-то сразу бросается в глаза. И чем дольше вы вглядываетесь в эти занятые работой умные лица, тем более понимаете, что перед вами не команда, а «группа разработчиков». А то, что они пишут… Вы и не думали, что программисты могут так писать код. Вы смотрите на пластилиновую архитектуру, на классы в 6000 строк кода, на методы, занимающие десять страниц машинописного текста, на кейсы, ветвящиеся как головы Лернейской гидры. И у вас появляется невольный вопрос: а можно ли что-то с такой командой сделать вообще?

И мой ответ — можно. И нужно!

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

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

Большинство провальных проектов обладают одной закономерностью. Они абсолютно лишены структуры. Я называю архитектуру таких систем «пластилиновой».

 

Почитать описание других паттернов.

Проблема

Необходимо иметь эффективное представление запросов к некоторой системе, не обладая при этом знаниями ни об их природе ни о способах их обработки.

Описание

Существует по крайней мере три мотивации к использованию шаблона “Команда”:

• инкапсулирование запроса в виде объекта для последующего протоколирования/логирования и т.п.
• наделение сущности “вызов метода объекта” свойствами самостоятельного объекта;
• объектно-ориентированный обратный вызов (callback);
  
  

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

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

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

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

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

Почитать описание других паттернов.

Проблема

Эффективно и компактно реализовать механизм обработки потока событий/запросов/сообщений в системах с потенциально большим количеством обработчиков.

Описание

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

Государственная комиссия из министерства транспорта США и НАСА изучила 280 000 строчек кода в автомобилях Toyota и не нашла в них ошибок. Таким образом, названы две причины массовых случаев ДТП с участием автомобилей Toyota: это неправильное расположение коврика и залипающая педаль акселератора.

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

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

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

Кристофер Александер в соавторстве с пятью другими специалистами по архитектуре действительно написал книгу об архитектурных шаблонах, в которой он действительно рассмотрел свыше двухсот оных. Краткое и широко известное название это книги — «A Pattern Language». Однако же достаточно взглянуть на обложку книги, чтобы увидеть ее полное название: «A Pattern Language: Towns, Buildings, Construction». Такие длинные названия книг и широкая распространенность только названий кратких — не редкость; например, все знают «Происхождение видов» сэра Чарльза Дарвина, но редко кто сможет вспомнить ее полное наименование: «Происхождение видов путем естественного отбора, или Сохранение благоприятных рас в борьбе за жизнь».

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

Почитать описание других паттернов.

GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.

Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

Рассмотрим характеристики основных GRASP шаблонов.

Почитать описание других паттернов.

Проблема

Необходимо контролировать доступ к объекту, не изменяя при этом поведение клиента.

Описание

При проектировании сложных систем, достаточно часто возникает необходимость обеспечить контролируемый доступ к определенным объектам системы. Мотивацией для этого служит ряд приобретаемых преимуществ. Таких как, ленивая инициализация по требованию для «громоздких» объектов, подсчет количества ссылок на объект и т.д. и т.п. Однако, не всегда потребность в контролируемом доступе к объекту базируется только на преимуществах. Как правило, сложность процессов реального мира, ограничения вычислительных ресурсов просто не оставляют проектировщику выбора, нежели как воспользоваться паттерном «Заместитель» («Сурогат»).

Почитать описание других паттернов.

Проблема

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

Описание

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

Почитать описание других паттернов.

Проблема

Минимизировать зависимость подсистем некоторой сложной системы и обмен информацией между ними.

Описание

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

Таким образом, минимизация зависимости подсистем, а также снижение объема передаваемой между ними информации — одна из основных задач проектирования.

Один из способов решения данной задачи — использование паттерна «Фасад».

Почитать описание других паттернов.

Проблема

Возложить дополнительные обязанности (прозрачные для клиентов) на отдельный объект, а не на класс в целом.

Описание

Для более детального понимания проблемы, рассмотрим конкретную ситуацию. Пусть имеется некоторый объект — «кнопка», принадлежащий классу объектов «Кнопка», на который понадобилось возложить дополнительные обязанности. Под обязанностями, в данном контексте, понимаются какие-либо особенности поведения объекта. В случае с кнопкой, можно рассмотреть поведение объекта при его отображении на экране. При этом, будем считать, дополнительными обязанностями — отображение рамки кнопки, надписи, иконки. Важно понимать, что все эти обязанности должны иметь возможность быть наложенными как одновременно, так и по отдельности. Очевидно, первое, что приходит на ум — порождение классов (механизм наследования). Для данной задачи возможно это и выход — расширить класс «Кнопка» семью (2³-1 = 7) различными классами, сочетающими в себе всевозможные комбинации обязанностей. Это классы: «Кнопка_С_Надписью», «Кнопка_С_Рамкой», «Кнопка_С_Иконкой», «Кнопка_С_Надписью_И_Иконкой», «Кнопка_С Рамкой_И_Иконкой», «Кнопка_С_Надписью_И_Рамкой», «Кнопка_С_Надписью_И_Рамкой_И_Иконкой». А если таких обязанностей будет не три, а хотя бы десять, не говоря уже про неудобство работы с подобной структурой. Безусловно, порождение классов в таком случае — заведомо проигрышный вариант. Однако, из этой ситуации есть выход — паттерн «Декоратор».

Почитать описание других паттернов.

Проблема

Предоставить клиенту единообразный доступ к листовым и составным элементам древовидной структуры.

Описание

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

upd: Изменил диаграмму и код. Расширил пример и описание.

Почитать описание других паттернов.

Предыстория

Вернувшись домой, после непродолжительных посиделок у старого друга, я обнаружил, что оставил у него свой мобильный телефон, а вместе с тем и единственный в квартире будильник. Ситуация осложнялась тем, что завтра в 8:00 надо было быть на работе. Вариант вернуться за мобильником в 11 часов вечера я даже не рассматривал. И первое, что пришло мне на ум — написать свой будильник, причем с применением паттерна «Мост», который мне и без того надо было реализовать в рамках спецкурса. Как говорится, двух зайцев… Я думаю, не стоит пояснять что лег спать я под утро, но довольный собой. А утром, ровно в 7:00 меня победоносно разбудил мой bridge-будильник, весело наигрывая мотив из TBBT.

Как я до такого докатился, читайте под хаброкатом.

Почитать описание других паттернов.

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

• Описание того или иного паттерна, является моей сугубо личной интерпретацией теоретического и практического материала, собранного из книг и интернет-статей;
• При построении UML-диаграмм, я буду использовать свободный редактор от компании astah, ввиду его простоты и независимости от конкретного языка или среды. При этом, диаграммы не будут отличатся изобилием картинок и цветов, но будут ясно отображать суть паттерна;
• При реализации практических примеров, язык программирования будет выбираться совершенно случайно. Однако, я буду стараться подбирать те языковые средства, на которых данный паттерн реализуется не тривиально;
• Каждый мой пост, будет содержать как минимум 5 секций — Проблема, Описание патерна, Практическая задача, Диаграмма классов и Реализация;
• Если Вы, с чем-то не согласны или у Вас есть дополнения к материалу, изложенному мной — я буду рад их почитать в комментариях. Однако, помните — я тоже изучаю паттерны вместе с Вами :)