Сложности Многоэтажного Программирования

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

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

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

Многие годы я мечтал и продолжаю мечтать о создании качественных приложений.

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

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

В такие дни я погружался в работу с головой, забывая обо всем на свете.

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

Мне хотелось мысленно продлить этот график роста, и казалось, что ничто не может его остановить.

Я думаю, это случалось с каждым из нас.

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

Работа над доработкой программы постепенно становилась все более сложной и безрадостной.

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

Трудно писать новые функции, зная, что со старым поведением что-то не так.

В такие моменты понимаешь, насколько сложна разработка программного обеспечения.

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

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

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

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

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

Смерть того, что существовало раньше, и рождение новой версии того же приложения, написанного с нуля.

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

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

Это, конечно, может сработать.

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

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

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

Это хорошо проявилось, когда я исследовал причины плохого поведения таких классов.

Что-то нужно было изменить.

Переписывание программы дало хорошие результаты, но потребовало больших усилий.

Я не всегда могла решиться на этот шаг.

Больше никогда.

Я попробовал, понял объём работы и сдался.

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

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

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

Это настоящее проклятие программирования, которое рано или поздно настигает любую программу, это лишь вопрос времени.

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

Условно можно выделить три фазы положения дел в программе:

  1. Зеленая фаза или детство проекта.

    Код кажется простым, его не много, руки свободны и программировать хочется.

    :)

  2. Желтая фаза или рабочие дни.

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

    Многие были бы рады остаться на этом этапе навсегда, но нет. :|

  3. Коричневая фаза или катакомбы.

    В проекте много неизвестного.

    Одни и те же действия выполняются разными способами.

    Переписывать отдельные части смелости не хватает, так как непонятно, на что это может повлиять.

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

    Костыли вставляются.

    Количество затраченных усилий намного превышает результат. Разработка программы невозможна.

    Есть желание заняться чем-то другим.

    :(

У меня есть пример из жизни.

Я знаю одну компанию, которая всегда программирует на зеленой фазе.

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

Кажется, море им по колено.

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

Он продает стартапы.

Графики роста прилагаю.

Отчеты о проделанной работе превосходны.

Время выполнения потрясающее.

Перспективы кажутся впечатляющими.

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

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

Все проблемы коричневой фазы остаются за покупателем, а компания, продавшая стартап, чувствует все прелести и оптимизм зеленой фазы.

Решение, конечно, оригинальное, но явно не единственное.

Есть Microsoft, Apple, Oracle, которые знают, как преодолеть эти проблемы роста.

Как они это делают? Каковы методы сохранения зеленых насаждений? Предлагаю вам написать свой ответ в комментариях.

Я также изложу свои мысли.

Спасибо за ваши Коментарии.

Теги: #разработка #разработка сайтов

Вместе с данным постом часто просматривают: