Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть. G>>А что еще нужно? S>Вникнуть в принципы работы, прочесть документацию, прочесть отзывы, собрать из исходников, создать тестовую среду и оценить какая лучше. Легко уходит неделя-две.
Если требуется столько времени значит не подходит.
Ты же сам ссылался на задачу с сортировкой файла, там решение на leveldb требует 10 строк кода и один package-install для решения этой задачи.
Если у тебя "готовое" решение требует примерно столько же времени, сколько написание с нуля, то оно не готовое и точно не подходит.
G>>Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени. S>Даже если собрать точные требования — на реализацию все равно уйдет намного больше сил и времени.
Что ты понимаешь под "точными требованиями"? Мне кажется то, что ты понимаешь как раз не является точными, поэтому "на реализацию все равно уйдет намного больше сил и времени".
S>Да, не каждый может собрать. Часто и заказчик сам не знает что лучше — часть осознанно делают эксперименты и выкидывают решения, если не понравились на практике.
Это тоже способ сбора и анализа требований, это и занимает 85% времени. Причем времени программистов, которое очень дорогое.
G>>Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию. S>А что вы вкладываете в понятие "анализ требования"?
Это зависит от контекста.
— Прототипы интерфейса, по возможности интерактивные, и\или описание api вплоть до примеров вызовов в postman.
— Функциональные спецификации как Спольски завещал.
— Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя.
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Да.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
Ммммм, тут надо говорить о методах сбора, систематизации и анализы требований, это не просто описание разделов соответствующей документации по госту, иногда стоит в начале проекта поставить пилот, и собирать замечания от пользователей: тут то не так, а тут это. Но обязательно их фиксировать отдельным документом, и утверждать протоколом специального совещания. И нужно различать шароварный сидиэжектор и какую-нибудь корпоративную автоматизацию. Во втором случае основная работа не просто собрать требования, а еще и согласовать функционал, чтобы потом на приемке тебе мозг не вынесли (тут расширенное ТЗ больше в юридической плоскости лежит, надо тщательно подбирать формулировки — был случай в моей практике, когда нас кинули на два млн, докопались как раз до формулировки в расширенном ТЗ).
Кроме того, хорошо прописанные требования это почти готовая программа, ее осталось перевести с естественного языка на формальный язык программирования.
Счастье — это Glück!
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>- Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя.
Это самое сложное и зачастую легче просто написать программу, чем сначала написать спецификации в терминах программы. Это и есть методы нахождения решений.
Более того — даже по готовой программе написать спецификацию — это очень трудоемкий процесс. Это как бы два раза выразить одно и тоже — сначала на ЯП, потом на языке диаграмм.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>Если требуется столько времени значит не подходит. G>Ты же сам ссылался на задачу с сортировкой файла, там решение на leveldb требует 10 строк кода и один package-install для решения этой задачи. G>Если у тебя "готовое" решение требует примерно столько же времени, сколько написание с нуля, то оно не готовое и точно не подходит.
LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов.
То решение что я быстро набросал — на самом деле задачу не решает — там неправильная сортировка и не учитываются дубликаты. Нужно думать как сделать, может даже проще написать мердже-сорт с нуля. Может быстрее будет а может и нет — не знаю. Думаю что и вы не знаете без исследования.
Re[2]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Dym On, Вы писали:
DO>Кроме того, хорошо прописанные требования это почти готовая программа, ее осталось перевести с естественного языка на формальный язык программирования.
Почти готовая программа — это не требования а описание методов реализации требований. К примеру, будет ли в вашей "почти готовой программе" описано какую библиотеку применить для того или иного решения?
Re[15]: Сбор, систематизация и анализ требований vs кодирован
S>LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов.
Написание ни одной СУБД не стоит таких маленьких денег. Если это не лабораторная/курсовая/дипломная работа. Думаю, вы ошиблись на 1-2 порядка, если говорить о коммерческом продукте.
Патриот здравого смысла
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>LevelDB писать с нуля — не неделя-две — а требует квалифицированного программиста и стоит это около несколько десятков тысяч долларов. DP>Написание ни одной СУБД не стоит таких маленьких денег. Если это не лабораторная/курсовая/дипломная работа. Думаю, вы ошиблись на 1-2 порядка, если говорить о коммерческом продукте.
Это почему вы так думаете? Что считать СУБД? Сколько строк кода в LevelDB?
Re[17]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>Это почему вы так думаете? Что считать СУБД? Сколько строк кода в LevelDB?
DP>http://rsdn.org/forum/job/8345884.1:
Здравствуйте, Shmj, Вы писали:
S>Есть здравый смысл и людям не нужно уточнять миллионы деталей, потому что пределы здравого смысла и так ясны.
Да вот как раз наоборот. Полагаться на "здравый смысл" в командной разработке — очень плохая идея. Во-первых, люди очень часто принимают решения иррационально, на основе "интуиции". Это далеко не всегда приводит к оптимальным решениям. В быту это скорее полезно (меньше ресурсов мозга тратится), а вот в разработке — вредно. Во-вторых, все люди разные. Образование, опыт, воспитание и культурные традиции, текущие цели и текущий контекст работы. То, что для опытного работника с десятилетним стажем на производстве является здравым смыслом может быть совсем не очевидным фактом для разработчика, который разрабатывает систему для того же производства. Хорошо систематизированные требования уменьшают вероятность того, что возникнет взаимонепонимание на "очевидных" вещах.
S>Вспомнилось: https://xakep.ru/2006/12/16/35784/
О! Прекрасная иллюстрация о том, что происходит при неодстаточной систематизации требований. Смотрите. "Солонки на столах" сами по себе не являются требованием. Это одно из возможных решений задачи "досолить пищу после подачи". В процессе эксплуатации выяснились новые требования — безопасность и доступность. При этом заказчик, путая цель и средства, продолжает вкладывать ресурсы в уже существующее решение "солонки на столах". Хотя для исходной задачи "досолить" есть простое административное решение. Убрать солонки со столов, раздать официантам. Обязать официантов досаливать еду по просьбе клиента. И для получения решения всего лишь было нужно обратиться к специалистам по систематизации требований.
Re[3]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>К примеру, будет ли в вашей "почти готовой программе" описано какую библиотеку применить для того или иного решения?
Это зависит от условий договора, лицензирования и т.п. У меня был случай, когда в договоре был прописан запрет на использование СУБД, любой, и был зафиксирован перечень exe-файлов и dll с именами. IT спецы заказчика потом сами ставили софт на чистую ОС и мониторами смотрели куда она тыкается. Что любопытно на открытых исходниках они не настаивали. Очень причудливо все бывает.
Счастье — это Glück!
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Да
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик. S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Если у исполнителя нет опыта в решении задач которые ставит заказчик, так и будет.
Просто не надо нанимать такого исполнителя, который не знает как решать твою задачу и какие там есть подводные камни.
Для того чтобы понимать реальные проблемы и подбирать работающие решения до написания кода, существуют специально обученные люди.
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>- Опционально технические спецификации, те самые таблицы и диаграммы, но в терминах программы, а не пользователя. S>Это самое сложное и зачастую легче просто написать программу, чем сначала написать спецификации в терминах программы. Это и есть методы нахождения решений.
Поэтому и опционально. Зачастую действительно программу написать проще.
Re[3]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, AleksandrN, Вы писали:
AN>>Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.
S>А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?
Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал
А тест-кейсы создаются на основе требований.
Re[4]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, AleksandrN, Вы писали:
AN>Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал AN>А тест-кейсы создаются на основе требований.
И что? Время и ресурсозатраты на тесты — не входят в учет времени на сбор и анализ требований.
Re[5]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
AN>>Роль тестирования для таких проектов тоже возрастает. Но тема про сбор требований, про него и написал AN>>А тест-кейсы создаются на основе требований.
S>И что? Время и ресурсозатраты на тесты — не входят в учет времени на сбор и анализ требований.
Речь же была не про требования только, а про весь проект
Написание кода — как правило, малая его часть
Если в проекте распределение ролей, понятно что разработчик будет в основном писать код,
другую работу будут делать другие люди.
Re[6]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
bnk>>Речь же была не про требования только, а про весь проект bnk>>Написание кода — как правило, малая его часть
S>Написание кода совмещено с поиском решений. А поиск решений — это основная часть. Уже две недели ищем решение коллективно для простой задачи
Здравствуйте, bnk, Вы писали:
bnk>Речь скорее всего про разные вещи. bnk>Задача "сортировка файла" проектом не является, это же просто задача.
Проект состоит из таких вот задач. И на поиск решения для некоторых из них — троится немало времени.
Да, можно согласится что время тратиться на написание документации, тесты, создание авто-тестов. Но никак не на сбор и анализ требований — это вообще 1% от проекта.
Re[7]: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Как можно этого не видеть и не понимать?
Рискну предположить, что вам никогда не приходилось самостоятельно вести проект начиная от самого первого общения с заказчиком и до внедрения. Или, если вы работаете в продуктовой разработке, никогда не приходилось вести разработку продукта от идеи до состояния продаваемой "коробки".
"Вести" в смысле управлять и отвечать за результат.
