нет простого ответа на проблему поставленную Вами в каментах. ИМХО это должна быть "бизнес" ориентированная среда разработки. Что я под этим понимаю, попробую объяснить утрированном примере. В жизни каждый из нас сталкивается с разными документами, а программисты которые каждый день манипулируют разного уровня абстракциями, до сих пор не разработали библиотеку с абстрактным классом документ и производными от него типами и видами документов, которые можно использовать и дописывать в разных проектах? Почему на описание, я не говорю про хранение, одного вида документа определенного типа, аналитик, проектант и кодировщик должны потратить по Х часов, вместо одной декларации "создать документ вида Приказ о приеме на работу типа приказ" или "создать документ вида Транспортная накладная типа накладная". При этом я ожидаю, что среда разработки сама знает какие таблицы в БД надо создать и в общем виде, что этот документ должен делать в системе и какие ему данные надо подпихнуть на вход, а что получить на выходе. Разве это я придумал, разве не законодательство страны в которой мы живем определило и законодательно закрепило функции и требования к этим документам? Вот вы обсуждаете сложность использования всяких всяких зависимостей, классов, библиотек, а это всё пустое с точки зрения бизнеса это ваша внутренняя кухня. Вы же в серьез не обсуждаете проблемы технологов выбиравших материал для коленвала вашего личного автомобиля. Бизнесу важно, чтобы приказ по кадрам манипулировал объектом сотрудник, а накладная манипулировала позицией номенклатуры в разрезе объекта хранения и не наоборот. Когда говоришь позиция номенклатуры содержит наименование товара и его характеристики, на тебя смотрят круглые недоуменные глаза и становящиеся еще более круглыми, когда вдруг внезапно до них доходит что это не просто текстовая переменная, а набор значений разного типа уникальный для каждого типа номенклатуры. А вы что ни кода не покупали туфли ХХ размера, черные, на шнурках или бензин АИ-95 не заливали в бак? Что непонятного и сверхъестественного я произнес и почему это очень сложные требования и требуют много времени на проектирование структуры данных и методов их обработки? Скажите где есть такая среда разработки, где не просто объявляются документы "счет" и "накладная", но еще и описывается их поведение в зависимости от порядка их создания и не путайте его с порядком в несения в учетную систему... Продолжать можно бесконечно.
Каждый из тех кто осилит этот камент, не сможет сказать, а я не знаю, что такое счет, да и накладной ни разу в глаза не видел потому, что для этого надо быть конем в сферическом вакууме. Так почему же тогда, ни одна из причастных к области автоматизации учета фирм, не создала ни какого инструментария содержащего в себе метаданные абстрактных объектов описывающих любую отрасль бизнеса? Ответ прост это дорого, в режиме "вендер-лок" такие затраты без сиюминутной отдачи, никто не потянет. А вот для себя, для облегчения программирования, отладки, тестирования, сколько опенсорс инструментария написано, пишется и будет написано. Но упростит это решение задач бизнеса и соответственно увеличит прибыль разработчика, я например сильно сомневаюсь. Уже дело дошло до того, что задания для тестировщика (!!!) выдаются - протестировать смену темы день/ночь. Скажите вот почему за эту чушь и неспособность решать такие мелочи, в итоге должен заплатить бизнес?
Скорее всего наши понятия, что такое хороший код, очень сильно отличаются, только потому, что Вы и я представители разных профессий. Вы оцениваете код по своим профессиональным параметрам, а я по потребительским.
Возможно, ваш проект просто кусок говнокода, за который разработчики не хотят браться, вот и ставят условия по поводу переписывания.
Вот!!! Вы сформулировали главную проблему. Кусок это или не кусок но: 1. Я заплатил за него не малые деньги, а не говнофантики. 2. Тогда, да и сейчас я не являюсь экспертом чтобы понять ..вно.. это или не ..вно... Жизнь научила что любой софт написанный не тем у кого спрашиваешь мнение - это говнокод. Так уж устроено сообщество программистов.
Вы сравниваете свою ситуацию "сейчас" с ситуацией "сейчас + костыли", но правда в том, что ваш проект никогда бы не достиг ситуации "сейчас + костыли" - эти костыли ему бы помешали.
я не покупал проект, я покупал инструмент для решения своих задач. Хотел и хочу пользоваться этим инструментом, но не могу.
К примеру, прошлая команда разработчиков разбежалась бы раньше.
Вот поэтому, ни на какой самый мега пупер революционный, суперсовременный "вендер-лок" продукт, я даже смотреть не буду, какие бы коврижки мне не обещали продаваны этого продукта. Обидно, что ситуация с разработкой для бизнеса не только не разрешается, а еще более усугубляется...
Ну вот мы используем специализированный инструмент для решения "бизнесовых задач". Специально для этого заточенный "от и до" - железо, операционка, язык. Высоконадежный, высокопроизводительный.
Я заранее прошу прощения и не имею желания Вас обидеть или задеть! Но именно примерно такие слова я слышал когда несколько лет назад заказал разработку продукта который открыт у меня на соседнем экране. С этими разработчиками ни чего не произошло, они в добром здравии, приятные в общении и хорошие по жизни люди, но это теперь не область интересов их коллектива. Они теперь работают на совершенно другими задачами. Поэтому:
А теперь вопрос к бизнесу - вы готовы закупить недешевую, вендер-лок платформу, заточенную под "решение бизнесовых задач"?
Не готов... Пока ваше решение не станет массовым, пока не будет понятна фактическая стоимость его сопровождения и доработки под новые требования, пока на сайте не исчезнет строка "Вам надо ХХХ рабочих мест - звоните мы рассчитаем", и еще много чего... Простите, но не готов даже вникать в чем фишка вашего решения, ибо время мое не резиновое. И еще одно замечание. Решения "вендер-лок" помимо несомненных плюсов имеет как минимум два очень больших минуса для заказчика. 1. Постоянно ощущение себя в роли подопытного кролика. 2. Меня, как заказчика, сажают на иглу. И даже если на практике мне это не выказывают, но я то все равно понимаю, что у меня нет альтернативы. За каждым чихом, мне обращаться только к одному вендору. А сколько чихов мне завтра подбросит правительство, налоговая, роструд и прочие ведомства ни я, ни вендор даже не представляем. Ну а если вендор бросил свой проект как экономически не выгодный, то для заказчика это просто выброшенные деньги, такой проект уж точно никто не подхватит. Брать на себя эти риски сейчас мало найдется желающих.
Еще раз повторюсь, ни кого не хочу обидеть или задеть. Я просто высказываю точку зрения с другой стороны.
Прошу прощения, но ваш совет не является чем-то умным. Это что-то из разряда, не довольны малым количеством мест стоянок для автомобилей, ходите пешком и у вас не будет проблемы где оставить авто.
Я рад, что вас пока полностью устраивает функциональность нового программного продукта, который копирует недостатки своего (очень старого) прообраза. Но есть очень много применений этого программного продукта, где эта "фича" зло злейшее, а разработчик даже не подумал о том, чтобы сделать хотя бы галочку для ее отключения. Я не говорю о более интеллектуальном её решении.
И да, давая совет использовать другой продукт, вы лишаете разработчиков денег тех пользователей которым эта фича мешает, поэтому не думаю, что они согласятся с предложенным вами методом решения проблемы.
Мне минусов наставили, не знаю получится ответить или нет.
...
Не нужно так сильно бояться перекомпиляции и переустановки.
Всё написанное Вами, я понимаю и даже частично согласен. Но прямо сейчас, на соседнем экране, у меня открыт пример того о чем вы пишите, написанный несколько лет назад. Мне надо добавить в него, с моей точки зрения мелочи, обусловленные текущим законодательством. И даже его исходники разработчики предоставили, но теперь это не их профиль. В результате другой разработчик написал мне пятистраничное и даже понятное не специалисту обоснование, почему этого нельзя сделать (библиотеки, фрэймворки, зависимости, конфликт версий и ядер и т.п.) и проще все переписать заново. Ладно говорю, а данные будут перелиты в новый продукт? О-о-о это отдельная тема и перелить так просто их нельзя потому, что на первых этапах еще не будет того функционала, что создал эти данные в старом продукте... Честно, находясь в этой ситуации я бы предпочел решение описанное вами в цитате:
А всяким желаниям сделать 'если поле в таблице начинается с "$", то там не значение имени пользователя стоит, а формула, по которой оно вычисляется, что делается....' - лучше сопротивляться.
И самое интересное, я не обвиняю ни предыдущих, ни новых разработчиков и понимаю почему так произошло в принципе. Самое страшное для меня то, что если я продолжу с новыми разработчиками, то через некоторое время неминуемо окажусь в точно такой же ситуации. Знакомство с внутренностями неуважаемого продукта, поразило меня тем, что там разработчик работает с понятиями номенклатура и ее характеристики, что есть объекты типа справочник и документ, что данные хранятся в регистрах сведений, остатков, движения и т.п. Я стал "понимать" (ну или точнее то представлять) как можно реализовать имеющийся функционал в этих объектах. Самое интересное и меня не грузят "библиотеками", а уточняют деталями то, что я себе на бумажечке нарисовал в этих объектах.
Вывод: Используемый для автоматизации бизнеса программный стэк, должен быть заточен под решение прикладных задач, иметь готовые объекты и модули реализующие типовые атомарные задачи и т.п. Тогда разработчик не будет тратить свое время и деньги заказчика на кописпаст обвязки каждой таблицы кучей тригеров и функций, тратя время в ущерб решению специфичных и уникальных для заказчика задач.
А ведь есть еще общие для бизнеса задачи, ну например обмен ЭДО между контрагентами, маркировки, ЭТД, электронная отчетность и т.п. И надо сказать это очень неудобное и непродуктивное занятие, прыгать между скомпилированными разными разработчиками модулями или между разными экранами браузера походу разбираясь в несовместимости версий и библиотек...
мы же за простоту и ORM принципиально с самого начала не используем...
Это подход разработчика. А я пишу со стороны заказчика. Поставленная задача должна быть решена и желательно не так чтобы на следующем этапе ее надо будет переписывать заново. Если честно, то мне не понятно и не интересно, почему сами разработчики усложнили себе жизнь написав кучи однотипных/различных фрэймворков, придумав стопитсот разных технологий якобы для облегчения своего труда, не придумали ни чего стандартизированного для решения конкретных "бизнесовых задач" за исключением одного, неуважаемого в определенных кругах продукта. Почему разработчики считают, что бизнес должен ставить им задачу познав дзен и предсказав как она будет выглядеть через несколько лет. Что впрочем всё равно не даст бизнесу сто процентную гарантию, что его задача будет решена, а не утонет в метаниях разработчика применять ORM или нет, использовать фрэймворк ХХХ или YYY, и т.д и т.п. Возможно я кого-то из программистов обижу, но если простейшее, понятное, обоснованное требование сделать дневной и ночной режим для пользовательского экрана, превратилось в серьезную проблему, на решение которой требуются месяцы а то и годы, то это значит программирование как отрасль производства, где свернуло не в ту сторону.
Зачем??? Сколько пользователей из нескольких миллионов заходящих, зайдут с проблемой отраженной в текущих сторис или разработчики считают, что граждане загружают приложение ради его изучения и просмотра сторис?
С точки зрения разработчика, Вы абсолютно правы, но есть ньюансы... С точки зрения потребителей начинает превалировать мнение "криворукие, недоучки, ничего своего придумать не могут. Даже ошибки исправить не в состоянии". Вопрос, а для кого разрабатывается этот продукт, чье мнение важнее??? Вот у меня на предприятии, мы не стали внедрять мой офис, по разным причинам. Нам не нужна монстроуозный и не дешевый продукт, напичканный функционалом который в 90% бесполезен в нашей модели использования.
Я больше про то, что все как-то постепенно движется к условной мысли вида 'а давайте формулы вычисления тарифов хранить в базе и конфигах, а то пока программисты напишут наши желания и протащат через все через тестирование - сто лет проходит. А так можно будет просто базу быстренько поправить да переконфигурировать'.
А ведь именно так и происходит. Именно по этой причине родился миф про могущество SAP а энтерпрайз автоматизации. А на самом деле сложность доработки собранных модулей заставила пойти их по пути - мы не автоматизируем ваши требования, мы учим вас работать в нашем продукте.
задачи написать нормальный язык для всего этого ни в какой момент не ставится
Ну хоть подходы к описанию предметных областей стали вырисовываться, посмотрите на доменную архитектуру платформы Гостех. Правда под капотом там все с ног на голову поставлено и родовые травмы видны уже сейчас. Но доменный подход к предметной области, ее систематизация целей, задач, наборов данных это реально серьезнейший шаг в сторону переориентации программирования ради программирования на программирование ради решения задач заказчика. Лучшей систематизации "бизнес требований" или другого подхода к этой задаче, я еще не видел.
что приложение становится интерпретатором медленного, кривого и проектируемого 'как получится' DSL языка, живущего где-то внутри баз данных и конфигов...
Ну да, оракал, посгресс и прочие им подобные (большие) БД смотрят на вас с удивлением... Они от своего рождения (лек так 30+) поддерживали классическую двухуровневую клиент-серверную архитектуру. Просто в какой-то момент, стало не модно писать бизнес логику в БД. Но есть продукты которые до сих пор именно так в них работают и решают свои задачи. Просто Вы указываете недостатки фактически единственного российского бизнес ориентрованного продукта. А других-то таких массовых нет.
ИМХО развитие ЭДО красноречиво показывает направление автоматизации учета в бизнесе. Лет через несколько, налоговая разродится облачным налоговым компилятором, которому на вход будут скармливать типизированные файлики электронных документов, а на выходе получать учетный и налоговый баланс предприятия. А из всех нынешних задач на локальном рабочем месте, останется только правильное отображение этих документов для конкретного юзера, да связь с этим компилятором... А вот кривые и косые интернет магазины продолжат плодиться как грибы после дождя еще долгое время, пока кто-нибудь в Гостехе не реализует типовой конструктор...
Чуть выше, в другой ветке, я написал «не работайте с такими постановщиками задач». Проблема для Вас заключается в том, что, если постановщик недалекий и неумный, то, как бы качественно вы не выполнили свою работу, результат будет один — бизнес будет недоволен работой такой команды.
А это уже явный сигнал к выносу этого в отдельный и легко в случае надобности заменяемый компонент, что и есть паттерн "стратегия"
Вот!!! Это понимание того, что для того чтобы писать для бизнеса, нужны соответствующие бизнес ориентированные библиотеки и наборы метаданных. Причем желательно заточенных под конкретную отрасль бизнеса. Но кто же будет тратить время на их написание, ведь за это бизнес не заплатит.
Проще ругать "не уважаемый продукт", но в нем вы можете не знать, что такое "номенклатура" и ее характеристики, но глянув описание этих метаданных вы поймете и будете использовать в своей доработке не сломав остальной работающий код. Я специально так завернул "доработке", дело в том, что любая программа это инструмент за который платит бизнес. И естественно бизнес хочет, чтобы его инструмент жил и развивался вместе с ним. Но большинство разработчиков, относится к результату своего труда, как к одноразовой работе - сделал и забыл...
...а от фазы Луны и високосного года?
будет добавлено еще одно измерение в этом же регистре "фаза луны" и простая функция расчета фазы для конкретного дня текущего (или любого другого) года. А високосный год или нет об этом знает сама платформа.
Спросите у любого бухгалтера, частотность 99,99% Проблема в том, что никто не думал сделать НОВЫЙ продукт, задача ставилась слизать готовый. А если бы думали, то как минимум бы ввели новый тип колонки - нумератор. А если бы еще подумали, то и шаблоны нумерации к этому типу прикрутили. Но мы же считаем, что в мелкософте боги и копировать надо только, что и как есть у них.
А в одном не любимом многими продукте, любой начинающий, создал бы регистр сведений состоящий из измерений "контрагент", "номенклатура" и ресурса "срок годности". Сам отбор номенклатуры для отгрузки конкретному контрагенту формировал бы с учетом этого регистра. А о том, что там юзеры конкретного бизнеса занесут в этот регистр, даже бы не парился...
Выше Вам ответили. Любые параметры бизнеса, не должны быть прописаны в коде. Если бизнес говорит "есть исключение", для Вас это означает, что вводимый как чье-то конкретное исключение параметр, в дальнейшем будет применяться как типовой для всех. Аналитики, проектировщики почему-то не понимают, что пока нет инструмента, бизнес хочет чтобы он появился побыстрее и поэтому не думает над тем, какие у него появятся хотелки, когда первая версия инструмента заработает.
Короче, все недостатки экселя плавно перетекли в "мой офис" Мне всегда интересно было, когда разрабатывается новый программный продукт, недостатки имеющихся, кто-нибудь изучает?
нет простого ответа на проблему поставленную Вами в каментах.
ИМХО это должна быть "бизнес" ориентированная среда разработки. Что я под этим понимаю, попробую объяснить утрированном примере.
В жизни каждый из нас сталкивается с разными документами, а программисты которые каждый день манипулируют разного уровня абстракциями, до сих пор не разработали библиотеку с абстрактным классом документ и производными от него типами и видами документов, которые можно использовать и дописывать в разных проектах?
Почему на описание, я не говорю про хранение, одного вида документа определенного типа, аналитик, проектант и кодировщик должны потратить по Х часов, вместо одной декларации "создать документ вида Приказ о приеме на работу типа приказ" или "создать документ вида Транспортная накладная типа накладная".
При этом я ожидаю, что среда разработки сама знает какие таблицы в БД надо создать и в общем виде, что этот документ должен делать в системе и какие ему данные надо подпихнуть на вход, а что получить на выходе.
Разве это я придумал, разве не законодательство страны в которой мы живем определило и законодательно закрепило функции и требования к этим документам?
Вот вы обсуждаете сложность использования всяких всяких зависимостей, классов, библиотек, а это всё пустое с точки зрения бизнеса это ваша внутренняя кухня. Вы же в серьез не обсуждаете проблемы технологов выбиравших материал для коленвала вашего личного автомобиля.
Бизнесу важно, чтобы приказ по кадрам манипулировал объектом сотрудник, а накладная манипулировала позицией номенклатуры в разрезе объекта хранения и не наоборот.
Когда говоришь позиция номенклатуры содержит наименование товара и его характеристики, на тебя смотрят круглые недоуменные глаза и становящиеся еще более круглыми, когда вдруг внезапно до них доходит что это не просто текстовая переменная, а набор значений разного типа уникальный для каждого типа номенклатуры. А вы что ни кода не покупали туфли ХХ размера, черные, на шнурках или бензин АИ-95 не заливали в бак?
Что непонятного и сверхъестественного я произнес и почему это очень сложные требования и требуют много времени на проектирование структуры данных и методов их обработки?
Скажите где есть такая среда разработки, где не просто объявляются документы "счет" и "накладная", но еще и описывается их поведение в зависимости от порядка их создания и не путайте его с порядком в несения в учетную систему...
Продолжать можно бесконечно.
Каждый из тех кто осилит этот камент, не сможет сказать, а я не знаю, что такое счет, да и накладной ни разу в глаза не видел потому, что для этого надо быть конем в сферическом вакууме. Так почему же тогда, ни одна из причастных к области автоматизации учета фирм, не создала ни какого инструментария содержащего в себе метаданные абстрактных объектов описывающих любую отрасль бизнеса?
Ответ прост это дорого, в режиме "вендер-лок" такие затраты без сиюминутной отдачи, никто не потянет. А вот для себя, для облегчения программирования, отладки, тестирования, сколько опенсорс инструментария написано, пишется и будет написано. Но упростит это решение задач бизнеса и соответственно увеличит прибыль разработчика, я например сильно сомневаюсь.
Уже дело дошло до того, что задания для тестировщика (!!!) выдаются - протестировать смену темы день/ночь. Скажите вот почему за эту чушь и неспособность решать такие мелочи, в итоге должен заплатить бизнес?
Скорее всего наши понятия, что такое хороший код, очень сильно отличаются, только потому, что Вы и я представители разных профессий.
Вы оцениваете код по своим профессиональным параметрам, а я по потребительским.
Вот!!! Вы сформулировали главную проблему. Кусок это или не кусок но:
1. Я заплатил за него не малые деньги, а не говнофантики.
2. Тогда, да и сейчас я не являюсь экспертом чтобы понять ..вно.. это или не ..вно...
Жизнь научила что любой софт написанный не тем у кого спрашиваешь мнение - это говнокод. Так уж устроено сообщество программистов.
я не покупал проект, я покупал инструмент для решения своих задач. Хотел и хочу пользоваться этим инструментом, но не могу.
Вот поэтому, ни на какой самый мега пупер революционный, суперсовременный "вендер-лок" продукт, я даже смотреть не буду, какие бы коврижки мне не обещали продаваны этого продукта.
Обидно, что ситуация с разработкой для бизнеса не только не разрешается, а еще более усугубляется...
Я заранее прошу прощения и не имею желания Вас обидеть или задеть! Но именно примерно такие слова я слышал когда несколько лет назад заказал разработку продукта который открыт у меня на соседнем экране. С этими разработчиками ни чего не произошло, они в добром здравии, приятные в общении и хорошие по жизни люди, но это теперь не область интересов их коллектива. Они теперь работают на совершенно другими задачами.
Поэтому:
Не готов...
Пока ваше решение не станет массовым, пока не будет понятна фактическая стоимость его сопровождения и доработки под новые требования, пока на сайте не исчезнет строка "Вам надо ХХХ рабочих мест - звоните мы рассчитаем", и еще много чего...
Простите, но не готов даже вникать в чем фишка вашего решения, ибо время мое не резиновое.
И еще одно замечание. Решения "вендер-лок" помимо несомненных плюсов имеет как минимум два очень больших минуса для заказчика.
1. Постоянно ощущение себя в роли подопытного кролика.
2. Меня, как заказчика, сажают на иглу.
И даже если на практике мне это не выказывают, но я то все равно понимаю, что у меня нет альтернативы. За каждым чихом, мне обращаться только к одному вендору. А сколько чихов мне завтра подбросит правительство, налоговая, роструд и прочие ведомства ни я, ни вендор даже не представляем. Ну а если вендор бросил свой проект как экономически не выгодный, то для заказчика это просто выброшенные деньги, такой проект уж точно никто не подхватит.
Брать на себя эти риски сейчас мало найдется желающих.
Еще раз повторюсь, ни кого не хочу обидеть или задеть. Я просто высказываю точку зрения с другой стороны.
Прошу прощения, но ваш совет не является чем-то умным. Это что-то из разряда, не довольны малым количеством мест стоянок для автомобилей, ходите пешком и у вас не будет проблемы где оставить авто.
Я рад, что вас пока полностью устраивает функциональность нового программного продукта, который копирует недостатки своего (очень старого) прообраза.
Но есть очень много применений этого программного продукта, где эта "фича" зло злейшее, а разработчик даже не подумал о том, чтобы сделать хотя бы галочку для ее отключения. Я не говорю о более интеллектуальном её решении.
И да, давая совет использовать другой продукт, вы лишаете разработчиков денег тех пользователей которым эта фича мешает, поэтому не думаю, что они согласятся с предложенным вами методом решения проблемы.
Мне минусов наставили, не знаю получится ответить или нет.
Всё написанное Вами, я понимаю и даже частично согласен. Но прямо сейчас, на соседнем экране, у меня открыт пример того о чем вы пишите, написанный несколько лет назад. Мне надо добавить в него, с моей точки зрения мелочи, обусловленные текущим законодательством. И даже его исходники разработчики предоставили, но теперь это не их профиль. В результате другой разработчик написал мне пятистраничное и даже понятное не специалисту обоснование, почему этого нельзя сделать (библиотеки, фрэймворки, зависимости, конфликт версий и ядер и т.п.) и проще все переписать заново. Ладно говорю, а данные будут перелиты в новый продукт? О-о-о это отдельная тема и перелить так просто их нельзя потому, что на первых этапах еще не будет того функционала, что создал эти данные в старом продукте...
Честно, находясь в этой ситуации я бы предпочел решение описанное вами в цитате:
И самое интересное, я не обвиняю ни предыдущих, ни новых разработчиков и понимаю почему так произошло в принципе. Самое страшное для меня то, что если я продолжу с новыми разработчиками, то через некоторое время неминуемо окажусь в точно такой же ситуации.
Знакомство с внутренностями неуважаемого продукта, поразило меня тем, что там разработчик работает с понятиями номенклатура и ее характеристики, что есть объекты типа справочник и документ, что данные хранятся в регистрах сведений, остатков, движения и т.п. Я стал "понимать" (ну или точнее то представлять) как можно реализовать имеющийся функционал в этих объектах. Самое интересное и меня не грузят "библиотеками", а уточняют деталями то, что я себе на бумажечке нарисовал в этих объектах.
Вывод: Используемый для автоматизации бизнеса программный стэк, должен быть заточен под решение прикладных задач, иметь готовые объекты и модули реализующие типовые атомарные задачи и т.п. Тогда разработчик не будет тратить свое время и деньги заказчика на кописпаст обвязки каждой таблицы кучей тригеров и функций, тратя время в ущерб решению специфичных и уникальных для заказчика задач.
А ведь есть еще общие для бизнеса задачи, ну например обмен ЭДО между контрагентами, маркировки, ЭТД, электронная отчетность и т.п. И надо сказать это очень неудобное и непродуктивное занятие, прыгать между скомпилированными разными разработчиками модулями или между разными экранами браузера походу разбираясь в несовместимости версий и библиотек...
Это подход разработчика.
А я пишу со стороны заказчика. Поставленная задача должна быть решена и желательно не так чтобы на следующем этапе ее надо будет переписывать заново.
Если честно, то мне не понятно и не интересно, почему сами разработчики усложнили себе жизнь написав кучи однотипных/различных фрэймворков, придумав стопитсот разных технологий якобы для облегчения своего труда, не придумали ни чего стандартизированного для решения конкретных "бизнесовых задач" за исключением одного, неуважаемого в определенных кругах продукта.
Почему разработчики считают, что бизнес должен ставить им задачу познав дзен и предсказав как она будет выглядеть через несколько лет. Что впрочем всё равно не даст бизнесу сто процентную гарантию, что его задача будет решена, а не утонет в метаниях разработчика применять ORM или нет, использовать фрэймворк ХХХ или YYY, и т.д и т.п.
Возможно я кого-то из программистов обижу, но если простейшее, понятное, обоснованное требование сделать дневной и ночной режим для пользовательского экрана, превратилось в серьезную проблему, на решение которой требуются месяцы а то и годы, то это значит программирование как отрасль производства, где свернуло не в ту сторону.
Зачем???
Сколько пользователей из нескольких миллионов заходящих, зайдут с проблемой отраженной в текущих сторис или разработчики считают, что граждане загружают приложение ради его изучения и просмотра сторис?
С точки зрения разработчика, Вы абсолютно правы, но есть ньюансы...
С точки зрения потребителей начинает превалировать мнение "криворукие, недоучки, ничего своего придумать не могут. Даже ошибки исправить не в состоянии".
Вопрос, а для кого разрабатывается этот продукт, чье мнение важнее???
Вот у меня на предприятии, мы не стали внедрять мой офис, по разным причинам. Нам не нужна монстроуозный и не дешевый продукт, напичканный функционалом который в 90% бесполезен в нашей модели использования.
А ведь именно так и происходит. Именно по этой причине родился миф про могущество SAP а энтерпрайз автоматизации. А на самом деле сложность доработки собранных модулей заставила пойти их по пути - мы не автоматизируем ваши требования, мы учим вас работать в нашем продукте.
Ну хоть подходы к описанию предметных областей стали вырисовываться, посмотрите на доменную архитектуру платформы Гостех. Правда под капотом там все с ног на голову поставлено и родовые травмы видны уже сейчас. Но доменный подход к предметной области, ее систематизация целей, задач, наборов данных это реально серьезнейший шаг в сторону переориентации программирования ради программирования на программирование ради решения задач заказчика.
Лучшей систематизации "бизнес требований" или другого подхода к этой задаче, я еще не видел.
Ну это если юзеры начнут активно менять значения сроков годности для номенклатуры или фаз луны для контрагентов, а может быть и номенклатуры... :-)))
Ну да, оракал, посгресс и прочие им подобные (большие) БД смотрят на вас с удивлением... Они от своего рождения (лек так 30+) поддерживали классическую двухуровневую клиент-серверную архитектуру. Просто в какой-то момент, стало не модно писать бизнес логику в БД. Но есть продукты которые до сих пор именно так в них работают и решают свои задачи.
Просто Вы указываете недостатки фактически единственного российского бизнес ориентрованного продукта. А других-то таких массовых нет.
ИМХО развитие ЭДО красноречиво показывает направление автоматизации учета в бизнесе. Лет через несколько, налоговая разродится облачным налоговым компилятором, которому на вход будут скармливать типизированные файлики электронных документов, а на выходе получать учетный и налоговый баланс предприятия. А из всех нынешних задач на локальном рабочем месте, останется только правильное отображение этих документов для конкретного юзера, да связь с этим компилятором...
А вот кривые и косые интернет магазины продолжат плодиться как грибы после дождя еще долгое время, пока кто-нибудь в Гостехе не реализует типовой конструктор...
Чуть выше, в другой ветке, я написал «не работайте с такими постановщиками задач». Проблема для Вас заключается в том, что, если постановщик недалекий и неумный, то, как бы качественно вы не выполнили свою работу, результат будет один — бизнес будет недоволен работой такой команды.
Вот!!! Это понимание того, что для того чтобы писать для бизнеса, нужны соответствующие бизнес ориентированные библиотеки и наборы метаданных. Причем желательно заточенных под конкретную отрасль бизнеса. Но кто же будет тратить время на их написание, ведь за это бизнес не заплатит.
Проще ругать "не уважаемый продукт", но в нем вы можете не знать, что такое "номенклатура" и ее характеристики, но глянув описание этих метаданных вы поймете и будете использовать в своей доработке не сломав остальной работающий код.
Я специально так завернул "доработке", дело в том, что любая программа это инструмент за который платит бизнес. И естественно бизнес хочет, чтобы его инструмент жил и развивался вместе с ним. Но большинство разработчиков, относится к результату своего труда, как к одноразовой работе - сделал и забыл...
будет добавлено еще одно измерение в этом же регистре "фаза луны" и простая функция расчета фазы для конкретного дня текущего (или любого другого) года. А високосный год или нет об этом знает сама платформа.
Спросите у любого бухгалтера, частотность 99,99%
Проблема в том, что никто не думал сделать НОВЫЙ продукт, задача ставилась слизать готовый.
А если бы думали, то как минимум бы ввели новый тип колонки - нумератор. А если бы еще подумали, то и шаблоны нумерации к этому типу прикрутили.
Но мы же считаем, что в мелкософте боги и копировать надо только, что и как есть у них.
А в одном не любимом многими продукте, любой начинающий, создал бы регистр сведений состоящий из измерений "контрагент", "номенклатура" и ресурса "срок годности". Сам отбор номенклатуры для отгрузки конкретному контрагенту формировал бы с учетом этого регистра. А о том, что там юзеры конкретного бизнеса занесут в этот регистр, даже бы не парился...
Выше Вам ответили.
Любые параметры бизнеса, не должны быть прописаны в коде. Если бизнес говорит "есть исключение", для Вас это означает, что вводимый как чье-то конкретное исключение параметр, в дальнейшем будет применяться как типовой для всех.
Аналитики, проектировщики почему-то не понимают, что пока нет инструмента, бизнес хочет чтобы он появился побыстрее и поэтому не думает над тем, какие у него появятся хотелки, когда первая версия инструмента заработает.
Короче, все недостатки экселя плавно перетекли в "мой офис"
Мне всегда интересно было, когда разрабатывается новый программный продукт, недостатки имеющихся, кто-нибудь изучает?
Так это контент, а что собственно из функционала обновлено?
Не работайте с такими постановщиками!!!
Как только вы это напишите, залетит желание на 72 и 52,5 процента, причем для каждого клиента индивидуально...
Ага, чтобы так сразу в 152ФЗ с головой нырнуть и не вынырнуть...
А еще паспорта могут менять...