Если вы не работали программистом в 1990-е , то вы, вероятно, не знаете, какой катастрофой были те годы

Если вы не работали программистом в 1990-е , то вы, вероятно, не знаете, какой катастрофой были те годы. Подавляющее большинство проектов провалились, а те, что удавались, оказались через некоторое время практически непригодны к использованию. Мы тогда плохо знали, как писать программы (во многом потому, что не было интернета), и отчаянно пытались найти подходящие способы. Например, давно известная водопадная модель в своей первоначальной форме была весьма хороша, но тут вы следуете жёстким правилам — сначала вырабатываете требования/ТЗ, затем подписываете их с заказчиком, затем делаете архитектуру/дизайн, затем начинается низкоуровневый кодинг и т. д. и т. п.

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

В начале 2000-х были придуманы agile-подходы, гибкая/скоростная разработка. Идея заключалась в том, что мы договариваемся об очень коротких периодах времени (спринты, обычно неделя), когда мы что-то делаем, а затем получаем обратную связь от заказчика, и эта обратная связь помогала нам и направляла нас.

Но ключевая проблема, о которой я пишу в СильныхИдеях, заключалась в том, что нам нужно было уметь справляться прежде всего с постоянными изменениями, то есть научиться тому, как создавать эволюционно развивающуюся систему, готовую к достаточно сильным модификациям. Но всё наше понимание тогда было неправильным, все наши инструменты были неправильными, и наши клиенты почти всегда не знали, чего именно они хотят, и все инструменты, которые мы имели тогда, не были сосредоточены на ключевой возможности — корректно изменить себя, они были ориентированы на правильности кода. Но идея правильности не имеет значения, потому что если вы не знаете, чего вы хотите, это означает, что нам нужна не правильность, а способность изменяться.

=

Сегодня у нас уже есть множество техник проектирования: SOLID, DI и т.п. Это нам предлагается как твёрдые принципы, как инженерные способы проектирования, но если посмотреть на это с другой стороны, то на самом деле это примеры того, как делать вещи легко изменяемыми. Та же идея DRY в том, что когда вам нужно сделать изменение, у вас есть ровно одно место для этого.

Идея коротких итераций некоторое время помогала создавать системы более легко изменяемыми. Действительно, показалось, что быстрые беспорядочные циклы коротких итераций побеждают тщательное предварительное проектирование. Но потом это превратилось в бизнес, в жёсткий свод правил, который не имеет никакой связи с agile. Погуглите "Agile is Dead, McKinsey Just Killed It", там есть две части. Dave Thomas кстати и автор классной книги "Прагматичный программист", рекомендую.

Идея agile заключается в том, что сперва вы определяете, где вы находитесь, затем вы определяете, где вы хотите оказаться дальше, и затем делаете короткий шаг в этом направлении. А затем вы оцениваете, где вы оказались реально, идёте ли вы правильным путём или неправильным, а затем возвращаетесь к началу, и делаете это снова и снова. И если вы будете применять эту рекурсию ко всему, что вы делаете, вы обнаружите, что на самом деле добились весьма хорошего прогресса.

Но всегда будет выбор: делать что-то так или иначе, поэтому вторая часть этого манифеста заключалась в том, что при выборе между двумя вещами, которые приносят в проект равную пользу, выбирайте ту, которую легче изменить.

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

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

=

Наш мозг работает как компьютерная нейросеть: он обучается различным шаблонам в прошлом, и затем может применять эти шаблоны к текущей ситуации, как-то их аппроксимируя. Мозг позволяет нам ходить без необходимости думать о каждой мышце, которая должна напрягаться/расслабляться, или ездить на велосипеде без непрерывного решения в голове дифференциальных уравнений, поэтому мы можем здорово натренировать и ту часть нашего мозга. которая отвечает за принятие правильных проектных решений.

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

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

Вот и всё, что вам нужно делать: вы даёте своему мозгу обратную связь, вы даёте своему подсознанию что-то, что он может "пожевать". И если вы будете делать это регулярно, вы обнаружите — и это удивительно, как это происходит! — вы обнаружите, что в течение считанных месяцев вы на самом деле становитесь лучше в принятии подобных решений. Потому что ваш мозг будет выявлять и изучать паттерны в том, что вы делаете, и он научится применять это без вашего ведома, а вы будете считать себя невероятно интуитивным :)

Резюме: вносите все изменения в проект (на всех уровнях!) так, чтобы их было впоследствии легко модифицировать, и дополните это программированием своего мозга, чтобы он обучался и рос весело и легко!

P.S. Со временем мастера обретают мощное интуитивное представление обо всей своей профессиональной области. Если вы будете терпеливы, вас ждет захватывающее волнение и радость! ?

Источник: vk.com

Комментарии: