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

Одна из вещей, которая делает классические русские романы столь тяжелыми для чтения (для иностранцев) это то, что главные герои имеют кучу имён. К примеру, в романе "Братья Карамазовы" один из персонажей — Алексей Фёдорович Карамазов (Alexei Fyodorovich Karamazov), которого по ходу текста называют также Алёша, Алёшка, Алёшенька, Алёшечка, Алексейчик, Лёша и Лёшенька (Alyosha, Alyoshka, Alyoshenka, Alyoshechka, Alexeichik, Lyosha и Lyoshenka)

«Программирование в стиле русских романов» — это антипаттерн, возникающий в ситуации, когда одна вещь имеет много имён. Для какой-нибудь программы у вас может быть путь в системе контроля версий, путь на диске, имя проекта, имя исполняемого файла и т.д. Все они могут иметь одинаковые (однокоренные) имена или наоборот — называться каждая по-своему. Например, синонимами. Или вообще разными словами. Так уж вышло по историческим причинам, что бинарник foo.exe получается при компиляции проекта bar, лежащего в папке baz и т.д.

Инспектирование кода — это очень сложная и ответственная задача, которая может отнимать много ресурсов. Важно ответственно подходить к инспектированию и проводить его эффективно. Эффективно — это значит тратить мало времени и находить много дефектов. Но как повысить эффективность? Ниже представлены несколько советов, которые помогут в этом.

Думаю, многие разработки знакомы с понятием code review или обзор кода по-русски (также данный термин переводят как просмотр кода, инспектирование кода или рецензирование кода – далее, для единообразия, будет использоваться вариант «обзор кода»). Недавно я столкнулся с необходимостью «разложить по полочкам» и классифицировать знания по этой теме. Результат – данная статья. Надеюсь, она окажется полезной, а также поможет внедрить обзоры кода в свой производственный процесс тем, кто только об этом задумывается.

Обзор кода является одним из наиболее эффективных методов поиска и устранения дефектов программы. Обзоры проводятся человеком, что позволяет находить широкий класс ошибок, в том числе с трудом детектируемых или вообще не детектируемых автоматическими средствами. Безусловно, обзор кода, не отменяет использование анализаторов кода или других методик обнаружения ошибок, например, unit-тестирования. К сожалению, не существует метода, который один обеспечил бы обнаружение всех дефектов программы (в исследованиях эффективность обзора кода обычно оценивается как 30-50% обнаруженных ошибок в приложении).

Джофф Гарен (Geoff Garen) из компании Apple обнаружил вызов Sleep() в спинлоке функции TCMalloc сборщика мусора WebKit.

 -#if OS(WINDOWS)
-    Sleep(2);
-#else
-    struct timespec tm;
-    tm.tv_sec = 0;
-    tm.tv_nsec = 2000001;
-    nanosleep(&tm, NULL);
-#endif

После удаления Sleep производительность сборщика в определённых условиях выросла в 3,7 раза. Это наглядный пример, как одна маленькая оптимизация способна в несколько раз повысить производительность.

Привет, хабражители!

Сейчас какой-то спец с многолетним опытом работы с Qt подумал: «Что за фигня? Хабр — для вещей покруче!». Но ведь даже спецам с многолетним опытом иногда надо читать вот такие статьи про простые вещи, ведь это — важно. Код — это одна из самых важных составляющих программирования. А наша задача — держать его в чистоте. Эта статья посвящена всем Qt программистам которые стремятся к идеалу.

Конечно есть статья на Qt Project — Qt Coding Style. Только вот там материала ценного меньше…

