Pull to refresh

Завяжите шнурки и подтяните свои штаны!

Reading time 5 min
Views 34K
Original author: John Sonmez
Итак, что же замедляет разработку программного обеспечения?

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

И почему раньше задачи решались так просто, а теперь выглядят запутанными и сложнореализуемыми?

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



В поисках ответов


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

Если бы мы знали ответы на все вопросы, то и проблем бы никаких не было.

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

И в первую очередь все начинают винить процесс. Ведь очевидно, что проблемы с процессом негативно влияют на скорость разработки.

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

Я хочу чтобы Вы меня здесь правильно поняли. То есть две вещи, которые я упомянул — не единственные, что должны Вас волновать, я лишь пытаюсь сказать, что раз уж большую часть времени команда реально работает над действительно важными для проекта вещами, Вы никак не сможете волшебным образом наладить процессы, хоть как-то заметно увеличивая продуктивность разработки команды (в большинстве случаев).

Рассматриваются и такие варианты:

  • Парное программирование?
  • Сменим скрам на канбан?
  • Разве мы не должны определять бэклог иначе?
  • Может нам стоит использовать попугаев для оценки задач? Стори поинты? Или вообще пусть все бэклоги будут одинакового размера?
  • Нам нужно больше девелоперов? Или бизнес аналитиков?
  • Стоит ли реорганизовать команды?

Конечно, это всё замечательные вопросы, которые следует время от времени себе задавать, однако я постоянно убеждаюсь в том, что есть другая позабытая проблема побольше…

ВАШ КОД!




Давайте проведём небольшой эксперимент.

Забудем обо всех процессах, забудем о скраме и бэклогах и стори поинтах и всём-всём остальном.

Вы — Разработчик. Вам надо сделать поставленную Вам задачу, изменить кое-что в коде. Вы сидите один, нет никаких процессов, аналитиков. Только Вы и Ваша работа.

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

Наверняка у Вас будут примерно такие мысли:

1. Эта фича имплементится быстро и просто, я знаю как и куда её добавить, всё будет тип-топ!

Вот так, замечательно! Выходит, на самом деле у Вас нет никаких проблем.

2. Что-то я не понимаю, что надо сделать. Как и где это будет использовано в системе?

Хм, в таком случае у Вас, скорее всего, присутствуют кое-какие проблемы с процессом. Может быть Вам нужна постановка задачи почётче или следует задать больше вопросов. Такое случается, правда. Идеи-полуфабрикаты попадают в процесс и кому-то определённо придётся побегать и пошевелить мозгами прежде чем разработчики на самом деле смогут заняться ими.

3. Я боюсь что-то менять, это почти невозможно. Прежде чем начать, понадобится копать в других частях приложения и разбираться: что, как и почему так работает (и как оно вообще должно работать).

Как не печально, но это наиболее вероятный исход. Что-то среднее между вторым и третим пунктом, потому что у них одна и та же причина — готовый код и либо усопшая, либо «её-нет» архитектура.

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

Но подобные проблемы Вы увидите только в успешных компаниях, потому что…

Иногда необходимо бежать с развязанными шнурками


Было время, я консультировал пару провальных стартапов. И должен заметить, у них была одна общая черта (как в прочем и у большинства других стартапов): ноль проблем с кодом. Да-да, отличная кодовая база, причёсанная, ухоженная, пахнет приятно.

Я видел самую лучшую архитектуру и идеальный код в умерших стартапах.

Может быть это выглядит так, будто я противоречу сам себе. Сейчас поясню.

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

Что происходит? Они создают прекрасный код, клёвую архитектуру. Но слишком поздно. Конкуренты вырываются вперёд и двое обкофеиненных не-совсем-программистов-но-я-чуть-кодил бодро обходят Вас со своим приложением на VB6, написанным прошлой ночью на коленке. Да, может не совсем то, что хотел заказчик, но зато как оперативно!

Но что, я разве теперь утверждаю что надо написать салфеточный говнокод и быстренько сдать его, иначе провал?

Или я говорю, что нельзя выраситить успешную контору на хороших практиках и качественном коде?

Нет. Но я пытаюсь сказать что большинство успешных компаний в первую очередь вовремя сосредоточили свои усилия на заказчике и только затем на ПО.

Другими словами, если Вы взгляните на код десятка успешних компаний за последние лет пять, в 9 из них вы обнаружите дерьмовую архитектуру и систему весьма отдалённую от исходного дизайна и хороших манер.

Так, а что насчёт штанов?




Окей, к чему я всё это?

Компании-победители бегут и выживают! Однако и после 5 лет они всё ещё продолжают бежать изо всех сил и тут их некрасивые шнурки начинают развязываться.

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

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

Это самую малость их тормозит и потому они продолжают бежать, яростно клепая фичи и брызжа слюной.

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

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

И тут они начинают думать. Что же делать? Как решить проблему, не сбавляя скорости и не подтягивая лишний раз штаны? Начинается импровизация. Они пытаются прыгать. Кому-то в голову даже взбредает идея что нужно больше ног… =)

Я думаю, Вы уловили мысль. На самом деле, нужно всего лишь…

Остановиться, завязать шнурки и подтянуть наконец свои штаны!


Надеюсь, что аналогия ясна и теперь Вы понимаете что происходит с закостенелой архитектурой и затхлым системным кодом.

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

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

К сожалению, у меня нет волшебного ответа. Если Вы можете ускориться, забив на архитектуру и дизайн системы в целом, то рано или поздно Вам придётся расплатиться и зарефакторить всё по-нормальному.

Возможно, Вы начнёте с нуля. Возможно, придётся объединить все свои силы, чтобы привести всё в порядок. В любом случае, Вам придётся остановиться. Хотя может быть кто-то пробовал завязывать шнурки на бегу? =)

Не печальтесь, Вы не сделали ничего плохого. Более того — Вы выжили в то время, когда другие были слишком бережными и провалились. Только не игнорируйте свои штаны, в которых Вы путаетесь на каждом шагу, сделайте что-нибудь страшное!

Прим. перев.: я не переводчик, я такой же как и все, поэтому вышел более-менее вольный перевод. Старался передать ироничность статьи. Об опечатках и недочётах пишите, пожалуйста, в личку. Спасибо за внимание и хорошего дня!
Tags:
Hubs:
+77
Comments 40
Comments Comments 40

Articles