K>>Во-первых, в таких случаях обычно предполагается анализ "крупными мазками". Чтобы приблизительно оценить трудоемкость и цену вопроса. Более детальный анализ делается уже потом.

S>А зачем делать более полный анализ, если цена уже названа?

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

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

S>Стоит 0.5-1% общего времени проекта. Но никак не большую часть времени.

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

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

S>>>Пример

Автор: Shmj
Дата: 18.08.22

— нужна библиотека для сортировки больших файлов.
G>>Это слишком маленький пример. Речь идет о проектах минимум полгода до первого релиза. Выбор как сортировать файлы потеряется на фоне других задач.
S>Из маленьких и состоит проект. Не убегайте от ответа.
В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла.


S>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
Я бы готовый вариант взял через полчаса гугления.

S>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе.
И чего мы хотим получить на выходе "анализа требований" ?



S>>>Сколько у вас времени займет подбор библиотеки? Предложенный мной вариант с LevelDB — хороший или плохой? Будете писать самостоятельно или лучше такой вариант?
G>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
S>Вы убегаете от ответа таким образом. Хотите размазать истину.
Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься.

S>>>>>Некоторые конторы готовы выполнить анализ требований и даже назвать стоимость разработки вообще БЕСПЛАТНО!!! Вы понимаете это?
G>>>>Я тоже могу бесплатно стоимость назвать, как это относится к теме?
S>>>А как ты назовешь стоимость без сбора, систематизации и анализ требований?
G>>Возьму и назову, что мне помешает?
S>А как вы назовете, если не знаете что будете делать? Ведь чтобы знать что от вас требуют — нужно собрать и проанализировать требования.
Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?
Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.

S>>>>>Это все процесс кодирования — написания кода. И этот процесс включает исследования.
G>>>>Хочешь сказать, что в принципе нет возможности описать продукт до того как будет написан код?
G>>>>Или ты просто не видел этого ни разу?
S>>>Это будешь еще дольше, чем выразить в коде.
G>>Что именно будет дольше?
S>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
Зачем это делать?

S>В коде это проще и быстрее. Те же состояния — можно автоматом сгенерить схему переходов на основе кода машины состояний.
Это верно. Только с UI так не получается. В подавляющем большинстве случаев UI сгенерированный на основе схемы не подходит вообще никому. А UI не учитывающий пользовательских сценариев оказывается "не интуитивно понятным" для конечных пользователей.
Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов?

Здравствуйте, DiPaolo, Вы писали:

S>>Вы бы писали свою такую библиотеку или использовали готовую? Причем тут старый опыт?
DP>It depends. Опыт — это опыт выбора библиотек.

Оно по разному бывает. Бывает что просто ввел название пакета и подключил. А бывает что нужно дорабатывать настолько, что легче самому переписать. И чтобы это понять — нужно попробовать библиотеку применить.

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

В смысле неделя — это вообще много. И влияет на стоимость и сроки. А так да — неделю можно допиливать библиотеку и даже больше недели.

DP>Вы же не берете каждую библиотеку и не встраиваете к себе в продукт, чтобы проверить ее.

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

DP>Да. Но в рамках разработки продукта (продукта!) это мелочь. Это как если при строительстве завода заморачиваться, какого цвета болты брать — никелированные или какие-то другие. Да пофиг, решит бригадир или архитектор в соответствии с нагрузками или требованиями по влажности и т.п.

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

DP>Все зависит от проекта. Сделать дабу можно и без оценки. Написать утилиту для парсинга веб-страницы — чуть посложнее. Сделать веб-сайт на 10 страниц — еще сложнее.

Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.

Здравствуйте, klopodav, Вы писали:

K>Чтобы понимать, что и как разрабатывать и какой код писать программисту. При том, что по трудоемкости этот код будет плюс-минус укладываться в полученную ранее оценку, но нюансы реализации могут уже сильно варьироваться.

Как же дали первоначальную оценку, не понимая до конца что нужно сделать?

Вот дали вам задание — 1 простая Web-страница с 1 полем и 1 кнопкой, после нажатия кнопки выводит список.

Какие требования вам нужно собрать? Много ли их будет?

И потом сколько вы будете это делать?

K>Так никто и не предполагает, что это будет большая часть.

В стартовом сообщении ссылка.

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

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

Здравствуйте, gandjustas, Вы писали:

G>В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла.

