четверг, 27 марта 2014 г.

Zen and the Art Of Software Engineering

Вообще хотел написать пост на хабр, но поскольку ребята там дико огороженные и слили мне всю карму за наезд на Galaxy S2, пишу сюда. Привет ребята.

Несмотря на большое количество теоретически рассуждений о философии, книга Роберта Пирсига «Дзен и искусство ухода за мотоциклом» может здорово пригодиться даже последнему программисту на Borland Pascal. image В одной из глав автором вводится понятие "сметки", или более просто -- энтузиазма. В частности, дается замечательная классификация ловушек сметки, которую мы в этой статье попробуем применить к нашим ежедневным обязанностям.

Внешне обусловленные ловушки

Я починю тесты с пяти раз!

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

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

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

Гейзенбаги

Да-да, Пирсиг описал понятие до того, как оно стало мэйнстримом! Баг пропадает как раз после того, как на стендапе вы пообещали сделать это уж хотя бы в этот раз? Здесь все очень просто. Если позволяет время, нужно отложить задачу в сторону, и ждать проявления. Как только проблема проявит себя -- попытайтесь собрать все малейшие детали поведения системы в этот момент. Неожиданные пики CPU, логи сборщика мусора, время обеда ваших тестировщиков, расстояние до почтового сервера в милях -- когда-то вы сможете увидеть взаимосвязи даже в самых бредовых вещах. И уж тогда эта проблема от вас не убежит.

Какой из десяти GIS-форматов выбрать

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

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

Во-вторых, хорошенько определитесь с требованиями. Вы же не хотите переписывать ваши очереди с Redis на SQS, потому что у него проблемы с надежностью при сетевых проблемах? Или вдруг выяснится, что прикрутить авторизацию нужной гранулярности к Elasticsearch -- проблема достойная отдельной команды?

Если вдруг выяснится, что вопреки воззрениям Лоритов вашей библиотеки нет в природе, то все-таки придется писать свой велосипед. С другой стороны, кто не любит велосипеды?

На этом дзенская классификация внешних ловушек заканчивается, и мы переходим к внутренним.

Внутренне обусловленные ловушки

А в своем коде не видим и GOTO

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

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

Я-то все правильно делаю, это индусы из циски виноваты

Следующая ловушка связана с предыдушей, но немного отличается. Если в том случае вы просто недооценивали факт по невнимательности, то в этом случае вы переоцениваете себя. «Я же двадцать пять лет в отрасли, конечно я знаю как работает AOP в спринге, тут явно замешано взаимодействие фазы луны и нашей версии JBoss». Возможно, пришло время прочитать документацию.

Релизный мандраж

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

Вместо массового убийства нервных клеток, попробуйте выразить свои тревоги на бумаге. Составьте план, выделите самые важные детали, закрывайте одну за одной до готовности. Trello -- ваш друг. И помните -- даже Doug Lea может ошибаться.

Как же задолбала вся эта фигня

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

Скука отбирает возможность видеть вещи свежим взгядом, в этом состоянии бывает просто невозможно найти по-настоящему верное решение. «Хоть как-то» сданную задачу придется переделывать. Вместо этого, опять же, отвлекитесь. Возможно, это сигнал о какой-то другой проблеме. Может быть, занятие деплоймент-инженера просто вам не подходит? Или настало время выкинуть пару сотен килобайт копипасты и написать один генератор форм на липкой ленте и макросах?

Если вы думаете, что IT-область вся такая из себя особенная, то вы ошибаетесь. Даже среди сварщиков есть специализация. Пирсиг намекает нам, что среди нас могуть быть как прирожденные кодеры, которые могут перелопачивать тонны говнокода день за днем, а есть утонченные творческие ребята, которых хлебом не корми, но дай автоматизировать что-нибудь эдакое на scalaz и акторах. Каждый должен делать то, что ему по душе!

Да ладно, там делов-то на пять минут

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

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

Ответ на задачу о двух стульях

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

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

Иногда инструменты все-таки виноваты

Хотите написать систему, которую нужно долго сопровождать, на питоне? Редактируете Scala-код в nano? Анализируете гигабайты логов less'ом? Деплоите сотни серверов в гетерогенных средах голым башем? И недовольны своей производительностью? Нет, серьезно, у вас еще есть вопросы почему ваши ежедневные активности вас так бесят?

Найдите правильный инструмент. Системы типов придумали правильные чуваки, выкиньте свои тесты на сложение. IntelliJ-плагин весьма неплох, забейте на принципы UNIX. Освойте ELK наконец, вы сможете отдебажить весь этот ад на хадупе быстрее, чем нагрепаете следующее вхождение строчки со словом WARN. Эксперементируйте, это в любом случае лучше, чем продолжать в том же духе.

В конце всех разъяснений на тему сметки Пирсиг дает очень дельный совет -- применять эти принципы нужно не от случая к случаю, ими надо жить. Вы не сможете быть расчетливым и наблюдательным, если питаетесь энергетиками в остальные 128 часов в неделю. Нужных логов всегда не будет под рукой, если в своей собственной квартире вы не можете найти носки без помощи жены.

У вас в голове уже есть инструментарий, чтобы стать продуктивнее на 1000%. У вас есть наводка на оригинал, который вы просто обязаны прочитать. Теперь, со всем этим -- действуйте!