Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
Согласны с этим или нет? Что по вашему опыту?
То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
Уточни у того кто заявляет какие артефакты на выходе этого процесса он рассматривает, чтобы в говорили об одном и том же.
S>Согласны с этим или нет? Что по вашему опыту?
По моему опыту если взять любой длинный проект, среднюю дневную продуктивность программистов в строках кода поделить на количество строк кода в проекте, то получится как раз около 15%.
Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик. S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.
По факту такой анализ требует больше знаний, умений и навыков, чем программирование.
По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.
Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.
А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.
Re[2]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
G>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований".
Нахождение оптимальных решений. К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
G>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста.
Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
G>По факту такой анализ требует больше знаний, умений и навыков, чем программирование.
Нужен человек со сверхспособностями для этого. Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
G>По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют.
Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
Это все процесс кодирования — написания кода. И этот процесс включает исследования.
S>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы? G>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение.
Интересует мнение и опыт других.
G>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз.
Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.
G>А если никто заранее этого сделать не может, то идем итерационным путем — делаем прототип, получаем фидбек, переделываем. Схемы, диаграммы и длинные текстовые описания не помогают.
Я хотел бы посмотреть в глаза человеку, который это может сделать. Узнать что он выдает по итогу — как проверяет гипотезы.
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы. S>Согласны с этим или нет? Что по вашему опыту?
Когда начинается большой проект (или сперва он маленький, а потом быстро растет), то к нему собираются требования (бывает очень быстро тяп-ляп, бывает долго и тщательно), потом он реализуется, при этом пишется куча кода, так что процентное соотношение достаточно большое в плане кода, даже если требования собирались и анализировались тщательно.
Потом проект расширяется, растет, и через несколько лет это уже большой-большой проект, с кучей логики. И оказывается что что-то внедрить или изменить в большой системе это надо очень хорошо подумать как эта новая функциональность будет соотноситься со старой, так чтобы система оставалась адекватной, а не превратилась в мутное болото.
Если при этом еще есть и интеграция с другими системами, то надо узнавать, как поведение логики тут может отразиться на тех системах.
И оказывается что вот этот анализ "нужна ли эта функциональность и в каком именно виде" часто занимает много больше времени чем собственно изменение кода.
Предельный случай — но он бывает! — когда заказчик запрашивает функциональность для решения проблемы, проводится аналитика и выясняется что эту проблему можно решить уже имеющейся в системе другой функциональностью. Несколько дней анализа и 0 минут изменения кода.
Так что процент времени разный в зависимости от размера проекта и времени его жизни.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы?
Описание требуемой функциональности системы. Чем четче — тем проще потом будет кодировать и меньше вопросов придется решать по месту (но какие-то все равно наверняка придется, действительно учесть все сразу часто не удается или занимает неоправданно много времени)
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Выглядит как "надо сделать АПИ, мы не знаем зачем оно нужно, кому оно нужно, какие задачи будет выполнять, но АПИ нам вот точно надо".
Но пусть даже так, решить вопрос по месту — это то же самое, часть времени ты будешь кодировать, а часть переписываться с разработчиком клиента согласовывая детали реализации. Вот эта вторая часть и есть сбор, систематизация и анализ требований, и она вполне может быть сложнее самого кодирования (намекну — клиентов может быть 50, у каждого свой разработчик, и чуть-чуть разные пожелания, а тебе в твоем АПИ придется как-то учесть все потребности).
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
15% от вообще всего времени, потраченного на разработку?
Ну да.
потому что никто не отменял сбор, систематизацию, анализ требований.
Никто не отменял декомпозицию задач, планирование.
И архитектуру.
И всякие код-ревью.
И тестирование.
И развертывание на дев-тест-препрод-прод (или что там из этого присутствует) Возможно, в ручном режиме, а возможно, надо долго и нудно писаь, а потом поддерживать всякие ci/cd и прочие штуки
и поддержку 3-й линии. ковыряние в логах, выяснение у всех свечку-державших, что же собственно, произошло.
и помощь коллегам
И кучу времени, убитых на интеграцию (не написание кода, а на понимание, как оно вообще может работать вместе)
И коммуникации с командой, и с заказчиками, и со смежниками.
А, ну еще документацию — руководство пользователя, администратора, базу знаний по траблшутингу.
Документацию самого проекта в конце концов.
И вишенкой на торте — всякие аджайл и прочие религиозные ритуалы, отъедающие туеву хучу времени.
В общем, надоело описывать активности.
Они могут быть раскиданы по разным другим людям. А могут падать на разрабов. Это уж смотря какие процессы сложились в компании.
15% от времени конкретного программиста? Возможно, если он сидит на двух или нескольких стульях. Но в среднем скорее процентов 50 или даже больше.
Re[3]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>Чем делают программисты 85% времени? Видимо этот самый "сбор, систематизация и анализ требований". S>Нахождение оптимальных решений.
Увы нет
S>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований?
Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
S>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени.
G>>Потому что многие считают, что для анализа нужна более низкая квалификация, чем для написания кода. Средний ценник системного или бизнес-аналитика ниже ценника программиста. S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
Я тоже могу бесплатно стоимость назвать, как это относится к теме?
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
по факту стоимость этой работы включена в другие этапы
G>>По факту такой анализ требует больше знаний, умений и навыков, чем программирование. S>Нужен человек со сверхспособностями для этого. Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
Тонкости как раз знать необязательно, а основные принципы — необходимо, причем из разных областей. Навскидку чтобы разработать просто web api надо как минимум понимать в проектировании БД, HTTP и REST, "паттернах" разработки кода сервера и клиента.
G>>По этому фактически анализом и систематизацией по большей части занимаются сами программисты теми средствами, которыми владеют. S>Не по большей части — а просто нет иного пути. Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
Я не просто представляю, я в таком работал. Более того, на стороне заказчика такая же команда анализировала квадратики.
Проекты для госов вообще страшная вещь. Только толку от таких квадратиков незаметно больше нуля.
S>Это все процесс кодирования — написания кода. И этот процесс включает исследования.
Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код?
Или ты просто не видел этого ни разу?
S>>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы? G>>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение. S>Интересует мнение и опыт других.
Сильно зависит от того, что говорящий вкладывает в эти слова.
G>>Я, например, считаю что до начала кодирования нужно проектирование интерфейсов. С артефактами в виде интерактивных прототипов UI, для пользовательского UI, или коллекцией запросов в Postman для будущего веб-сервиса. Естественно эти прототипы должны быть не просто художеством в вакууме, а согласованы с программистами, которые их будут делать. Наличие заранее подготовленных таких артефактов, по моему опыту, помогает сократить время на написание кода до 10 раз. S>Даже согласование с программистами не поможет — пока не начнешь делать — не поймешь все ли нюансы учтены в API или нет. Даже не подумаешь о том, что всплывет в процессе использования.
Тем не менее разницу в 10 раз я наблюдал своими глазами
Re[3]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Нахождение оптимальных решений.
Прежде чем искать оптимальное решение, нужно определить, что именно является оптимальным решением. Быстродействие? Надежность? Потребление памяти? Скорость кодирования? Да и вообще, нужно определиться, нужно ли "оптимальное решение" в данном месте (ладно, если не нужно — у нас оптимальное решение по критерию "сложность реализации"). Т.е. чтобы начать искать оптимальное решение, нужно собрать требования.
S>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований?
Архитектор/лидер/команда. Зависит от процесса. Потому что часть анализа проекта — проверка возможности его выполнения (feasibility). Прямо в процессе разговора с пользователями требования приоритизируются по техническим рискам. Если все более-менее ложится в знакомые библиотеки, проблем нет. А вот если не ложится, производится дальнейшее исследование. Может производиться архитектором. Может отдаваться команде. При этом может оказаться, что команда уже решала проблему и знает решение. Или не знает и нужно провести эксперименты. После этого выяснить, что у нас получились три требования, которые друг с другом не сочетаются. И опять идет процесс общения с "заказчиками" о том, что можно выкинуть. А может вопрос записывается в риски и проект строится на условии успешной реализации прототипа.
S>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код.
Исследовательская работа. Ну и да, с целью уточнения/изменения требований. А потом выяснится, что допиливать библиотеку придется следующие три года и внезапно выясняется, что требование не очень-то и нужно было.
S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!!
А они готовы дать гарантии? По качеству решения и по срокам выполнения. А потом заплатить, если не уложились в сроки или если приложение не удовлетворяет спецификации. А так подобные конторы работают с типовыми решениями в нише. Там все требования более-менее известны и ложатся в шаблон. "Кастомизация" готового решения опять же будет по большей части выяснение требований, описание контракта и т.п. Кодирования там мало. А какие-нибудь нестандартные требования они вряд ли делать станут. Или вообще не реализуют в надежде, что заказчику и так сойдет (гарантий они обычно не дают).
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
Не совсем. У них "сбор требований" размазан по многим типовым заказчикам. Там "кодирование" обычно тоже не так много стоит.
S>Предвидеть все заранее, знать тонкости каждого протокола, знать все алгоритмы, которые придется реализовывать, знать тонкости библиотек.
Не нужно предвидеть все заранее. Нужно уметь структурировать знания. Что-то может быть определено в риски и получить приоритет в реализации (чтобы можно было остановить проект если риски реализовались). Что-то уже известно, что работает. Какие-то вещи можно спросить у команд, которые с этим уже работали и могут заметить проблемы. А какие-то вещи можно изолировать в архитектуре и иметь несколько планов (План А для первого приближения и План Б на случай, если всплыли какие-то проблемы). Проверка доступности — это командная работа. Да, нужно знать, как распределяются компетенции в команде/компании. Можно привлекать разных людей на разных этапах. Никто же не говорит, что нужно в одиночку это все делать.
S>Вы представляете себе, чтобы до написания кода некая команда МЕСЯЦАМИ на хорошем окладе просто анализировала требования и рисовала квадратики? Я не могу такого представить.
А почему "до написания кода"? Это никто кроме вас не утверждал. Выяснение/уточнение/анализ требований происходит и до, и в процессе кодирования. Разработчики могут выполнять несколько разных активностей/ролей в течение дня. Кодирование — одна активность, выяснение требований — вторая.
S>Это все процесс кодирования — написания кода. И этот процесс включает исследования.
Исследования-то оно включает. Но во многих случаях можно сделать наоборот и включить "написание кода" в процесс выяснения требований. Ну хотя бы потому, что на встречу с пользовтаелем тратится час, потом за 10 минут его хотелки реализуются и задается вопрос: "ты этого хотел?".
S>>>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. G>>Этот вопрос надо задавать не сообществу, а тому кто делает утверждение. S>Интересует мнение и опыт других.
Еще раз. Никто не утверждал, что сбор требований должен быть завершен перед кодированием. Он может продолжаться и в процессе реализации, и в процессе тестирования и даже в процессе эксплуатации. Автор всего лишь утверждает, что большую часть времени программист как раз выясняет, что должно быть сделано а не пишет код.
S>Даже не подумаешь о том, что всплывет в процессе использования.
"Что всплывет в процессе использования" — тоже сбор требований. Но на позних этапах. Потому что если это всплывшее не является требованием, то зачем на него вообще вни
S>Узнать что он выдает по итогу — как проверяет гипотезы.
План он выдает с четкими условиями. Выглядит примерно так: "На данном этапе мы знаем/считаем, что ... (длинный и скучный список). Поэтому предлагается решение АБВ, которое удовлетворяет контексту и требованиям. Другие решения в данном контексте не применимы". Когда приходит фидбэк (от программистов, от пользователей, от девопсов — не важно), он включается в требования/контекст. Потом список превращается в табличку, обрастает приоритетами, рисками и прочими атрибутами. В какой-то момент страничка может превратиться в "изначально у нас были условия АБВ, поэтому решение было ..., теперь условия изменились, у нас условия ВГД, идеальное решение будет выглядеть как ... и рабочий план перейти к нему состоит из ... (еще один список)". Все документы живые. Гипотезы часто проверяются общением с людьми.
Re: Сбор, систематизация и анализ требований vs кодирование
Там контекст был шире — речь шла про разработку продукта в целом.
Я в целом согласен. Но думаю, что не 15%, а больше. Но если взять вообще полностью создание программного продукта, то да — процентов 10-20% без учета дальнейшей поддержки продукта.
Тут интересно было бы услышать мнение шароварщиков: сколько у них в процентах уходит времени на написание кода.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
Не очень хороший вариант. А как руководство давало добро на старт проекта? Сроки изначально как-то оценивали?
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
Ну что-то очень рискованный бизнес получается. Если только речь не о чем-то действительно новаторском, которого никто еще не реализовывал.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
Ну а все митинги по разбиению задач, их оценке? А работа ПМа и тимлида по декомпозиции? А работа сейлзов, маркетологов, application field engineers и CEO/CTO/CFO по поиску нужных областей, общению с клиентами, выявлению "болей" клиентов, написанию бизнес-фич?
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Это все программирование. И только в рамках программирования кодирование — далеко не 100%. А помимо программирования (см. выше) есть еще очень много другой работы.
Ну и опять же, приведенный пример показывает не очень эффективно налаженные процессы.
Патриот здравого смысла
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, gandjustas, Вы писали:
S>>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? G>Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
— нужна библиотека для сортировки больших файлов. Писать самому или использовать готовые? Если готовые — то насколько сильно придется дорабатывать? Кто и когда это будет решать?
S>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени.
Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
S>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>Я тоже могу бесплатно стоимость назвать, как это относится к теме?
А как ты назовешь стоимость без сбора, систематизации и анализ требований?
S>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>Или ты просто не видел этого ни разу?
Это будешь еще дольше, чем выразить в коде.
Re: Сбор, систематизация и анализ требований vs кодирование
Здравствуйте, Shmj, Вы писали:
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
Похоже на правду.
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения.
S>Т.е. по сути никто не тратит основное время на некую работу перед кодированием. Да и каков будет результат этой работы? UML-диаграммы и нарисованные в виде квадратиков алгоритмы?
S>Приведу простой пример. Есть некое API. Можно с умным видом описать его в виде таблиц — перечислить все методы и входящие-исходящие параметры. Но в реальности, когда это API начнут использовать, когда создадут первого клиента — только тогда выявляются реальные требования и ищутся пути решения — какие методы реально нужны, какие данные нужно принять и вернуть. Даже до того как клиент создан — разработчик клиента может посмотреть и сказать — ну вроде все ОК. И только как начал писать код — только тогда всплывает что нужно на самом деле.
Да, так и происходит. Поэтому если даже на кодирование уходит много времени, там будет куча переписываний и доработок.
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Прежде чем искать оптимальное решение, нужно определить, что именно является оптимальным решением. Быстродействие? Надежность? Потребление памяти? Скорость кодирования? Да и вообще, нужно определиться, нужно ли "оптимальное решение" в данном месте (ладно, если не нужно — у нас оптимальное решение по критерию "сложность реализации"). Т.е. чтобы начать искать оптимальное решение, нужно собрать требования.
— является ли выбор библиотеки оптимальным решением или лучше своя реализация? Или не своя, а другая библиотека? Кто и когда это будет решать?
Архитектор или технический лидер команды. И это обычно выводится из общей стратегии использования библиотек. Это не всегда формальная стратегия. Но она определяет, в каких случаях применяются внешние библиотеки. Какие критерии применения (их поддержка, предоставляемая функциональность vs требуемая функциональность, наличие других задач, которые можно решить с использованием библиотеки, соображения безопасности, распространенность в индустрии (косвенно влияет на нахождение ошибок) и т.п.).
S>Понятно что цель — чем меньше памяти и чем быстрее — тем лучше. Но тратить много дней тоже не хочется — как бы здравый смысл определяет.
Обычно — нет, не цель. Обычная цель — получить сортировку, которая влезает в существующую память и работает более-менее разумное время. Исходя из задачи, решение будет IO-bound. Теория хорошо известна — external sort, пишется за один-два часа. Всё. Реализуем сами. Потом при необходимости добавляем метрики, профилируем и т.п. Я не вижу смысла тратить много времени на исследование и выбор лучших библиотек. Более того, я вообще не вижу смысла включать внешнюю библиотеку. Вот что вы будете делать, если со временем выяснится, что библиотека не оптимально работает в вашей задаче? Править библиотеку? Так можно и свой код править. И обычно свой код будет исправить проще. А еще библиотека может притащить кучу транзитивных лишних зависимостей, которые конфликтуют с другими библиотеками. Или иметь уязвимости, которые нужно регулярно исправлять/поддерживать.
После того, как это ручное решение реализовано, можно дальше собирать требования. Если все устраивает — ничего не нужно делать. Если не устраивает, поялвюятся новые объективные критерии — "сортировка X Гб файла с таким-то распределением данных не должна занимать более Y минут и потреблять больше Z Мб памяти". Вот тогда уже можно общаться с бизнесом о том, сколько они готовы платить за достижение результата. Бюджетом определяется, сколько можно анализировать. Если бюджет только 1000$, это один день анализа (может даже меньше) и день на реализацию. Если бюджет 10)00$, можно анализировать уже неделю (остаток уйдет на реализацию и, возможно, лицензии и т.п.).
Re[5]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>К примеру, выбор подходящей библиотеки — кто этим будет заниматься на этапе сбора требований? G>>Если библиотека распространяется пакетом, то это настолько мелочь, что нет смысла обсуждать.
S>Какая разница пакетом или нет?
Болшая
S>Пример
— нужна библиотека для сортировки больших файлов.
Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач.
S>>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени. S>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Анализом требований можно назвать что угодно, в этом и суть проблемы.
S>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
S>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>А как ты назовешь стоимость без сбора, систематизации и анализ требований?
Возьму и назову, что мне помешает?
S>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>>Или ты просто не видел этого ни разу? S>Это будешь еще дольше, чем выразить в коде.
Что именно будет дольше?
Re[5]: Сбор, систематизация и анализ требований vs кодирован
— нужна библиотека для сортировки больших файлов. Писать самому или использовать готовые? Если готовые — то насколько сильно придется дорабатывать? Кто и когда это будет решать?
В рамках проекта это всего лишь одна из сотен разработческих задач. Команда сможет эту задачу оценить из своего опыта, например, она знает, что поиск, выбор и интеграция с библиотекой на языке X занимает примерно N дней. Вот и все. Как уже сказали — это мелочь в рамках всего проекта.
S>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
Зависит от процесса в команде. Вообще, анализ требований — это скорее не про выбор библиотек, а про предметную область. Какие требования регулятора соблюсти, какие нагрузки нужно держать, какие специфичные требования для пользователей, какие форматы данных надо поддерживать и так далее. Выбор библиотеки — это всего лишь выбор инструмента. Примерно как для анализа и подсчета сметы делать выбор — считать в экселе, на бумажке или в Google Sheets.
S>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
Также как и выше. Выбор бибилиотки хоть и важный процесс, но даже с написаное Proof of Concept крайне редко занимает больше недели. Я говорю об узкоспециализированных библиотеках на плюсах, например. Выбор утилитарной либы для реакта будет в разы быстрее.
S>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>А как ты назовешь стоимость без сбора, систематизации и анализ требований?
Ну вот именно, что ее точность будет примерно такой же по ценности. Это будет очень примерная оценка.
Патриот здравого смысла
Re[3]: Сбор, систематизация и анализ требований vs кодирован
S>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
S>Т.е. по их мнению этот этап стоит не значительных денег, которыми можно пренебречь.
Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.
Во-вторых, это вовсе не означает, что по мнению конторы-разработчика эта работа ничего не стоит. Просто эта работу делают "авансом", рассчитывая на то, что при хорошем раскладе им этот проект закажут, и доходы от него все компенсируют.
Re[6]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Архитектор или технический лидер команды.
Он не пользовался этими библиотеками. Когда это делать — на этапе разработки или на этапе сбора/систематизации требований?
M>Обычно — нет, не цель. Обычная цель — получить сортировку, которая влезает в существующую память и работает более-менее разумное время. Исходя из задачи, решение будет IO-bound. Теория хорошо известна — external sort, пишется за один-два часа. Всё. Реализуем сами.
А откуда вы взяли цифру 1-2 часа? Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали?
Re[6]: Сбор, систематизация и анализ требований vs кодирован
— нужна библиотека для сортировки больших файлов. G>Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач.
Из маленьких и состоит проект. Не убегайте от ответа.
Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
S>>>>Иногда нужно из исходников собрать библиотеку, протестировать на неких данных — сделать выводы о необходимых доработках — смотреть код. G>>>Тогда она попадет в подсчет строк кода, которые все равно занимают 15% времени. S>>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований? G>Анализом требований можно назвать что угодно, в этом и суть проблемы.
Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе. Библиотеки тут ни при делах — это уже внутренняя кухня разработки.
S>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант? G>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
Вы убегаете от ответа таким образом. Хотите размазать истину.
S>>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это? G>>>Я тоже могу бесплатно стоимость назвать, как это относится к теме? S>>А как ты назовешь стоимость без сбора, систематизации и анализ требований? G>Возьму и назову, что мне помешает?
А как вы назовете, если не знаете что будете делать? Ведь чтобы знать что от вас требуют — нужно собрать и проанализировать требования.
S>>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования. G>>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код? G>>>Или ты просто не видел этого ни разу? S>>Это будешь еще дольше, чем выразить в коде. G>Что именно будет дольше?
Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
В коде это проще и быстрее. Те же состояния — можно автоматом сгенерить схему переходов на основе кода машины состояний.
Re[6]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>В рамках проекта это всего лишь одна из сотен разработческих задач. Команда сможет эту задачу оценить из своего опыта, например, она знает, что поиск, выбор и интеграция с библиотекой на языке X занимает примерно N дней. Вот и все. Как уже сказали — это мелочь в рамках всего проекта.
Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт?
Нужно брать конкретные библиотеки и анализировать. И это займет много времени. Потом брать и пробовать дорабатывать одну из них — и только спустя N дней поймешь подводные камни.
S>>Можно ли подбор подходящей библиотеки с учетом возможности ее доработки — назвать анализом требований?
DP>Зависит от процесса в команде. Вообще, анализ требований — это скорее не про выбор библиотек, а про предметную область. Какие требования регулятора соблюсти, какие нагрузки нужно держать, какие специфичные требования для пользователей, какие форматы данных надо поддерживать и так далее. Выбор библиотеки — это всего лишь выбор инструмента. Примерно как для анализа и подсчета сметы делать выбор — считать в экселе, на бумажке или в Google Sheets.
Выбор библиотеки очень на многое влияет.
S>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
DP>Также как и выше. Выбор бибилиотки хоть и важный процесс, но даже с написаное Proof of Concept крайне редко занимает больше недели. Я говорю об узкоспециализированных библиотеках на плюсах, например. Выбор утилитарной либы для реакта будет в разы быстрее.
Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
DP>Ну вот именно, что ее точность будет примерно такой же по ценности. Это будет очень примерная оценка.
Вот в том то и дело. Такой анализ требований делается бесплатно за 0.5-1% времени и другого никто не делает — дальше уже как угадали.
Re[4]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, klopodav, Вы писали:
K>Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.
А зачем делать более полный анализ, если цена уже названа?
K>Во-вторых, это вовсе не означает, что по мнению конторы-разработчика эта работа ничего не стоит. Просто эта работу делают "авансом", рассчитывая на то, что при хорошем раскладе им этот проект закажут, и доходы от него все компенсируют.
Стоит 0.5-1% общего времени проекта. Но никак не большую часть времени.
Re[7]: Сбор, систематизация и анализ требований vs кодирован
S>Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт?
It depends. Опыт — это опыт выбора библиотек.
S>Нужно брать конкретные библиотеки и анализировать. И это займет много времени. Потом брать и пробовать дорабатывать одну из них — и только спустя N дней поймешь подводные камни.
Вы сами себе противоречите. Вот же ниже вы пишите S>Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
Вы же не берете каждую библиотеку и не встраиваете к себе в продукт, чтобы проверить ее.
S>Выбор библиотеки очень на многое влияет.
Да. Но в рамках разработки продукта (продукта!) это мелочь. Это как если при строительстве завода заморачиваться, какого цвета болты брать — никелированные или какие-то другие. Да пофиг, решит бригадир или архитектор в соответствии с нагрузками или требованиями по влажности и т.п.
S>Неделя — это уже много. Вот в том то и дело — а когда библиотек несколько десятков экзотических и одну их них проще написать с нуля чем править — вот тогда время и уйдет.
Еще раз: если вам надо выбрать какую-то особо важную библиотеку, на которой будет весь функционал, то их будет немного. Вы на это потратите чуть больше времени. А если вам нужно выбрать сотню мелких либ для JS, то конечно вы не будете так тщательно каждую изучать.
S>Вот в том то и дело. Такой анализ требований делается бесплатно за 0.5-1% времени и другого никто не делает — дальше уже как угадали.
"никто не делает" — весьма спорное утверждение, когда вам тут как минимум 3 человека в теме сказали, что бывает иначе
Все зависит от проекта. Сделать дабу можно и без оценки. Написать утилиту для парсинга веб-страницы — чуть посложнее. Сделать веб-сайт на 10 страниц — еще сложнее. Написать систему для доставки суши с мобильными приложениями — еще сложнее. Чем выше сложность, тем больше необходимость предварительной оценки. Есть такое негласное примерное правило: оцени в днях, и ошибешься на день, оцени в неделях, ошибешься на неделю, оцени в месяцах — ошибешься на месяц. А некоторые оценки даются вообще в годах.
Когда делают бесплатную оценку срока, то либо это каткая-то конвейерная работа (сделать типовой сайт), либо вас кхм-кхм, обманут и вы потеряете x3 вложений и срок по факту будет в 2-3 раза дольше. Ну либо это что-то совсем простое (написать парсер для простенького сайта, где оценка будет 3 дня). Все, что более-менее сложное — надо садиться и предварительно обсчитывать. Не детально, без выбора библиотек, а просто примерно с точностью в +- пару недель (для небольших проектов), +- пару месяцев (не очень большие — средние), ну и так далее. Бесплатно такого никто делать не будет. Потому что это будет 2-3 человека-дня. И это будет грубая оценка. Если уже заказчик договаривается о работе, то тогда уже начинается плотная коммуникация с ним и обсуждение/утверждение требований. И это все затягивается не то что на недели, порой на месяцы. Программисты тут даже еще не приступают к работе.
