<commit_before>---
layout: post
title: Совершенный код, ч.1 
---
# {{page.title}} (_Макконнелл С. - Code Complete_)

<blockquote>
За время, которое вы потратите на чтение текста ниже, можно развернуть до пяти сайтов на вордпресс или объявить около двадцати фабрик. 
</blockquote>


Сразу скажу — я горячий сторонник всяких [programming mothefucker](http://programming-motherfucker.com/). Модно не называть программирование программированием, но попытаясь разложить это для семилетнего,  окажется, что в этой среде есть очень разные цели. Есть спортивное программирование, когда пацанчики на спорте ебашат задачи, используя знания алгоритмов и математики; они как турникомены с 6 лет делают выход силы по вечерам и утренний подъем с переворотом. Есть хакеры — когда задачи реальные, а правил, в общем-то нет — эти ребята якобы не знают слова невозможно, поэтому так симпатичны для голливуда и 14-летнего меня. А вот дяди, которые потеют за то, чтобы у них регулярно, два раза в месяц, обновлялись цифры в базе данных платежных систем — промышленные программисты. А по вечерам, когда эти дяди едут домой, слушая подкасты, они смотрят в запотевшее окно и мечтают о том, как сделают библиотеку с тысячью звездочками на гитхабе.

И что мне не нравится в таких книгах, это когда я вижу вот такие диаграммы: ![Глава 1, Процессы конструирования](/img/cc/1.png)

Недостаток внутрннего академического воспитания и силы воли у меня, конечно, но — такая скука!

![Глава 1, Кодирование и отладка](/img/cc/2.png)

Однако, уже второй рисунок всё меняет. Кодирование и отладка! В конце концов, через текст Стива Макконнелла чувствуется боль, которую невозможно было заглушить маленькой книжечкой, поэтому Стив написал здоровенный тяжелый кирпич, которым можно было бы приговорить плохого программиста на месте.

## Глава 2

Первая осмысленная глава. “Метафоры, позволяющие лучше понять разработку ПО”. Сначала метафора литературная, она описывает, конечно, в какой-то мере небольшие проекты: сел такой и написал код на хакатоне. Слишком примитивная, говорит автор, код, в отличие от книги не будет законченным. ОТКАЗАТЬ.

Та метафора, в которой софт это взращивание картошки, включая подготовку, поливку, прополку, удобрения и очень многие этапы — сельскохозяйственная. Есть опасность начать говорить про “надо проредить проект” и “сдобрить его новым ~~навозом~~ библиотеками”. Я не могу повлиять на картошку напрямую, тогда как на код могу и поэтому ОТКАЗАТЬ. 

Фантазия людей, что ты делаешь, и следующей выступает метафора жемчужины. Инкрементная разработка наращиванием. Сначала создаем скелет, прототип, потом начинаем по слоям. Читайте Фред Брукс “Мифический человеко-месяц”, пишет автор и даёт  ДОБРО. 

Самая популярная метафора, которой нашлось место даже на башорге, это строительная. Очень много аналогий. Хотите перенести стену? Тратится время рабочих на перепроектировку. Что-то можно поменять уже в построенном доме, сделать капитальный ремонт, но зачастую проще построить новый дом. И никто не будет создавать вещи, которые можно купить (стиральную машину, базу данных, шкаф, фреймворк), только если это не индивидуальный, особенный проект, под особые деньги. ДОБРО.

Но как обычно, мир не черный и белый, а между ними все 50 оттенков серого (через год выйдет фильм, я получу свои 100 посетителей!). Комибинируйте метафоры, меняйте их, пользуйтесь этими эвристическими аналогиями, смело придумывайте новые аналогии с друзьями, используя бульбулятор (а ведь это тоже метафора).

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

## Глава 3. Про предварительные условия.

Глава открывается поговоркой про плотников "Measure Twice, Cut Once". В русской версии книги это уже «Семь раз отмерь — один раз отрежь». В индийской версии я не проверял, то бы подошло «Отмеряй вечность, пока не сотрется метр» на хинди. И дальше глава говорит как важно, как важно соблюдать все эти условия.

В наш век, когда на первый план людских глаз выходит софт, написанный ночью за выпитыми литрами кофе, создается впечатление, что вся эта штука с проектированием — пустая суета. Конечно, это так, ведь 90% рынка софта остается за пределами видимости среднего уличного кодера-микроблоггера. От NASA до медицины — там всё по-старому.

Люди не знакомые с разработкой ПО могут болеть синдромом WISCA: «Why Isn’t Sam Coding Anything? (Почему Сэм не пишет код?)». Тут на помощь приходят метафоры, помните. Стройка ещё не началась, даже фундамента нет — все сидят и чертят планы здания и всё согласуют! Поэтому автор приводит пару аргументов: обращение к логике, обращение к аналогиям, обращение к статистики из прошлого. Чем раньше исправляется ошибка, тем дешевле это стоит. 

А теперь снова моя нелюбимая часть, “всё зависит от проекта”. Конечно, К.О. Пишешь сайты если ты, то тебе даже Стив советует “нечеткую спецификацию требований”. Ни предварительное проектирование, ни комбинация итеративного подхода к исправлению ошибок не может дать однозначных гарантий, но всё-таки для большинства типов проектов можно вывести какие-то рекомендации. 

Все рекоменндации вкратце звучат так “Суть предварительных условий конструирования в том, что вам следует сначала определить, какие из них уместны для вашего проекта.”. Вот вам картинка, будто бы из рассылки очередного психологического тренинга, который откроет вам глаза:

![Глава 3, Пирамида](/img/cc/3.png)

Первое — это определение проблемы. Не решения, а проблемы. Чувствуете разницу? Если плохо сформуровать проблему, можно потратить время, решая не ту.
Второе — требования. Не программистом, а заказчиком. 

<blockquote>
Требования подобны воде. Опираться на них легче, если они заморожены.
Аноним
</blockquote>

Затем идут советы. Когда читаешь такие советы не видишь противоречий. Но и откровений тоже. Но если у вас в проекте постоянно меняются требования посмотрите страницу 39. Там даже приведен контрольный список вопросов. Типа “можно ли провести независимое тестирование, которое определит, что выполнены все требования”. 

В описании правильной архитектуры сквозит ООП подход. Классы, методы. Стандартные слова, что GUI должен быть GUI, масштабирование, безопасность и всё такое. Отличная копипаста в коммерческие предложения и тендеры. 

## Глава 4. Основные решения, которые приходится принимать при конструировании

Вот есть требования. И что дальше? Выбор языков программирования. Это смешно. Jбосновнные специальным научным трудом и моделью оценки Cocomo II фразы в духе “если опыт с языком три года, эффективность выше на 30%, чем у тех, для кого язык новый” звучат хорошо только для руководителей. Стив наверняка выполнял какую-то задачу по минимальному объему текста, который корпоративные инженеры должны использовать в своих письмах руководителям и кадровикам. Особенно мне понравилась вот эта таблица:

![Глава 4, таблица](/img/cc/4.png)<commit_msg>Update 2014-09-01-code-complete.md<commit_after>---
layout: post
title: Совершенный код, ч.1 
---
# {{page.title}} (_Макконнелл С. - Code Complete_)

<blockquote>
За время, которое вы потратите на чтение текста ниже, можно развернуть до пяти сайтов на вордпресс или объявить около двадцати фабрик. 
</blockquote>


Сразу скажу — я горячий сторонник всяких [programming mothefucker](http://programming-motherfucker.com/). Модно не называть программирование программированием, но попытаясь разложить это для семилетнего,  окажется, что в этой среде есть очень разные цели. Есть спортивное программирование, когда пацанчики на спорте ебашат задачи, используя знания алгоритмов и математики; они как турникомены с 6 лет делают выход силы по вечерам и утренний подъем с переворотом. Есть хакеры — когда задачи реальные, а правил, в общем-то нет — эти ребята якобы не знают слова невозможно, поэтому так симпатичны для голливуда и 14-летнего меня. А вот дяди, которые потеют за то, чтобы у них регулярно, два раза в месяц, обновлялись цифры в базе данных платежных систем — промышленные программисты. А по вечерам, когда эти дяди едут домой, слушая подкасты, они смотрят в запотевшее окно и мечтают о том, как сделают библиотеку с тысячью звездочками на гитхабе.

И что мне не нравится в таких книгах, это когда я вижу вот такие диаграммы: ![Глава 1, Процессы конструирования](/img/cc/1.png)

Недостаток внутрннего академического воспитания и силы воли у меня, конечно, но — такая скука!

![Глава 1, Кодирование и отладка](/img/cc/2.png)

Однако, уже второй рисунок всё меняет. Кодирование и отладка! В конце концов, через текст Стива Макконнелла чувствуется боль, которую невозможно было заглушить маленькой книжечкой, поэтому Стив написал здоровенный тяжелый кирпич, которым можно было бы приговорить плохого программиста на месте.

## Глава 2 Метафоры, позволяющие лучше понять разработку ПО

Первая осмысленная глава. Так хочется шутить в духе "нет, не метаамфетамин, а метафоры". Сначала метафора литературная, она описывает, конечно, в какой-то мере небольшие проекты: сел такой и написал код на хакатоне. Слишком примитивная, говорит автор: код, в отличие от книги не будет законченным, код нельзя выбросить полностью, следовательно, по Стиву метафора неполная. ОТКАЗАТЬ. 

Та метафора, в которой софт это взращивание картошки, включая подготовку, поливку, прополку, удобрения и очень многие этапы — сельскохозяйственная. Есть опасность начать говорить про “надо проредить проект” и “сдобрить его новым ~~навозом~~ библиотеками”. Я не могу повлиять на картошку напрямую, тогда как на код могу и поэтому ОТКАЗАТЬ. 

Фантазия людей, что ты делаешь. Следующей выступает метафора жемчужины. Инкрементная разработка наращиванием. Сначала создаем скелет, прототип, потом начинаем наращивать ценность по слоям. Читайте Фред Брукс “Мифический человеко-месяц”, пишет автор и даёт ДОБРО. 

Самая популярная метафора, которой нашлось место даже на башорге, это строительная. Очень много аналогий. Хотите перенести стену? Тратится время рабочих на перепроектировку. Что-то можно поменять уже в построенном доме, сделать капитальный ремонт, но зачастую проще построить новый дом. И никто не будет создавать вещи, которые можно купить (стиральную машину, базу данных, шкаф, фреймворк), только если это не индивидуальный, особенный проект, под особые деньги. ДОБРО.

Но как обычно, мир не черный и белый, а между ними все 50 оттенков серого (через год выйдет фильм, а я получу с гугла свои 50 посетителей). Комибинируйте метафоры, меняйте их, пользуйтесь этими эвристическими аналогиями, смело придумывайте новые аналогии с друзьями, используя бульбулятор (а ведь это тоже метафора).

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

## Глава 3. Про предварительные условия.

Глава открывается поговоркой про плотников "Measure Twice, Cut Once". В русской версии книги это уже «Семь раз отмерь — один раз отрежь». Индийскую версию (как и инди- версию) я не проверял, но там бы отлично подошло «Отмеряй вечность, пока не сотрется метр» на хинди. Дальше в главе говорится как важно, как важно соблюдать все эти условия.

В наше время, когда на первый план обывателя выходит софт, написанный ночью за выпитыми литрами кофе, создается впечатление, что вся эта штука с проектированием — суета. Девяносто процентов рынка софта остается за пределами видимости среднего уличного кодера-микроблоггера. От NASA до медицины — там всё по-старому.

Люди не знакомые с разработкой ПО могут болеть синдромом WISCA: «Why Isn’t Sam Coding Anything? (Почему Сэм не пишет код?)». Тут на помощь приходят метафоры, помните. Стройка ещё не началась, даже фундамента нет — все сидят и чертят планы здания и всё согласуют! Поэтому автор приводит пару аргументов: обращение к логике, обращение к аналогиям, обращение к статистики из прошлого. Чем раньше исправляется ошибка, тем дешевле это стоит. 

А теперь снова моя нелюбимая часть, “всё зависит от проекта”. Конечно, К.О. Пишешь сайты если ты, то тебе даже Стив советует “нечеткую спецификацию требований”. Ни предварительное проектирование, ни комбинация итеративного подхода к исправлению ошибок не может дать однозначных гарантий, но всё-таки для большинства типов проектов можно вывести какие-то рекомендации. 

Все рекоменндации вкратце звучат так “Суть предварительных условий конструирования в том, что вам следует сначала определить, какие из них уместны для вашего проекта.”. Вот вам картинка, будто бы из рассылки очередного психологического тренинга, который откроет вам глаза:

![Глава 3, Пирамида](/img/cc/3.png)

Первое — это определение проблемы. Не решения, а проблемы. Чувствуете разницу? Если плохо сформуровать проблему, можно потратить время, решая не ту.
Второе — требования. Не программистом, а заказчиком. 

<blockquote>
Требования подобны воде. Опираться на них легче, если они заморожены.
Аноним
</blockquote>

Затем идут советы. Когда читаешь такие советы не видишь противоречий. Но и откровений тоже. Но если у вас в проекте постоянно меняются требования посмотрите страницу 39. Там даже приведен контрольный список вопросов. Типа “можно ли провести независимое тестирование, которое определит, что выполнены все требования”. 

В описании правильной архитектуры сквозит ООП подход. Классы, методы. Стандартные слова, что GUI должен быть GUI, масштабирование, безопасность и всё такое. Отличная копипаста в коммерческие предложения и тендеры. 

## Глава 4. Основные решения, которые приходится принимать при конструировании

Вот есть требования. И что дальше? Выбор языков программирования. Это смешно. Jбосновнные специальным научным трудом и моделью оценки Cocomo II фразы в духе “если опыт с языком три года, эффективность выше на 30%, чем у тех, для кого язык новый” звучат хорошо только для руководителей. Стив наверняка выполнял какую-то задачу по минимальному объему текста, который корпоративные инженеры должны использовать в своих письмах руководителям и кадровикам. Особенно мне понравилась вот эта таблица:

![Глава 4, таблица](/img/cc/4.png)
{'fraction_non_alphanumeric': 0.04997543342458061, 'fraction_numerical': 0.004000842282585807, 'mean_word_length': 5.162629757785467, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 11, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1863827', 'n_tokens_mistral': 5984, 'n_tokens_neox': 7215, 'n_words': 1993}