Наавнокодить прототип

Довольно часто встречаю такой подход к разработке:
Вместо четкой разработки и проектирования ТЗ на бумаге, быстро левой ногой авнокодится прототип, примерно за 10% времени разработки, который показывается заказчику. Далее, на основе прототипа, уже разрабатывается рабочая версия.

Насколько такой подход уместен?

Какой основной недостаток вижу: Заказчик может подумать что это и есть рабочее приложение и внедрит у себя прототип, вместо дальнейшей разработки. Хотя это открывает возможности бесконечной поддержки, так как бизнес уже завязан на ПО, а кроме автора там никто ничего с этим не сможет сделать.

Основное преимущество — можно откатать хотелки заказчика так сказать в-коде. В результате уже можно строить архитектуру, которая идеально ложится под проект, а не наоборот.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

История про успешного Васю овнокодера с распухшим банковским счётом и голодного архитектора это вообще байки из склепа и цукерберг позвонит.

Архитектура которая не работает сразу это не архитектура, а овнокод.

Если не обманывать заказчика то невозможно навонокодить прототип. Максимум можно сделать набросок уя и демонстрируя этот уй постоянно повторять «тут будет город сад» сгорая от стыда и молясь чтобы он не нажал не ту кнопку.

Хотелось бы уточнить, вы сейчас все еще безработный?

Дайте-ка угадаю — А вы всё ещё СЕО?

Ну тогда ответ в стиле «Цукерберг позвонит» сами додумаете.

Когда я вижу СЕО с такой манерой общения я теряю веру в справедливость. Тысяча чертей!

Да что же это такое, каждый второй считает, что СЕО должен быть душой компании, вежлив, галантен и привлекателен -(

Я надеялся хотябы на чёткое изложение своих мыслей.

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

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

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

Мне всё равно. Нужно было переключиться немного от безработья. Тут вы со своим эго размером с ваш багтреккер. Ну и понеслась.

www.agilemanifesto.org/...principles.html — принципы гибкой методологии разработки ПО.
Или вот более детально ru.wikipedia.org/...огия_разработки

Прототип — это, по большому счету [походу], потеряное время или показатель бестолковости команды/абстракции ТЗ, что подразумевает большую начальную неопределенность и необходимость подбирать варианты вместо старта в четко определенном направлении. Лучше эти «неопределенные» вопросы решить _до_ начала работы, чем тратить ресурсы (возрастающие экспоненциально) на исправление курса проекта, вот почему agile — это в половине случаев яркий epic fail менеджеров, которые теперь зная это слово могут переложить свой очередной f*ckup на команду.
Пожалуй, прототип удобно использовать в начале сотрудничества для завязывания доверительно-профессиональных отношений.

а если заказчик хочит PoC. ну во просто не верит, что то, что вы ему предлагаете может существовать и работать хоть как-то?

прототип в любом случае должен работать, иначе в нем нет смысла

Далеко не всегда возможно решить все неопределенности в продукте до начала разработки. И это более, чем нормально — пересматривать план по ходу дела, отталкиваясь от полученых результатов, восприятия юзерами и т.п.
И вообще значимость MVP (minimum valuable product), тот же прототип по сути, для компании намного выше, чем гора бумажек описывающих сферического коня. Потому что с прототипом можно и к пользователям и к инвесторам идти за отзывами на основе которых можно понять надо ли оно кому то в таком виде, а бумажками только на ночь зачитываться.

есть еще такая беда с прототипами: если через 10% времени показать прототип, заказчика будет ой как сложно убедить, что для завершения надо еще год времени и чемодан денег.

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

Ну так дать ему прототип и вечно держать на поддержке.

Поддержка для заказчика — это «деньги на ветер». 99% думает, что все должно работать сразу, вечно и дорабатываться бесплатно по истечении любого периода после сдачи проекта.

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

Вася и Петя одновременно начали писать один и тот же продукт (софт, программу на продажу).

Вася был «ориентирован на результат» и начал сразу писать говнокод не продумав толком архитектуру.

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

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

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

У Пети было вылизанное никому не известное приложение, минус на банковском счёте и ни одного клиента.

Маэстро! Кста — вроде видел тебя в ПУМБе не так давно.

да я тож, походу мы килограм по 20 набрали.

Все более чем верно! Жаль что только не про прототипы ;)

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

Да, и я не помню, кто автор исходного текста, но, возможно и не Евгений Чечель. Как бы не Cartmendum.

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

