Что считать прототипом или моделью, а что – готовым продуктом? Что считать велосипедом, а что – платформой? Какой из этих подходов более правильный?… На эти и многие другие вопросы ответы можно найти в обсуждениях ниже.
ПРЕДЫСТОРИЯ. Мы с Олегом (Oleganza //vkontakte.ru/id7146) в оффлайне, похоже, не смогли придти к единому мнению. И как раз этот вопрос всплыл в теме //vkontakte.ru/board.php?act=topic&tid=2277….
СОДЕРЖАНИЕ. Моя точка зрения заключается в том, что существует два подхода к созданию ПО – "протоип" и "платформа". Рассмотрим сначала сами подходы, их преимущества и недостатки, затем постараемся понять, какая модель и где применима. На "закуску" горяченькое – несколько слов о языках программирования и программистов.
ПОДХОДЫ. Итак, вот эти подходы.
1. "Прототип".
Когда что-то надо сделать в сжатые сроки, продемонстрировать заказчику свои умения, показать образец продукта, работающий с ограничениями – используется подход "прототип". Прототип создаётся в сжатые сроки, ударными темпами. Как следствие – многие моменты проектирования и разработки ускользают от инженера. Задача ведь проста и понятна – получить работающий образец ПО.
Особенности (следствия экономии времени):
- документация отсутствует
- проектирование либо не производится либо производится в черне (это экономит время на написание требований, описание интерфейсов и прочее – до 30% времени)
- отсутствуют чётко определённые интерфейсы (поскольку отсутствует заранее разработаный проект)
- стандарты либо не поддерживаются, либо подерживаются частично (реализация стандартов обычно довольно сложна и порой требует до 80-90% времени)
- не всегда соблюдается структурность кода (по Дейкстре) (так как это экономит несколько минут
- много "велосипедов" (экономит время на поддержку стандартов существующих систем)
- чаще всего один разработчик (так как многое держиться в голове, а срок ввода ещё одного разработчика в курс дела велик)
- тестирование упрощено (экономим до 50% суммарного времени)
Плюсы:
- малое время разработки (следствие всего вышеперечисленного)
Минусы:
- сложность модификации (из-за велосипедов, хаков, дыр в стандарте, отсутствия документации, порой отсутствие структурности и проч.)
- периодически выявляются трудноустранимые ошибки (следствие хаков)
- необходима постоянная техническая поддержка (следствие упрощённого тестирования)
- часто используются хаки
- как правило, неработоспособность даже при незначительных изменениях конфигурации окружения (следствие хаков, отказа от стандартов)
- невозможность разработки ресурсоёмких проектов (следствие долгого введения новых разработчиков в курс, часто – невозможности параллельной работы из-за кода в виде фарша или одного куска)
- невозможность параллельной разработки (следствие постоянно меняющегося кода)
2. "Платформа"
Термин "платформа" здесь используется в широком смысле – любое ПО, обладающее приведёнными ниже особенностями. В это понятие я вкладываю смысл "ПО, простое в развитии и модификации". В некотором смысле "платформа" – это синоним "продукта". Платформа разрабатывается основательно, трудозатраты определены и сроки не поджимают либо их можно продлить, ограничивая функциональность платформы.
Особенности:
- пристуствует документация
- присутствует этап проектирования и моделирования (возможно, с созданием прототипа)
- все интерфейсы чётко определены
- стандарты поддерживаются в полном объёме
- структурность кода (следствие проектирования и моделирования)
- используются существующие системы (как следствие наличия ресурсов на поддержку стандарта системы) (вместо разработки велосипедов)
- обычно много разработчиков
- полнофункциональное тестирование
Плюсы:
- простота дальнейшей модификации
- практически отсутствие трудноустранимых ошибок
- минимальная техническая поддержка (следствие полнофункционального
4 марта 2008 в 23:00
Странный какой-то вопрос: "Что лучше черновик или конечный продукт?" Смотря для чего. Если нужно оценить состоятельность какого-то технического решения, то можно быстренько наваять черновик, не сильно заботясь об удобстве интерфейса и стройности внутренней структуры. Если коммерческий продукт под заказчика, то и документация, и тестирование, и проектирование должны быть.
4 марта 2008 в 22:05
Тема действительно пространная. Олегу, по поводу "проще". Вот, к примеру, у вас есть замечательные люди, они используют супер-инструменты, а задача в срок не решается – что делать? Заменить людей, инструменты, задачу или срок?Тут кроме людей, инструментов, задачи и срока имеется кое-что, скрывающееся за словом "задача", а именно её постановка или "требования". Это действительно пространная тема, потому что некоторые считают, что 90% успеха проекта обуславливает именно правильная работа с требованиями. И я склонен думать так же. Хотя, конечно, нельзя забывать про людей. Именно правильные люди будут правильно это делать. А процессы и инструменты – второстепенны.
4 марта 2008 в 12:03
[Олег], не может быть, ты прочитал все сообщения?!
Хотя, если бы прочитал, не утверждал бы о пространности темы.
Здась как раз и обсуждается, как решать некую задачу за некоторый срок, имея инструменты и людей. И выделяется два глобальных подхода – прототип и платформа. Оба подхода позволяют решить задачу, и оба они – антагонисты в некотором роде (либо второй вытекает из первого). Так что либо предложи свою классификацию (не обязательно описывать, достаточно намекнуть, что имеешь в виду), либо дополни тему полезным постом… как там у тебя в правилах – посты, не относящиеся к теме, удаляются?
Впрочем, я понимаю, почему ты так рассуждаешь. С твоей точки зрения (как сторонника прототипов) достаточно лишь иметь ресурсы, продукт (а иже с ним и план) сам собой образуется =) Так?
3 марта 2008 в 12:01
Тема очень пространная. Как правило, все гораздо проще: есть набор инструментов, люди, которые им пользуются, и нужно решить некоторую задачу в некоторый срок.
3 марта 2008 в 12:00
[Глеб], фраза "потому что фактически в начале проекта у тебя нет к ней никаких технических требований" объясняет причину твоих неудач. Насчёт меняющихся требований (да и требований вообще) почитай-ка Спольского, чтоб мне не повторяться лишний раз – //russian.joelonsoftware.com/PainlessSpecs/1.html. У меня как раз одним из первых пунктиков стоит документация, в которой, естественно, на первом месте находятся требования. Как получить требования? – либо детально рассмотреть задачу (включая возможные расширения – твоя же фраза "Сначала надо поиграться с прикладной задачей"), если сразу не получается – то написать модель (прототип). А вообще, мысль о сложности проектирования интерфейсов справедлива – и решение тут только одно: опыт и расширяемые интерфейсы. Из простейших примеров – введение передачи ссылки на любой объект в каллбаках (н-р void* для С++). Олег, думаю, ты здесь ты припоминаешь пример из Оперы =) Как сказал Страустрап, "проектирование библиотек – дело не простое". Но не невозможное, добавим мы. Ну и по поводу DirectDraw. В восьмой версии ничто не мешает (более того, если повнимательнее посмотреть документацию, то даже разрешает и настаивает =) использовать DirectDraw7. Microsoft велик тем, что поддерживает старые интерфейсы столько, сколько это возможно, и DirectX – самый наглядный пример. Написаные мной ещё в 98-99 годах приложения DirectX 5 (для Windows 98, кстати) успешно работают на Windows Vista DirectX 10 (или какой он там =), то есть спустя 10 (!) лет.
[Антон], паттерны проектирования почти не имеют отношения к рассматриваемой теме, или нет?
А вот насчёт рефакторинга – это один из верных путей превращения модели в платформу. Кстати, я опустил этот путь из рассмотрения. Жду дальнейших мыслей =)
[Олег], ты лучше выскажись по теме =) О том, что ты не любишь С++ но любишь Руби, мы все знаем… лучше покажи нам на примере, благодаря чему Руби позволяет создавать платформы эффективней, чем С++? Иначе твои высказывания голословны =(
[Дмитрий], 100% согласен =))))
3 марта 2008 в 12:00
Да, [Жека], с тобой тоже согласен, как и с Дмитрием =)
1 марта 2008 в 11:04
Даже на этапе разработки прототипа часто можно понять или хотя бы "жопой почуять", где понадобится общность, или по крайней мере – где она допустима без существенного увеличения сложности, и почти нулевыми (или даже отрицательными) усилиями добавить щепотку абстракции. После этого превращение прототипа в платформу становится инкрементальным, легким и приятным.
Боюсь показаться банальным, но – SICP rules
1 марта 2008 в 11:04
С другой стороны, алгоритмические вещи я обычно пишу быстро и влоб, безо всякого намека на общность, и только потом начинаю ее выделять – тут нюха нехватает, все равно придется перекроить все заново несколько раз, и до тех пор пока не появятся результаты исследований, не имеет смысла даже пытаться что-то абстрагировать – нужен максимально тонкий контроль над каждой деталью, а общность может этому помешать.
1 марта 2008 в 3:03
Считаю прототип просто одним из способов выявления требований. Причём, в том виде, в котором он описан ("на выброс") – достаточно дорогим способом. Часто простая раскадровка и интервью даютнормальную почву для полноценной первой версии, а времени занимают в 10 раз меньше. Хотя, если заказчику кровь из носу нужно сразу понажимать кнопочки – тут не отвертеться, факт.
По поводу этапности и прочего. В моей практике документация, стандарты, проектирование, тестирование, модифицируемость – всё это не присутствует полностью в продукте или в планах на него сразу, всё это постепенно и итеративно добавляется сообразно целям очередного шажка. Agile – неплохая идея, не так ли? Поэтому вот это перечисление, что там все четко определено, супер-пупер тестирование и сплошное следование стандартам в подходе "платформа" – это все тоже утопия в каждый конкретный момент времени.
Резюме. Эти "два разных подхода" -просто ВОЗМОЖНЫЕ этапы жизненного цикла одного и того же проекта.
Мои ответы на вопросы:
– прототипом считать слепленный на скорую руку софт, не удовлетворяющий всем нуждам пользователей, а чисто иллюстративный;
– модель – это модель, это как правило, вообще не софт;
– готовый продукт – тот, который в основном покрывает набор пользовательскитх нужд;
– велосипедом считать велосипед. Один мой знакомый изобрел индекс в БД -чистейшей воды "велосипед", так как, похоже, индекс уже изобрели до него
- платформа в том виде, в котором она описана – это, как правило, библиотека, живущая от проекта к проекту, элемент стратегии разработчика.
29 февраля 2008 в 19:05
Нужен пункт "…а получается все равно как обычно" =)
29 февраля 2008 в 19:05
Нужно писать на таких языках, где соотношение качество/время максимальное. Лисп или руби, к примеру. И далее по обстановке.
29 февраля 2008 в 19:03
Я так понимаю разница модель и платформав том, что платформа позволяет написать базу для всего, что на ней будеть писаться в дальнейшем.Хотя без грамотной архитектуры любой софт со временем превращается в монстра на несколько мегов исходного кода.Куда уж лучше модульная система с плагинами, когда есть небольшое ядро и куча плагинов для него, реализующих тот или иной функционал.
29 февраля 2008 в 18:02
Я пока довольствуюсь паттернами проектирования и рефакторингом
29 февраля 2008 в 17:02
Очень трудно сразу хорошо спроектировать платформу (чтобы ей было удобно пользоваться, она была универсальной, безглючной и масштабируемой или, по крайней мере, легко модифицируемой), потому что фактически в начале проекта у тебя нет к ней никаких технических требований. Заказчик выдвигает только требования к прикладному софту, которые часто меняются по ходу разработки. Из них вытекают требования к платформе, но нужно время, чтобы ты мог эти требования осознать и сформулировать. Сначала надо поиграться с прикладной задачей. Не факт, что с первого раза получится удачная платформа (посмотри, сколько у Microsoft версий DirectX, все разные. В седьмом усовершенствовали DirectDraw, в восьмом выкинули его совсем).
Вот какие-то такие мысли. А голосовать в опросе я не стал. Нету кнопки "Против всех":)
29 февраля 2008 в 17:00
У меня было увлечение "платформами", в том смысле, что я каждую софтину пытался сделать модульной, универсальной и расширяемой. В этом очень легко увязнуть и отклониться от решаемой задачи.
Типо: надо было написать программулину, которая проводила кое-какие статистические анализы и преобразования над двумерными сигналами. Я сказал: давайте добавим туда командную строку, как в автокаде, и скриптовый язык, чтобы преобразования можно было задавать не сходя с места. В итоге провозился с ней полгода и нихрена хорошего не написал. Тогда решил всё переделать: настрогал простенький механизм, чтобы можно было прицеплять к программе DLLки, в которых находятся процедуры необходимых преобразований. Они получали указатели на внутренние объекты программы и с ними уже работали. Таким макаром была сделана бинаризация сигнала по заданному порогу и ещё какая-то хрень. Потом оказалось, что интерфейс работает одновременно только с одним сигналом, а надо было реализовать алгоритм сравнения нескольких. Получилась двойная работа: на каждое требование приходилось не только плагин писать, а ещё и платформу доделывать. Когда всё это приняло мало-мало удобоваримый вид, задача уже потеряла актуальность.
Ещё пример: надо было сделать простенькую прогу, которая искала входимость детале-сборочных единиц в различные производственные заказы. Я сказал: а давайте прибабахаем туда COM-интерфейс, чтобы можно было скриптовать это дело прямо из VBA. Внутреннюю иерархию объектов я изначально спроектировал неудачно, в итоге получилась куча взаимосвязанных COM-интерфейсов, которыми было неудобно пользоваться, а любая доработка или хотя бы анализ того, что происходит в проге, тонула в море COM-специфичного кода. Тогда я плюнул на платформу и буквально за два дня с нуля закодил всё как надо. Работать с деревом ДСЕ из Ексела уже не получится, но по крайней мере поставленная задача выполнена чётко.
Третий пример. Писали простенькую специализированную учётную систему (учёт компьютеров и оргтехники), не стали брать готовую платформу типа 1С, стали делать всё на PHP + MySQL. Я просто писал прогу, исходя из потребного функционала, по мере возможности делал редизайн (выделял одинаковые куски, складывал их в библиотеку), получался прототип, на основе которого плавно вырастала платформа. Всё было хорошо до тех пор, пока мной не овладели глобальные мысли о жизненном цикле абстрактных объектов, управляемом документами. Ещё мне не понравился механизм событий, который там получился, и ещё в одном месте образовался кусок, который не был повторно входимым, а это было надо. И я решил редизайнить платформу. Короче, воз и ныне там (проект заморожен, оргтехника у нас учитывается ручками в Екселе).
29 февраля 2008 в 17:00
Я вот что хочу сказать. Выделенные тобой преимущества платформы, как то:
- простота дальнейшей модификации
- практически отсутствие трудноустранимых ошибок
- минимальная техническая поддержка
являются преимуществами вовсе не платформы как таковой, а хорошо поставленной задачи и хорошо спроектированной проги. В то же время выделенные тобой недостатки прототипа:
- сложность модификации
- периодически выявляются трудноустранимые ошибки
и прочее в той же мере (и даже чуть более) присущи и плохо спроектированным платформам.