Для построения надёжных приложений важно разрабатывать их итеративно и в тесном взаимодействии со специалистами предметной области (представителями бизнеса).

#ddd

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

Два важных момента:
+ Взаимодействие технических специалистов и представителей бизнеса.
+ Общий язык.

#ddd

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

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

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

#ddd

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

“Тесты, которые должен писать разработчик” @ArturBasak https://medium.com/@arturbasak/%D1%82%D0%B5%D1%81%D1%82%D1%8B-%D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B5-%D0%B4%D0%BE%D0%BB%D0%B6%D0%B5%D0%BD-%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C-%D1%80%D0%B0%D0%B7%D1%80%D0%B0%D0%B1%D0%BE%D1%82%D1%87%D0%B8%D0%BA-a04cab35f45b

#tests

Нельзя отрывать модель от реализации. Придумали модель, но в коде она не используется? Значит она ничего не стоит.

Те, что думают над моделью должны писать код. Те, кто пишет код, должны думать над моделью.

Нельзя допускать до кода человека, не погруженного в предметную область.

#ddd

PHP бесит, в частности тем, что встроенные функции не кидают исключения, а возвращают false, 0 или какую-то другую дичь при ошибке.

Крутейшая библиотека, которая решает эту проблему — https://github.com/thecodingmachine/safe

#php

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

Ну и это позволяет стать чуть более полезным.

Видео о том, как расти разработчику — https://youtu.be/BULiyNTlq8o

Эванс предлагает строить приложения по многоуровневой архитектуре.

1. Представление (Presentation). Работа с внешним источником команд. Это может быть интерфейс пользователя, API. Тут только принимаем запрос и формируем ответ.
2. Операционный (Application). Тут занимаемся оркестрацией объектами доменной модели. Решаем как и куда их дёрнуть.
3. Предметной области (Domain). Вся логика работы приложения. Бизнес правила.
4. Инфраструктурный (Infrastructure). Обеспечение работы других слоев. Общение с базой данных, отправка уведомлений, загрузка файлов на удаленное хранилище.

При этом компоненты слоя могут зависеть только от компонентов находящихся в том же слое, или ниже. То есть Application не может зависеть от Interface, но может от Infrastructure.

#ddd

При разработке React-приложений почти всегда используют Redux.

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

https://github.com/atomixinteractions/redux-symbiote

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

#js

Важная мелочь для меня в программировании — комфорт от набора текста. Он складывается из темы редактора, шрифта, клавиатуры и много чего ещё, наверно.

Уже несколько лет использую шрифт Fira Code. Во-первых, он крутой. А во-вторых, в нем есть лигатуры.

Лигатуры — это когда несколько логически связанных символов становятся одним. Например, != станет ≠.

На мой взгляд, так код воспринимается много легче.

https://github.com/tonsky/FiraCode

#удобство_разработки

Вернёмся к Эвансу.

Слой предметной области представляет три типа объектов.

1. Сущности — эти объекты уникальные от рождения и до смерти. Например, в контексте банковской сферы, это клиент. Не важно, сменил он имя, пол или адрес. Нам важно сохранить его историю.
2. Объекты-значения — не уникальны, ценны только своим значением. В том же контексте, это могут быть адреса. Адрес однозначно характеризуется городом, улицей, домом. Если что-то из этого изменилось — это уже совсем новый адрес.
3. Сервисы. Кусочки логики не относящиеся к сущностям или объектам-значениям. Например, сервис выполнения транзакций. Он работает сразу с двумя счетами и хранит логику перевода средств с одного на другой.

#ddd

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

Так как агрегаты сложно строить руками, часто используют фабрики для этого.

А для получения корневой сущности по какому-нибудь принципу — репозиторий.

#ddd

По долгу службы, в скором времени буду строить довольно крупное приложение на NodeJS.

На этой неделе написал технический прототип и познал всю боль с Express. Неудобно, нужно много написать самому. Подумал, что нужно что-то другое. И как раз на митапе несколько дней назад добрый человек посоветовал посмотреть на Nest.js.

И оно выглядит прямо хорошо!

Особенно, меня, как большого любителя TypeScript, порадовала их дружба.

Всем, кто строит хоть сколько-нибудь большие приложения на NodeJS рекомендую посмотреть на это решение. Возможно, оно подойдёт и вам.

https://docs.nestjs.com

#js #ts

​​Проектирование

Разберёмся, что такое инверсия зависимости. Представьте ситуацию, ваша функция использует какую-то другую. И она её берет и вызывает. Все вроде хорошо. Но что если нужно теперь заменить вызываемую функцию на другую? Становиться как-то сложно.

Чтобы сложно не было, можно передать эту функцию как аргумент. Тогда заменить ее будет легко.

Было:

function square(x) {
  return power(x, 2)
}

Стало:

function square(x, power) {
  return power(x, 2)
}

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

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

#проектирование

​​Проектирование

Для инверсии зависимостей важна информация о типах данных.

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

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

function square(
  x: number,
  power: (x: number, y: number) => number
) {
  return power (x, 2)
}

Мы обезопасим код от многих ошибок.

Это не обязательное условие для реализации инверсии зависимостей. Но так писать надёжные приложения легче.

#проектирование

​​Исследуя GitHub

В функциональном программировании есть удобная концепция Option. Это абстракция над переменной, которой может и не быть (null, undefined, etc.). Она позволяет работать с такими значениями как с коллекцией (пустой, или из одного элемента).

Было:
const parsedInput = !!nullableVar
? parseInt(nullableVar) + 12
: 1

calculate(parsedInput)

Стало:
const parsedInput = optionInput
.map(v => parseInt(v))
.map(v => v + 12)
.getOrElse(1)

calculate(parsedInput)

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

Надавно нашел бибилиотеку для JavaScript/TypeScript, реализующую эту Option.

https://github.com/bcherny/tsoption

#js #ts #fp

​​Проектирование

Относительно функций все сказанное о инверсии зависимостей не слишком часто используется в реальной практике.

Основная область применения этого принципа — объектно-ориентированное программирование.

Если один из ваших классом занимается отправкой уведомлений и для этого ему нужно куда-то послать HTTP запрос, лучше не создавать HTTP-клиент внутри.

Плохо:
class Notificator {
constructor() {
this.httpClient = new HttpClient()
}

notify() {
// do something with this.httpClient
}
}

Хорошо:
class Notificator {
constructor(httpClient) {
this.httpClient = httpClient
}

notify() {
// do something with this.httpClient
}
}

Почему?
+ Для тестов легко передать фейковый клиент.
+ Заменить реализацию HTTP-клиента можно не трогая Notificator.
+ Можно сделать один клиент, раздать его всем желающим и сэкономить на создании.
+ Циклические зависимости разрешать легко.

#проектирование

​​Онлайн-курс

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

Уверен, что это знание сильно помогает писать приложения без удивления.

Отличный бесплатный курс на Stepik. Рассказывают как работает компьютер, немного про ассемблер, как устроены операционные системы.

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

#общие_знания

​​Проектирование

Итак, мы написали весь код передавая зависимости через конструктор. И получили такой клиентский код:
const notificator = new Notificator(
new SmsAdapter(
new HttpClient(),
new Logger(),
),
)

Как этим пользоваться? Никак.

Вместо создания сервисов руками в клиентском коде следует делегировать эту работу кому-нибудь. Например, DI-контейнеру. Эта штука создает все нужные сервисы (на основании какой-то конфигурации) и позволяет получить уже подготовленный сервис в клиентском коде.

const notificator = Container.get(Notifier)

#проектирование

​​Нужная книга

Две недели назад закончил читать "Программиста-фанатика" и готов порекомендовать ее.

Книга совсем не о фанатизме. Оригинальное название "The Passionate Programmer" куда точнее отражает содержание. Она о том, как быть выдающимся программистом. И какую пользу это приносит.

В ней совсем мало про конструирование программ. Большая часть посвящена построению карьеры.

#программист_фанатик