На новой работе (С++) пришлось сменить привычный стиль кода, открывающие угловые скобки { надо было ставить на той же строке, что и начало блоков if/for etc. Поначалу было неприятно отказываться от старых привычек, но за неделю новый подход мне понравился. Тогда подумал — а вдруг существуют и другие аспекты стиля, которые надо изменить несмотря на то, что они пока еще кажутся непривычными? И несмотря на то, что большинство программистов по инерции их не использует. Оказалось, что так и есть. За пару месяцев я сильно переработал стиль, результаты ниже.

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

Cлышали ли вы об Open Source проектах, написанных на Java? А интересно ли вам узнать как они работают?



Если ваш ответ на последние два вопроса положителен, то неважно, слышали или нет вы о Queuepy до сих пор. Далее нам по пути.

Данный пост представляет собой выдержку «золотых правил» из примечательной книги Питера Гудлифа «Ремесло программиста».

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

От переводчика: The Codeless Code — сборник побасенок о философии программирования. Побасенки в сборнике разные — некоторые весьма кровожадные, некоторые достаточно хардкорные с технической точки зрения (родной язык автора — Java), но встречаются очень емкие. Представляю вам перевод семи наиболее полюбившихся мне историй, остальные 30+ (новые добавляются каждую неделю) можно найти на сайте.

Пустяк

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

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

Мастер ответил: «Здесь есть изъян, и я размышляю, как лучше его исправить.»

_{Две недели назад на Хабре публиковался перевод «Заблуждения программистов о времени», который по своей структуре и стилю основан на этом классическом тексте Патрика Макензи, опубликованном два года назад. Поскольку заметка о времени была крайне благоприятно воспринята аудиторией, то, очевидно, имеет смысл перевести и исходную статью об именах и фамилиях.}

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

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

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

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

Посмотрев конференцию GoingNative 2012 решил попытаться описать «best practice» для написания программ в стиле C++11. Планируется цикл статей, кому интересно,

Добрый день!

Сегодня ночью обнаружил, что очередной Stack Overflow Meetup состоится в этом году и в Москве.

Предыстория

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

Началось с того, что описал одну проблемку о проблемах ООП. Потом случайно благодаря разговорам тут начал обдумывать паттерны проектирования. И в связи с темой «полное копирование объекта» вышел на паттерн Flyweight. Кто не знает — прошу вначале читайте о нем в Приемы объектно-ориентированного проектирования. Паттерны проектирования (Не в вики, а в оригинале).

Основная идея там такова:

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

Задача

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

P.S. Если кому то интересна проблематика самих биовычислений по задаче сворачивания РНК/белков — делайте заказ напишу тогда отдельную статью.

Предыстория

Статья Неверное использование паттерна проектирования «Мост» / «Bridge» как то так получилось разделила аудиторию на двое. Далее я подумал, сказав А не сказать Б, будет не правильно. Нет я не отказываюсь от своих слов, но я нашел где и как я использовал паттерн «Мост». Т.к. его еще и неверно понимают, кажется альтернативное название «Описатель/тело» — меньше вводит в заблуждение.

Так где же? Оказалось в моем аналоге использования концепции MVC (Модель/Представление/Контроллер).

Поэтому вначале ознакомлю со своей вариацией «Бизнес-сущность — Визуализация — Контроллер». Я уже ее писал, но думаю мало кто с этим знаком. А затем посмотрим где же там «Правильный мост».

P.S. Мне тут выдали кредит доверия, и я обязался написать еще одну статью о усовершенствовании паттерна Flyweight — отчитываюсь написал.

Предистория

Я прочитал эту статью о паттерне проектирования «Мост». Увы, его очень часто используют неверно. Более того, я затем открыл книгу Приемы объектно-ориентированного проектирования. Паттерны проектирования. Оказалось — и там авторы очень смутно декларируют причины его наличия и когда его использовать. Поэтому ниже я вам сообщу, как и зачем подобное использовать.

Обновление

Это поверхностная статья, которую можно не совсем точно трактовать. Но её достоинство, что она короткая и вводит в проблематику. У специалистов она может вызвать вопросы более глубокого содержания, а у молодых разработчиков некоторые недоразумения, т.к. я спорю по сути с «Бандой четырех», но полностью согласен с Фаулером и его подходом к рефакторингу (да и у них между собой есть противоречия) — но типа а кто я такой, чтобы спорить.

Я готовлю расширенную статью для специалистов, но она может быть полезна и молодым разработчикам механистически выучившим паттерны проектирования. Они не очень хорошо понимают когда их использовать, а специалистам думаю будет важно аргументация в смысле, что из паттернов предпочесть. Эта расширенная статья надеюсь пояснит почему надо избавляться от паттерна «Мост», а также использовать паттерн Посредник в ограниченном смысле.

Уже есть ответвление этой статьи Правильное использование паттерна «Мост» (Мост с двухсторонним движением) или MVC->«Бизнес-сущность — Визуализация — Контроллер». Где показано, что Мост/Посредник можно использовать в некой комбинации при разделении визуализации и бизнес-логики, но это практически единственная сфера для этих шаблонов. В чистой бизнес-логике и низкоуровневых/системных задачах этих паттернов следует избегать.

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

Что такое паттерн проектирования «Мост» на самом деле

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

Посмотрим, что такое паттерн «Мост», что кроется за этим заумным термином. Это не что иное как комбинация применения наследования и агрегации. Увы, часто не знают, что такое агрегация. По- простому, это когда один объект включается в другой.

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

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

Теперь давайте посмотрим, как поступит в этом случае типичный джуниор. Есть задача – её надо решить. Их так учили в университетах. Многие из них ещё находятся под влиянием маргинального лозунга «пиши код, б##дь!». Итак, он наливает себе растворимого кофе, надевает наушники с чем-нибудь пожёстче и погромче и уходит в поток на пару-тройку часов.

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

Как это вообще взбрело мне в голову?

У каждого хабракомментария есть свой адрес. Строение адреса коментария:
habrahabr.ru/blogs/gtd/135090/#comment_4486120
То что до "#" — это ссылка на топик, а после — якорь, указывающий положение комментария на странице.
Если в комментариях указывать ссылки на другие комментарии, а потом жмякать по ним, то страница будет прокручиваться до нужного места. Еще у самих коментариев есть пара стрелок ↑ ↓ позволяющих перемещаться между ответами на комментарии.
«Эй!» — подумал я, — «что-то в этом есть». Сначала я размышлял над пределом запутанности комментариев, если в них ставить ссылки друг на друга. Но потом понял что тут кроется вообще что-то из элементарного программирования, сильно похожее на машину Тьюринга. Но какой-то детали не хватало, а ссылки в содержании комментариев использовать не хотелось. На помощь пришло добавление в избранное!

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

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

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

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