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

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



Недавно Физтех, Яндекс и ШАД запустили ещё один курс на платформе Coursera — «Основы разработки на C++: белый пояс». Он посвящён знакомству с С++. Я расскажу, для кого этот курс, как мы его готовили, что получилось в итоге и каковы наши дальнейшие планы.

Как всё началось, было выброшено и началось снова

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

Ошибок в условиях допускается великое множество. Можно взять для примера любой пост из блога PVS-studio, в каждом есть ошибки, связанные с невнимательным обращением с условиями. И правда, нелегко разглядеть ошибку в условии, если код выглядит так (пример из этого поста):

static int ParseNumber(const char* tx)
{
  ....
  else if (strlen(tx) >= 4 && (strncmp(tx, "%eps", 4) == 0
    || strncmp(tx, "+%pi", 4) == 0 || strncmp(tx, "-%pi", 4) == 0
    || strncmp(tx, "+Inf", 4) == 0 || strncmp(tx, "-Inf", 4) == 0
    || strncmp(tx, "+Nan", 4) == 0 || strncmp(tx, "-Nan", 4) == 0
    || strncmp(tx, "%nan", 4) == 0 || strncmp(tx, "%inf", 4) == 0
          ))
  {
      return 4;
  }
  else if (strlen(tx) >= 3
    && (strncmp(tx, "+%e", 3) == 0
     || strncmp(tx, "-%e", 3) == 0
     || strncmp(tx, "%pi", 3) == 0   // <=
     || strncmp(tx, "Nan", 3) == 0
     || strncmp(tx, "Inf", 3) == 0
     || strncmp(tx, "%pi", 3) == 0)) // <=
  {
      return 3;
  }
  ....
}

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

— Что, даже на том нечитаемом эзотерическом языке, где есть всего пара команд, которые едва-едва симулируют машину Тьюринга?
— Да, этот язык называется brainfuck. Я знаю brainfuck.

И это был не трюк — мы проверили. Я называл известный мне язык программирования, он тратил пару минут в Интернете на то, чтобы освежить свои знания по нему — и был способен писать на этом языке работающие алгоритмы. Я никак не мог понять этого. Ему, как и мне, было тогда около 18 лет — как он мог в этом возрасте знать все эти языки?


Интерпретатор brainfuck, написанный на brainfuck

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

Сегодня я советую своим студентам «постараться изучить все языки программирования». Подумайте сами — ведь эта идея лучше, чем все вот эти «В этом году я выучу Go! Ой, нет, теперь говорят что в моде Rust — выучу лучше Rust! Или Swift ...». Просто выучите все — не ошибётесь. А эта статья, возможно, вам в этом немного поможет.

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

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

Code review может быть большой болью для команды, которая только начинает его внедрять. Вы в любом случае наступите на много граблей: будете проводить ревью дольше, чем пишете код, устраивать смертельные споры про расположение скобочек и разбираться, можно ли сливать ветку в master до аппрува команды или нет. Я собрал ряд практик, которые помогут вам сделать процесс адаптации чуть менее болезненным — по крайней мере, мне они точно помогли.
 
Этот материал — краткая выжимка моего опыта, накопленного за несколько лет работы в крупных командах мобильной разработки. Опыт по большей части в мобильной разработке, что оказало влияние на используемые примеры и ссылки. Для тех, кто предпочитает не читать, а смотреть, в течение пары месяцев должно появиться видео с конференции Mobius, где я рассказываю доклад на эту же тему, но с кучей подробных практических примеров.
 

JavaScript-разработчик из Франции, Себастьян Кастель, поделился мыслями о том, как на его взгляд должен выглядеть JavaScript код в 2017 году.

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



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

Только что я столкнулся с еще одним проявлением синдрома самозванца: «Я правда разработчик — или просто хорошо гуглю?»

Далее следовал ответ, в котором я, однако, не увидел главного — поэтому ответить придется мне: слишком уж многие боятся без каких-либо оснований.

Переведено в Alconost

Если информацию легко найти, это не делает человека глупым

Частенько мне доводится слышать одну историю — полагаю, подлинность ее сомнительна, но, как бы там ни было, суть такова. Когда у Эйнштейна попросили номер телефона, он полез его искать и сказал: «Зачем запоминать то, что можно найти менее чем за две минуты?»

Так зачем же мы пишем этот плохой код, который изо дня в день замедляет нашу работу?
Потому, что мы тогда вынуждены были сделать что-то быстрее!
Я оставлю вас наедине с это логической несостыковкой…
_{На одной из лекций Роберта Мартина}

У нас на DevConf будет не самый обычный мастер-класс. Там не будут рассказывать о новых технологиях или хайлоаде. Будут говорить о коде. Хорошем, плохом. Называется он Принципы хорошего кода на реальных примерах. Расспросим немного автора.

Кто ты и чем занимаешься?

Меня зовут Адель. Я фрилансер. Обычно занимаюсь backend-разработкой. Еще иногда пишу и дописываю плагины для PhpStorm. Из популярных Laravel plugin и .env files support.

Что тебя побудило на такой мастер-класс?

Удрученность текущей ситуации в отрасли. Все одержимы технологиями. В последнее время облачными. Читаешь вакансию, перечисляют используемые технологии, необходимый опыт (который почти никогда, на самом деле, не нужен). Очень круто звучит на собеседованиях. Приходишь на проект. Смотришь на код… и он печально говорит тебе: «Пристрели меня». Смотришь глубже и понимаешь всю его печаль. Он смертельно болен. Как раковые опухоли разрослись классы, которые кто-то, словно в шутку, назвал контроллерами. Как метастазы везде расползлись копипасты. На психологию кода давит то, что он лишь жалкая обвязка для крутых облачных технологий. Но пристрелить дорого.

Задача публикации: доступно изложить способ организации иерархии исключений и их обработки в приложении. Без привязки к фреймворкам и конкретной архитектуре. Описываемый способ является де-факто стандартом в сообществе: он используется во многих серьёзных библиотеках и фреймворках. В том числе Zend, Symfony. Не смотря на его логичность и универсальность, формального описания предлагаемого подхода на русском языке я не нашёл. После неоднократного устного изложения концепции коллегам, родилась мысль оформить её в виде публикации на Хабрахабр.

В языке PHP, начиная с 5-ой версии, доступен механизм исключений. В актуальной, 7-ой, версии этот механизм был улучшен и переработан с целью единнобразной обработки разных ошибок при помощи конструкции try{} catch...

В стандартной библиотеке (SPL) PHP предоставляет готовый набор базовых классов и интерфейсов для исключений. В 7-ой версии этот набор был расширен интерфейсом Throwable. Вот диаграмма всех имеющихся в версии 7 типов (изображение — ссылка):

Проверим на примере: пишем сервис с аэропортами и направлениями.

defmodule Airport do
  defstruct [:id, :name]
end

defmodule Direction do
  defstruct [:origin, :destination]

  def example do
    madrid = %Airport{id: "MAD", name: "Madrid"}
    riga = %Airport{id: "RIX", name: "Riga"}
    %Direction{origin: riga, destination: madrid}
  end
end

Пока что всё в порядке. Отлично, съели печеньку, смотрим, что дальше в джире. Список самых популярных направлений?

Я был недоверчив, когда прочитал это наблюдение у Реджинальда Брейтуэйт:

Как и у меня, у автора возникают проблемы с тем фактом, что 199 из 200 претендентов на каждое задание программирования не могут писать код вообще. Повторяю: они не могут писать никакого кода вообще.

Чтобы полностью раскрыть все преимущества Kotlin, пересмотрим некоторые подходы, которые мы используем в Java. Многие из них могут быть заменены на лучшие аналоги из Kotlin. Давайте посмотрим на то, как мы можем написать идиоматичный код на Kotlin.

Все началось лет 8 назад. Я тогда писал одну программу для математических расчетов, и мой преподаватель указал, что я неверно именую переменные. Он был прав: x, xx, xxx сложновато различить в коде. После переименования они превратились в redSegment, greenSegment, blueSegment (в контексте задачи именование было подходящее). Потом были «Рефакторинг» Фаулера, «Совершенный код» Макконнелла, «Паттерны проектирования» банды четырех… каждый день я погружался все глубже в бездну.

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

Введение

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

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

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

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

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

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

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

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

Код, использующий неявное поведение, может быть основан на каком-нибудь недокументированном, но уже реализованном функционале. Например, в мире написана целая куча НЕВЕРНОГО кода, который полагается на то, что функция файловой системы, возвращающая список директорий, вернёт их в отсортированном по алфавиту порядке. Это и вправду часто работает именно так, но ровно до того момента, пока не ломается по «непонятным» причинам. А на самом деле просто никто никогда этой сортировки не гарантировал.

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

Информационная безопасность — это важно; впрочем, это знание мало кому помогает. Количество соединенных general-purpose компьютеров (==сложность) растёт каждый день, происходят очень реальные инциденты от Heart или Cloudbleed до Stuxnet или проблем с бортовым компьютером Toyota (когда машина не останавливается), и ситуация не становится лучше сама по себе. Становится хуже, потому что "интернет вещей" — это стартапы, делающие физическую инфраструктуру типа лампочек или дверных замков (разработчики SCADA плачут кровавыми слезами). Потому что огромное количество кода пишется на memory-unsafe языках. Потому что образование разработчиков — это, как правило, либо про фичи (проекты / этожпрототип), либо про фундаментальные алгоритмы (что не помогает пониманию того, что система работает не в вакууме).

Кажется, что основных корней проблемы два: это небезопасный инструментарий — например, ЯП (C/C++) и библиотеки (OpenSSL), и люди. Люди забывают про ИБ, думают "выпустим что-нибудь, а потом разберёмся", не понимают tradeoff'ы своих инструментов (то, что "C — это быстро", знают все, а вот про memory unsafety и масштаб UB — немногие), etc. Первая проблема сейчас решается сообществом: разрабатываются безопасные языки типа Rust и простые, понятные библиотеки типа TweetNaCl. Остаётся вторая (ведь хорошим инструментам надо ещё научить, как и соответствующему мышлению).

Поэтому мы проводим митап по информационной безопасности Security by Default.