Плюсую. Но на самом деле сначала пишется техническое задание. Заказчик (министерство, минобороны) разрабатывает совместно с генеральным конструктором.
ГОСТ 34.602-89, ГОСТ Р 2.114-2016, ГОСТ 19.201-78
Потом уже, когда параметры изделия определены, определены финансы, сроки, исполнители, это ТЗ передается проектировщикам.
И я бы да, поугарал бы, когда слесарь-сборщик (это, если что, сеньор-разработчик в нашем контексте, начал бы звонить в минобороны и убеждать, что надо вот так деталь выточить, уж он-то лучше знает).
Совершенно верно. В маленьких шаражках, мастерских и гаражных кооперативах, варящих оградки и решетки на окна, например, один и тот-же человек и "проектирует" оградку, и считает материалы, и режет и варит, и красит.
А когда стоит задача построить ракету и запустить ее в космос (с прошедшим, кстати!), такая система недопустима.
А в ИТ (по крайней мере, у нас) нормально, когда стартап на три человека вырастает до пятисот разработчиков, а методы разработки остаются на уровне стартапа, точнее, средневекового цеха с "фуллстек" мастерами.
На Западе, кстати, проблема реорганизации при увеличении конторы решается продажей Ораклу и слияние шаражки в корпорацию.
Мне кажется, вы все в кучу смешали. Точнее, у вас, как почти везде в ИТ, организация на уровне средневековых цехов, когда мастер делал все, начиная от придумывания ружья, и заканчивая изготовлением всех деталей.
Не надо проектирование архитектуры и системы смешивать с реализацией. SOLID, GOF, ООП - это реализация. Проектирование систем - это отдельно.
Вы работаете или проектировщиком, либо работаете разработчиком. Соответственно, и инструменты разные, и мышление, и примемы. Всё разное.
В современном мире (точнее, уже в прошлом веке) одни люди проектируют ракету, другие - изготавливают её.
Естественно, у вас возникает ощущение "мы откуда-то сверху должны знать". Ну и прочие "показывают, как писать".
Естественно. У вас, как разработчика, задача - реализовать УЖЕ СПРОЕКТИРОВАННУЮ систему.
От этой порочной практики современного ИТ, когда сеньор и придумывает систему, и разговаривает с заказчиками, и проектирует систему, и реализовывает ее в коде - надо отходить, в сторону специализации.
ТО есть, для строительства нормально, когда на середине строительства заказчик вместо пятиэтажки вдруг решил, что ему надо небоскреб (за те-же деньги, бгг) - то окружающие только пальцем у виска покрутят.
А в ИТ если заказчик просил простенький сайт-визитку и вы наполовину уже сделали, а потом заказчик вдруг потребовал соцсеть на десять миллионов пользователей - то вы с готовностью беретесь доделывать, потому что ответ "нет технической возможности" будет означать провал проекта?
Многоэтажки ремонтируются, реновируются, перестраиваются. Придомовая территория благоустраивается. Водопровод, электрооборудование, тепло - меняется, модернизируется. И все это делается по проекту, с составлением смет, сроков, стоимостей. Считаются деньги. Согласовываются и выделяются деньги (ну и воруются, бгг). И только в ИТ, я повторяю, с планированием и экономикой бардак фееричный.
Не нравится пример со строительством - берите судостроение. Военно-морской флот. Строются по проекту. Модернизируется и перевооружается флот по проекту. Соответственно, техническое задание, проект, сметы, стоимость, сроки.
Такой стиль - это от недоразвитости ИТ-индустрии. В машиностроении такого нет. Там все делается по проекту. Проектная документация ПОЛНОСТЬЮ определяет, каким необходимо изготовить изделие. Нынешний стиль работы сеньора - это как каменщик-шабашник, который обсуждает с частником, как надо выложить дом.
В ИТ я даже техническое задание на "изделие" нечасто вижу.
Как только в ИТ придет (а я надеюсь на это) методика, когда программную систему реализуют полностью по проектной документации, ТОЧНО по проекту, что сеньоры, что рядовые "каменщики" будут не "общаться с людьми" а работать.
Не люблю тернарники в таком вот виде. Во-первых, тернарник создает больше когнитивной нагрузки, чем простой if. Считаю, что каждый оператор (x-y и x+y) должны быть каждый на своей строке. При добавлении даже малейшего условия в любую ветку, этот тернарник мгновенно увеличивается и становится катастрофично нечитаемым и неподдерживаем. В обычном if он как был прост в прочтении, так и остался, разве что чуть увеличился.
Снижать нужно когнитивную нагрузку, а не количество строк.
Тернарник хорош при ВЫБОРЕ значения из двух переменных. В качестве структуры управления потоком выполнения программы применять его нельзя.
Хорошая подборка. Единственно, у меня вызывает сомнения, что сервис, который при невозможности выполнить операцию ввиду недоступности "подрядчика", возвращает что попало (нулевой остаток) - это "отказоустойчивость". Эти "чтопопало" потом уйдут в базу, пойдут гулять по бизнес-процессам, и потом сам черт ногу сломит их выкорчевывать и объяснять клиентам, почему такие странные данные в базе. Имхо, если операция не может правильно выполниться, дальше продолжать бизнес-процесс нельзя с некондиционными данными. Исключение - отображение на экране каких-то данных или наличие функционала. Не работает микросервис добавления комментариев и прочей некритической информации и функционала - панель добавления комментариев не должна отображаться.
Серьезные GUI под десктоп надо писать на Delphi (или какой у него сейчас преемник?).
Ради бога, не отправляйте туда никаких сигралов.
Плюсую. Но на самом деле сначала пишется техническое задание. Заказчик (министерство, минобороны) разрабатывает совместно с генеральным конструктором.
ГОСТ 34.602-89, ГОСТ Р 2.114-2016, ГОСТ 19.201-78
Потом уже, когда параметры изделия определены, определены финансы, сроки, исполнители, это ТЗ передается проектировщикам.
И я бы да, поугарал бы, когда слесарь-сборщик (это, если что, сеньор-разработчик в нашем контексте, начал бы звонить в минобороны и убеждать, что надо вот так деталь выточить, уж он-то лучше знает).
А как foreighn key?
В договорной подсистеме accountId, в расчетной подсистеме accountId. Таблицы УЖЕ связаны. При удалении (условно говоря) account надо удалять все bill.
Где ограниченность, где отсутствие связности?
Совершенно верно. В маленьких шаражках, мастерских и гаражных кооперативах, варящих оградки и решетки на окна, например, один и тот-же человек и "проектирует" оградку, и считает материалы, и режет и варит, и красит.
А когда стоит задача построить ракету и запустить ее в космос (с прошедшим, кстати!), такая система недопустима.
А в ИТ (по крайней мере, у нас) нормально, когда стартап на три человека вырастает до пятисот разработчиков, а методы разработки остаются на уровне стартапа, точнее, средневекового цеха с "фуллстек" мастерами.
На Западе, кстати, проблема реорганизации при увеличении конторы решается продажей Ораклу и слияние шаражки в корпорацию.
Мне кажется, вы все в кучу смешали. Точнее, у вас, как почти везде в ИТ, организация на уровне средневековых цехов, когда мастер делал все, начиная от придумывания ружья, и заканчивая изготовлением всех деталей.
Не надо проектирование архитектуры и системы смешивать с реализацией. SOLID, GOF, ООП - это реализация. Проектирование систем - это отдельно.
Вы работаете или проектировщиком, либо работаете разработчиком. Соответственно, и инструменты разные, и мышление, и примемы. Всё разное.
В современном мире (точнее, уже в прошлом веке) одни люди проектируют ракету, другие - изготавливают её.
Естественно, у вас возникает ощущение "мы откуда-то сверху должны знать". Ну и прочие "показывают, как писать".
Естественно. У вас, как разработчика, задача - реализовать УЖЕ СПРОЕКТИРОВАННУЮ систему.
От этой порочной практики современного ИТ, когда сеньор и придумывает систему, и разговаривает с заказчиками, и проектирует систему, и реализовывает ее в коде - надо отходить, в сторону специализации.
В смысле? А какой он должен быть? Пластмассовым? Стальная коробка с хорошей защитой. Скажите спасибо, что корпус не из литого алюминия.
ТО есть, для строительства нормально, когда на середине строительства заказчик вместо пятиэтажки вдруг решил, что ему надо небоскреб (за те-же деньги, бгг) - то окружающие только пальцем у виска покрутят.
А в ИТ если заказчик просил простенький сайт-визитку и вы наполовину уже сделали, а потом заказчик вдруг потребовал соцсеть на десять миллионов пользователей - то вы с готовностью беретесь доделывать, потому что ответ "нет технической возможности" будет означать провал проекта?
"Черный лебедь" читал. Унылая писанина об очевидных вещах.
Многоэтажки ремонтируются, реновируются, перестраиваются. Придомовая территория благоустраивается. Водопровод, электрооборудование, тепло - меняется, модернизируется. И все это делается по проекту, с составлением смет, сроков, стоимостей. Считаются деньги. Согласовываются и выделяются деньги (ну и воруются, бгг). И только в ИТ, я повторяю, с планированием и экономикой бардак фееричный.
Не нравится пример со строительством - берите судостроение. Военно-морской флот. Строются по проекту. Модернизируется и перевооружается флот по проекту. Соответственно, техническое задание, проект, сметы, стоимость, сроки.
Учитесь, айтишники.
"Безопасный сверхинтеллект" - то есть, они понимают, что это опасно, поэтому так и назвали?
Да, вы правы, такое присвоение тоже бесит.
А жилые многоэтажки? У девелоперов прям огромное желание делать качественно?
Или у девелоперов желание точно делать сметы, прогнозировать стоимость и сроки?
Такой стиль - это от недоразвитости ИТ-индустрии. В машиностроении такого нет. Там все делается по проекту. Проектная документация ПОЛНОСТЬЮ определяет, каким необходимо изготовить изделие. Нынешний стиль работы сеньора - это как каменщик-шабашник, который обсуждает с частником, как надо выложить дом.
В ИТ я даже техническое задание на "изделие" нечасто вижу.
Как только в ИТ придет (а я надеюсь на это) методика, когда программную систему реализуют полностью по проектной документации, ТОЧНО по проекту, что сеньоры, что рядовые "каменщики" будут не "общаться с людьми" а работать.
Импортозамещение, автаркия, продовольственная безопасность, протекционизм...
Диверсификация...
Не люблю тернарники в таком вот виде. Во-первых, тернарник создает больше когнитивной нагрузки, чем простой if. Считаю, что каждый оператор (x-y и x+y) должны быть каждый на своей строке. При добавлении даже малейшего условия в любую ветку, этот тернарник мгновенно увеличивается и становится катастрофично нечитаемым и неподдерживаем. В обычном if он как был прост в прочтении, так и остался, разве что чуть увеличился.
Снижать нужно когнитивную нагрузку, а не количество строк.
Тернарник хорош при ВЫБОРЕ значения из двух переменных. В качестве структуры управления потоком выполнения программы применять его нельзя.
Какие очереди поддерживаются? Простая очередь? Очередь с приоритетом поддерживается?
Хорошая подборка. Единственно, у меня вызывает сомнения, что сервис, который при невозможности выполнить операцию ввиду недоступности "подрядчика", возвращает что попало (нулевой остаток) - это "отказоустойчивость". Эти "чтопопало" потом уйдут в базу, пойдут гулять по бизнес-процессам, и потом сам черт ногу сломит их выкорчевывать и объяснять клиентам, почему такие странные данные в базе. Имхо, если операция не может правильно выполниться, дальше продолжать бизнес-процесс нельзя с некондиционными данными. Исключение - отображение на экране каких-то данных или наличие функционала. Не работает микросервис добавления комментариев и прочей некритической информации и функционала - панель добавления комментариев не должна отображаться.
@MockBean?
Дизайн очень спорный.