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

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

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

Непросто отказываться от иллюзий, но пришла пора подвести черту. Может кому-то сгодится на распутье выбора. Ну и внукам потом буду показывать. Этой истории уже 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.

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

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

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

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

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

public class Customer
{
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
}

• Вы изменяете состояние сущности до валидации, то есть ваша сущность может находиться в невалидном состоянии
• Неясен контекст операции (что именно пытается сделать пользователь)

• Погода с сайта гисметео
• Курс валют с сайта центробанка
• RSS лента с новостных порталов

Описание проблемы

var text = (
`foo
bar
baz`)

var html = `<article>
  <header>
    <h1>${title}</h1>
  </header>
  <section>
    <div>${teaser}</div>
    <div>${body}</div>
  </section>
  <footer>
    <ul>
      ${tags.map(tag => `<li>${tag}</li>`).join('\n      ')}
    </ul>
  </footer>
</article>`

Полезные ссылки:

1. Контрактное программирование, Программирование по контракту
2. Comparison Preconditions in Java
3. QAPlug vs FindBugs
4. QAPlug tutorials
5. Codacy Home