Этапы развития программного проекта
августа 3, 2011 | Published in Development Processes, Уголок философа | 7 Comments
Сейчас я разрабатываю собственную CMS на Ruby on Rails и поскольку у меня не много опыта решения задач касательно архитектуры приложения, да и разработки в целом, я сталкиваюсь с множеством вопросов касательно организации архитектуры приложения. В игру вновь вступает вредный перфекционизм, который вновь и вновь растягивает время разработки. Наконец-то собравшись с мыслями я сформулировал для себя жесткие правила процесса разработки.
1. Делай чтобы хоть как-то работало!
Если проект работает хоть как-то — это уже лучше, чем когда его совсем нету. Множество ошибок, неправильная архитектура, множество различных хаков, множество повторяющихся фрагментов кода, множества непроизводительного кода и т.д. — все это лучше, чем когда вообще ничего нет!
2. Делай чтобы это работало правильно!
Мы берем наш говнокод (да, для этого не только PHP годится) и делаем из него конфетокод (аналогия со «следать из говна конфектку»). Наш код уже умеет что-то делать, но делает это неправильно, не эффективно, и т.д. Имеющийся функционал мы проверяем на наличие ошибок и исправляем их. Свои велосипеды по возможности заменяем на сторонний код, сторонник код при необходимости на свои велосипеды. Итак, когда все матчеры и/или ассеты выводят надписи зеленым, что означает «very good» мы переходим к следующему этапу.
3. Делай чтобы все работало красиво!
Мы имеем корректно работающее приложение, однако правильная работа, хоть и является основным условием успеха разработки, не является его единственным условием. Мы имеем код который уже возвращает 2+2=4, а не 5, но который является говнокодом. Говнокод — понятие растяжимое, для меня говнокод, это то, что сейчас пишу я, все, что написано на PHP, Delphi и 1C (хотя с точки зрения синтаксиса, философии этих языков код может быть великолепен, им далеко по элегантности до Ruby), все, что можно обвинить в over-enginiring’е, и т.д. На данной стадии необходимо взять код и написать его красиво, что называется отрефакторить.
Кстати, не знаю, писал я или нет, но существует т.н. «правило 3й версии» согласно которому программный продукт становится более-менее готовым для использования только после выпуска третьей мажорной версии, это означает, что разработчики более-менее поправили проект, нашли более-менее совершенное архитектурное решение, исправили множество ошибок и т.д.
4. Делай чтобы работало быстро!
Когда код работает и выглядит очень хорошо, может возникнуть новая проблема (если не возникла ранее) — код работает недостаточно быстро, или хотелось бы, чтобы код работал быстрее. В этом случае можно отделаться мелкими исправлениями, а можно полностью пересмотреть всю архитектуру проекта. Это зависит только от того, какой прирост производительности нужен и кроется ли низкая производительность в архитектуре проекта. В случае с CMS производительность не так важна, ведь ориентироваться она будет на сайты посещаемостью не боле 5000 в сутки, с чем Ruby on Rails успешно справится на слабеньком VDS за $15-25, особенно если использовать кэширование, но даже при более высоких нагрузках, как на крупных новостных сайтах с 100000-300000 посетителями в сутки, проблему можно решить не прибегая к большим оптимизациям кода, а просто докупить серверов, что при такой большой аудитории не составит проблемы в финансовом плане. Лично мой блог отлично справляется с более-менее равномерной нагрузкой в <= 350 пользователей и <= 1100 просмотров при том, что находится на самом дешевом тарифном плане «Джет» предоставляемым компанией Locum, кроме того, он спокойно пережил 2 небольших хабра-эфекта в 1800 и 2100 посетителей и что-то ок 7-8 тыс. просмотров.
Есть предложения о том как улучшить процесс разработки -следуйте в комментарии!
Лучшая благодарность автору — ваши комментарии!
августа 3, 2011 at 07:06 (#)
Есть такой товарищ, которого зовут Гради Буч. Он написал книгу «Объектно-ориентированный анализ и проектирование». Так вот, согласно этой книге надо применять дуолистический подход при проектировании программных продуктов — алгоритмический и объектно-ориентированный. И этот подход разительно отличается от написанного выше.
Объясняю. Эти четыре пункта, предложенные тобой соответствуют типичному плану написания книги рядового графомана — писать по наитию и не задумываясь. Когда как настоящий писатель сначала составляет план произведения: определяет действующих персонажей, сюжетные ходы и определяет какие цели первые достигнут с помощью второго. Ну и получается с одной стороны легион бездарей, с другой такие как Толкиен. Так что предложенный план о четырёх пунктах хорош только если внести коррективы — после каждого пункта необходимо проанализировать сделанное, удалить всё написанное и каждый новый пункт писать заново.
Это долго, нудно и не практично. Лучше с самого начала определить что же будет уметь делать CMS и из чего она будет состоять. Это и должно быть первым пунктом. Всегда. И лучше будет если этот пункт будет сопровождаться различными записями, пометками, UML диаграмамми, картами памяти и т.д. Вторым пунктом — реализация минимума из всего того, что понавыдумывалось в первом пункте. Согласись — идеально рабочий минимум это намного лучше, чем хрен знает как работающий максимум. Третий пункт — реализация остального задуманного. Мы ведь в первом пункте так хорошо спроектировали, что внесение новых функций в CMS практически не затронет то, что мы написали во втором. Благодаря этому на выходе третьего пункта получится нечто очень похожее на задуманную CMS, состоящую из набора максимально независимых друг от друга модулей, что в четвёртом пункте существенно облегчит отладку каждой части. Пятый пункт — пишем документацию и пускаем в свободное плавание. Потом читаем книги «Рефакторинг» и «чистый код» и до конца своей жизни (вернее пока не надоест) можно применять полученные знания приводя код CMS к совершенству.
августа 3, 2011 at 07:28 (#)
guest, кое в чем с вами можно согласиться, но не во всем. Например, я считаю невозможным планирование приблеженной к совершенной архитектуры программного проекта на первых парах разработки, если бы это было возможно, люди бы сразу изобрели космолеты и не парились бы с лошадьми. Так же и шахматист не может не начав игру придумать идеальную комбинацию ходов, он действует по обстоятельствам продумывае ограниченное количество ходов, тем не менее имеет некоторую общую, формальную стратегию захвата центра доски, защиты флангов и т.д. Так же и при разработке программного проекта первые версии реализую сам функционал, а последующие обеспечивают этому функционалу более выгодную архитектуру, добавление новый возможностей, оптимизацию производительности, повышение читабельности кода в том числе его документирование. Кроме того, документация как мне кажется не относится к процессу разработки, кроме того, ее не следует выносить в отдельный пункт так как ее создание, по моему мнению, должно сопутствовать весь процесс разработки, добавлен новый функционал — комментарий к нему, сделан рефакторинг — необходимо отредактировать комментарий принадлежавший старому коду.
августа 3, 2011 at 08:37 (#)
>>если бы это было возможно, люди бы сразу изобрели космолеты и не парились бы с лошадьми.
Справедливости ради стоит отметить, что человечество до сих пор пользуется услугами лошадей :) Но в целом пример не совсем удачный. Хотя бы потому, что «строительство космолётов» — это не самостоятельная дисциплина, а совокупность разных инженерных направлений. Начиная от материаловедения и заканчивая кибернетикой. И развитие космолётостроения напрямую зависит от развития каждой из отдельных дисциплин. Поэтому в древности и не было возможности летать в космос. Понимание этого приводит к простому выводу — проектирование архитектуры эфемерного продукта действительно нереальная задача. Если дальше мучить пример с космолётами, то можно заметить, что космотлёты ведь не строят по наитию. Каждый комолёт проектируется сотнями и сотнями людей, каждая часть проекта проходит мнлжество инстанций, требует согласования смежных разработчиков. И пока не будет готового и согласованного проекта к строительству космолёта не приступают. Но почему же космолётостроители могут сначала спроектировать, а потом строить, а разработчик CMS нет? Ведь космолёт штука куда более сложная. Ответ простой — перед
разработчиками стоят конкретные цели и определены конкретные требования. Скажем нужно построить транспортный космолёт, который может перевозить три тысячи тонн груза и способный работать в атмосфере юпитера. Собственно есть цели и определены ли требования к разрабатываемой CMS? Если цель сздать ради процесса создания, то тогда да, ни о каких методологиях и речи не может быть.
>>шахматист не может не начав игру придумать идеальную комбинацию ходов
Пример с шахматистом тоже не совсем удачный, но тем не менее весьма показательный. Неудачный он просто потому, что шахматист выступает против хаотической и системы в виде другого шахматиста. В разработке ПО такой системы нет. А показательный он потому, что хорошо характеризует различность понимания идеальности системы. Идеальных систем не бывает, это должно быть понятно. Идеал сам по себе подразумевает не достижимость, а стремление к достижимости. Но если рассматривать конкретные вопросы и методы их достижения, то среди методов можно выделить те, которые можно назвать идеальными. Так почему бы не назвать идеальной последовательность ходов для захвата центра доски? В общем это ещё раз говорит о том, что необходимо выделить цели и требования.
>>Так же и при разработке программного проекта
Исходя из вышеизложенного получается, что совсем не так же.
>>документация как мне кажется не относится к процессу разработки
Последним пунктом в любой методологии циклов разработки стоит сопровождение написанной программы. Документация — это часть этого сопровождения. И да, имеется в виду не документация кода, а готового продукта, т.е. юзермануал, различные туториалы и прочее.
августа 3, 2011 at 08:39 (#)
ОМГ, чего-то комментарий так расплющило о_О
августа 3, 2011 at 12:17 (#)
Форматирование поправил, у меня так тоже было, когда копирую текст другого комментария.
Честно говоря в методологиях я слаб, не знал, что создание документации именно в виде туториалов, гайдов и т.д. является частью чыкла разработки, тем не менее считаю создание документации обязательным. Не смотря на это я описывал не так цикл всея разработки, как конкретно ту его часть, что связана непосредственно с написанием самого кода.
августа 4, 2011 at 16:16 (#)
А я придерживаюсь мнения автора! Во-первых: не все такие умные, это факт!)
Во-вторых: лучше уж написать кривой косой, но работающий код. Если уж совсем не нравится, учесть все ошибки/затруднения и переписать заново. Прокачиваем не только скилл, но и опыт :)
P.S Все идеальное — скучное
августа 8, 2011 at 09:46 (#)
IMXO: следует комбинировать мнение автора и пользователя «guest».
Начинающие программисты ОБЯЗАНЫ попытаться продумать архитектуру. Это пункт 0. При этом следует заранее определить лимит времени, который выделяется для п.0 (например, до часа для лабораторки, до 8ми часов для курсовой, неделя для дипломной и т.д.) Не получилось уложиться во временные рамки — значит не доросли, переходим к гомнокоду. В результате получаем компромисс между профессиональной разработкой и своими возможностями. Когда-то наступит счастливый переломный момент.