Совершенный код *

▍ Страдание

Hola, Amigos! Меня зовут Евгений Шмулевский, я PHP-разработчик в агентстве заказной разработки Amiga. В этой статье хотелось бы рассмотреть вопрос качества кода и что из рекомендаций по нему лично для себя использую. Статья адресована начинающим разработчикам.

⚡ Tl;dr

• Модуляризация — это метод разделения сложных систем на более мелкие удобоваримые части для лучшего управления и восприятия.
• Она повышает эффективность, надежность и ремонтопригодность программных проектов за счет организации кода в модули.
• Она снижает когнитивную нагрузку на разработчиков за счет уменьшения объема информации, которую им приходится обрабатывать за один раз, что облегчает понимание сложных систем и предотвращает их «выгорание».
• Модули при разработке программного обеспечения можно рассматривать как строительные кубики, наподобие деталей «Лего».
• Каждый модуль имеет уникальный набор общедоступных интерфейсов, структур данных или сообщений, которые служат контрактами для других разработчиков.
• При работе с модулями важно относиться к ним как к «черным ящикам» и взаимодействовать с ними только через определенные общедоступные интерфейсы, чтобы избежать сильного связывания и повысить модульность системы.
• Сборки используются для группировки кода в .NET, поскольку они обеспечивают более высокий уровень инкапсуляции (использование внутреннего доступа). Это позволяет разработчикам контролировать уровень доступа другого кода к членам типа и помогает защитить детали реализации типа или элемента.
• Чтобы сделать реализацию прозрачной для тестирования, можно использовать атрибут в файле csproj и указать имя сборки тестового проекта.

Прообраз code review появился в 60-х годах прошлого столетия, когда программы писали на перфокартах. Главной проблемой тогда было преобразование программного кода в машинный — компиляция. Это сложный процесс, чувствительный к ошибкам и структуре написанного кода. Если в процессе генерации всплывала одна незначительная ошибка, приходилось начинать процесс заново: набирать, проверять и занимать очередь доступа к системе, которая могла длиться месяцами из-за большого количества желающих воспользоваться компьютером. Из-за высокой цены ошибки программисты досконально проверяли перфокарты друг за другом.

Сегодня ошибки в информационных системах по-прежнему стоят недешево, хоть исправлять их попроще. Проверка кода одним программистом за другим получила широкое распространение и сегодня известна как практика code review.

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

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

Кучу времени можно сэкономить если:

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

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

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

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

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

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

Бунтарём себя можно считать только тогда, когда люди на самом деле защищают противоположную вашей позицию. Я не согласен с одной из best practices, недавно представленной в Google Testing Blog . Обычно это очень хороший ресурс, ведь этот пост не случайно попал в мою читалку новостей!

Авторы представили две версии функции и спросили, какая из них более читаема.

Рассмотрим разницу между популярными ошибками при работе с многопоточностью, такими как Data Race и Race Condition, а также способами борьбы с ними.

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

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

Чтобы исправить ситуацию, нужно собрать мощный, оптимизированный, а главное, реюзабельный ESLint.

Это статья написана на основе доклада Дениса Красновского для FronendConf 2022. Денис, руководитель направления разработки и фронтэнд-лид в компании Домклик.

Некоторые оптимальные алгоритмы, оказывается, можно вывести из неоптимальных, пользуясь эквивалентными преобразованиями алгоритма. Бёрд и Меертенс разработали формализм, который устанавливает свойства функций высшего порядка map, fold, scan, позволяющие преобразовывать алгоритмы в эквивалентные. (См. также на Вики). Ниже представлен вольный перевод статьи Бёрда.

Рассмотрим задачу поиска максимальной суммы сегмента массива. Эту задачу можно переформулировать в виде математически точного ответа:

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

Написание кода похоже на соединение двух точек. Ожидаемо, что самым простым путем будет нарисовать прямую линию между точками А и Б. 

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

Давайте увеличим количество препятствий на порядок. Линия становится все более извилистой.

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

А если мы заставим двигаться не только препятствия, но и сами точки? Вдобавок убедимся, что эти точки не приклеены к линиям, и вам придется следить за ними, чтобы они оставались соединенными. Начинает немного бесить?

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

Давай разберёмся подробнее, что это такое и как применять.

"Идеальный программист" Роберта Мартина давно стал руководством по профессионализму в сфере IT и одним из основополагающих трудов в современной разработке, наравне с "Чистым кодом", "Чистой архитектурой" и "Чистым эджайлом".

В посте ниже собраны наиболее значимые тезисы из "Идеального программиста".