s0ci0pat: на больших междунородных проектах просто эти "цели" достигаются чуть разными методами и все.
Вы смешали бизнес анализ и юриспруденцию. У вас уже есть доменные-эксперты (владельцы бизнеса) которые прекрасно знают что как в законодательстве какой страны и т.д. и команда разработчиков на основе своего опыта из знаний клиента формируют требования (ну и затем их реализуют).
Ну нежно совсем уж утрировать и подменять понятия. Все намного проще. Клиенты обычно не такие уж тупые чуваки, они могут не смыслить в разработке но это уже ваша задача объяснять вам что к чему.
. А через год вышли изменения в законе, который не позволял это ПО использовать
Это определенные риски, которые несет банк. Разработчики максимум что могут сделать - сделать систему гибкой для внесения изменений. В целом я не знаком с банковским сектором в странах СНГ и для меня кажется чуть более чем не реально что какой-то закон вышел и об этом узнали вот так вот резко. Для СНГ это может и норма но не для остального мира. Так что опять же... это все исключения из правил и т.д. Что взять если законотворцы дурные?
Это риски, которые несут на себе компании, работающие на нестабильных рынках с неразвитым законодательством. Так что позвольте оптатить всю работу и закрыть проект. Стартапы тоже закрываются частенько.
Короче хватит пичкать меня неправильными реалиями СНГ-шных гос проектов и т.д. Как я уже говорил - там все просто плохо. В остальном же цивилизованном мире - все относительно неплохо.
s0ci0pat: Ваш этот "архитектор" просто еще не дорос до мысли что "говнокод это нормально, если оно работает и не мешает масштабированию системы". Подобный перфекционизм это болезнь такая же как и отсутствие этого перфекционизма. Все должно быть вмеру.
Опять же рвение писать идеальный код (которого на самом деле не бывает) - это отсутствие желания решать проблемы бизнеса эффективно (иногда надо идти на компромисы, учитывая все переменные).
По поводу проектов с "секретностью" - сложно... я таких не встречал и мне сложно представить как в таких условиях работать. Единственное что я понимаю что на таких проектах очень детализированные требования и очень качественное тестирование должны проводиться (военная промышленность например).
По поводу междунородных проектов - не путайте цели бизнеса и законодательства. Для каждой страны просто будет все по разному. Разработчики к законадательству или правительству никакого отношения не имеет.
По поводу вопросов при найме сотрудников - ну как бы... да. Чувак разберется с предметной областью на том уровне на котором ему нужно.
И да, я не знаю ничего о тех "больших" проектах где вы работали (у разных людей разный опыт) но на сегодняшний день есть тенденция дробления больших проектов на микросервисы с маленькими командами и погруженностью разработчиков в бизнес логику, практики continuous improvement, lean и т.п. И погружаются разработчики в ту часть бизнес логики и бизнес процессов, на которую ориентируется их задача. Конечно на одном уровне со стэкхолдерами говорить они не смогут но отдельные вещи понимать будут. Будут формировать единый язык и все такое.
Вы пробовали работать по BDD? Я - да. И я знаю массу команд которые успешно применяют эти подходы. То есть там и клиент и разработчики обсуждают требования, предлагают идеи и т.д. Может быть будет отдельный бизнес аналитик который будет описывать требования и спускать их разработчикам. И да, эти подходы не для 100% случаев, серебрянной пули нет. Скажем ваш пример с "секретностью" весьма показателен. Я с этим не сталкивался и как-то даже не задумывался о подобных проектах и о подходах к разработке на оных.
В целом я понял... я похоже говорю о сферическом девелопере в реалиях кросс-функциональных команд (аля agile) вы же концентрируете внимание на чуваке который пишет код. Если так то программист это чувак который пишет код. Причем любой чувак который пишет код - программист.
s0ci0pat: ну как бы да, абстрактного программиста. Как по вашему еще можно формировать терминологию? Как по мне ориентироваться на "как должно быть" лучше чем на "как есть и причем не везде а в определенных ареалах обитания"
s0ci0pat: ну я на российский рынок не ориентируюсь. По сути там дела обстоят так же как и в остальном мире лет 10 назад (а то и больше).
В целом мое виденье мира - хороший программист должен уметь делать бизнес анализ, QA-ить и т.д. Другое дело что один человек все не в состоянии продумать потому появляются концепции трех амиго (продукт оунер, разработчик, qa). На большом проекте выгодно выделить отдельно бизнес аналитика и т.д. но разработчики должны быть в процесс бизнес анализа вовлечены хотя бы минимально. Ну и короч уже там дальше идут варианты.
Есть так же BDD и DDD которые на разных уровнях решают вопрос коммуникации при формировании и реализации требований. Ну и т.д.
Yaroslav Lyzlov: в принципе вы же сами ссылку на статью приводите. Там просто несколько стратегий для отслеживания изменений (что круто на самом деле).
Тут большая разница в том как происходит отслеживание изменений, разные стратегии для разных вариантов хранения данных дадут разную производительность. Дерти чекинг всеравно будет юзаться хотя бы как полифил для других стратегий.
lega: ну как таковой сущности $scope как это было в angular1 там нет. Но где-то внутри наверняка какая-то viewmodel есть (биндинги ж). Работают просто они чуть по другому. Вообще это надо пожалуй поковыряться будет и разобраться а не строить предположения.
Ну по поводу твоей идеи - годная, но я просто стараюсь не плодить иерархию прототипов большую. А в целом у меня приложеньки небольшие, и оптимизации подобные для меня погоды много не сделают.
Yaroslav Lyzlov: это как бы не суть важно. Просто убрали deep-watch что правильно. В общем и целом картина остается той же, просто убить производительность становится много сложнее так как идет простое сравнение ссылок.
s0ci0pat: ну давайте так. Програмист задаст вопросы, а как вы сейчас работаете? А где у вас узкие места и т.д. Ну то есть еще еще бизнес анализ. Бизнес анализом может заниматься как отдельный человек так и сам программист (обычно эти чуваки дороже). Ну то есть вы описали начало, адекватные люди потом вытягивают из клиента информацию. "увеличение продаж" это основная цель, как это сделать это уже другая штука.
На днях смотрел интервью с Робертом Мартином, и там как раз поднимался вопрос "кто такие программисты". Он назвал это основной проблемой отрасли так как профессии "программист" не существует. Нет никаких регламентирующих органов, любой кто написал простенькую програмку может назвать себя программистом. В принципе мы можем долго рассуждать о философской подоблеки но всеравно эта ситуация не изменится.
BakInRR: свой собственный уникальный IP адрес в пределах конкретной подсети. Это только с IPv6 у вас для каждого калькулятора можно IP уникальный выделять.
Nominom: псевдоязыки как раз таки норм, что бы люди научились алгоритмы строить а не код писать.
Опять же... вы хотите детский сад или специалистов готовить? В формате курсов выхлоп от этих "дополнительных" знаний будет нулевым, только больше мусора в голове будет. Подавляющее большинство людей которые идут на эти курсы хотят какой-то толчек. Сами курсы им "фундаментальных знаний" не дадут. Для этого как я уже говорил нужен минимум год. А на годовые курсы никто не пойдет.
Nominom: ну так это же проблема системы образования в целом, вы не находите? Да и как показывает практика далеко не всем просто дано это все. Многие люди просто не в состоянии постич общую картину и связать знания из одной области и другой.
Большинство сейчас идут в IT только ради денег, и им не выгодно вбивать в голову основы основ потому что выхлоп будет нулевой. Просто не поймут, они ради денег пришли в отрасль. Им это все не интересно. Идеальные код-манки. И рынок их проглотит и даже не заметит.