Ну ок. А сколько вы будете делать аналог библиотеки LevelDB? Она просто сортирует большой файл и находит бинарным поиском нужный ключ.

S>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
G>Я бы готовый вариант взял через полчаса гугления.

Почему именно пол часа?

А если бы не нашлось ничего — то сколько писать вручную?

S>>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе.
G>И чего мы хотим получить на выходе "анализа требований" ?

Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр.

G>>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
S>>Вы убегаете от ответа таким образом. Хотите размазать истину.
G>Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься.

Допускаете ли вы, что займет значительно дольше чем кажется?

G>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?

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

Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова.

Много еще требований нужно?

Что тут займет основное время?

G>Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.

Глупости. Костюм — это натянуть дизайн на готовый движок и максимум подправить пару мелочей.

Я же говорю о проектах, которые пишут с нуля.

S>>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
G>Зачем это делать?

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

G>Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов?

UI это больше к дизайнерам.

S>Оно по разному бывает. Бывает что просто ввел название пакета и подключил. А бывает что нужно дорабатывать настолько, что легче самому переписать. И чтобы это понять — нужно попробовать библиотеку применить.

S>В смысле неделя — это вообще много. И влияет на стоимость и сроки. А так да — неделю можно допиливать библиотеку и даже больше недели.

S>Создать тестовую среду нужно, чтобы повторяла реальное использование.

S>Нет, не мелочь. Написать библиотеку с нуля — может быть сопоставимо с разработкой самого проекта.

Приведите уже конкретный пример, пожалуйста. Чтобы предметнее говорить: что за задача/продукт и о каких библиотеках идет речь. Необязательно именно ваши (если NDA), можно сопоставимые по размеру и сложности.

S>Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.

Ну вот вам навскидку — 2 недели на все про все. Это очень грубая первая оценка. Дальше вы можете уже предметнее со мной говорить (это я сейчас для примера), показав макет вашей страницы или список требований, если это умещается на 1 страницу. Можно будет сделать оценку и бесплатно, т.к. тогда это мелкий проект. А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, maxkar, Вы писали:

M>>Архитектор или технический лидер команды.
S>Он не пользовался этими библиотеками. Когда это делать — на этапе разработки или на этапе сбора/систематизации требований?
Если библиотека критична для реализации функциональности — на этапе сбора требований. Так и говорим заказчику: "спасибо за информацию. Нам нужно ее обдумать, давайте через три дня встретимся еще раз, у нас могут появиться новые вопросы". В эти три дня детально исследуем вопросы. А если не критична, то все просто. Мы эту библиотеку на данном проекте использовать вряд ли будем. Потому что есть альтернативы — либо ручное решение, либо какая-то известная библиотека, которой команды в компании умеют пользоваться. Все выше — часть проверки проекта на выполнимость (feasibility). Это, конечно, зависит от компании и отношений с заказчиком. Лично я считаю, что лучше честно предупредить, что проект имеет большой шанс на провал (и заниматься высокоприоритетными рисками), чем долго и мучительно доить заказчика. К моменту, когда начинается более-менее серьезная разработка и инвестиции вопрос о наборе библиотек и основных технических решениях уже не стоит.

S>А откуда вы взяли цифру 1-2 часа?
Из практики. Что может быть сложного в задаче: прочитать файл кусками, отсортировать куски стандартной библиотекой, записать файл, потом произвести слияние нескольких файлов (здесь можно использовать priority queue)? Ну у у команды это займет может один день (прочитать про merge sort, написать, протестировать). А если команда не может, это отдельная проблема, которая решается своими способами.

S> Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали?
Она не делает "лишь ту же сортировку":

LevelDB is an open-source on-disk key-value store ...
It supports batching writes, forward and backward iteration, and compression of the data ...

Wiki.
Это не сортировка. Так что не надо подменять требования на ходу (здесь будет долгий разговор с заказчиком о том, что "может быть через 10 мы будем делать ххх но пока не уверены" — это тоже очень важная информация для принятия решений на текущем этапе). В таких требованиях — за неделю не напрягаясь. Может она будет не очень быстрая, но это уже другой вопрос. Здесь мы опять переходим к выяснению требований. Хотя... Не, давайте напишу за день. "Хранилище" — это каталог. Ключ записи — имя файла. Данные могут сжиматься при записи (gzip). Итерация — через чтение списка каталогов. Если файлов много (и их список в память не влезает), используем внешнюю сортировку оглавления каталога. Вроде удовлетворяет всем требованиям

