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

Меня зовут Дмитрий Шехтман, и я автор самых маленьких компьютерных шахмат в мире.

Началось всё с того, что моя (ныне бывшая) девушка предложила написать компьютерные шахматы. Идея меня заинтересовала, и я решил этим заняться. Правда, почитав интернет, я понял, что опоздал лет на сорок. Особенно впечатляли шахматные разработки Оскара Толедо — на Си размером в 1257 байт, на JavaScript в 1023 байта и, наконец, Atomchess на ассемблере x86, компилирующийся в 392 байта.

Прежде, чем я вернулся к теме, прошло несколько месяцев. Как оказалось, за это время был установлен новый рекорд размера — ChesSkelet для ZX Spectrum занимал всего 352 байта. Правда, он не знал всех правил и играл весьма слабо, но всё же! А не замахнуться ли мне на шахматы на ассемблере? — подумал я.

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

В этой статье мы рассмотрим некоторые из основных методик приведения (inference techniques) в оптимизирующих компиляторах: как спроектировать программу, с которой компилятору будет легко работать; какие приведения можно сделать в вашей программе и как использовать их для её уменьшения и ускорения.

Привет, Хабр!

Предлагаю вашему вниманию перевод статьи "Simple Hickey" автора Robert C. Martin (Uncle Bob).



Рич Хики выступил с отличной лекцией в «Strange Loop» под названием «Простое, сделанное легко». Я настоятельно рекомендую вам потратить час и послушать её. Это выступление стоит каждой потраченной секунды.

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

Привет, Хабр!

Предлагаю вашему вниманию перевод статьи "Too Clean?" автора Robert C. Martin (Uncle Bob).



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

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

Чтобы вас заинтриговать, покажу описание простой, но полезной инспекции:

/** @warning duplicated sub-expressions inside boolean expression */
$x && $x;

Эта инспекция находит все выражения логического &&, где левый и правый операнд идентичны.

NoVerify — статический анализатор для PHP, написанный на Go. Почитать о нём можно в статье «NoVerify: линтер для PHP от Команды ВКонтакте». А в этом обзоре я расскажу о новой функциональности и том, как мы к ней пришли.

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

Возможно вы читали первую часть статьи про код ревью со стороны ревьювера (кстати, мы уже успели ее обсудить в последнем выпуске подкаста "Цинковый прод").

Так как статья набрала много лайков, пишу обещанное продолжение про код ревью с другой стороны — со стороны автора изменений кода

Как обычно, будем говорить MR (Merge Request) вместо CL, потому что термин CL мало кто понимает.

Оригинал инструкции для авторов MR по версии Google можно посмотреть здесь, а я дам краткую выжимку.

Итак, поехали

В недавнем выпуске подкаста DotNet&More мы обсуждали с Максимом Аршиновым его предстоящий доклад на Московский .Next "Блеск и нищета предметной модели". С позицией Максима можно будет легко познакомиться непосредственно на конференции. И, в качестве дополнения, я бы хотел рассмотреть видение великого спора Анемичная VS "Богатая" ("Насыщенная") доменные модели через призму некогда популярных GRASP шаблонов

Дискуссии идут достаточно давно, например:

• Anemic Domain Model [Перевод]
• [Перевод] Анемичная модель предметной области — не анти-шаблон, а архитектура по принципам SOLID
  Судя по 190 комментариями к последней статье, данная тема не теряет актуальности.

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

"Богатая" модель, в свою очередь, может содержать логику, описывающую бизнес правила, функции и т.д. Обратите внимание, что мы рассматриваем именно методы, отражающие бизнес логику. ToString, GetHashCode и прочие "технические" части классов не входят в предмет обсуждения, потому и игнорируются.

До недавнего времени во всех проектах фронта разработчики Dodo Pizza Engineering использовали tslint – полезный инструмент, который подсказывает, когда ты накосячил в коде допустил неточность, помогает поддерживать код в одном стиле и сам исправляет многие замечания. Но тут tslint взял и умер. Под катом я расскажу, почему так вышло, как перестать лить слёзы по умершему и перейти на инструмент eslint, а также покажу кое-что очень интимное.

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

© Dragon Ball. Goku.

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

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

Давайте разберёмся подробнее, что входит в понятие «падать изящно».

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

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

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

Хороший код выразителен, а не впечатляющ.

Я помню, как услышав это спросил «А в чём разница?», и получил ответ.

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

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

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

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

Программирование — не работа в ЦРУ, вам не нужно быть смекалистым.

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

---

Вот ещё несколько принципов мудрых разработчиков.

Привет, Хабр!

Часто ли у вас было, что вы или ваши коллеги не могли описать свой собственный код парочкой фраз?

Предлагаю вашему вниманию перевод статьи "How to write easily describable code" автора Cedd Burge, в которой он делится советом, как избежать таких ситуаций.

В сортировках распределением элементы распределяются и перераспределяются по классам до тех пор, пока массив не отсортируется.

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

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

• Ни одну программу нельзя «закрыть» на 100%.
• Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

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

Это заключительная часть цикла про Dynamic Language Runtime. Предыдущие статьи:

1. Подробно о dynamic: подковерные игры компилятора, утечка памяти, нюансы производительности. В этой статье подробно рассматривается кэш DLR и важные для разработчика моменты, с ним связанные.
2. Грокаем DLR. Общий обзор технологии, препарирование DynamicMetaObject и небольшая инструкция о том, как создать собственный динамический класс.

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

Комментарий от переводчика: Это перевод замечательной статьи Дэна Абрамова (Dan Abramov), являющегося контрибутором React. Его примеры написаны для JS, но будут одинаково понятны разработчикам на любом языке. Идея общая для всех.

Вы слышали об алгебраических эффектах?

Мои первые попытки выяснить, кто они такие и почему они должны меня волновать, оказались безуспешными. Я нашел несколько PDF-ов, но они еще больше меня запутали. (Я почему-то засыпаю во время чтения академических статей.)

Но мой коллега Себастьян продолжал называть их ментальной моделью некоторых вещей, которые мы делаем в React. (Себастьян работает в команде React и выдвигал немало идей, среди которых Hooks и Suspense.) В какой-то момент это стало локальным мемом в команде React, и многие наши разговоры заканчивались следующим:

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