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

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

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

После создания проекта рано или поздно возникает вопрос: куда записывать номер версии, где хранить токены, пароли, настройки, каким форматом файлов конфигурации воспользоваться: .json, .yaml, .env, .cfg, .ini или просто создатьconfig.pyи записывать туда переменные?

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

В этом посте мы расскажем, как реализовывали плагин для поддержки функционального языка Frege в IntelliJ IDEA. Если вам интересно, как IDE от JetBrains работают внутри, или вы хотите поконтрибьютить в языковые плагины (а может даже написать свой!), эта статья для вас. Мы пройдемся по этапам создания языкового плагина для IDEA, расскажем, с какими трудностями столкнулись, и как подружили этот язык с JVM-миром.

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

Я уже давно выступал с критикой системы команд AMD64, сейчас более известной как x86-64. Причем, задача специально анализировать появившиеся и исчезнувшие команды не стояла. Просто при переносе средств программирования с Win32 на Win64 возникал ряд проблем, вызывавших один и тот же вопрос: «почему же раньше все работало, а теперь нет?». Это касается некоторых выброшенных разработчиками архитектуры AMD64 команд, которые пришлось эмулировать, и, особенно, аппаратной поддержки контроля целочисленного переполнения с помощью инструкции INTO, которая вдруг стала недоступной.

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

Но все-таки проблемы как-то разрешились, и пришло время не только бороться с недостатками системы команд AMD64, но и воспользоваться ее достоинствами. А основных достоинств, по сравнению с IA-32, напомню, два: восьмибайтная адресация, снимающая предел в 4 Гбайт, и увеличенное число регистров общего назначения в два раза.

В случае регистров размером в 2, 4 или 8 байт действительно все логично и естественно. Можно даже сказать, что число регистров увеличилось более чем в два раза, поскольку указатель стека и не используется в вычислениях как остальные. Поэтому в IA-32 у программиста реально было 7 регистров общего назначения, а в AMD64 их стало 15, т.е. RAX, RBX, RCX, RDX, RBP, RSI, RDI и R8-R15.

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

Эта статья является переводом материала «Domain model isolation».

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

Вначале было слово, и было два байта, и ничего больше не было. Но отделил Бог ноль от единицы, и понял, что это хорошо.

Потом, опуская некоторые незначительные события мироздания, была вот эта статья от @novar.

Ну а еще некоторое время спустя вышел разбор задания из оригинальной статьи от @PsyHaSTe.

И обожемой, как этот разбор мне понравился. Серьезно, @PsyHaSTe, я теперь твой подписчик. Пиши еще, статья восхитительная, всем рекомендую.

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

Всем привет, это PsyHaSTe и сегодня я хотел бы рассказать о том, куда меня занесла нелегкая в процессе оптимизации и рефакторинга кода решения тестового задания из статьи товарища novar (кто пропустил — рекомендую ознакомиться). Какие проблемы были у этого решения? Почему все-таки человеку отказали в работе? Что можно с этим сделать? Ответы на эти и многие другие вопросы оказались слишком длинными для комментария и вылились в статью с подробным разбором, примерами и альтернативной реализацией задания.

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

Эта статья является переводом материала «Immutable architecture».

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

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

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

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

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

Ревью кода это довольно обыденный процесс. Хотя и не многие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом сообразить пару причин, зачем же делать просматривать код коллег довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.

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

Эта статья является переводом материала «What is functional programming?».

В этой статье Владимир Хориков попытается ответить на вопрос: что такое функциональное программирование?

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

Математические функции не являются методами в программном смысле. Хотя мы иногда используем слова «метод» и «функция» как синонимы, с точки зрения функционального программирования это разные понятия. Математическую функцию лучше всего рассматривать как канал (pipe), преобразующий любое значение, которое мы передаем, в другое значение

Любите ли вы комиксы так, как люблю их я? Если нет, то вы просто неправильно их смотрите! Переписать сюжет в виде программного кода — и отдых, и развлечение, и возможность потренироваться. 

Всем привет, это снова Макс Кравец из Holyweb, и сегодня мы будем косплеить Ивана Ванко, то есть делать дронов. Много дронов. Для этого нам понадобится целая фабрика. Поехали!

Представьте диалог:

—  Здравствуйте, я водитель КАМАЗа!

—  Добрый день, к сожалению, в нашем автопарке только ЗИЛы, позовите следующего кандидата, пожалуйста!

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

Всем привет, это Макс Кравец из Holyweb, и сегодня мы поговорим о том, почему фронтенд-разработчику важно учить JavaScript, а не фреймворк или библиотеку.

К старту курса о разработке на C# делимся переводом статьи о типичных ошибках программирования на C# от Кристофа Насарре — технического рецензента книг Microsoft Press в целом и, конечно, книги CLR via C# в частности. Кроме того, Кристоф Насарре — один из авторов книги Windows via C++.

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

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

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

Эта статья является переводом материала «Cohesion and Coupling: the difference». 

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

Эта статья является переводом материала OCP vs YAGNI.

В этом посте хочется осветить тему OCP и YAGNI – противоречия между принципом открытости/закрытости и принципом «вам это не понадобится».

Давайте начнем с того, что вспомним, что такое OCP. Принцип открытости/закрытости гласит, что: Объекты программного обеспечения (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации.

Впервые он был представлен Бертраном Мейером в его канонической книге «Конструирование объектно-ориентированного программного обеспечения». С тех пор его популяризировал Боб Мартин, когда он представил принципы SOLID.

Официальное определение довольно расплывчато и на самом деле не помогает нам понять основной смысл. Итак, давайте углубимся в этот принцип.