WIP

Author: tabuna

content/006-naming.md

@@ -136,7 +136,7 @@ $shouldRetry
 ```
 
 
-## Единицы измерения
+### Единицы измерения
 
 Теперь давайте рассмотрим пример именования с единицами измерений
 

content/015-upgrade.md

@@ -1,7 +1,7 @@
 # Не отказывайтесь от будущего
 
 Часто можно услышать от разработчиков фразу **«пока работает — не трогай»**.
-Это звучит как здравый смысл. Но это в корне не верно. 
+Это звучит как здравый смысл. Но это в корне не верно.
 Очень плохая практика котороя являеться на самом деле самообманом.
 Как бы аккуратно ни был написан код — он не живёт в вакууме.
 Фреймворки развиваются, стандарты обновляются, экосистема не стоит на месте.
@@ -17,19 +17,30 @@
 
 ### Временные решения всегда становятся постоянными
 
-Разработчики вынуждены тратить время на создание временных решений и костылей для работы с устаревшими компонентами, вместо использования стандартных средств и функциональности, доступных в новых версиях.
+Разработчики вынуждены тратить время на создание временных решений и костылей для работы с устаревшими компонентами,
+вместо использования стандартных средств и функциональности, доступных в новых версиях.
 
 Пример:
-> Разработчики, использующие Laravel 5.0, разрабатывали собственную проверку, чтобы клиент мог просматривать только свои заказы в интернет-магазине. Однако менее чем через полгода в версии 5.1 были представлены Policies, ставшие стандартом. Вместо обновления как можно скорее, увеличение кодовой базы лишь увеличивало время на последующее устранение технического долга.
+> Разработчики, использующие Laravel 5.0, разрабатывали собственную проверку, чтобы клиент мог просматривать только свои
+> заказы в интернет-магазине. Однако менее чем через полгода в версии 5.1 были представлены Policies, ставшие стандартом.
+> Вместо обновления как можно скорее, увеличение кодовой базы лишь увеличивало время на последующее устранение
+> технического долга.
 
 ### Усложнение процесса обновления
-Большие разрывы в обновлениях создают снежный ком эффект, который требует значительных усилий и ресурсов для обновления проекта. Это может привести к тому, что если вы захотите обновиться, придется потратить на это несколько месяцев без внедрения какого-либо нового функционала.
 
-Пример:
-> Разработчики “Яндекс.Еда” пропустили три мажорных релиза, и полное обновление заняло целый год. За время накопления технического долга поддержка фреймворка, пакетов и самого PHP изменилась.
+Большие разрывы в обновлениях создают снежный ком эффект, который требует значительных усилий и ресурсов для обновления
+проекта. Это может привести к тому, что если вы захотите обновиться, придется потратить на это несколько месяцев без
+внедрения какого-либо нового функционала.
 
+Пример:
+> Разработчики “Яндекс.Еда” пропустили три мажорных релиза, и полное обновление заняло целый год. За время накопления
+> технического долга поддержка фреймворка, пакетов и самого PHP изменилась.
 
 ### Актуальность — это и про найм тоже
 
-Использование поддерживаемых версий также облегчает процесс найма новых разработчиков. Большинство опытных разработчиков предпочитают работать с современными и актуальными технологиями. Кроме того, знание того, что проект использует поддерживаемые версии, может быть важным моментом для кандидатов при принятии решения о присоединении к команде. Это также позволяет обеспечить более плавный процесс адаптации новых членов команды, так как они уже знакомы с особенностями работы с актуальными версиями.
+Использование поддерживаемых версий также облегчает процесс найма новых разработчиков. Большинство опытных разработчиков
+предпочитают работать с современными и актуальными технологиями. Кроме того, знание того, что проект использует
+поддерживаемые версии, может быть важным моментом для кандидатов при принятии решения о присоединении к команде. Это
+также позволяет обеспечить более плавный процесс адаптации новых членов команды, так как они уже знакомы с особенностями
+работы с актуальными версиями.
 

content/017-copilot.md

@@ -0,0 +1,70 @@
+# Второй пилот — не капитан
+
+В начале книги уже было отмечено: код читают гораздо чаще, чем пишут.
+Сегодня у нас появился второй пилот — только теперь он не сидит рядом на соседнем кресле, а встроен прямо в редактор.
+ChatGPT, Copilot и другие LLM-инструменты. Быстрые, дружелюбные, полезные.
+Но не обманывайтесь: это всё ещё второй пилот, не капитан
+
+Обычно код не меняют просто так.
+Чаще всего причина — баг или новая фича и
+задача для инструмента формулируется примерно так:
+
+> «Выступи в роли X. Иногда этот код выбрасывает исключение XXX. Исправь, пожалуйста».
+
+Но именно в таких формулировках и кроется проблема.
+
+Если передать ему метод на 800 строк, полных противоречий, логических дыр и нелепых зависимостей — не надейся,
+что он сделает из этого конфетку.
+Он будет **продолжать**. Механически, без разбора.
+Потому что его задача — **продолжить твой стиль**, а не **исправить твой хаос**.
+Старое правило `GIGO — *Garbage In, Garbage Out*.` никуда не делось.
+
+
+Рассмотрим простой пример: функция, которая записывает email в базу и отправляет приветственное письмо.
+Попросим второго пилота добавить логирование:
+
+```diff
+// >_ Добавь логирование
+
+function store()
+{
+    $email = $_POST['email'];
+
+    $conn = new mysqli('localhost', 'user', 'pass', 'db');
+    $conn->query("INSERT INTO users (email) VALUES ('$email')");
+
+    mail($email, 'Hi', 'Welcome!');
+
++    file_put_contents('log.txt', "User $email\n", FILE_APPEND);
+
+    echo 'Done';
+}
+```
+
+Он чертовски хорошо выполнил свою задачу, но проблема не в его работе, а в том, что переданный код
+выглядит очень плохо, потому что в нем:
+
+- Нет возврата осмысленного результата.
+- SQL-инъекция (строка вставляется напрямую).
+- Нет обработки ошибок.
+
+Если ты передал мусор — метод, который и швец, и жнец, и на дуде игрец — то не удивляйся, что он туда ещё
+и трубача припишет. Он **не откажет**, он скажет: «Да, командир!» — и продолжит работу.
+
+
+На сайтах вроде Stack Overflow вопросы задают и решают вручную, люди. Нередко там встречаются ответы, помеченные как "
+решение", но при этом заминусованные — в комментариях поясняют: да, работает, но приведёт к плачевным последствиям в
+долгосрочной перспективе. "Второй пилот" — помощник kkдругого типа. Он не будет указывать на архитектурные проблемы или спорные решения, пока вы
+сами его об этом не попросите. Его задача — помогать вам как можно быстрее двигаться к результату, решать
+бизнес-проблемы здесь и сейчас. Но и большинство разработчиков настроены точно так же: задача должна быть закрыта, сроки — вчера, и мало кто будет
+тратить время, чтобы просить помощника подумать над более выразительными именами переменных, архитектурой или стилем.
+
+Поэтому пилот продолжает ехать по плохой дороге.
+А это самое страшное — мы просто раздуваем MESS.
+И не просто так, а ещё и автоматизируем его рост.
+
+Вот почему важно начать с хорошей базы: чистого кода, понятной архитектуры, простых методов и имён.
+
+Второй пилот не заменит твоё мышление — он просто помогает писать.
+
+А хороший код начинается с тебя, а не с него!

draft/llm.md

@@ -1,18 +1,30 @@
 # Второй пилот — не капитан
 
-Сегодня в нашей разработке появился второй пилот — только теперь он не сидит рядом на соседнем стуле, а прямо в редакторе кода.
-Это ChatGPT, Copilot, LLM — как ни назови. Он хорош, быстр, дружелюбен. Но он всё ещё второй пилот.
+В начале книги мы уже говорили: код читают чаще, чем пишут.
+Сегодня у нас появился второй пилот — только теперь он не сидит рядом на соседнем кресле, а встроен прямо в редактор.
+ChatGPT, Copilot и другие LLM-инструменты. Быстрые, дружелюбные, полезные.
+Но не обманывайтесь: это всё ещё второй пилот, не капитан
 
-## Мусор на входе — мусор на выходе
+Обычно код не меняют просто так.
+Чаще всего причина — баг или новая фича.
+И мы формулируем задачу примерно так:
 
-Если ты суёшь ему в метод полотно на 800 строк, полное противоречий, логических дыр и нелепых зависимостей — не надейся,
-что он сделает из этого чистую архитектуру. Он будет **продолжать**. Механически, без разбора. Потому что его задача — *
-*продолжить твой стиль**, а не **исправить твой хаос**.
+> «Иногда этот код выбрасывает исключение XXX. Исправь, пожалуйста».
 
-> GIGO — *Garbage In, Garbage Out*.
+~~Обычно мы не меняем код без причины, самыми популярными являются исправление ошибки и добавление новых функций.
+По этому мы ставим задачу второму пилоту в духе: "Этот код иногда выдает Exception XXXX" пожалуйста исправь".~~
 
+Но именно в таких формулировках и кроется проблема.
 
-Небольшой пример:
+Если передать ему метод на 800 строк, полных противоречий, логических дыр и нелепых зависимостей — не надейся,
+что он сделает из этого конфетку. 
+Он будет **продолжать**. Механически, без разбора.
+Потому что его задача — **продолжить твой стиль**, а не **исправить твой хаос**.
+Старое правило `GIGO — *Garbage In, Garbage Out*.` никуда не делось.
+
+
+Рассмотрим простой пример: функция, которая записывает email в базу и отправляет приветственное письмо.
+Попросим второго пилота добавить логирование:
 
 ```diff
 // >_ Добавь логирование
@@ -32,15 +44,27 @@ function store()
 }
 ```
 
-В этом коде многое выглядит очень плохо, например:
+Он чертовски хорошо выполнил свою задачу, но проблема не в его работе, а в том, что переданный код
+выглядит очень плохо, потому что в нем:
 
 - Нет возврата осмысленного результата.
 - SQL-инъекция (строка вставляется напрямую).
 - Нет обработки ошибок.
 
-Если ты передал в LLM нарушенный SRP — метод, который и швец, и жнец, и на дуде игрец — то не удивляйся, что он туда ещё
+Если ты передал мусор — метод, который и швец, и жнец, и на дуде игрец — то не удивляйся, что он туда ещё
 и трубача припишет. Он **не откажет**, он скажет: «Да, командир!» — и продолжит кромсать.
 
+
+На сайтах помощи, типа "Stack Overflow" спросить/ответить на вопрос, в ручном режиме от человека.
+И там достаточно часто были помеченные как "Решение" ответы заминусованные, где в пояснениях обьясняли что решение может быть и рабочее, но приведет к плачевным последствиям.
+Важно отличие второго пилота, в том, что он не скажет какой ваш код пока вы его об этом не попросите, а вы сосредоточены на решении бизнес-проблем.
+А большинство разработчиков будут сосредоточены на бизнес-задаче, а не на качестве кода.
+
+Большинство разработчиков именно так и поступают.
+Поэтому пилот продолжает путь туда, куда ведёт плохая трасса.
+
+
+
 ---
 
 Когда мы запускаем LLM не ради рефакторинга, а ради **решения задачи** — будь то баг, фича или интеграция — мы часто
@@ -60,5 +84,12 @@ function store()
 
 ### Начинай правильно
 
+Поэтому пилот продолжает путь туда, куда ведёт плохая трасса.
+И вот тут начинается самое страшное: мы **раздуваем MESS**. И не просто раздуваем, а автоматизируем его рост.
+
 Вот почему так важно начать с сильной позиции. 
 С чистого кода, с понятной архитектуры, с ясных методов и простых имён.
+
+
+Второй пилот не думает за тебя. Он просто пишет.
+Хороший код начинается с тебя, не с него!