Наверно, самые большие проблемы в первые месяцы работы разработчики испытывают с гитом.

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

+ Git снизу вверх: https://habr.com/post/344962/
+ Git: распространненные ошибки и способы их исправления: https://habr.com/post/423015/

#git

Круто быть разработчиком. Не фронтендером, бекендером или верстальщиком.

Не важно в какой области разработки лежит проблема бизнеса — ее нужно решить.

И многие проблемы бизнеса связаны с доставкой приложения до клиента, масштабированием. Последние годы они решаются с помощью докера.

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

“Docker для начинающего разработчика” https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d

#docker

Просто посмотрите этот доклад.

https://youtu.be/f4uXBpP_xxY

На ту же тему.

https://www.youtube.com/watch?v=xPFRUM_oDKA

Начал читать "Предметро-ориентированное проектирование" Эванса.

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

#ddd

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

#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)
}

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

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

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