Рубрика «Совершенный код» - 13

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

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

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

Как работает оптимизирующий компилятор - 1

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

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

Привет!
Предлагаю вашему вниманию перевод статьи "Too Clean?" автора Robert C. Martin (Uncle Bob).
image
Я только что посмотрел выступление Сары Мэй: Жизнеспособный код. Это было очень хорошо. Я полностью согласен с основными моментами ее выступления. С другой стороны, темой ее выступления было то, что я раньше должным образом не рассматривал.
Читать полностью »

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

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

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

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

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

Как добавить проверки в NoVerify, не написав ни строчки Go-кода - 1

Читать полностью »

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

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

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

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

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

Читать полностью »

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

Лошадь сдохла – слезь: переход с tslint на eslint - 1
Читать полностью »

Программист-защитник сильнее энтропии - 1

© Dragon Ball. Goku.

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

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

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

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

Читать полностью »

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

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

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

Читать полностью »

Хороший разработчик мудр, а не гениален - 1

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

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

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

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

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

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

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

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

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


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

Читать полностью »

Я в одиночку отрефакторил 15 тысяч строк легаси. Это были худшие две недели в жизни - 1

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


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js