Обновить
128K+

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

Как Макконнелл завещал

61,2
Рейтинг
Сначала показывать
Порог рейтинга
Уровень сложности

Работает? Трогай! Рефакторинг

Уровень сложностиПростой
Время на прочтение11 мин
Охват и читатели14K

«Работает — не трогай!» — знакомая фраза? Звучит как девиз стабильности. Но в наше время все меняется со слишком большой скоростью, а такой подход может стать настоящей ловушкой Джокера. Оставленный без внимания проект рискует превратиться из мощного инструмента решения проблем в неподъемный багаж, неспособный соответствовать новым требованиям.

Как же понять, когда «не трогать» становится опаснее, чем «поменять»? Как определить момент, когда старый код начинает замедлять развитие, а не поддерживать его? Сегодня я хочу поговорить с вами о рефакторинге — о том, как найти баланс между работоспособностью и необходимостью изменений, как сохранить проект конкурентоспособным и жизнеспособным, и как, наконец, сделать этот самый рефакторинг.

Читать далее

Интеграция API — это кошмар

Время на прочтение4 мин
Охват и читатели4.5K
А вам казалось, что соединение API друг с другом — это нескончаемая битва?

Сейчас у нас уже есть машины, которые умнее людей. Но мы до сих пор не можем как следует справиться с интеграцией API. Что не так с API, которые часто становятся для разработчиков камнем преткновения? Интернету примерно 55 лет. Всемирной Паутине — 34 года. Даже JSON уже 18, я не шучу. За всё это время так и не найден простой способ соединять API. Почему так складывается, и почему мы общими силами не можем этого исправить? Читайте дальше.
Читать дальше →

Упрощаем «простой» ELF

Уровень сложностиСредний
Время на прочтение13 мин
Охват и читатели13K

Давайте-ка напишем простую программу для Linux. Насколько трудной она может быть? Только тут надо учесть, что простота противоположна сложности, но не трудности*, и создать нечто простое на удивление трудно. А что останется, если избавиться от сложности стандартной библиотеки, всех современных средств безопасности, отладочной информации и механизмов обработки ошибок?
Читать дальше →

К слову об именах переменных в Go

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели10K

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

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

Одной из ключевых особенностей Go является ориентация на читаемость и краткость кода. Это проявляется как в конструкциях языка, так и в стилевых рекомендациях, принятых сообществом и разработчиками языка.

Короткие имена переменных — важная часть этой философии. В отличие от языков, где длинные и описательные имена переменных могут быть нормой (например, PHP или Java), Go поощряет использование коротких имен, особенно в случаях, когда их смысл легко понять из контекста. 

Читать далее

Ошибки инженеров в больших кодовых базах

Уровень сложностиПростой
Время на прочтение6 мин
Охват и читатели16K

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

- От одного до десятка миллионов строк кода (допустим, примерно пять миллионов)

- Примерно от 100 до 1000 разработчиков, работающих над одной кодовой базой

- Первая работающая версия кодовой базы была выпущена как минимум десять лет назад

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

Читать далее

Пишем медленный код на Go

Уровень сложностиПростой
Время на прочтение5 мин
Охват и читатели15K

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

На самом деле, нет. Оптимизация кода на Golang ради производительности — это попросту трата времени, и вот почему:

1. Производительность в большинстве случаев не имеет значения
2. Go и так быстрый
3. Читаемость важнее скорости

Эти аргументы нуждаются в объяснении, и я его дам. Для них есть исключения, как, собственно говоря, для всех нетривиальных утверждений. Честно говоря, стоит сказать, что эти 3 пункта вряд ли являются компромиссом среди программистов‑инженеров. Так что, прежде чем начать снижать мне рейтинг и писать негативные комментарии («Худшая статья на Хабре»), прочитайте до конца.

Прочитать до конца

Как типы делают сложные задачи простыми

Уровень сложностиСредний
Время на прочтение20 мин
Охват и читатели33K

Последнюю пару лет мой мозг программиста всё больше увлекался типами, принципами функционального программирования и Typescript. По большей мере на это повлияло огромное количество времени, потраченное мной на кодовую базу Heartbeat — фулстек-приложения из трёхсот тысяч строк на Typescript, включающего в себя веб-приложение React, мобильное приложение React Native и сервер Node.js. Мой опыт работы с этой кодовой базой показал мне, что чем больше я полагаюсь на систему типов, тем больше пользы из этого извлекаю.

Написание кода в кодовой базе, полностью сделавшей упор на типы, похоже на жульничество. Часто я могу реализовать 80% новой фичи, ни разу не запустив код. Я начинаю работать над крупным рефакторингом, требующим нарушить допущение, принятое во всём коде, но вскоре выясняю, что благодаря системе типов изменения оказываются тривиальными. Простые фичи практически кодируют себя сами, потому что опечатки мгновенно отлавливаются, а половина моего кода пишется автодополнением. На вопросы от команды техподдержки о тонкостях работы какой-то фичи можно ответить при помощи Ctrl+F в коде, даже если письменной документации почти нет. Целые категории багов, с которыми мне приходилось бороться, попросту исчезли.

Я начал называть стиль кодинга, позволяющий реализовать подобное, Type Driven Development. В статье я приведу разрозненные мысли и ссылки на ресурсы, сильно повлиявшие на то, как я понимаю type driven development.
Читать дальше →

Архитектура фронтенд-приложений на React. (Нам не нужен FSD)

Уровень сложностиСредний
Время на прочтение9 мин
Охват и читатели46K

Всем привет, меня зовут Павел Рожков, я lead фронтенда в компании Doubletapp. Мы занимаемся заказной разработкой, и в нашей работе над React-проектами важную роль играет наш архитектурный гайдлайн, который мы постоянно совершенствуем. Это свод договоренностей о том, каким образом будет организован код в нашем проекте.

Гайдлайн помогает нам:

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

Сократить время разработки. У нас часто не возникает вопроса, как здесь сделать лучше, куда что положить, как организовать. Мы подумали об этом заранее.

Поддерживать старые проекты, т.к. они написаны по тем же принципам. 

Поднять качество кода: работать на проекте становится удобнее и можно сосредоточиться на важных вещах.

Онбордить новых членов команды благодаря готовой документации.

Содержание:

Почему бы нам просто не взять FSD?
Шаблон проекта с архитектурой
Структура кода приложения
Заключение

Читать далее

Давайте договоримся о тех.долге

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели7.4K

— Нам нужно выплачивать тех.долг!
— У нас нет на это ресурсов, нам нужно выпустить новую фичу!
Знакомый диалог? Давайте поговорим про технический долг и про то, как он влияет на бизнесовые цели. И на выпуск новых фичей

Читать далее

Книга: «Рецепты чистого кода»

Время на прочтение6 мин
Охват и читатели14K
image «Неуместная близость»? «Оргия объектов»? «Принцип KISS»? А мы точно о программировании?

Привет, Хаброжители! Если ваша первая и единственная реакция на эти словосочетания — смех, то вполне вероятно, что от вашего кода «пахнет». Запах кода (code smell) — термин, который был введен разработчиком Кентом Беком и популяризирован Мартином Фаулером. По сути, запах кода — это симптом, признак проблемы; он указывает на такой фрагмент кода, который можно (и нужно) улучшить.

Чем чище код, тем проще его читать, понимать и — что самое важное — поддерживать. И «Рецепты чистого кода» как раз про это! Четкая структура и краткость кода, а также осмысленные имена переменных, функций и классов, отражающие их суть, сокращают количество времени, которое тратится на поиск и устранение проблемы, — не говоря уже о том, что код, этими свойствами не обладающий, с трудом поддается масштабированию.
Читать дальше →

Миф о RAM

Уровень сложностиСредний
Время на прочтение5 мин
Охват и читатели33K

Миф о RAM — это верование о том, что память современного компьютера напоминает идеальную память с произвольным доступом. Кэш люди считают оптимизацией для малых данных: если они умещаются в L2, то будут обрабатываться быстрее; если нет, то тут уж ничего не поделаешь.

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

groups = [[] for _ in range(n_groups)]

for element in elements:

groups[element.group].append(element)

Он и в самом деле линеен (то есть асимптотически оптимален), и мы всё равно должны выполнять доступ к произвольным индексам, так что кэш здесь нам ни в чём бы не помог.

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

Читать далее

От мидла к синьору. Часть первая

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели16K

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

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

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

На основе этих наблюдений уточним критерий уровня разработчика — это качество принимаемых решений в условиях недостаточной информации.

Под качеством я имею ввиду «живучесть» решения. То есть принятое когда-то решение не начинает приносить проблемы и неудобства по мере развития системы. Другими словами, оно является эволюционно устойчивым.

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

Поехали

