Мой путь

Думал начать так: «Если бы мне дали почитать эту статью много лет назад я наверное сейчас....», но нет — неправда это. Это мой путь и ускорить его думаю не получилось бы никак. Знать и чувствовать — это небо и земля. Стоило сделать очень-очень-очень много ошибок, чтобы сейчас понимать то, что понимается. Пост написан, а значит найдет своего читателя. Желаю успехов.

Все началось с бытового компьютера ЛИК, на котором бессонными ночами в возрасте 8-12 лет я понял, что такое кремниевый друг и то, как с ним общаться. Это был период, когда компьютер был другом, но на Вы. Каждый день я стремился к нему, чтобы получить еще какую-то новую историю. Это было красиво, как и все в первый раз. Первая строка кода на интерпретаторе Бейсик, первая ассемблерная команда, первое обращение к видеопамяти... Это было скорее: «— а можно так? — что пожелаешь».

Длительный перерыв и встреча с Его Величеством ПК. Помню, на первый урок нам сказали купить дискету. Я купил две. Вторую разобрал тут же. Это было время бокса для дискеток, в которой с трудом посещалось 21 дискетка со всем, что я имел. Это было время Паскаля. Процедуры и функции, массивы и индексы, Begin-End и всякие алгоритмы отформатировали в мозгу некоторое место для дальнейших прорывов. Это была эпоха БИОСа и ДОСа, которая закончилась появлением Windows95. Как бы я не фукал сейчас Окна, но именно они мне показали, что такое черное по белому.

Потом были Delphi и Интернет. В это время появлялась идея, которая тут же реализовывалась за пару суток до ЕХЕ-шника. Как в анекдоте: «— что ты делаешь? — сейчас запустим и посмотрим!» Все было именно так. Процедурный стиль не оставлял меня. Если была кнопка — был и ее обработчик. В обработчике описывалось все, что должно было быть сделано. То, что может понадобиться в другом проекте, устранялось в отдельный файл-монстр — MyUnit.pas. В это время я впервые услышал и прочно заучил: ООП = полиморфизм + наследование + инкапсуляция. Но в моих проектах ООП и не пахло. Я его не чувствовал.

Время шло. Университет закончился. Устроился на работу. Язык для кофеварок, команда, SVN и много-много файлов на один WEB проект. Думал, не осилю. Осилил. Новый язык и моя команда заставили меня писать в одном файле не больше одного класса, научили новому слову Архитектура. Кто-то сказал что «метод, не вмещающийся на один экран — плохой метод». Разработка шла методом Try-Error — так же, как раньше. Нашел подходяще название привычному для меня стилю разработки — Google DrivenDevelopment. Понимаешь, это тогда, когда отключается Интернет и разработка приостанавливается.

Прошло еще немного времени, и появились тесты. Мне предложил их попробовать на вкус лидер проекта. И понеслась. Я сразу понял, зачем их придумали. Эра «сейчас запустим — проверим» закончилась. Началась эра jUnit. Пришлось немного повоевать с менеджерами. Я часто слышал: «зачем писать 10-20 строк кода для тестирования 2х?», «зачем тестировать то, что и так работает?» или «почему ты не пишешь хороший код сразу?». Сложно объяснить на пальцах — это чувствовать надо (или как говорят быть test infected). А так — люди ошибаются. Программисты — люди, которые ошибаются чаще. Именно тесты позволили мне больше не волноваться за код, отправленный в хранилище. Снизился стресс — повысилось качество работы. Со временем тестов стало больше и их преимущество проявились во всей красе. Я получил возможность приводить некрасивый код в более красивый, и делал это безопасно для проекта.

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

Открытием и новым периодом стал для меня TDD (Test Driven Development или разработка, управляемая тестированием). Я избавился сразу от всех недостатков подхода «вначале код, а потом тест». Я получил еще большего ускорения и простоты в коде. Абсолютно все покрыто тестами и каждый тест жизненно необходимым — без него нельзя сделать следующий шаг. Функционал «на будущее» остается в виде идеи на бумаге. — правило 80/20 проявило себя во всей красоте — минимум кода только чтобы заработало. Я стал более последовательным в разработке. И этим все не закончилось — до сих пор делаю интересные открытия... Как всегда — недостатки имеются...

Мне было сложно словами объяснить, что тест приходится писать до написания кода. Как написать тест на то, что еще не существует? На меня непонимающе смотрели, когда я продвигал тесты в команде, а когда заговорил о том, что мне не стоит думать об архитектуре или о том, что я забыл что такое Debug или о том, что я делаю более 200 ошибок в день, на меня начали смотреть еще более непонимающе. Единственное что давало 100% успех — когда я показывал то, что я делаю, подсаживаясь к напарнику за его компьютер.

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

Где-то в это время в мои руки попала книга Совершенный код. Библия программиста, скажу. Именно из нее узнал про XP (eXtreme Programming). Каково было мое удивление, когда и парное программирование и TDD и Refactoring и совместные разборки кода и еще что-то (что к тому времени для меня было уже родным и очевидным) я нашел в методике экстремального программирования от Кент Бека. Все такое близкое и все в одном месте... Я снова влюбился. Как оно все гармонично сочетается. Есть, конечно, и недостатки, но пока тащусь от достоинств.

А недавно я узнал, что недостаток понимания TDD классно снимается в BDD (Behavoir Driven Development). Cейчас интенсивно пробую. Идея в том, что не тесты пишутся вначале, а требования к системе. Ну а все остальное как в TDD :)

Наверное, самая революционная эра началась, когда начал замечать аналогии между программированием и жизнью. Кто-то говорит не путать личную жизнь и работу, но это невозможно. 8 часов, 5 дней в неделю не могут не отпечататься на все, что ты делаешь в «свободное» время. Я заметил, что в повседневной жизни стал более последовательный, перестал себе доверять: делая что-то, желаю получить обратную связь — как-то проверить новое убеждение. Понял, что программирование и жизнь имеют много общего, только в программировании причина и следствие стоят ближе во времени.

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

Что дальше? Не знаю, но уверен оно будет. Быть может, кто-то подскажет что? Буду рад любым напутствиям.

А сколько ошибок еще предстоит сделать...

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU