От переводчика: при разработке Web-payment.ru, сайта с мониторингом обменников и множеством разделов о платежных системах, я на интуитивном уровне использовал принципы, описанные в этой статье. Подсознательно я их знал, но не мог сформулировать. Предлагаю вам ознакомиться с интересным подходом, которым поделился опытный программист, автор многих книг Jeffrey Ventrella.

Мой папа часто говорил мне: «Помедленнее, сынок, ты делаешь дело слишком быстро».

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

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

Но ничего не вышло

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

Полный бред

Нельзя просто так выкинуть из работы процесс проектирования. Он существует с тех самых пор, как появились цивилизации и даже самые новые, и умные инструменты разработки, насколько бы умными они не были, не смогут заменить коллективное сотрудничество в реальном мире, и передовые практики человечества, благодаря которым были созданы соборы, железные дороги, и полнометражные художественные фильмы.

Точно так же, сколько бы вы не программировали, у вас никогда не получится создать инструмент, который позволил бы вам полноценно разрабатывать ПО с той же скоростью, что и команда манки-кодеров.

Аритмия

Моё медленное программирование в среде быстрых программистов было похоже не какую-то форму аритмии. То есть мой ритм написания кода просто растворился в итерациях других кодеров, которые строчили его как из пулемета. Мой стиль программирования предполагает абсолютно разную длительность работы над проектами самой разной сложности. Каждая ветвь начинается с исследования, проб и ошибок, хаков и временных переменных. По сути, все это можно сравнить с конструированием лесов вокруг строящегося здания. Постепенно картина вырисовывается. Немного позже, я возвращаюсь к работе, расставляю все точки над «i» и наношу последние штрихи. Результатом каждого такого сеанса творчества является что-то вроде готового к использованию кода. (Я никогда не оставляю «в мастерской» ничего лишнего после работы). Добавление в репозиторий ветки разрабатываемого кода равносильна появлению новой стратегии, схемы проекта или архитектурного объекта.

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

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

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

Движение за медленное программирование

Согласно Википедии: «движение за медленное программирование является частью медленного движения. Это философия разработки программного обеспечения, которая придает особое значение качеству кода, внимательному проектированию, тестированию программного обеспечения и обдумыванию процесса разработки. Она рекомендует избегать использования костылей, слишком быстрых циклов разработки и писать код, в котором нет багов».

Кроме того, Википедия также дает нам информацию и о «Медленной разработке программного обеспечения»: «Придерживаясь гибкой методологии разработки, группы разработчиков ПО по всему миру ищут проекты, результаты которых можно спрогнозировать заранее, и стремятся к построению прочной карьеры, соблюдению рационального баланса между работой и личной жизнью. Они предлагают использовать такие практики, как парное программирование, ревизия кода и рефакторинг кода, что в результате позволяет получить более надежные и более отлаженные программные приложения.»

Популярность разработки ПО при поддержке венчурного капитала здесь, в заливе Сан-Франциско, сейчас растет с сумасшедшей скоростью. Деньги, которые выступают в роли движущей силы, предъявляют неестественно завышенные требования к процессу развития творческой мысли, который на деле лучше всего отдать на откуп естественному биологическому ритму эволюции. Быстрее не всегда значит лучше. На самом деле, медленнее иногда означает быстрее — в те моменты, когда все обещанное выполняется на практике. О том, как цифровые технологии узурпируют наши природные временные ритмы рассказывается в книге Дугласа Рушкова Present Shock.

Есть и другая проблема: почти религиозная одержимость технологиями, сопровождаемая фетишистской любовью к инструментам разработки. Люди удивляются, почему софт получается таким отстойным (да, он и правда отстой), а получается он таким из-за зацикленности на самом себе. Быстрые программисты сначала делают посредственные утилиты, которые помогают в написании кода, а потом бесконечно улучшают их, создавая все новые и новые посредственные решения для улучшения предыдущих, таких же посредственных разработок, созданных ранее.

Вот почему я считаю, что нам нужны взрослые люди, женщины, педагоги и творческие люди внутри цикла разработки приложений. Больше человечных людей, меньше людей-объектов. Говорю не о влиянии таких людей на процесс извне, когда мы садим их в техподдержку, или поручаем им украсить дизайн интерфейса. Я имею в виду внутреннюю сторону процесса, необходимость добиваться того, чтобы программы находили отклик у всего человеческого общества в целом.

Как же я рад, что я не машинистка, печатающая вслепую

Один из моих друзей — взрослая женщина, специалист по программному обеспечению, как-то с усмешкой подметила: «Программирование приложений и набор текста на клавиатуре — разные вещи». Все это знают, однако вспоминать об этом время от времени никому не помешает. Брэндан Энрик уже писал об этом. Мы, программисты, проводим свое время стуча пальцами по клавиатуре, и со стороны такая физическая активность выглядит как будто это и есть программирование. Однако на самом деле, программирование представляет собой акт соединения вместе замысла, языка, логики и умозрительных конструкций в некую определенную форму, такую, что её можно сохранить в память компьютера.

Моя жена часто выходит во двор и спрашивает меня: «Ты кодишь?». И часто я отвечаю, что «Да», однако на самом деле, в такие моменты я, как правило, обрезаю ветки секатором или вожусь с компостом.

Растения, грязь и секаторы имеют к программированию почти такое же отношение, что и клавиатуры c мерцающими экранами.

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

Автор:

Источник