Как стать автором
Обновить
37.64

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

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

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

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

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

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

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

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

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

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

Новости

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Содержание:

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

Читать далее

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

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

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

Читать далее

Истории

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

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

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

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

Миф о RAM

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

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

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

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

for element in elements:

groups[element.group].append(element)

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

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

Читать далее

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

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

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

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

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

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

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

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

Поехали

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

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

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

Читать далее

Configuration-as-Code

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

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

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

Читать далее

Грязный код

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

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

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

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

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

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

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

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

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

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

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

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

Читать далее

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

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

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

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

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

Читать далее

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

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

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

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

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

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

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

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

Начнём.

Читать далее

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

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

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

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

Читать далее

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

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

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

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

Читать далее

Разумный подход к «Considered Harmful»

Время на прочтение7 мин
Количество просмотров1.8K
image

Недавно мне попалась статья Against Best Practices, и в целом я согласен с посылом этого поста. Но у меня были и собственные мысли на эту тему, поэтому изложу их здесь.

Даже не особенно углубляясь в историю разработки ПО, вы легко найдёте манифест в жанре Considered Harmful («Считается вредным»), самый знаменитый из которых составил легендарный учёный-информатик Эдсгер Дейкстра. Другая распространённая аналогия таких документов в духе времени — это «наилучшие практики». Это не менее субъективный кодекс подобных законов, которым зачастую критически не хватает такой обоснованности, как у манифестов из первой категории. Притом, что, на мой взгляд, и первые, и вторые имеют право на существование, их важно понимать в контексте, так как без контекста их значение легко размывается.
Читать дальше →

Структурный дизайн. Древний секрет простого и быстрого кода

Уровень сложностиСредний
Время на прочтение30 мин
Количество просмотров9.5K

Я пишу коммерческий код с 2005 года и с 2014 года ищу способ систематически писать хороший код.

В рамках этих поисков я изучил всю популярную литературу о хорошем коде и его дизайне — от «Чистого кода» Анкл Боба до «DDD» Эрика Эванса. Однако все популярные подходы в значительной степени субъективны: они не дают объективного и последовательного судьи, который бы решал, какой код лучше.

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

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

Отчаявшись научиться писать стабильно хороший объектно‑ориентированный код, в 2016 году я пошёл в сторону функционального программирования и архитектуры. Там с детерминированностью было получше: если в коде нет побочных эффектов (ввода‑вывода, оператора присваивания и чтения глобальных переменных) — то код хороший, если есть — плохой. Однако как затащить в коммерческий проект и, главное, собственную голову свободные монады и их интерпретаторы — я так и не понял.

Поэтому в 2020 году поиски своего Святого Грааля я продолжил в «эзотерических» и древних книгах. Одной из таких книг стал «Структурный дизайн» Ларри Константина. И в этой книге я, наконец, нашёл простой и понятный принцип, который лёг в основу моего текущего подхода к проектированию и кодированию, и для которого можно быстро и однозначно дать ответ, соответствует ли тот или иной кусочек кода этому принципу или нет.

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

Читать далее

Меньше JOIN’ов — больше скорость! Или несколько примеров оптимизаций DAX и SQL

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

Все мы любим ClickHouse, но прекрасно знаем, что у этой СУБД есть свои особенности и ограничения. В этой статье мы поговорим о том, почему нужно избавляться от лишних операторов JOIN, если вы работаете с большими нагрузками, а также оценим, какой эффект дает исключение JOINов, поднятие их на уровень выше, перестановка таблиц местами и некоторые другие хитрые трюки на уровне кода SQL. Всех, кто работает с ClickHouse, а также тех, кто не хочет работать с ClickHouse, но подумывает получить все готовенькое от Visiology, приглашаю под кат!

Читать далее

Почему ИИ рано поручать код-ревью

Время на прочтение8 мин
Количество просмотров2.4K

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

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

Читать далее

Игровое поле экспериментов: какие ошибки могут подстерегать программиста при создании эмулятора

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

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

Читать далее
1
23 ...

Вклад авторов