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



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

Хочу сразу оговориться: эта статья не дает готового к использованию рецепта. Это скорее моя история путешествия в мир Typescript и NodeJS, а также результаты моих экспериментов. Тем не менее, в конце статьи будет ссылка на GitLab репозиторий, который вы можете посмотреть, и может быть взять что то понравившееся себе на вооружение. Может быть даже по моему опыту создадите свое автоматизированное решение.

Предыстория

За последние пару лет я поучаствовал в немалом количестве собеседований. На каждом из них я спрашивал соискателей о принципе единственной ответственности(далее SRP). И большинство людей о принципе ничего не знают. И даже из тех, кто мог зачитать определение, почти никто не мог сказать как они используют этот принцип в своей работе. Не могли сказать, как SRP влияет на код, который они пишут или на ревью кода коллег. Некоторые из них также имели заблуждение, что SRP, как и весь SOLID, имеет отношение только к объектно ориентированному программированию. Также, зачастую люди не могли определить явные случаи нарушения этого принципа, просто потому что код был написан в стиле, рекомендованном известным фреймворком.
Redux — яркий пример фреймворка, гайдлайн которого нарушает SRP.

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

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

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

let a = {
  'myKey': 'myValue'
}
let key = 'constructor'; // comes from outside source
let b = a[key] || 'defaultValue';
expect(b).to.be.equal('defaultValue'); // fails

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

Долгое время я задумывался, что же не в порядке с некоторыми частями кода. Раз за разом, в каждом из проектов находится некий «особо уязвимый» компонент, который все время «валится». Заказчик имеет свойство периодически менять требования, и каноны agile завещают нам все хотелки воплощать, запуская change request-ы в наш scrum-механизм. И как только изменения касаются оного компонента, через пару дней QA находят в нём несколько новых дефектов, переоткрывают старые, а то и сообщают о полной его неработоспособности в одной из точек применения. Так почему же один из компонентов все время на устах, почему так часто произносится фраза а-ля «опять #компонент# сломался»? Почему этот компонент приводится как антипример, в контексте «лишь бы не получился ещё один такой же»? Из-за чего этот компонент так неустойчив к изменениям?

Тестирование с помощью SpecFlow прочно вошло в мою жизнь, в список необходимых технологий для «хорошего проекта». Более того, несмотря на ориентированность SpecFlow на behaviour тесты, я пришел к мысли, что и integration и даже unit тесты могут получить преимущества этого подхода. Конечно, в написании таких тестов уже не будут участвовать люди из BA и QA, а только сами разработчики. Разумеется, что для небольших тестов это привносит немалый оверхэд. Но насколько же приятнее читать человеческое описание теста, нежели голый код.

В первой своей попытке закрыть дыру в производительности Entity Framework'а я рассматривал только материализацию. Но дальше в процессе работы, как того и следовало ожидать, я наткнулся и на другое, более весомое ограничение. Операции вставки, модификации и удаления записей происходят тоже медленно. На 100 вставок EF посылает в базу 100 запросов на вставку, никак не пытаясь их сгруппировать.

Кроме этого, в одном из проектов была обнаружена одна неприятная ошибка: EF версии 5.0.0, при работе с Oracle, в Clob/Xml поля не позволяет вставлять строки более 2000 символов.

В процессе работы над проектом веб-портала, я исследовал возможности улучшить производительность, и наткнулся на небольшую статью про микро-ORM Dapper, который был написан авторами проекта StackOverflow.com. Изначально их проект был написан на Linq2Sql, а теперь все критичные к производительности места переписаны с использованием означенного решения.
Недостаток этого, а также других подобных решений, которые я успел посмотреть, в том, что они уж очень незначительно помогают облегчить процесс разработки, предоставляя по большому счету лишь материализацию, скрывая работу с непосредственно ADO.Net. SQL запросы же нужно писать руками.

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

Прошел год с тех пор, как наша команда разрабатывает web portal используя паттерн MVVM и фреймворк Knockout в частности. Понемногу копился опыт, появлялись различные решения, хорошие и плохие практики, и вот, так сказать, назрело. Для linq-синтаксиса в javascript уже существует библиотека linq.js, и долгое время мы думали, затянуть ли ее к нам в проект. И даже примеры использования вкупе с knockout в интернетах есть.
Идея же, которая меня постигла, была в том, чтобы создание computed инкапсулировать внутрь Linq-методов.
Для сравнения, код из fiddle:

    this.filteredItems = ko.computed(function() {
        var term = this.searchTerm();
        
        return this.items.where(function(item) { 
            return item.name.indexOf(term) > -1; 
        });
    }, this);

и код, который хотелось бы писать вместо этого:

    this.filteredItems = this.items
        .Where(function(item) { return item.name.indexOf(this.searchTerm()) > -1; });

Крис Тейлор, известный миру игрохитами Total Annihilation и Supreme Commander, явил миру свою новую разработку, пока что носящую рабочее имя Project Mercury. Игровая технология, которая легла в основу — strategic zoom. Впервые подобная технология была, если не ошибаюсь, применена в игре M.A.X. 2, вышедшей в 1998м году. Крис же выжал из нее все возможное и, благодаря ему, теперь «классические» RTS игры вызывают ощущение клаустрофобии, запертости в «маленьком экране».
И теперь Крис предлагает использовать эту технологию на «рабочем столе», называя его Infinite Desktop. О проекте лучше всего расскажет его автор:

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