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

Софт постоянно усложняется. Стабильность и простота расширения приложения напрямую зависят от качества кода.

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

• Функции слишком длинные, и на них слишком много задач
• Часто у функций есть побочные эффекты, которые сложно определить, а иногда даже сложно отлаживать
• Непонятные имена у функций и переменных
• Хрупкий код: небольшая модификация неожиданно ломает другие компоненты приложения
• Плохое покрытие кода тестами или вообще его отсутствие

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

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

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

Такие ситуации случаются часто, и это печально. Но что делать?

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

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

1.Плохой код делает слишком много, чистый код сфокусирован

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

Но я бы не ограничивал определение классами. В свой последней статье Ральф Вестфал (Ralf Westphal) представил более широкое определение принципа единственной обязанности:

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

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

В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:

1. Что такое фреймворк, и зачем их пишут.
2. Почему для некоторых языков их десятки, а для некоторых — единицы.
3. В чём плюсы и минусы применения.
4. Наиболее распространённые мифы.
5. Использовать или нет — примеры из жизни.
6. Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

Ранее, я упоминала, что помощники (Helper) Ember'а были введены в версии 1.13. На мой взгляд, помощники одни из самых полезных, но не часто обсуждаемых, функций Ember.

Введение

Мера обсуждается в России уже более десяти лет: считается, что из-за сильных различий в двух видах учета в стране слишком много бухгалтеров (в России насчитывается три миллиона бухгалтеров, что в 2,5 раза больше, чем в США).

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

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

Непросто отказываться от иллюзий, но пришла пора подвести черту. Может кому-то сгодится на распутье выбора. Ну и внукам потом буду показывать. Этой истории уже 20 лет. Краткое содержание: фреймворки — больше никогда; выход есть.

var fs = require("fs");
fs.readdir(__dirname, function(error, files) {
    if (error) {
        console.error(error);
    } else {
        for (var i = 0, j = files.length; i < j; i++) {
            console.log(files[i]);
        }
    }
});

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

Если вы просто хотите ознакомиться с реализацией класса, то эти самые вспомогательные методы очень сильно мозолят глаза, приходится прыгать по коду туда-сюда. Да, конечно, можно разнести их по отдельным модулям, но я считаю, что зачастую это слишком избыточно (я, например, не хочу создавать модуль, который, по сути, определяет только один метод, декомпозированный на n частей). Особенно неприятно, когда эти вспомогательные функции состоят из одной строки (например, метод, который выдергивает определенный элемент из распарсенного JSON).

1. Количество строк кода.
2. Сколько было исправлено багов.
3. Сколько было добавлено новых фич, которые хотят ваши пользователи.
4. Насколько производительнее стал продукт.
5. Насколько более удобным стал продукт.
6. Насколько более качественным стал результат продукта, если для него вообще есть метрика качества (точность классификации, ранжирования и пр.)
7. Другие различные метрики.

Котаны!

Вы знаете про Meteor? Ну да — странный вопрос.

Вы знаете про CSS-Modules? Прощай БЭМ.

Вы знаете про SugarSS? Прощай SASS.

Перец из Техаса сегодня принял мой pull-request. И всем этим счастьем теперь можно пользоваться. CoffeeScript, Jade, SugarSS — полный комплект для кошерного кода.

Тут мелькнула статья, как чувак, выбирая инструментарий, ничего не мог написать. Это про меня! Под Новый год нашёл ViewModel.org. А внутри прекрасный Two-Way Binding. Но не проходит ощущение ящика в гараже, заваленного гаечными ключами вперемешку с "лишними" деталями. Наглядный пример, как в собственной же демке пришлось ввернуть костыль, гы-гы. И я застрял на четыре месяца — хобби по вечерам после работы. Перебрал все пакеты, хоть как-то полезные для Blaze. Приставал к авторам с мольбами… Собрал в итоге новый велосипед с громким именем Template2.

Очень сложно сделать просто, как известно. Зацените: