Розробка · 3 березня 2013, 17:57 1635

Alexandr Gavriluk, .Net developer в Aspose

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

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

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

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

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

Теми: розробка

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Ctrl + Enter

Ctrl + Enter

anonymous 05.03.2013 08:53

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

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

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

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

Відповісти

Підтримати

Oleksandr Kholodov CEO в Yalantis 05.03.2013 09:08

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

Відповісти

Підтримати

anonymous 05.03.2013 10:56

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

Відповісти

Підтримати

Oleksandr Kholodov

Oleksandr Kholodov CEO в Yalantis 05.03.2013 10:56

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

Відповісти

Підтримати

anonymous 05.03.2013 11:03

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

Відповісти

Підтримати

Oleksandr Kholodov

Oleksandr Kholodov CEO в Yalantis 05.03.2013 11:05

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

Відповісти

Підтримати

anonymous 05.03.2013 11:07

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

Відповісти

Підтримати

Oleksandr Kholodov

Oleksandr Kholodov CEO в Yalantis 05.03.2013 11:09

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

Відповісти

Підтримати

anonymous 05.03.2013 11:21

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

Відповісти

Підтримати

Oleksandr Kholodov

Oleksandr Kholodov CEO в Yalantis 05.03.2013 11:22

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

Відповісти

Підтримати

anonymous 05.03.2013 11:29

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

Відповісти

Підтримати

Oleksandr Kholodov

Апполинарий Эмануилович 05.03.2013 00:26

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

Відповісти

Підтримати

anonymous 04.03.2013 20:34

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

Відповісти

Підтримати

Dmytro Riabov 04.03.2013 22:01

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

Відповісти

Підтримати

anonymous 05.03.2013 03:32

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

Відповісти

Підтримати

Anton Bredykhin Senior Software Engineer в if(we) 05.03.2013 00:31

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

Відповісти

Підтримати

Васисуалий Лоханкин 04.03.2013 18:32

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

Відповісти

Підтримати

anonymous 04.03.2013 18:53

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

Відповісти

Підтримати

Васисуалий Лоханкин

flyman 04.03.2013 19:40

хіба RAD таке говорить?

Відповісти

Підтримати

Alexandr Gavriluk 04.03.2013 20:04

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

Відповісти

Підтримати

Васисуалий Лоханкин

anonymous 04.03.2013 20:21

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

Відповісти

Підтримати

Alexandr Gavriluk

anonymous 04.03.2013 20:23

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

Відповісти

Підтримати

Васисуалий Лоханкин

anonymous 04.03.2013 14:58

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

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

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

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

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

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

Відповісти

Підтримати

Denis Negometyanov Software Engineer 04.03.2013 17:41

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

Відповісти

Підтримати

anonymous 04.03.2013 18:13

А я не поверил своим глазам

Відповісти

Підтримати

Denis Negometyanov

Denis Negometyanov Software Engineer 04.03.2013 18:22

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

Відповісти

Підтримати

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 04.03.2013 20:29

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

Відповісти

Підтримати

byteslav cyberovskij 04.03.2013 20:58

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

Відповісти

Підтримати

Maksym Yemets web developer в WebDevs 10.03.2013 14:25

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

Відповісти

Підтримати

byteslav cyberovskij

Anton P Software Engineer в Roku 04.03.2013 14:44

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

Відповісти

Підтримати

anonymous 04.03.2013 14:44

-

Alexander Kuznyak Delivery Manager Consultant в сам себе режиссёр 04.03.2013 12:47

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

Відповісти

Підтримати

Alexandr Gavriluk 04.03.2013 13:54

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

Відповісти

Підтримати

Alexander Kuznyak

Bogdan Shyiak SE or Dev 04.03.2013 13:58

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

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

Відповісти

Підтримати

Alexandr Gavriluk

Grez 04.03.2013 16:33

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 04.03.2013 16:39

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

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

Відповісти

Підтримати

Grez

Grez 04.03.2013 16:45

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 04.03.2013 16:54

Эта разница в первую очередь в голове у девелопера.

2) Не предполагалось, тогда это не прототип, а про...б.

Відповісти

Підтримати

Grez

Grez 04.03.2013 17:19

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

Відповісти

Підтримати

Maks Slesarenko Web Developer 04.03.2013 10:54

Как вариант Метод прогрессивного джипега

Відповісти

Підтримати

Grez 04.03.2013 09:41

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

Відповісти

Підтримати

Alexandr Gavriluk 04.03.2013 10:34

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

Відповісти

Підтримати

Grez

Grez 04.03.2013 11:07

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

Відповісти

Підтримати

Alexandr Gavriluk

shadow 04.03.2013 11:13

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

Відповісти

Підтримати

Alexandr Gavriluk

Grez 04.03.2013 12:02

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

Відповісти

Підтримати

shadow 04.03.2013 16:26

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

Відповісти

Підтримати

Grez

Mykola Gurov тролль 03.03.2013 21:53

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

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

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 03.03.2013 18:11

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

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

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

Відповісти

Підтримати

Sergii Voloshyn Product Manager в DOU.ua 03.03.2013 22:03

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

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

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

Відповісти

Підтримати

Sergii Voloshyn

Sergii Voloshyn Product Manager в DOU.ua 03.03.2013 22:18

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

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

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

Відповісти

Підтримати

Sergii Voloshyn

Sergii Voloshyn Product Manager в DOU.ua 04.03.2013 11:16

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

Відповісти

Підтримати

Sergii Voloshyn

shadow 03.03.2013 18:09

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

Відповісти

Підтримати

Alexandr Gavriluk 03.03.2013 18:27

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

Відповісти

Підтримати

shadow 03.03.2013 18:53

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

Відповісти

Підтримати

Alexandr Gavriluk

Володимир Дубовий Dev in Looksery 04.03.2013 16:25

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

Відповісти

Підтримати

Bogdan Shyiak SE or Dev 03.03.2013 18:02

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

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

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

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

Відповісти

Підтримати

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

Ваша пошта

Не підписуватись