Ну и вопрос. оО
Если нужен прототип — подход уместен. Если он не нужен — не уместен.

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

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

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

По идее то да, но часто нет времени/денег, а давай какнибуть докрутим/допилим, бо клиенты ждут им срочно надо, итд.
Еще раз:
1) Предполагалось отдавать клиенту этот результат, тогда — это не прототип, а аджайл.
2) Не предполагалось, тогда это не прототип, а про...б.

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

Эта разница в первую очередь в голове у девелопера.
2) Не предполагалось, тогда это не прототип, а про...б.

Ну это из той же оперы что и «менеджер не нужен».

Подход, имхо, очень уместен, если заказчик сам толком не знает чего хочет, а есть только набор идей-требований.
К сожелению, сколько-нибуть полезный прототип, в овер 99% случаев, тупо уходит на продакшн, а времени-денег на переписать тупо нету :-(

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

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

Для этого и придумали Agile чтобы хоть как то оправдать некомпетентность менеджмента ИТ компании и вытянуть как можно больше денег из заказчика: «нам так заказчик сказал (даже в случае если заказчик гонит абсолютную пургу) то вы (разработчики) тупо так и делайте, потом если денег еще дадут то все переделаем по правильному, а не дадут так и останется #авнокод и им же хуже в итоге будет». ;-)
P.S. Заказчик обычно далекий от ИТ ему можна простить, но менеджмент ИТ компании предварительно должен провести анализ процессов заказчика, построить модель, формализировать задачи, построить каркас ( еще вопрос кто это будет делать 23-х летний аналитик-менеджер-архитектор? ) и только потом браться за код но зачем это нужно? Если есть Agile и там можна под каждую хотелку заказчика начинать хоть с нуля писать код, потому что ну никак не лезет новая фишка в старую архитектуру разработанную в предыдущем спринте.

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

Нет ничего более постоянного чем временное решение ©

то есть у вас есть полноценная версия, которую нужно еще за 90% времени доводить до ума? Тут ИМХО два варианта. Или убогий непрофессионализм, т.к. более-менее объемную систему проще писать сразу начистую, или множественно нереализованных деталей, которые клиенту все равно понадабятся, вопрос только насколько ему это прозрачно.

В целом же развитие живой системы из прототипа — вполне разумный и в большинстве случаев правильный подход.

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

Вопрос прототипов поднимается в книжке «Психбольница в руках пациентов», там написано

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

Забыл добавить, что есть два случая:

— прототип всего большого проекта/продукта, тут нужно поаккуратнее, чтобы потом не копаться 10 лет в этом всем.

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

Можно придумать примеры

— написать прототип ДОУ на каком-нибудь Drupal или Joomla можно, но потом может оказаться, что этот прототип принесет больше геморроя чем пользы, так как этот весь код и данные потом сложно применить в других системах.

— jobs.dou.ua/salaries появилось как развитие небольшого виджета, который я сделал за несколько часов для статьи-зарплатного отчета, код там довольно сильно менялся, но скорее эволюционно, учитывая потребности и особенности всего проекта.

А если для себя решить, что вот возьмем, все хорошо продумаем, спланируем, качественно запрограммируем не спеша, все равно может выйти как на это картинке:
i.imgur.com/y1lvsbq.jpg
а потраченного времени и денег не вернуть.

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

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

Так вы будете 10 раз за 10 лет менять все по ходу и продвинетесь только на год вперед.
Есть проекты которые растут вширь с ними намного проще (аналог: построить одноэтажный котеджный городок), а с теми проектами которые растут в высоту (построить один но 1000 этажный небоскреб) здесь уже нужен очень хороший опыт и отличное понимание предметной области для создания таких систем.

да проблемка в том, что чтоб писать красиво нужно время, как у Карла Маркса: «извини,Фридрих, не было времени написать тебе по-коротче», а обычно ставятся требования чтоб фича Х, работала сегодня-завтра, а сегодня-завтра ее можно прицерить только ч-з задницу. А если говоришь, что там работы в Х2-Х3 раза больше, а потому ETA — 3 дня, то слышишь вопли типа «ю’ре булшиттинг ми......!!!»

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

Это не прототип,
это аджайл, детка!

Насколько такой подход уместен?

До первого судового иска на 100500 гига-денег, то есть практически всегда.

Подписаться на комментарии