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

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

Среди бесчисленных режимов адресации архитектуры х86 существует один такой…
Впрочем, почему «бесчисленных» режимов? Если разобраться, то их немного. Со времен первого процессора 8086 адресация укладывалась в байт, который имел аббревиатуру MODRM, где «MOD» - это собственно режим адресации (т.е. mode), «R» - регистр и «M» - очевидно, память (memory).
Если не рассматривать дальнейшее совершенствование системы адресации с помощью SIB-байта, то, поскольку под MODE в MODRM-байте выделено всего два бита, получается, что возможны всего-навсего четыре режима адресации.

Меня зовут Кирилл Мокевнин, я CEO и сооснователь онлайн-школы программирования Хекслет. Мы помогаем людям с самым разным бэкграундом стать разработчиками уже 10 лет. За это время я не раз замечал, что зачастую студенты плохо представляют себе профессию. Вещи, не относящиеся напрямую к технической составляющей программирования, но имеющие огромное значение для успеха в будущей специальности, становятся для них сюрпризами еще во время обучения.

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

Почему ты выбрал такой подход к решению?

• Не знаю. Прочитал в какой-то статье.
• Не знаю. Скопипастил его из X.
• Не знаю. Такой же подход я использовал в предыдущем проекте.
• Не знаю. Кто-то мне посоветовал.

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

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

Конечно же эта простая программа не должна иметь баги. Верно?

Привет Хабр! Пятничного тру ФП хардкора с Free Monad, Таглес Финал, Монад трансформерами, Refined Types, Smart Constructors и прочим таким вам в ленту. Хардкор сам себя в ленту не принесет так что погнали.

Гексагональная архитектура делит наш код на три основные части.

1) Primary Adapters,

2) Secondary Adapter

3) Logic aka Domain.

Эта статья является переводом материала «Mapper Contexts & Supercontexts: Decoupling Domain-Specific and Domain-Generic Bounded Contexts».

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

Первый разработчик предлагает модель push: ограниченный контекст должен дать указание Notifications отправить уведомление. Notifications должен просто подчиняться командам и отправлять указанные уведомления.

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

Как бы вы спроектировали решение? Что еще более важно, как бы вы приняли это решение в команде? Как вы будете разрабатывать наиболее эффективную архитектуру, которая поддерживает краткосрочные цели и долгосрочное развитие?

Программисты читают код намного чаще, чем пишут его, поэтому важно писать понятный, последовательный, однозначный код. Автор книги С++17 in detail написал о способах избегать путаницы. Делимся его материалом к старту курса по разработке на С++.

С появлением подсказок типов (type hints) в Python 3.5+ добавилась опциональная статическая типизация – поэтому эти подсказки так мне нравятся. Теперь я аннотирую ими все мои проекты.

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

Тем не менее, я осознал: нет такого понятия — чистый код.

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

Всем привет, меня зовут Макс Кравец, я CEO IT-компании Holyweb, и сегодня хочу поделиться вредными советами о том, как стать незаменимым React-разработчиком. Поехали!

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

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

Слишком мало запятых

Правильный процесс ревью кода — это процесс итеративного улучшения продукты и контроля.
Контроля того, что:
1) Cоблюдены общие правила и договорённости
2) Решение не избыточное и масштабируемое.
3) Решение покрывает все критерии приемки указанные в описании к задаче

Для начала будет хорошо задать в своей команды такие вопросы:
1) Сколько времени занимает ревью кода для средней (сферической в вакууме) задачи
2) Как вы минимизируете время ревью?
3) Как вы определяете, что ревью конкретной задачи сделано правильно?