Обновить
51
0
Денис Сапоненко @VaiMR

Системный архитектор подрабатывающий лидом

Отправить сообщение
Вам очень повезло, если вы не сталкиваетесь с этими «избитыми банальностями» каждый день. В большинстве же случаев очень трудно объяснить, почему описанные в статье проблемы съедают время.
Разве зря потратили?
Так получилось. Учтем.

Кстати, в статье всего два упоминания, а в комментарии выше целых три. В процентном соотношении вы меня обогнали.
Читать можно и нужно с пользой.
Хлопальщиков я привел в пример, как последнюю запомнившуюся попытку повысить производительность. Никто и не предлагает работать на износ. Есть конкретное предложение для повышения эффективности своего труда. Если работать эффективно, то и времени свободного появится больше. Освобожденное время можно потратить на семью, саморазвитие, отдых, хобби и общение с друзьями.
Популярная байка с долей правды.
Согласен с вами. Но стоит учитывать, что один прототип — одна концепция решения проблемы. Если появилась новая концепция, то для нее должен создаваться отдельный прототип.
Если изначально настраивать себя на то, что все прототипы будут выкинуты, то это работоспособный вариант разработки.
Вы додумываете за заказчика. Заказчик хочет быстро, вчера, дешево и без ошибок в выходные.
Первое, что пришло в голову: "Код в стиле дамп потока сознания". Вполне приемлемый подход для прототипа и недопустимый для реального продукта.
Да, согласен. Если включать создание прототипов в стадию разработки, то оно занимает большую ее часть. В полном жизненном цикле ПО, на прототип тратится не очень много времени. На разработку же меньше всего. Документирование, прототипирование, документирование, исследование пользователей, тестирование, разработка, снова тестирование, документирование, сопровождение. Этап разработки совсем затерялся.
Прототипы бывают разные. Кнопка с некой простой логикой, позволяет получить данные от реальных пользователей системы. В вашем случае, эти три варианта и есть прототипы. Вы же не создаете для каждого продуманную монтажную плату, не пишете талмуд документации, опускаете некоторые ньюансы. Каждый вариант может быть похож на это:
Быстрый монтаж


А вот если прототип заведется, то будут разведены платы, написаны инструкции, стандартизированы элементы.
На самом деле на прототип тратиться совсем мало времени.

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

По какому критерию у вас на прототип уходит столько же времени, сколько и на разработку основного продукта?
Да, ни один комплект тестов не гарантирует 100% безошибочности кода. Но, с другой стороны, тесты выявляют ошибки архитектуры, дизайна API. Исключают регрессию кода и повторное возникновение проявившейся ошибки в будущем. Тесты упрощают модернизацию системы, а также дают больше свободы действий при рефакторинге — всегда можно проверить, не сломалось ли что.
Можно сказать и иначе. Большую часть времени работы с кодом, его приходится читать, поэтому грамотное его оформление, прозрачная архитектура, актуальные комментарии, позволяют экономить уйму времени. Та же ситуация с тестами. Большую часть времени работы с кодом, разработчик тратит не на написание функционала, а на его сопровождение. В этом случае любое тестирование экономит уйму времени.

В этот критерий, конечно же, не входят сайты визитки и проекты «разработал за вечер и забыл».
Уже очень много написано о том, что прототип надо выкинуть. Нельзя дорабатывать прототип и превращать его в конечный продукт.
Да, бытует мнение, что создание прототипа — это двойная работа. Поэтому из прототипа рождаются полуживые продукты. Прототип, это способ исследования проблемы, позволяющий получить критику заказчика и необходимый багаж знаний в предметной области.
Исправлять ошибки в своей работе — это профессиональный этикет. А судиться с заказчиком, из-за недопонимания — это разорение.
Бросаетесь в крайность. Надо понимать, что разрабатывается. И заказчик должен быть в курсе. Нет опыта? Не проблема, создаем прототип, тестируем, обсуждаем с заказчиком, и только потом разрабатываем продукт, имея необходимый багаж знаний.
Мы же серьезные «дядьки» и не бросаем заказчика с большим куском кода, написанного «под пиво» ибо это не выгодно.

Во множестве случаев имеется длинный период сопровождения. Думаю, это 80% процентов дохода.

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Бэкенд разработчик, Архитектор программного обеспечения
Старший
Java