Здравствуйте, Shmj, Вы писали:

S>Хочу детально поднять этот вопрос

Автор: Vlad_SP
Дата: 30.07.22

.

S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.

S>Согласны с этим или нет? Что по вашему опыту?

Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.

Здравствуйте, Shmj, Вы писали:

S>Хочу детально поднять этот вопрос

Автор: Vlad_SP
Дата: 30.07.22

.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?

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

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, gandjustas, Вы писали:

G>>В том и проблема что не состоит. В крупном проекте (от полугода программирования) задачи типа "сортировка большого файла" занимают настолько мизерную часть кода, что обсуждать проблемы связанные с этой задачей не имеет смысла.
S>Ну ок. А сколько вы будете делать аналог библиотеки LevelDB? Она просто сортирует большой файл и находит бинарным поиском нужный ключ.
Я наверно откажусь от такой задачи, я же не гугл.


S>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
G>>Я бы готовый вариант взял через полчаса гугления.
S>Почему именно пол часа?
Я думаю за полчаса можно найти любой вменяемый код, если он есть.


S>А если бы не нашлось ничего — то сколько писать вручную?
Я думаю для сортировки файла есть готовый код.


S>>>Все же нет — анализ требований — это четкое понимание что мы хотим получить на выходе.
G>>И чего мы хотим получить на выходе "анализа требований" ?
S>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр.
Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали.


G>>>>Я думаю в масштабах достаточно крупного проекта (см выше) займет незаметно малую величину.
S>>>Вы убегаете от ответа таким образом. Хотите размазать истину.
G>>Это вы хотите свою идею подогнать под условия, я не хочу этим заниматься.
S>Допускаете ли вы, что займет значительно дольше чем кажется?
Что именно? Сортировка файла — вряд ли. Проект который изначально планировался на год одного разработчика может по трудозатратам в итоге составить от 50% до 1000%

G>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?
S>Потому что без анализа требований — ты не будешь знать что именно нужно сделать.
С чего это?

S>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова.
Это финальная задача для программиста, или предложение поговорить?

Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал).
Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.


S>Много еще требований нужно?
Нет.

S>Что тут займет основное время?
Выбор подходящей системы, которая решает задачу.


G>>Разработка ПО это не НИОКР уже давно. Даже не инженерия вида "построить мост". Это скорее ремесло как "сшить костюм". С одной стороны у заказчика есть требования, с другой стороны уже миллионы костюмов были сшиты за всю историю, да и вы сами скорее всего уже не один костюм сшили. Весьма вероятно что мастер даже гораздо лучше заказчика знает какой костюм надо сшить. Что ему помешает назвать цену? По короткому, даже устному, брифу будет понятно какой костюм нужен. Также и в ПО.

S>Глупости. Костюм — это натянуть дизайн на готовый движок и максимум подправить пару мелочей.
Твоя задача про поиск полностью подходит под это определение


S>Я же говорю о проектах, которые пишут с нуля.
С нуля написать поиск могут позволить себе гугл или на худой конец яндекс, хотя в последнем я не уверен. Все остальные пользуются готовыми системами\библиотеками.

S>>>Представить все алгоритмы в виде квадратиков. Представить все состояния в виде диаграмм...
G>>Зачем это делать?
S>Ну это можно назвать анализом и систематизацией требований. Тогда да — займет и больше времени чем кодирование. Но не видел чтобы так делали.
Я же говорю, что назвать анализом требований можно что угодно. Это максимально абстрактное понятие, без формализации которого в каждом конкретном случае говорить не о чем.


G>>Можно ли "проще и быстрее" сделать UI в коде и не заниматься рисованием прототипов\интерфейсов?
S>UI это больше к дизайнерам.
То есть в коде не "проще и быстрее" ?

K>>Чтобы понимать, что и как разрабатывать и какой код писать программисту. При том, что по трудоемкости этот код будет плюс-минус укладываться в полученную ранее оценку, но нюансы реализации могут уже сильно варьироваться.

S>Как же дали первоначальную оценку, не понимая до конца что нужно сделать?

Первоначальную оценку дали понимая не до конца, а в общих чертах. Этого достаточно.

S>Вот дали вам задание — 1 простая Web-страница с 1 полем и 1 кнопкой, после нажатия кнопки выводит список.

