S>Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.
Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны.
Вот это S>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
И это S>Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.
Ну сильно отличающиеся вещи. Теперь стало более понятно что делать, но все-равно не до конца. Я бы, например, уточнил, какой список операций нужен? Что скрывается за и т.д.? Числа с плавающей точкой надо предусмотреть? Какие будут максимальные числа? Отрицательные могут быть? Только GET запросы? Что значит не дозволяющий? Должен выдавать ошибку? Какую? Что по скорости работы? Какие планы по дальнейшему расширению? Нудна ли интеграция? Куда это будет встраиваться/интегрироваться? Какие ОСи поддерживать? Это должна быть CLI или прямо интерпретатор языка со своей грамматикой?
Это я все для примера. Не надо на них отвечать, пожалуйста.
И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
S>2-4 недели — это уже существенное время в рамках даже 1-2 лет.
Я ж написал, что будут и другие фичи. 2-4 недели половины или трети команды на отрезке в 2 года — не так уж и много.
DP>>Нет, не взялся. Вот же написано: DP>>>>А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
DP>>Если бы вы сразу сказали, что это поисковик, то разговор был бы другой.
S>Почему другой?
Потому что вот что я написал:
А если описание/ТХ больше чем на страницу, тогда уже тут скорее всего речь будет идти о реализации дольше чем 2 недели + оплата проработки ТЗ/оценке сроков.
А вот что изначально написали вы:
Да причем тут 10 страниц? Сколько будет стоить написать сайт с 1 страницей, 1 полем и 1 кнопкой? Отож.
Вот как раз чтобы выудить из заказчика все нюансы и требования, и надо достаточно много времени. И это будет сделано не вами еще до того, как техническая задача на разработку дойдет до вас как разработчика/архитектора/тимлида.
Патриот здравого смысла
Re[13]: Сбор, систематизация и анализ требований vs кодирован
S>Сказав что аналог гугл и бинг — уже получили достаточное описание, из которого только дурак не поймет нужна ли поддержка HTTPS. Требования достаточно точно выражаются этой короткой фразой.
Имхо, вот тут основная особенность, почему возникла эта тема и почему вы не понимаете и не слышите, что вам говорят тут нескольких человек. Дальше можно не продолжать.
Патриот здравого смысла
Re[12]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, so5team, Вы писали:
S>>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. S>Это не требование. Это хотелка.
Достаточно для того, чтобы сказать сделана работа или нет.
S>>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований. S>Это как раз и будет сбор и анализ требований.
Что вы вкладываете в понятие "анализ требования"? Подобрать библиотек из опенсорса, с помощью которых можно как из кирпичиков собрать части системы — это анализ требований?
Re[13]: Сбор, систематизация и анализ требований vs кодирован
S>>>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. S>>Это не требование. Это хотелка.
S>Достаточно для того, чтобы сказать сделана работа или нет.
Это смешно. Это даже не студенческий уровень, тк даже там в лабораторных работах будет более четкое условие. А в реальном же мире с такими "требованиями" и "приемками" никто не работает.
Патриот здравого смысла
Re[11]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
S>>>>>Вот это как бы вы решали? Искали бы готовую библиотеку или же писали вручную? Понятно что структура данных может усложняться. G>>>>Я бы готовый вариант взял через полчаса гугления. S>>>Почему именно пол часа? G>>Я думаю за полчаса можно найти любой вменяемый код, если он есть. S>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть.
А что еще нужно?
S>>>А если бы не нашлось ничего — то сколько писать вручную? G>>Я думаю для сортировки файла есть готовый код. S>А для чего нет готового кода?
Для любого сценария использования например.
S>>>Требования — это описание того что мы хотим получить в результате работ. Можно словами, можно добавить таблицы, диаграммы, схемы и пр. G>>Ну и? Что это будет? В каком объеме? В какой структуре? Ведь начиная какую-то работу нужно понимать когда она сделана, я пока не вижу границ того, что вы описали. S>Суть вот в чем — требования не описывают как достичь — описывают что нужно. А вот как сделать то что нужно — это уже большая работа и выполнить ее без кодирования может только гений (или тот, кто уже делал аналог проекта и помнит как).
Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени.
S>Вот требование — сделать поисковик по интернету аналог гугл и бинг. Все! Это достаточно четкое требование. Только дурак может прикинуться что ничего не понял.
Взяться за такой проект может гугл, майкрософт или больной на голову и очень богатый человек. Это не значит что у него не получится, это значит что у тебя и всех тут присутствующих не получится.
S>А вот уже раскрыть тех. детали — каким образом мы сможем сделать такой поисковик — это не сбор и анализ требований.
Алгоритмическая часть поисковика уже многократно реализована. Причем как сам инвертированный индекс, так и алгоритмы релевантности типа page rank, нейросетей и прочих индексов цитирования.
Если вдруг ты достаточно богатый и больной на голову и захочешь сделать свой поисковик, то 85% времени ты потратишь не на алгоритмы TF-IDF или page rank, а на то, чтобы:
— сделать обходчик, который с одной стороны не слишком агрессивный и не будет отрезаться как ДДОС, а с другой стороны сможет контент держать в достаточной свежести
— сделать хранилище, которое сможет сохранить индекс всего интернета и будет достаточно отказоустойчивым
— защититься от возможных атак на твой индекс (покупных ссылок, фейковых страниц с ключевыми словами итд)
— научить движок запросов определять тему и синонимы, чтобы он понимал чем отличаются C# C Sharp и Си-бемоль
Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию.
Пойми наконец, что в любой достаточно крупной программе алгоритмы — не самая большая часть.
G>>>>Я сам назову и цену, и состав работ. Зачем мне что-то для этого анализировать? S>>>Потому что без анализа требований — ты не будешь знать что именно нужно сделать. G>>С чего это? S>А с того — требования описывают что хотим получить. Если ты не знаешь что от тебя требуют — то цену чего будешь называть? Просто с потолка?
А с чего ты взял что я не знаю? Я сделал программ гораздо больше чем любой заказчик. Если он просто озвучит свою проблему, то я смогу придумать её решение лучше чем он сам.
Ты мыслишь как программист, который может накодить по ТЗ, поэтому тебе сложно понять процессы разработки программ за пределами кодинга.
S>>>Вот я тебе говорю — нужна 1 страница с 1 полем и 1 кнопкой. По нажатию на кнопку просто вывести список их текстов, где встречается введенные 2-3 слова. G>>Это финальная задача для программиста, или предложение поговорить?
G>>Если если финальная задача, то кто-то уже сделал 85% работы (или думает что сделал). G>>Если предложение поговорить, то я бы предложил воспользоваться готовыми системами поиска, их десятки как минимум.
S>Вы лучше назовите хотя бы одну систему, которых уже не написали десятки.
Я вот много лет занимался SharePoint, там есть поисковый движок и той самой одной страницей и с одной кнопкой. Аналоги есть у оракла, IBM, гугла и я думаю даже у яндекса.
Есть и подешевле вариант — elasticsearch.
А если вдруг твой поиск это часть большого приложения со своим хранилищем, разграничениями доступа итд, то можно воспользоваться Lucene(.NET).
Еще раз повторю: писать свой поиск может 5-10 компаний в мире или очень богатые и не совсем здоровые люди.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>Вот то то и оно — именно исследования занимают все время. И это не сбор и не анализ требований. Требования понятны — не ясно как это сделать на практике.
DP>Вот смотрите: даже сейчас нам понадобилось несколько сообщений туда-сюда, чтобы уточнить требования. И они все еще ясно не прописаны.
Вы понимаете разницу между сбором требований и нахождением путей решения? Что, по вашему мнению, занимает больше времени?
DP>Вот это S>>Вот из проекта. Нужно записи в базе привязать скрипт на одном из популярных ЯП с возможностью передавать в него данные строковые и возможностью в скрипте основных операций со строками и числами а так же делать определенные запросы к разрешенным сайтам. Нужно гарантировать что скрипт не выполнит вредоносных действий.
DP>И это S>>Скриптовый язык, который поддерживает основные операции со строками (поиск, конкатенация и т.д.), числами и возможность GET-запросов, но больше ничего не дозволяющий.
DP>Ну сильно отличающиеся вещи. Теперь стало более понятно что делать, но все-равно не до конца.
Это не сложно детализировать, причем делается все быстро.
А вот потом как решить — как воплотить в жизнь — это уже время.
DP>Я бы, например, уточнил, какой список операций нужен? Что скрывается за и т.д.?
Вот этот список операций со строками: https://metanit.com/java/tutorial/7.2.php
DP>Числа с плавающей точкой надо предусмотреть? Какие будут максимальные числа? Отрицательные могут быть?
Целые 64 битные со знаком. Основные 4 арифметические операции. Так же преобразование в/из строки.
DP>Только GET запросы? Что значит не дозволяющий? Должен выдавать ошибку? Какую?
Любую ошибку, не важно какую. Допустим Interpretation Error.
DP>Что по скорости работы? Какие планы по дальнейшему расширению? Нудна ли интеграция? Куда это будет встраиваться/интегрироваться? Какие ОСи поддерживать? Это должна быть CLI или прямо интерпретатор языка со своей грамматикой?
Скорость не критична. Развитие не требуется. Вызывать нужно из .Net Core на Ubuntu.
Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
DP>Это я все для примера. Не надо на них отвечать, пожалуйста.
Нет уж, я ответил и вы поймете что это много времени не займет. Время займет это сделать — ответил я бесплатно и спросили вы бесплатно. А теперь попробуйте сделать ЛЮБОЕ решение, которое удовлетворяет озвученным требоаниям!!! Фигли!!!
DP>И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
Это не занимает много времени. То что раз в неделю — это сугубо проблемы вашей организации.
DP>Вот как раз чтобы выудить из заказчика все нюансы и требования, и надо достаточно много времени. И это будет сделано не вами еще до того, как техническая задача на разработку дойдет до вас как разработчика/архитектора/тимлида.
Нет, не много и это делать легко. Вы только что у меня все узнали бесплатно. И я ответил бесплатно.
Станете ли вы бесплатно это выражать в коде? Фигли. Это работа надолго, а собрать требования — 3 минуты.
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Имхо, вот тут основная особенность, почему возникла эта тема и почему вы не понимаете и не слышите, что вам говорят тут нескольких человек. Дальше можно не продолжать.
абсолютно бесплатно. И я вам ответил, много времени не ушло.
А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
Re[12]: Сбор, систематизация и анализ требований vs кодирован
G>Еще раз повторю: писать свой поиск может 5-10 компаний в мире или очень богатые и не совсем здоровые люди.
... и даже там будет ооооочень много работы помимо не то что кодинга, но и всей разработки вместе взятой (архитектура, тестирование и т.д.). В частности, всякие юридические моменты, удовлетворение требований регуляторов в разных странах, какая-то ручная модерация и рассмотрение жалоб, обслуживание CI/CD/прода, обслуживание железа и куча всего.
Патриот здравого смысла
Re[14]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Это смешно. Это даже не студенческий уровень, тк даже там в лабораторных работах будет более четкое условие. А в реальном же мире с такими "требованиями" и "приемками" никто не работает.
Здравствуйте, gandjustas, Вы писали:
S>>Ну вот нашли вы 15 библиотек опенсорсных. Даже просто по 1 минуте посмотреть каждую из них — это 15 минут. А нужно не просто посмотреть. G>А что еще нужно?
Вникнуть в принципы работы, прочесть документацию, прочесть отзывы, собрать из исходников, создать тестовую среду и оценить какая лучше. Легко уходит неделя-две.
G>Открою тайну: подавляющее большинство того что называют "требованиями" как раз не описывают что нужно. Именно поэтому 85% времени уходит не на создание продуктивного кода. Именно поэтому нужна очень высокая квалификация чтобы помочь программистам не тратить свои 85% времени.
Даже если собрать точные требования — на реализацию все равно уйдет намного больше сил и времени. Да, не каждый может собрать. Часто и заказчик сам не знает что лучше — часть осознанно делают эксперименты и выкидывают решения, если не понравились на практике.
G>Причем каждое из этих требований займет 85% времени на анализ и лишь 15% на реализацию.
А что вы вкладываете в понятие "анализ требования"?
Re[15]: Сбор, систематизация и анализ требований vs кодирован
S>Вот этот список операций со строками: https://metanit.com/java/tutorial/7.2.php
Даже для юзер-стори нужно прописывать конкретный список.
S>Любую ошибку, не важно какую. Допустим Interpretation Error.
Вот тут нужно еще уточнять, даже в рамках юзер-стори.
S>Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
Мы собрали требования для одной юзер-стори, как я уже говорил. Такое делает команда технических инженеров и ПМа в рамках регулярных встреч (ака груминг/планирование/you name it). В рамках продукта это какая-то одна из сотен фич.
DP>>И таких итераций много. И это мы с вами достаточно быстро все решили. А представьте, что встречи с заказчиком проходят 1 раз в неделю.
S>Это не занимает много времени. То что раз в неделю — это сугубо проблемы вашей организации.
Причем тут моя организация?
Патриот здравого смысла
Re[15]: Сбор, систематизация и анализ требований vs кодирован
абсолютно бесплатно. И я вам ответил, много времени не ушло.
S>А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
Коллега, возможно, вам не хватает признания от коллег/руководства вас как разработчика. Так вот, могу с уверенностью сказать: работа программиста, и ваша, в частности, очень важна для любой компании! Она непростая и занимает много времени. И немногие могут с ней справиться.
Патриот здравого смысла
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
DP>Мы собрали требования для одной юзер-стори, как я уже говорил. Такое делает команда технических инженеров и ПМа в рамках регулярных встреч (ака груминг/планирование/you name it). В рамках продукта это какая-то одна из сотен фич.
Собрали требования мы бесплатно. Это мизер времени. Ну даже минут 15 если займет от силы — и то вряд ли.
А теперь подумайте сколько займет реализация. Отож — может легко занять и день, если найдете подходящее готовое решение, может занять и неделю — если решения не найдете.
В любом случае анализ требований — это процентов 5 работы. Обычно даже меньше.
Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, DiPaolo, Вы писали:
S>>А теперь подумайте сколько нужно времени, чтобы эти требования реализовать!!! Понимаете что реализовать намного сложнее и дольше — что это действительно работа, которую никто делать бесплатно не будет.
DP>Коллега, возможно, вам не хватает признания от коллег/руководства вас как разработчика. Так вот, могу с уверенностью сказать: работа программиста, и ваша, в частности, очень важна для любой компании! Она непростая и занимает много времени. И немногие могут с ней справиться.
DP>
Это просто суровая реальность. Высказать требования к любому проекту — да, важно и это экономит много средств. Однако же реализация — это основная часть времени и сил.
Даже житейский пример. Ремонт квартиры. Можете заказать детальный анализ ремонта на основе опыта бывалых, небезызвестный Земсков давно толкает такую услугу. Ну да, купите проект — так сказать анализ ваших требований. Возможно это и поможет сэкономить, однако же реальная работа — это сам ремонт, а не красивый анализ на бумаге. Более того — в процессе могут прийти решения лучшие, более подходящие.
Re[17]: Сбор, систематизация и анализ требований vs кодирован
S>Собрали требования мы бесплатно. Это мизер времени. Ну даже минут 15 если займет от силы — и то вряд ли.
S>А теперь подумайте сколько займет реализация. Отож — может легко занять и день, если найдете подходящее готовое решение, может занять и неделю — если решения не найдете.
S>В любом случае анализ требований — это процентов 5 работы. Обычно даже меньше.
S>Никто не спорит что это важно и может сэкономить время, если грамотно составлены требования и заказчик сам точно знает что нужно. Часто сам точно не знает и уже в процессе рождаются лучшие решения. Однако же не отменяет того факта, что сбор выполнить быстро и легко, а вот воплотить слова в жизнь — сложно и долго.
Это вы все про разработку. В нашем примере — разработку одной фичи из сотен.
А теперь еще раз обращаю ваше внимание, третий раз: изначально речь шла про разработку продукта, а не про кодинг. Разработка продукта состоит из разработки + другое. Разработка состоит из кодинга + другое.
Патриот здравого смысла
Re: Сбор, систематизация и анализ требований vs кодирование
.
S>Чел. ответственно заявляет — кодирование это 15% а вот "сбор, систематизация и анализ требований" — это основная часть работы.
S>Согласны с этим или нет? Что по вашему опыту?
S>То с чем я сталкивался — никто не проводил детального анализа до написания кода. Система обычно известна в общих чертах, примерно что хотят получить на выходе. Могут нарисовать и попытаться с умным видом описать детали — в при соотнесении с реальностью все рушится как карточный домик.
S>И только когда идея получает выражение в коде — только тогда появляются четкие вопросы, осознаются реальные проблемы и ищутся пути решения...
Вопрос поставлен общо, поэтому, в общем, да, соласен, кодирование порядка 15%.
Про систематизацию и анализ, тут все очень специфично, как ни странно, хотя вроде бы это фундаментальная вещь.
По моим наблюдениям существуют две взаимопротивоположные парадигмы. Первая — это то, что, мол, хорошо бы вначале
пообщаться с заказчиками и будущими пользователям, посмотреть на конкурентов, и в итоге предусмотреть как можно
больше ключевых моментов, которые затем сложно будет менять (ЯП, фрамеворк, архитектура и т.д.).
Вторая — это то, что всего сразу не предусмотришь, а выжить надо, поэтому делается то, что будет привлекать внимание и
генерить фидбек (МВП и т.д.).
Мне субьективно ближе первый подход. Но фейлов и успехов и той и другой парадигмы за 20 лет видел примерно одинаковое
количество. Кмк, большинство фейлов которые пришлось видеть были связаны с тем, что парадигма уже изначальна была заложена в разработку,
до или после слишком поверхностного знакомства с требованиями и ситуацией на рынке.
В то же время, если во главе проекта находится опытный человек (из разработчиков или из бизнеса, опыт должен быть
существенный), и сбор требований, МВП, фидбеки, анализ проводит как для себя (иными словами, если руководитель
нормально заинтересован, в том числе финансово), то проект взлетает хорошо, как минимум выходит в ноль при крайне неблагоприятных условиях.
Re[9]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, 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 ...
S>Так а что, из-за компрессии данных — уже не сможете за пол дня сделать? Сложно добавить 1 строчку кода gZip?
Две. На распаковку и на запаковку. И столько же (а то и больше) времени на прокрастинацию над требованиями. Например, нужно ли сжимать ключи записей или только их значения. Должна ли упаковка быть независимой для всех записей или группы могут сжиматься вместе (это влияет на итоговый объем). Видите, уже на требования потратил больше времени, чем на реализацию. В некоторых специальных условиях можно было бы и в одну строчку сделать — установить файлу атрибут storage compression, но опять же — нужно сначала выяснить требования и применимость. Это куча времени, gzip универсальнее.
S>Поймите что я таких как вы уже не первого наблюдаю — причем некоторые с 15 летним опытом. Думают что все легко и просто, пока не коснется практики.
Нормально у меня все с практикой. Не все легко и просто. Но то, что вы описываете — это такие мелочи. Которые для типичного проекта выливаются в придуманные внутренние проблемы. Т.е. очень часто приходится сначала выпилить кучу конфликтующих библиотек, обложенных костылями, и уже потом приступать к решению интересных задач на пересечении бизнеса и технологии. Самые интересные задачи возникают, когда есть с десяток разных требований к одному и тому же участку кода. Производительность, безопасность, потребление памяти, сопровождаемость и т.п.
S>Т.е. вы предлагаете не писать а использовать готовый инструмент — сортировку B-tree, которую использует ОС для файловой системы?
Ну не знаю, моя FS испольует htree. И API, которые я знаю, не гарантируют порядок обхода файлов в каталоге. Так что придется писать сортировку. Хотя я бы в памяти ключи сотритровал. Не было требования поддерживать объем ключей, который в память не влезает. А данные — так и быть, пусть их будет много.
S>Есть ли у вас осознание что именно вы предложили?
Я предложил минимальное решение, удовлетворяющее требованиям .
S>Операционная система — это тоже всего лишь программа. И вызывать ее функции — это тоже вызов своего рода библиотеки.
Нет. Это среда выполнения. Так просто от нее не отказаться. И, в отличие от библиотек, нельзя смешивать функции нескольких ОС в одном приложении.
S>Однако же вам нужно исследовать эту библиотеку, чтобы понять корректно ли она работает, к примеру, с большим количеством файлов в одной папке.
Нет. Не нужно. Не было такого требования, что среда выполнения работает некорректно. Поэтому по условиям задачи я могу хранить хоть триллионы файлов в одном каталоге. Не нравится? Можно протестировать конкретную ОС. Но пойдет это по статье "выяснение требований" — я будут тратить время на выяснение контекста, в котором должна работать библиотека. Да, я буду писать какой-то код. Но к коду библиотеки он не будет иметь никакого отношения. Это не кодирование.
S>В идеале вообще ничего писать не нужно — просто найти готовую систему. Второй случай — собрать систему из готовых библиотек. Третий случай — доработать готовые библитеки. Четвертый — писать самому.
Приоритет зависит от требований. Да, найти готовую систему (которая отвечает всем современным и будущим требованиям) — идеальный вариант. Только для этого нужно знать все требования. А обычно заказчик хочет "точно такую же систему, но с бриллиантовыми пуговицами". Начинаешь выяснять — выясняется, что решается вообще другая проблема и есть лучшее решение.
Re[15]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, Shmj, Вы писали:
S>Скорость не критична. Развитие не требуется. Вызывать нужно из .Net Core на Ubuntu. S>Все! Мы все требования собрали. 2 минуты ушло. А теперь подумайте сколько времени уйдет на реализацию!!!
Допустим, 4 дня мне на реализацию (я ленивый и имею склонность к идеализму в решениях) плюс один день кого-нибудь с форума, кто хорошо знает .NET. Эксплуатация будет вам стоить 30000$ в месяц.
Не верите? Архитектура и реализация следующая. Я пишу систему, которая через http принимает запросы с выражениями для вычисления (плюс basic authorization) и сохраняет их в базу. Я раз в день читают очередные запросы и очень тщательно лично выполняю (интерпретирую) их на бумажке. Могу curl'ом делать GET-запросы. Потом записываю результат выполнения скрипта в базу, где его может опросить скрипт. Все крутится в AWS (Postgresql RDS + Beanstalk + ELB). Помощь коллег будет нужна на написание клиента, который будет вызывать мой сервис и периодически опрашивать результаты. Собственно, всё. Эта архитектура удовлетворяет всем требованиям. Какие требования — такое и решение. Ничего особо сложного.
Re[16]: Сбор, систематизация и анализ требований vs кодирован
Здравствуйте, maxkar, Вы писали:
M>Здравствуйте, Shmj, Вы писали: M>Не верите? Архитектура и реализация следующая. Я пишу систему, которая через http принимает запросы с выражениями для вычисления (плюс basic authorization) и сохраняет их в базу. Я раз в день читают очередные запросы и очень тщательно лично выполняю (интерпретирую) их на бумажке. Могу curl'ом делать GET-запросы. Потом записываю результат выполнения скрипта в базу, где его может опросить скрипт. Все крутится в AWS (Postgresql RDS + Beanstalk + ELB). Помощь коллег будет нужна на написание клиента, который будет вызывать мой сервис и периодически опрашивать результаты. Собственно, всё. Эта архитектура удовлетворяет всем требованиям. Какие требования — такое и решение. Ничего особо сложного.
Свести к абсурду приёмами демагогии можно все что угодно. Есть здравый смысл и людям не нужно уточнять миллионы деталей, потому что пределы здравого смысла и так ясны.
.