​​Мудрость из книги

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

Конспект книги Роберта Мартина "Чистая архитектура".

#чистая_архитектура #проектирование

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

Часто люди вокруг рассказывают, что копирование код — чистое зло. Мол, DRY во все поля. Копировать код, действительно, почти всегда плохо.

Но иногда все же стоит. Поля в ответе API и в базе данных сейчас одинаковые. Так как мы не хотим повторять кода, для этих двух мест приложения следует создать только один класс и использовать его дважды. Логично? Вроде да. Но только меняются эти две части системы в разное время и разными людми.

DRY — это про копирование логики. Код иногда нужно копировать.

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

​​Мудрость из книги

Бизнес правила в приложении бывают двух видов.

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

2. Варианты использования. Они возникают благодаря приложению. Это некоторые правила, которые должно соблюсти ПО. Например, отображение вип-клиентов выше в списке.

Первые важнее и стабильнее вторых. Потому варианты использования должны зависеть от критических бизнес-правил.

Конспект книги Роберта Мартина "Чистая архитектура".

#чистая_архитектура #проектирование

​​Мудрость из книги

Фреймворк — детали. Приложение должно зависеть от фреймворка минимально. Нужно не писать "на фреймворке", а писать "с использованием фреймворка".

Конспект книги Роберта Мартина "Чистая архитектура".

#чистая_архитектура #проектирование

​​Мудрость из книги

Признаки чистой архитектуры:
+ Независимость от фреймворков
+ Простота тестирования
+ Независимость от пользовательского интерфейса
+ Независимость от базы данных
+ Независимость от любых внешних агентов

Конспект книги Роберта Мартина "Чистая архитектура".

#чистая_архитектура #проектирование

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

Дочитал "Чистую архитектуру" дядюшки Боба.

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

#чистая_архитектура

​​Развитие

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

Начал читать книгу — "7 языков за 7 недель". В ней рассмотрены очень разные языки программирования. В каждом есть какая-то идея.

#языки

​​Языки

Ruby странный. Очень дружелюбный и удобный. Но полный магии.

Я не люблю магию. Она затрудняет чтение кода. А читаем мы его чаще, чем пишем.

Ruby позволяет слишком многое. Если объявить класс с именем, которое уже занято, ошибки не будет. Просто второе объявление модифицирует первое. Это супер-магическое поведение.

Зато, при должной сноровке получается действительно семантический код.

#языки

​​Ссылка

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

Сделать ≠ делать.

Интересно, что программист сделал, а не что он делал. Если он весь день смотрел сериалы и ел печенье, но работа сделана, то хорошо. А если работа не сделана, то уже плевать, что он делал.

Тематическая статья: Что значит «сделать»

#softskills

​​Языки

Io. Готов поспорить, большинство даже не слышало о нем.

Этот язык основан на прототипах, как и JavaScript. Он имеет динамичкую строгую типизацию, аскетичный синтаксис и полную свободу.

Пример кода (поиск n-ого числа Фибоначчи):
fib := method(n, if(n == 2 or n == 1, 1, fibR(n - 1) + fibR(n - 2)))

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

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

#языки

​​Подумал, что не рассказал кто я такой и чем занимаюсь.

Я Игорь, Tech Lead в Breadhead. Большую часть времени программирую на TypeScript. Иногда на JavaScript или PHP.

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

​​Ссылка

Наверное, я не встречал еще ни одного проекта, где программисты бы не пилили никому не понятные фичи просто "вдруг кому-то понадобиться". Это опасный подход.

С заделом на будущее надо делать не фичи, а архитектуру. Тогда при необходимости новые возможность в приложение добавить будет совсем легко.

Тематический перевод: Не решайте воображаемые проблемы.

#softskills

​​Полезная книга

Стив Макконнелл, Совершенный код.

Тяжёлое чтиво. Прямо очень. Самое печальное, что простые и очевидные концепты перемешаны с довольно сложными.

Но прочесть стоит. Хорошо вправляет мозг.

#совершенный_код

​​Ссылка

Условные конструкции сложные. Особенно когда они вложенные или множественные.

5 советов по написанию лучших выражений с условными операторами в JavaScript

Правила валидны не только для JS, а вообще для любого языка.

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

Завел себе твиттер, буду писать туда разное, что не попало сюда.

Подписывайтесь, что-ли — @kamyshev_code.

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

Настроил @IFTTT, достойные статьи будут попадать сюда автоматически.

Статья

Описать задачу в виде истории

https://ift.tt/2DWkCpr

via IFTTT

Статья

Принципы SOLID, о которых должен знать каждый разработчик

https://ift.tt/2P21POk

via IFTTT

Статья

Применение принципов SOLID при разработке React-приложений

https://ift.tt/2EPz7N1

via IFTTT