S>Какие требования вам нужно собрать? Много ли их будет?

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

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

S>И потом сколько вы будете это делать?

Порядок величины зависит от основных требований.

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

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

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

Детальный анализ может занять очень дохрена времени. Особенно если этот анализ завязан на взаимодействие с другими людьми. Этот анализ может выглядеть как-то так: состыкуйся вот с теми чуваками, обсуди с ними в каком формате они будут предоставлять данные, дождись пока они родят описание и примеры своих данных в этом формате, и уже потом подумай как адаптировать свой софт под этот формат.

Здравствуйте, DiPaolo, Вы писали:

DP>Приведите уже конкретный пример, пожалуйста. Чтобы предметнее говорить: что за задача/продукт и о каких библиотеках идет речь. Необязательно именно ваши (если NDA), можно сопоставимые по размеру и сложности.

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

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

Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется.

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

Время уходит на это, а не на требования.

DP>Ну вот вам навскидку — 2 недели на все про все. Это очень грубая первая оценка. Дальше вы можете уже предметнее со мной говорить (это я сейчас для примера), показав макет вашей страницы или список требований, если это умещается на 1 страницу. Можно будет сделать оценку и бесплатно, т.к. тогда это мелкий проект. А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.

Ну вот вы взялись за 2 недели делать Гугл без рекламы.

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

S>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.

Это всего-навсего юзер стори, одна мелкая деталь проекта, а проект — часть продукта. Эта юзер стори рисерчится, если надо, потом оценивается командой и впоследствии делается. И, честно говоря, я не понял суть задачи. Либо вы опечатались в нескольких местах, либо неправильно расставили падежи, но там чисто из текстового описания непонятно, что требуется.

S>Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется.

Энивей, этот масштаб — работа команды над фичей, 2-4 недели. Помимо этого еще какие-то фичи будут делаться.

S>И вопрос тут не в детализации требования а в поиске решения. Сначала поиск готовой библиотеки, потом поиск наиболее близкой, потом поиск алгоритмов готовых и уже самое сложное — изобретение новых алгоритмов.

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

S>Время уходит на это, а не на требования.

Вы все верно говорите применительно к кодированию. Но речь в изначальном топике шла о продукте. Продукт включает в себя очень много всего. Непосредственно разработка в нем, условно, 30-50%. В эти проценты входит, помимо самого кодирования: тестирование, дизайн архитектуры, выбор решений, багфиксинг, написание тестов, какая-то работа по релиз-менеджменту, и прочее. Потому в рамках всего выпуска продукта само кодирование — маленькая его часть.

S>Ну вот вы взялись за 2 недели делать Гугл без рекламы.

Нет, не взялся. Вот же написано:
DP>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.

Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.

Здравствуйте, maxkar, Вы писали:

S>> Вот ту же библиотеку LevelDb, которая, по сути, тоже делает лишь сортировку — вы бы за сколько написали?
M>Она не делает "лишь ту же сортировку":
M>

M>LevelDB is an open-source on-disk key-value store ...
M>It supports batching writes, forward and backward iteration, and compression of the data ...

Так а что, из-за компрессии данных — уже не сможете за пол дня сделать? Сложно добавить 1 строчку кода gZip?

Поймите что я таких как вы уже не первого наблюдаю — причем некоторые с 15 летним опытом. Думают что все легко и просто, пока не коснется практики.

M>Wiki.
M>Это не сортировка. Так что не надо подменять требования на ходу (здесь будет долгий разговор с заказчиком о том, что "может быть через 10 мы будем делать ххх но пока не уверены" — это тоже очень важная информация для принятия решений на текущем этапе). В таких требованиях — за неделю не напрягаясь. Может она будет не очень быстрая, но это уже другой вопрос. Здесь мы опять переходим к выяснению требований. Хотя... Не, давайте напишу за день. "Хранилище" — это каталог. Ключ записи — имя файла. Данные могут сжиматься при записи (gzip). Итерация — через чтение списка каталогов. Если файлов много (и их список в память не влезает), используем внешнюю сортировку оглавления каталога. Вроде удовлетворяет всем требованиям

Т.е. вы предлагаете не писать а использовать готовый инструмент — сортировку B-tree, которую использует ОС для файловой системы? Есть ли у вас осознание что именно вы предложили? Операционная система — это тоже всего лишь программа. И вызывать ее функции — это тоже вызов своего рода библиотеки.

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

