Обновить
158.17

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

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

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

Чему я научился на своём горьком опыте (за 30 лет в разработке ПО)

Время на прочтение22 мин
Охват и читатели118K
image

Это циничная, клиническая коллекция того, чему я научился за 30 лет работы в разработке программного обеспечения. Повторюсь, некоторые вещи весьма циничны, а остальное — результат долгих наблюдений на разных местах работы.
Читать дальше →
982 слайда Фридмана на тему производительности во фронтенде, обсуждение Yandex Database, мониторинг Postgres, взгляд на свой продукт глазами инвестора под руководством Морейниса, новая конференция по качеству, слет DevRel'ов, текучка кадров, оценка вклада сотрудника, польза от факапов — все это в небольшом фоторепортаже с площадки РИТ++, где мы наблюдали за происходящим глазами участника. А также о программе фестиваля, гиковских играх, призах и о прочих интересных моментах.
Подробности – под катом

Один язык чтобы править всеми

Время на прочтение6 мин
Охват и читатели28K

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



На момент написания этой статьи запрос «программирование какой язык изучать первым» выдаёт 517 миллионов поисковых результатов. Каждый из этих сайтов будет нахваливать один определённый язык, и 90% из них, в конечном итоге, порекомендуют Python или JavaScript.


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


Просто знать как кодить ещё не достаточно. Рынок настолько насыщен выпускниками институтов и курсов, что позиция джуниора практически перестала существовать*. Чтобы преуспеть в сегодняшнем мире, вы должны и кодить, и иметь продвинутое фундаментальное логическое мышление.


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


Мой первый урок информатики


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


«Сегодня мы будем дегустировать самостоятельно приготовленные пломбиры. Но с одним условием: вы должны составить список конкретных инструкций, как приготовить десерт, а я — буду им следовать»

Читать дальше →

Стоит ли высокое качество ПО затрат на его разработку?

Время на прочтение12 мин
Охват и читатели29K

Часто в процессе реализации проектов команды сталкиваются с вопросом: чему следует уделять больше внимания – выпуску новых фич или повышению качества кода? Обычно менеджеры делают выбор в пользу фич. Зачастую разработчики таким положением дел недовольны, считая, что им выделяется недостаточно времени для работы над архитектурой и качеством кода.

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

Несмотря на то, что основная целевая аудитория статьи это разработчики, для её понимания не требуется специальных знаний. Мне бы хотелось чтобы эта статья принесла пользу всем, кто так или иначе связан с процессом разработки, а особенно менеджерам, которые формируют вектор развития продуктов.
Читать дальше →

Эффективная генерация числа в заданном интервале

Время на прочтение16 мин
Охват и читатели39K
image

В подавляющем большинстве моих постов о генерации случайных чисел рассматривались в основном свойства различных схем генерации. Это может оказаться неожиданным, но производительность алгоритма рандомизации может зависеть не от выбранной схемы генерации, а от других факторов. В этом посте (на который меня вдохновила превосходная статья Дэниела Лемира) мы исследуем основные причины снижения производительности генерации случайных чисел, которые часто перевешивают производительность движка ГПСЧ.

Представьте такую ситуацию:

В качестве домашнего задания Хуан и Саша реализуют одинаковый рандомизированный алгоритм на C++, который будет выполняться на одном университетском компьютере и с одним набором данных. Их код почти идентичен и отличается только в генерации случайных чисел. Хуан торопится на свои занятия по музыке, поэтому просто выбрал вихрь Мерсенна. Саша, с другой стороны, потратил несколько лишних часов на исследования. Саша провёл бенчмарки нескольких самых быстрых ГПСЧ, о которых недавно узнал из соцсетей, и выбрал наиболее быстрый. При встрече Саше не терпелось похвастаться, и он спросил Хуана: «Какой ГПСЧ ты использовал?»

«Лично я просто взял вихрь Мерсенна — он встроен в язык и вроде неплохо работает».

«Ха!», — ответил Саша. «Я использовал jsf32. Он намного быстрее, чем старый и медленный вихрь Мерсенна! Моя программа выполняется за 3 минуты 15 секунд!».

«Хм, неплохо, а моя справляется меньше, чем за минуту», — говорит Хуан и пожимает плечами. «Ну ладно, мне пора на концерт. Пойдёшь со мной?»

«Нет», — отвечает Саша. «Мне… эээ… нужно снова взглянуть на свой код».

Эта неловкая вымышленная ситуация не особо и вымышлена; она основана на реальных результатах. Если ваш рандомизированный алгоритм выполняется не так быстро, как хотелось бы, и узким местом похоже является генерация случайных чисел, то, как это ни странно, проблема может быть и не в генераторе случайных чисел!
Читать дальше →

Стэнфорд, кажется у нас проблемы…

Время на прочтение3 мин
Охват и читатели5.6K

На ваш суд скорее статья-вопрос, статья-рассуждение и местами — недоумение. С одной стороны нам презентовали авторитетное мнение Лесли Лэмпорта "Programming Should Be More Than Coding", расставляющее программирование и кодирование в импровизированном табеле о рангах. С оппонирующей стороны — я, не обладающий статусом достаточным для споров с мэтром и легендарным ВУЗом, который он представляет… но отказать себе в таком удовольствии и риске я не могу. Надеюсь, более опытные товарищи поправят мои огрехи в рассуждениях.


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


Как опытные инженеры, мы — мастера абстракций. Поэтому для нас не составит труда представить условного программиста по имени Лесли Лэмпорт (все имена и совпадения не случайны) и его основной инструмент — машину Тьюринга. Он — мастер своего дела, во многом благодаря железному дао:

Читать дальше →

Рекомендации по написанию чистого кода на JavaScript

Время на прочтение8 мин
Охват и читатели39K
Если вы заботитесь о самом коде, и о том, как он написан, а не заняты лишь тем, чтобы создавать работающие программы, это означает что вы стремитесь к тому, чтобы ваш код был чистым. Профессиональный разработчик пишет код не только в расчёте на компьютеры, но и в расчёте на себя самого, встретившего этот код в будущем, и в расчёте на других программистов. Код, который вы пишете, не исчезает навсегда в недрах компьютера. Он живёт, изменяется, и, если написан плохо, вполне может сильно расстроить того, кому придётся редактировать его после того, как вы его написали. Вполне возможно, что этим «кем-то» будете именно вы.



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

5 принципов здравого смысла для создания cloud-native apps

Время на прочтение9 мин
Охват и читатели5.2K
«Облачно-ориентированные» (cloud native) или просто «облачные» приложения создаются специально для работы в облачных инфраструктурах. Обычно они строятся как набор слабо связанных микросервисов, упакованных в контейнеры, которые, в свою очередь управляются облачной платформой. Такие приложения по умолчанию готовы к сбоям, а значит надежно работают и масштабируются даже при серьезных отказах инфраструктурного уровня. Обратная сторона медали – наборы ограничений (контракты), которые облачная платформа накладывает на контейнерные приложения, чтобы иметь возможность управлять ими в автоматическом режиме.



Прекрасно осознавая необходимость и важность перехода на облачные приложения, многие организации все еще не знают, с чего начать. В этом посте мы рассмотрим ряд принципов, соблюдение которых при разработке контейнерных приложений позволит реализовать потенциал облачных платформ и добиться надежной работы и масштабирования приложений даже при серьезных отказах на уровне ИТ-инфраструктуры. Конечная цель изложенных здесь принципов – научиться создавать приложения, которые могут автоматически управляться облачными платформами, такими как Kubernetes.
Читать дальше: 5 принципов здравого смысла для создания cloud-native apps

Мы написали самый полезный код в своей жизни, но его выкинули на помойку. Вместе с нами

Время на прочтение16 мин
Охват и читатели72K


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

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

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

Метаморфическое тестирование: почему об этой перспективной методике почти никто не знает

Время на прочтение8 мин
Охват и читатели11K
image

Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория


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

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

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

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.
Читать дальше →

Single Responsibility Principle. Не такой простой, как кажется

Время на прочтение10 мин
Охват и читатели63K

image Single responsibility principle, он же принцип единой ответственности,
он же принцип единой изменчивости — крайне скользкий для понимания парень и столь нервозный вопрос на собеседовании программиста.


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


В лесу нас разделили на группы по 8-9 человек в каждой и устроили соревнование — какая группа быстрее выпьет бутылку водки при условии, что первый человек из группы наливает водку в стакан, второй выпивает, а третий закусывает. Выполнивший свою операцию юнит встает в конец очереди группы.


Случай, когда размер очереди был кратен трем, и являлся хорошей реализацией SRP.

Но почему соображать нужно именно на троих?

Что же такое «Модель предметной области»?

Время на прочтение5 мин
Охват и читатели41K
Привет, Хабр.

Сегодня зашел в канал #school в русскоязычном GoCommunity в Slack и обнаружил там один интересный диалог. Данный диалог навел меня на некоторые мысли относительно того, как коллеги интерпретируют понятие “модель предметной области (домена)”.

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

Мозговой штурм: как смотреть на задачи под другим углом

Время на прочтение9 мин
Охват и читатели10K

Мозговой штурм с помощью транспонирования


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

A B C D E
1 A1 B1 C1 D1 E1
2 A2 B2 C2 D2 E2
3 A3 B3 C3 D3 E3
4 A4 B4 C4 D4 E4
5 A5 B5 C5 D5 E5

Ячейки, с которыми я работаю, выстроены в столбцы и строки. Давайте возьмём пример из простой игры:

Attack Defend Special
Fighter sword armor slam
Mage fireball reflect freeze
Thief dagger dodge disarm

Строки — это классы персонажей: воин, маг, вор.

Столбцы — это типы действий: нападение, защита, особое действие.

Матрица содержит весь код для обработки каждого из типов действий для каждого типа персонажа.

Как выглядит код? Обычно подобные структуры упорядочивают в такие модули:

  1. Fighter будет содержать код для обработки ударов мечом, снижения урона с помощью брони и особого мощного удара.
  2. Mage будет содержать код обработки фаерболов, отражения урона и особую атаку заморозкой.
  3. Thief будет содержать код для обработки атак кинжалом, избегания урона уклонением и особую обезоруживающую атаку.

Иногда бывает полезно транспонировать матрицу. Мы можем упорядочить её по другой оси
Читать дальше →

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

Поднимаем читаемость кода в iOS разработке

Время на прочтение3 мин
Охват и читатели14K
Представьте себе книгу, в которой нет деления на главы, а все идет без логической и смысловой разбивки, книгу, где нет абзацев, нет точек и запятых, книгу, где в первой строке рассказывается про одно, во второй про другое, в третьей опять про первое.

Представили?

Смогли бы вы понять, о чем книга?

Насколько быстро вы смогли бы найти интересующий вас отрывок?

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

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

Для удобства я буду использовать слово класс (class), но подразумевать любой вид типа (class, struct, enum).

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

Про ООП

Время на прочтение2 мин
Охват и читатели39K


Чем больше читаю про ООП, тем больше возникает ощущение, что ООП понимают не только лишь все. Очередная статья этому пример.


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

Читать дальше →

Чем быстрее вы забудете ООП, тем лучше для вас и ваших программ

Время на прочтение7 мин
Охват и читатели224K

Объектно-ориентированное программирование — чрезвычайно плохая идея, которая могла возникнуть только в Калифорнии.

— Эдсгер Вибе Дейкстра

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

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

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

Business Intelligence по-русски — на квинтетах

Время на прочтение26 мин
Охват и читатели3.8K

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


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




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

Читать дальше →

Размышления о красоте и коде

Время на прочтение27 мин
Охват и читатели7.7K
Думаю, у каждого разработчика рано или поздно возникают в голове мысли о том, что код нужно писать определенным образом. Почему фреймворк этого автора так прост в использовании, и погружение в него проходит так быстро? Почему данный кусок кода кажется мне ужасным? В этот момент происходит важный виток в развитии разработчика как профессионала. Он не только начинает задумываться о том, как ему реализовать конкретную задачу, но и том, как оформить свое решение. В голове начинают зарождаться мысли об определенном структурировании кода и красивом его оформлении. Кто-то начинает создавать для себя некий эмпирический набор правил по оформлению кода, кто-то приходит к помощи литературы или совету более опытных товарищей. В любом из этих сценариев код начинает рассматриваться не просто как безусловное решение проблемы. Появляются мысли о том, что некоторая часть кода сделана некрасиво, а вот здесь получилось круто и элегантно. Но кто определяет эти критерии красоты относительно кода и что в них закладывается? Однозначно ли все в вопросах кодового этикета и красоты?

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

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

Краткий и бодрый обзор архитектуры компиляторов

Время на прочтение19 мин
Охват и читатели41K

Большинство компиляторов имеют следующую архитектуру:



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

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

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

«Фабричный метод» и «Абстрактная фабрика» во вселенной «Swift» и «iOS»

Время на прочтение9 мин
Охват и читатели19K
Слово «фабрика» – безусловно одно из самых часто употребляемых программистами при обсуждении своих (или чужих) программ. Но смысл в него вкладываемый бывает очень разным: это может быть и класс, порождающий объекты (полиморфно или нет); и метод, создающий экземпляры какого-либо типа (статический или нет); бывает, и даже просто любой порождающий метод (включая, конструкторы).

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

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