CodeChecker — контроль качества кода с использованием PVS-Studio

Уровень сложностиПростой
Время на прочтение4 мин
Охват и читатели3.1K

CodeChecker — довольно популярный Open Source инструмент контроля качества кода для Linux и macOS. В этой небольшой заметке расскажем о том, как его использовать вместе с анализатором PVS-Studio.

Читать далее

Ближайшие события

Configuration-as-Code

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели6.4K

За последнее десятилетие мы убедились, что выполнение вручную процессов расследования и реагирования ограничивает нас по скорости, что сильно сказывается на возможности обрабатывать прирастающий с каждым днем поток инцидентов и угроз. Для того, чтобы помочь в решении складывающейся ситуации специалисты ИБ начинают применять в своей практике новые подходы, такие как Everything as Code (EaC), который зародился на базе практик разработки ПО.

Одна из основных проблематик обнаружения инцидентов, процедур Threat hunting и обнаружения угроз (TI) — высокая гранулярность скриптов и функций, необходимость контроля версий и учета изменений. Поэтому инженеры по информационной безопасности, стремясь повысить эффективность детекта и улучшить качество работы переняли лучшие практики из IT-разработки и назвали этот метод Configuration-as-Code. Давайте разберемся, что он из себя представляет.

Читать далее

Грязный код

Уровень сложностиСредний
Время на прочтение10 мин
Охват и читатели50K
Эдсгер Дейкстра: «Грязно и быстро — мне это не понравится»

«Чтобы иметь право называть себя профессионалом, вы должны писать чистый код. Нет никаких разумных оправданий тому, чтобы не стремиться к лучшему». Clean Code

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

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

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

Я программирую уже довольно давно и видел разнообразные подходы к обеспечению работоспособности ПО. Кто-то любит объектно-ориентированное программирование (я тоже), другие умные люди его ненавидят. Кому-то нравится выразительность динамических языков, кого-то она бесит. Кто-то успешно выпускает программы, строго следуя концепции Test Driven Development, другие добавляют в конце проекта несколько сквозных тестов, а многие остаются где-то посередине этих крайних точек.

Я был свидетелем проектов, выпускавших и поддерживавших успешное ПО на основе всех этих разнообразных подходов.

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

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

Уровень сложностиПростой
Время на прочтение7 мин
Охват и читатели3.3K

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

Далее, для относительно сложных вариантов генерации SQL при изменениях бизнес-логики (или других изменениях) может измениться и сам динамически генерируемый SQL, причем результаты выполнения SQL могут остаться неизменными, однако производительность поменяется. В таких случаях изменения в производительности можно уловить при помощи бенчмарков, однако прогон бенчмарков может занимать значительное время, в связи с этим актуальна задача быстрого анализа изменений в производительности динамически генерируемого SQL. Интересны особенности анализа производительности приложения на основе SQL — добро пожаловать под кат :)

Читать далее

Многослойная архитектура FrontEnd-приложений на основании SOLID, часть 2

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели19K

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

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

Большинство нормально структурированных приложений придерживается ее высокоуровнево, но на деле она вас не особо ограничивает. Есть много сходств со стандартной MVC-архитектурой:

Читать далее

Domain-Driven Design: чистая архитектура снизу доверху

Уровень сложностиСредний
Время на прочтение18 мин
Охват и читатели92K

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

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

Да, мы уже знаем самые популярные практики: KISS, DRY, YAGNI, SOLID, что там ещё... Мы умеем их применять. Но нас не покидает чувство, что все эти практики объединяет общая научная основа. Знаете, это как с Менделеевым, который на основе закономерностей практически по наитию составил периодическую систему, а потом открыли электроны и всё встало на свои места.

У меня для вас хорошие новости: научная основа есть. Это предметно-ориентированное проектирование.

Но есть и плохая новость: тема настолько новая и непростая в изучении, что какая-никакая популярность к ней пришла лет 5 назад, и до сих пор совсем небольшое число разработчиков достаточно хорошо в ней разбирается.

Но есть ещё одна хорошая новость: в статье ниже я постараюсь дать максимально понятный ответ, что же такое предметно-ориентированное проектирование.

Начнём.

Читать далее

Гадание на пяти строчках: о чем молчит программа

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели4.6K

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

Читать далее

Многослойная архитектура FrontEnd-приложений на основании SOLID, часть 1

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели16K

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

Но в основном сначала получается та самая картина с балконом.

Читать далее