В идеале вообще ничего писать не нужно — просто найти готовую систему. Второй случай — собрать систему из готовых библиотек. Третий случай — доработать готовые библитеки. Четвертый — писать самому.

Здравствуйте, AleksandrN, Вы писали:

AN>Чем крупнее проект и чем выше цена ошибки, тем больше времени тратится на сбор требований и системную аналитику.

А как же время на тестирование — если цена ошибки высока? Почему именно сбор требований?

Здравствуйте, Sharov, Вы писали:

S>Это во всех книжках пишут, вроде Роберт Гласс в какой-то из своих писал, то ли в книге "программист-прагматик". Это общее место, что кодирования не
S>самая главная и долгая часть, тестирование и отладка дольше. Сбор, систематизация и анализ требований -- кмк, это самый важный этап. Чем тщательнее этот
S>этап проработан, тем легче будет далее.

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

Здравствуйте, gandjustas, Вы писали:

S>>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться.
G>>>Я бы готовый вариант взял через полчаса гугления.
S>>Почему именно пол часа?
G>Я думаю за полчаса можно найти любой вменяемый код, если он есть.

Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть.

S>>А если бы не нашлось ничего — то сколько писать вручную?
G>Я думаю для сортировки файла есть готовый код.

А для чего нет готового кода?

S>>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр.
G>Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали.

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

Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.

А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.


G>>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать?
S>>Потому что без анализа требований — ты не будешь знать что именно нужно сделать.
G>С чего это?

А с того — требования описывают что хотим получить. Если ты не знаешь что от тебя требуют — то цену чего будешь называть? Просто с потолка?

S>>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова.
G>Это финальная задача для программиста, или предложение поговорить?

G>Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал).
G>Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.

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

S>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.

Это не требование. Уж во всяком случае не требование в том смысле, каким оно подразумевается в этой теме. Это бизнес-идея.

S>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.

Это как раз уточнение требований, включая, но не ограничиваясь, требованиями по нагрузке (должно держать 100К рпс), по SLA (99.99999%), по затратам в месяц (не более $30000 на железо), должно поддерживать HTTPS, поддерживать 3 языка (английский, русский, французский) и т.д.

А как мы это будем делать — уже технические детали. Что не отменяет предварительной оценки от разработчиков.

Вы б лучше привели более конкретный пример. Сделать поисковик — такой себе пример для обсуждения. Тут ясно, что это на годы работы. Обсуждать на этом примере сложно.

Здравствуйте, DiPaolo, Вы писали:

DP>Это всего-навсего юзер стори, одна мелкая деталь проекта, а проект — часть продукта. Эта юзер стори рисерчится, если надо, потом оценивается командой и впоследствии делается.

Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.

DP>И, честно говоря, я не понял суть задачи. Либо вы опечатались в нескольких местах, либо неправильно расставили падежи, но там чисто из текстового описания непонятно, что требуется.

Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.

S>>Может уже есть что-то готовое. Может есть почти готовое. А может придется писать с нуля, тогда масштаб работ меняется.
DP>Энивей, этот масштаб — работа команды над фичей, 2-4 недели. Помимо этого еще какие-то фичи будут делаться.

2-4 недели — это уже существенное время в рамках даже 1-2 лет.

DP>Нет, не взялся. Вот же написано:
DP>>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.

DP>Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.

Почему другой?

Здравствуйте, DiPaolo, Вы писали:

DP>Это как раз уточнение требований, включая, но не ограничиваясь, требованиями по нагрузке (должно держать 100К рпс), по SLA (99.99999%), по затратам в месяц (не более $30000 на железо), должно поддерживать HTTPS, поддерживать 3 языка (английский, русский, французский) и т.д.

См. https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BB%D0%BC%D0%BE%D0%B3%D0%BE%D1%80%D0%BE%D0%B2%D1%81%D0%BA%D0%B0%D1%8F_%D1%81%D0%BB%D0%BE%D0%B6%D0%BD%D0%BE%D1%81%D1%82%D1%8C

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

DP>А как мы это будем делать — уже технические детали. Что не отменяет предварительной оценки от разработчиков.

DP>Вы б лучше привели более конкретный пример. Сделать поисковик — такой себе пример для обсуждения. Тут ясно, что это на годы работы. Обсуждать на этом примере сложно.

Почему ясно что на годы? А если готовую библиотеку взять?