Здравствуйте дорогие читатели и программисты!
Должен предупредить, что мой сегодняшний пост будет больше похожим на вопрос, чем на статью. Целью поста является поиск единомышленников, увлеченных азартом людей, желающих создавать качественные и конкурентоспособные приложения. Начну я из далека, налью немого воды, чтобы пост был похожим на что-то, что не сразу удаляют с хабра.
Многие годы я мечтал и продолжаю мечтать до сих пор создавать качественные приложения. Каждый раз, когда я начинал писать свою новую программу, я был на 100% убежден, что это будет самая лучшая программа в своем роде. Начало любого приложения было воодушевляющим, восхитительным и внушающим надежды на большие перспективы. В такие дни я был погружен в работу с головой, забывая обо всем на свете. Каждый день появлялись новые функции, применялись и новые удачные решения, всё сулило небывалый прогресс и золотые горы, если бы все продолжалось в том же темпе. Хотелось мысленно продлить этот график роста, и казалось, ничего не могло ему помешать. Думаю у каждого из нас такое бывало.
Со временем программа росла, как высотное здание этаж за этажом, местами превращаясь в катакомбы, по которым приходилось блуждать часами, возобновляя в памяти весь замысел автора, или ища куда же тут можно вставить очередной костыль.
Работа над доработкой программы постепенно становилась все труднее и безрадостнее. Каждый новый глюк был коварнее предыдущего, и так случалось, что цель развития программы сменилась целью избавления её от ошибок. Сложно писать новые функции, зная что в старом поведении что-то не в порядке. В такие моменты осознаешь насколько трудна разработка программного обеспечения. Все грехи и просчеты в начале, недоработки архитектуры и вставленные костыли возвращались ко мне как повторяющийся кошмарный сон. Кроме того что это были крайне неприятные несовершенства программы, они еще и заставляли работать меня часами, в попытках избавиться от этого кошмара. В конечном итоге оставался выбор: либо проснуться от кошмара и начать программу заново, в надежде что во второй (третий, четвертый) раз я смогу предусмотреть все подводные камни, и уж на этот раз сделаю грамотную архитектуру, разделю всё по понятиям, инкапсулирую сложности и вынесу повторяющийся код в отдельные места; либо законсервировать программу в том состоянии, в котором она была в тот момент, устранить все наиболее видимые ошибки и ждать лучших времен, нового вдохновения к этой программе или новых идей.
Такая схема развития событий повторялась каждый раз, с каждым новым проектом, каждый год по несколько раз, в не зависимости от уровня моих навыков, в не зависимости от того, писал ли я программы для себя или это были денежные заказы от других людей. Сначала искры в глазах от легкости, с которой появляются новые функции, затем упорный труд (утешая себя, ну что же, без труда не сдвинешь никуда), потом многосерийный кошмар и предсмертные муки, и, наконец, смерть проекта. Смерть в том виде, в котором он существовал прежде, и рождение новой, написанной с нуля версии того же приложения.
Со временем стало понятно, какая часть кода сможет прожить долго, а какая умрет через несколько попыток её доработать. Достаточно взглянуть на наполненный условиями участок кода, не вмещающийся ни на экран монитора, ни в человека, и становится понятно что этот код близок к тому, чтобы быть заброшенным. Он конечно может работать. И если он работает хорошо, в нем нет ошибок и производительность не вызывает проблем, то лучшее что можно сделать — не трогать его. Можно посмотреть на класс, имена методов которого говорят что он является смесью каких-то разнородных понятий, и становится понятно, что использовать второй раз его не хочется. Он достиг предела своей сложности, здание выросло до такой высоты, что еще этаж и основание не выдержит и все завалится. Не выдержит мой , в попытках обрисовать все множество комбинаций состояний этого объекта, понятие становится слишком сложным для понимания. Это хорошо проявлялось когда я расследовал причины неправильного поведения таких классов. Нужно было что-то менять.
Переписывание программы давало хорошие результаты, но затрачивало большое количество сил. Я не всегда мог решиться на этот шаг. Почти никогда. Порывался, осознавал объем работы и у меня опускались руки. Я знаю, я не одинок в этом воспоминании, потому как по другому и не может быть. Пользователи говорят, неплохо бы добавить всего лишь вот такую функцию, а ты понимаешь что ты уже добавил слишком много вот таких функций и пришло время переписывать все сначала. Пользователи (или заказчик) не понимают: неужели так сложно добавить еще одну единственную функцию? Они не понимают, что нужно переделать все, переписать, устранить архитектурные ляпы, переделать все с нуля, потому что когда мы добавляли последние десять новых фич, мы уже говорили себе, что каждая из этих фич будет последней.
Нарастание сложности программы неизбежно, и тем неизбежнее оно становится, чем больше людей работают над проектом. Это настоящее проклятие программирования, которое настигает любую программу, рано или поздно, вопрос лиш времени. И именно навыки противостоять этому снежному кому растущего кода и отличают успешные проекты, от массы замерзших поделок.
Условно можно выделить три фазы положения дел в программе:
- Зеленая фаза или детство проекта. Код кажется простым, его не много, руки развязаны и хочется программировать. :)
- Желтая фаза или трудовые будни. Проект большой, работа над ним трудна, но кажется вполне оправданной. Новый функционал добавляется осторожно, но регулярно. Многие были бы довольны оставаться в этой фазе навсегда, но ведь нет. :|
- Коричневая фаза или катакомбы. В проекте много непонятного. Одни и те же вещи делаются несколькими разными путями. Переписывать отдельные части не хватает духа, так как непонятно на что это может повлиять. Слишком много неудачных решений, всего не изменить, и стоит ли ввязываться? Переделка отдельных участков влечет за собой долгий период отлавливания ошибок в самых разных участках программы. Вставляются костыли. Количество затраченных сил намного превышает результат. Развитие программы не представляется возможным. Появляется желание заняться чем-то другим. :(
У меня есть пример из жизни. Я знаю одну фирму, которая программирует всегда в зеленой фазе. Программисты в этой фирме кажутся довольными и оптимистичными, не видавшими трудностей людьми. Такое впечатление, что им море по-колено. Чудесно, не правда ли? В чем же дело? Её смекалистый руководитель давно понял о закономерной смене фаз в процессе разработки и продает проект каждый раз, когда начинает чувствоваться накопление сложности. Он продает стартапы. Графики роста прилагаются. Отчеты о проделанной работе отличные. Срок выполнения завораживает. Перспективы кажутся внушительными. Наивные инвесторы полагают что программа это товар, как любой другой обычный бизнес, купил, поставил на места продавцов и бухгалтеров и получай себе прибыль. Они часто не понимают, что покупают себе головную боль замедленного действия, которую они выбросят через год, когда программисты начнут лезть на стены, лишь бы все стояло на месте. Все проблемы коричневой фазы остаются на долю покупателя, а фирма продавшая стартап чувствует все прелести и оптимизм зеленой.
Выход конечно оригинальный, но, очевидно не единственный. Существует ведь Microsoft, Apple, Oracle которые умеют преодолевать эти трудности роста. Как они это делают? Какие есть методы сохранить зеленую зону?
Предлагаю вам написать ваш ответ в комментариях. Я также изложу свои соображения.
Спасибо вам за ваши комментарии.
Автор: Oleg_Yozhik
