Прочитал эту книжку. Вообще я до хера книжек прочитал, просто | Trve Shlak

Прочитал эту книжку. Вообще я до хера книжек прочитал, просто эту только что. Сейчас перескажу ключевые очевидные тезисы. Перескажу общё, ни слова про программирование, чтобы ты мог интерпретировать это под свою деятельность.
Вкратце:
Баланс сила, крайности могила.
__________________
Подробнее.
Рефакторинг — хирурго-косметическое улучшение какой-то системы или конструкции, чтобы в ней было проще разобраться, легче внести изменения, быстрее и приятнее работать. В моушене под этим можно подразумевать реструктуризацию проекта.
_________________
Главный признак, что пора бы порефакторить:
Для внесения одной правки тебе нужно править несколько моментов в разных местах проекта. С этим можно жить, но с этим опасно работать дальше, потому что говно будет копиться и размножаться, и однажды рефакторить станет уже поздно. Поздно — это когда построить проект заново было бы быстрее, чем внести одну правку. Такое у меня было один раз, я в натуре отгрохал проект заново. Мне не понравилось.
_________________
Собсна тезисы:
1. Раздроби задачу как можно мельче, решение каждой подзадачки тестируй. Чем меньше подзадача, тем легче поймать и исправить в ней ошибку.
2. Не борщи с дробью. Если вероятность ошибки в подзадаче околонулевая, то её отдельное решение и тестирование — безвозмездная трата времени.
3. Не стремайся делегировать, цепочные делегации очень даже ок, если каждое звено выполняет свою часть работы. Под делегейтом можешь понимать прекомпозы в АЕ, или инстансы в синьке, или любые сущности с таким же смыслом.
4. Не борщи с делегированием, убирай лишних посредников, которые бездельничают (ебут вола — прим. автора). Такие посредники кушают твоё внимание, не компенсируя это пользой.
5. Разделяй ответственность, не допускай чтоб две (или более) сущности копались в делах друг друга больше, чем в своих. Если копаются — вытащи им кишки, распредели нормально и засунь обратно. Это могут быть экспрешены, слишком обильно ссылающиеся на другой слой или икспрессы, сильно подсматривающие в другой объект. Частенько такое братание вынуждает тебя вносить одну правку сразу в два места.
6. Не давай сущности много ответственности. Если у многозадачника сломается что-то в фундаменте, то ты лишишься сразу всего спектра его услуг. Если сущность выполняет до хера задач, раздели её на две\три\сколькопонадобится и следом проверь пункт 5.
7. Не давай сущностям мало ответственности. Каждая сущность хавает твоё внимание (время), и если она при этом мало что делает, то она хронофаг. Таких может быть много, в этом случае их можно пообъединять, следом проверить пункты 5 и 6. Если таких мало, можно передать их функционал ближайшим по семантике сущностям и уничтожить дармоедов.
9. Если твоя конструкция/система одноразовая, то смело забивай на все предыдущие пункты, не трать время на качество, которое здесь неуместно (одноразовость подразумевает качество "на отъебись" во имя дешевизны и быстроты).
8. Рефакторинг даёт пользу только на длинной дистанции. Менеджера (или кто с тебя спрашивает) обычно не интересуют длинные дистанции, ему надо срочно внести правку и не делать мозгу с этими твоими терминами. Поэтому вслух лучше не заикаться, просто попроси больше времени на какую-то задачку, мол это сложно ууу охереть, и часть этого времени потрать на рефакторинг.
10. Если тебе покажется, что какое-то улучшение пойдёт во вред производительности — скорее всего показалось. Но если в итоге окажется и правда во вред, то ничего страшного: наладить производительность в чистой и ясной системе гораздо проще, чем оптимайзить паучий бред с волами и делегациями.
11. Чистой и ясной системы не бывает, всегда есть нерешаемые моменты, которые придётся оставить нерешёнными. Такова суровая реальность.
12. Бегит.