singlepost

Прототипы или платформы (prototypes or platforms) << На главную или назад  

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

ПРЕДЫСТОРИЯ. Мы с Олегом (Oleganza http://vkontakte.ru/id7146) в оффлайне, похоже, не смогли придти к единому мнению. И как раз этот вопрос всплыл в теме http://vkontakte.ru/board.php?act=topic&tid=2277....

СОДЕРЖАНИЕ. Моя точка зрения заключается в том, что существует два подхода к созданию ПО - "протоип" и "платформа". Рассмотрим сначала сами подходы, их преимущества и недостатки, затем постараемся понять, какая модель и где применима. На "закуску" горяченькое - несколько слов о языках программирования и программистов.

ПОДХОДЫ. Итак, вот эти подходы.
1. "Прототип".
Когда что-то надо сделать в сжатые сроки, продемонстрировать заказчику свои умения, показать образец продукта, работающий с ограничениями - используется подход "прототип". Прототип создаётся в сжатые сроки, ударными темпами. Как следствие - многие моменты проектирования и разработки ускользают от инженера. Задача ведь проста и понятна - получить работающий образец ПО.

Особенности (следствия экономии времени):
- документация отсутствует
- проектирование либо не производится либо производится в черне (это экономит время на написание требований, описание интерфейсов и прочее - до 30% времени)
- отсутствуют чётко определённые интерфейсы (поскольку отсутствует заранее разработаный проект)
- стандарты либо не поддерживаются, либо подерживаются частично (реализация стандартов обычно довольно сложна и порой требует до 80-90% времени)
- не всегда соблюдается структурность кода (по Дейкстре) (так как это экономит несколько минут
- много "велосипедов" (экономит время на поддержку стандартов существующих систем)
- чаще всего один разработчик (так как многое держиться в голове, а срок ввода ещё одного разработчика в курс дела велик)
- тестирование упрощено (экономим до 50% суммарного времени)

Плюсы:
- малое время разработки (следствие всего вышеперечисленного)

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

2. "Платформа"
Термин "платформа" здесь используется в широком смысле - любое ПО, обладающее приведёнными ниже особенностями. В это понятие я вкладываю смысл "ПО, простое в развитии и модификации". В некотором смысле "платформа" - это синоним "продукта". Платформа разрабатывается основательно, трудозатраты определены и сроки не поджимают либо их можно продлить, ограничивая функциональность платформы.

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

Плюсы:
- простота дальнейшей модификации
- практически отсутствие трудноустранимых ошибок
- минимальная техническая поддержка (следствие полнофункционального

44 ответов в теме “Прототипы или платформы (prototypes or platforms)”

Страницы: [1] 2 »

  1. 1
    Глеб Раздолбаев ответил:

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

    Типо: надо было написать программулину, которая проводила кое-какие статистические анализы и преобразования над двумерными сигналами. Я сказал: давайте добавим туда командную строку, как в автокаде, и скриптовый язык, чтобы преобразования можно было задавать не сходя с места. В итоге провозился с ней полгода и нихрена хорошего не написал. Тогда решил всё переделать: настрогал простенький механизм, чтобы можно было прицеплять к программе DLLки, в которых находятся процедуры необходимых преобразований. Они получали указатели на внутренние объекты программы и с ними уже работали. Таким макаром была сделана бинаризация сигнала по заданному порогу и ещё какая-то хрень. Потом оказалось, что интерфейс работает одновременно только с одним сигналом, а надо было реализовать алгоритм сравнения нескольких. Получилась двойная работа: на каждое требование приходилось не только плагин писать, а ещё и платформу доделывать. Когда всё это приняло мало-мало удобоваримый вид, задача уже потеряла актуальность.

    Ещё пример: надо было сделать простенькую прогу, которая искала входимость детале-сборочных единиц в различные производственные заказы. Я сказал: а давайте прибабахаем туда COM-интерфейс, чтобы можно было скриптовать это дело прямо из VBA. Внутреннюю иерархию объектов я изначально спроектировал неудачно, в итоге получилась куча взаимосвязанных COM-интерфейсов, которыми было неудобно пользоваться, а любая доработка или хотя бы анализ того, что происходит в проге, тонула в море COM-специфичного кода. Тогда я плюнул на платформу и буквально за два дня с нуля закодил всё как надо. Работать с деревом ДСЕ из Ексела уже не получится, но по крайней мере поставленная задача выполнена чётко.

    Третий пример. Писали простенькую специализированную учётную систему (учёт компьютеров и оргтехники), не стали брать готовую платформу типа 1С, стали делать всё на PHP + MySQL. Я просто писал прогу, исходя из потребного функционала, по мере возможности делал редизайн (выделял одинаковые куски, складывал их в библиотеку), получался прототип, на основе которого плавно вырастала платформа. Всё было хорошо до тех пор, пока мной не овладели глобальные мысли о жизненном цикле абстрактных объектов, управляемом документами. Ещё мне не понравился механизм событий, который там получился, и ещё в одном месте образовался кусок, который не был повторно входимым, а это было надо. И я решил редизайнить платформу. Короче, воз и ныне там (проект заморожен, оргтехника у нас учитывается ручками в Екселе).

  2. 2
    Глеб Раздолбаев ответил:

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

  3. 3
    Глеб Раздолбаев ответил:

    Очень трудно сразу хорошо спроектировать платформу (чтобы ей было удобно пользоваться, она была универсальной, безглючной и масштабируемой или, по крайней мере, легко модифицируемой), потому что фактически в начале проекта у тебя нет к ней никаких технических требований. Заказчик выдвигает только требования к прикладному софту, которые часто меняются по ходу разработки. Из них вытекают требования к платформе, но нужно время, чтобы ты мог эти требования осознать и сформулировать. Сначала надо поиграться с прикладной задачей. Не факт, что с первого раза получится удачная платформа (посмотри, сколько у Microsoft версий DirectX, все разные. В седьмом усовершенствовали DirectDraw, в восьмом выкинули его совсем).

    Вот какие-то такие мысли. А голосовать в опросе я не стал. Нету кнопки "Против всех":)

  4. 4
    Антон Непомнящих ответил:

    Я пока довольствуюсь паттернами проектирования и рефакторингом :)

  5. 5
    Дмитрий Щёголев ответил:

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

  6. 6
    Олег Андреев ответил:

    Нужен пункт "…а получается все равно как обычно" =)

  7. 7
    Олег Андреев ответил:

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

  8. 8
    Дмитрий Гайдамович ответил:

    Считаю прототип просто одним из способов выявления требований. Причём, в том виде, в котором он описан ("на выброс") – достаточно дорогим способом. Часто простая раскадровка и интервью даютнормальную почву для полноценной первой версии, а времени занимают в 10 раз меньше. Хотя, если заказчику кровь из носу нужно сразу понажимать кнопочки – тут не отвертеться, факт.

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

    Резюме. Эти "два разных подхода" -просто ВОЗМОЖНЫЕ этапы жизненного цикла одного и того же проекта.

    Мои ответы на вопросы:
    – прототипом считать слепленный на скорую руку софт, не удовлетворяющий всем нуждам пользователей, а чисто иллюстративный;
    – модель – это модель, это как правило, вообще не софт;
    – готовый продукт – тот, который в основном покрывает набор пользовательскитх нужд;
    – велосипедом считать велосипед. Один мой знакомый изобрел индекс в БД -чистейшей воды "велосипед", так как, похоже, индекс уже изобрели до него
    - платформа в том виде, в котором она описана – это, как правило, библиотека, живущая от проекта к проекту, элемент стратегии разработчика.

  9. 9
    Жека Кирпичев ответил:

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

    Боюсь показаться банальным, но – SICP rules :)

  10. 10
    Жека Кирпичев ответил:

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

Страницы: [1] 2 »

Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.