some fixes

manuscript/1-bad-habits.md

@@ -55,11 +55,11 @@ public function store(Request $request)
 }
 ```
 
-Какая-то логика должна быть скопирована в **update** метод, но, например, отправка email должна быть только после создания. Код всё ещё выглядит неплохо, но количество дублированного кода растет. Еще 3-4 таких добавления и у нас будут красоваться два уже весьма больших и почти одинаковых метода **store** и **update**. Тут часто совершается ошибка - в попытке устранить дублирование кода создается метод-монстр с названием, допустим, **updateOrCreateSomething**. Этому методу нужен параметр, чтобы понимать, что он сейчас делает: "update" или "create".  
+Какая-то логика должна быть скопирована в **update** метод, но, например, отправка email должна быть только после создания. Код всё ещё выглядит неплохо, но количество дублированного кода растет. Еще 3-4 таких добавления и у нас будут красоваться два уже весьма больших и почти одинаковых метода **store** и **update**. Тут часто совершается ошибка - в попытке устранить дублирование кода создается метод-монстр с названием, допустим, **updateOrCreateUser**. Этому методу нужен параметр, чтобы понимать, что он сейчас делает: "update" или "create".  
 Сразу после выделения код обычно выглядит весьма прилично, но с добавлением новых требований, особенно разных для создания и изменения сущности, разработчик начинает осознавать, что попал в капкан. В одном из проектов я видел 700-строковый метод с большим количеством `if($update)`:
 
 ```php
-protected function updateOrCreateSomething(..., boolean $update)
+protected function updateOrCreateUser(..., boolean $update)
 {
     if ($update)...
     if ($update)...
@@ -69,7 +69,7 @@ protected function updateOrCreateSomething(..., boolean $update)
 
 Стоит ли говорить, что в нем частенько заводились баги, которые было трудно отлавливать в такой каше. Ошибка проста - разработчик вынес **разную** логику, которая показалась ему похожей, в один метод. Выносить в отдельный метод или класс надо всегда только одинаковую логику. Логика создания или редактирования сущности может показаться одинаковой поначалу, но почти наверняка окажется разной по мере развития проекта.
 
-Здесь я хочу отвлечься и поговорить про naming - процесс наименования элементов языка (переменных, методов и классов). Если стараться именовать методы по смыслу, то многое можно понять уже по имени метода. **updateOrCreateSomething** - тут проблема видна без какого-либо анализа. **Or**(**Или**) это явный знак как минимум двух разных действий - двух разных логик. С развитием проекта все такие логики имеют свойство всё сильнее и сильнее отличаться друг от друга, и находиться в одном месте им совершенно противопоказано.
+Здесь я хочу отвлечься и поговорить про naming - процесс наименования элементов языка (переменных, методов и классов). Если стараться именовать методы по смыслу, то многое можно понять уже по имени метода. **updateOrCreateUser** - тут проблема видна без какого-либо анализа. **Or**(**Или**) это явный знак как минимум двух разных действий - двух разных логик. С развитием проекта все такие логики имеют свойство всё сильнее и сильнее отличаться друг от друга, и находиться в одном месте им совершенно противопоказано.
 
 Надо всегда стараться называть методы, классы и переменные по смыслу. Иногда даже просто попытка назвать их хорошо может навести на хорошие мысли, которые помогут улучшить дизайн вашего кода. 
 

manuscript/2-di.md

@@ -72,9 +72,9 @@ public function store(Request $request)
 
 Здесь я бы хотел остановиться и поговорить о двух важных базовых характеристиках программного кода — связность (cohesion) и связанность (coupling).
 Связность — это степень того, как методы одного класса (или части другой программной единицы: функции, модуля) сконцентрированы на главной цели этого класса.
-Близко к SRP.
+Звучит очень похоже на SRP.
 Связанность между двумя классами (функциями, модулями) — это степень того, как много они знают друг о друге.
-Сильная связанность означает, что какие-то знания принадлежат нескольким частям кода и каждое изменения может вызвать каскад изменений в других частях приложения.
+Сильная связанность означает, что какие-то знания принадлежат нескольким частям кода и каждое изменения может вызвать каскад изменений в других частях приложения. Под знаниями я имею в виду какую-нибудь логику, например знание о том, как сохранить картинку в хранилище, или как обновить поля сущности Пользователь. То же самое, что и ответственность, но под другим углом.
 
 
 ![](images/coupling_cohesion.png)