Я бы аналитиков заставлял рисовать схемы для себя(для начала) - если получился осьминог, то задачу точно надо упрощать до щупальца. А потом уже презентовал там команде....Да и команде оно не надо...разрабу нужно щупальце, а оно укладывается в понятие сценарий, для которого сложные инструменты обычно только вредят.
Переход на строку, поиск внутри файла, поиск внутри проекта, выделить слово, выделить строку, выделить несколько строк, скопировать-вставить — то, что мне хватает в моей IDE(да и в любом текстовом редакторе все эти комбинации, разве что не везде есть переход на строку).
Зачем ВИМ?
пс. Написание кода — это в том числе вставка бойлер принта, рефакторинг и прочие фишки, которые в виме надо реализовать с помощью почти полностью убогих плагинов. Нет, спасибо, лучше уж саблайм с мультикурсором.
Может быть шаблон DTO и важен, но, как мне кажется, его слишком превратно понимают, сужая его до отображаемого набора полей или трансформации в более плоские сущности. Предположим, для карточки свойство дают полную сущность и называют DTO как-то вроде UserFullView, а для отображения user`ов в таблице както вроде UserSimplifiedView. Но тут есть нюансы, если вы даете разные dto для разных запросов клиента, то клиенту надо с ними «по-разному работать». Для пример у нас есть класс Контрагент с реквизитами, которые имеют поле ИНН(схематично можно изобразить так):
Для карточки свойств уровень вложенности мы не меняем, тогда как для отображения в таблице мне делаем что то вроде того:
class Counterparty {
prvate String inn;
}
Теперь нам на клиенте, во-первых, надо иметь 2 модели: одну для карточки, другую для таблицы, во-вторых, если мы реализуем поиск по таблице, то мы не сможем его использовать в карточки(под реализуем я подразумеваю, что мы сможем отправить запрос на сервер с фильтрацией по ИНН), потому что ИНН находится на разных уровня и придется чуть иначе формировать запрос. И ради чего? Ради просто наличия DTO как шаблона, который в таком варианте, я вообще сомневаюсь что решает какие-то насущные проблемы.
DTO для меня имеют реальный смысл в двух случаях: если очень сложные модели на бэке и их надо упрощать для клиента; если мы используем DDD, тогда user может быть и сотрудником, и пользователем системы, из-за чего реально одна сущность будет проецироваться в разные поля на клиенте.
А при таком подходе есть вариант указать обязательность некоторых тегов, которые относятся к аспекту? Допустим, мы указали, что данный продукт — Еды. У еды есть аспект Классификация, куда входит набор тегов: Тип, Упаковка, и ЕСЛИ для еды был выбран аспект Классификация, то обязательно следует заполнить ВСЕ теги.
Разработчики, которые логгируют вообще все, а потом придумывают, как с этим работать с помощью какого-нить очередного ELK, удивляются, что правительство логгирует все и не понимают, кому это надо.
Когда в компании появятся четкие бизнес процессы для автоматизации, тогда компании потребуется ERP автоматизация этих бизнес процессов. Честно сказать, из моей практики, только в таком случае, когда люди четко осознают, что они планируют автоматизировать, а разработчики предлагают «как», после внедрения что-то выходит.
Когда-то споры вокруг n-tier or n-layer архитектурами — были нормой. Все это многоуровневая, просто в одном случае под уровнем подразумевают логическое деление(layer), а в другом — физическое(tier).
Я сам один раз перевод делал… Все таки терминология хромает, потому что все эти шаблоны я знаю, как и любой из программистов, но опознать их по этим названиям я смог не все.
Если бы передо мной поставили цель: вот тебе 50 сотрудников и сделай им систему KPI, я бы отказался. Потому что эта система слишком сложна. Система KPI — это как расчет уравновешенной системы, только где там главный вектор, где там момент силы, как их привести к нулю — никто не знает. Система KPI — это как баланс в играх, где не 3 расы, как в SC2, а 50, причем часть из рас воевать в принципе не умеет.
Я могу подробно описать как работает HashMap, например, но на вопросе про односвязный список, который я легко писал на любом языке еще 20 лет назад — я бы подзавис. Во-первых, я тупо не сразу бы выудил из головы, что это такое, во-вторых, я бы стал вспоминать, почему он односвязный, и в-третьих, что значит развернуть? Потому что развернуть для меня это равносильно — раскрыть, но никак отсортировать в обратном порядке. И спустя 5-10 минут, осознав, что от меня хотят — я бы набросал все это на листке, но… зачем?
Очень сомневаюсь, что алгоритмические знания по деревьям нужны в таксономической организации меню или каталогов. Я уж не говорю о том, что в каталоге товаров, скорее, понадобится фасетный поиск, тем не менее, который тоже имеет 100 реализаций в обед. Я уж не говорю о том, что еще вчера все это решалось EAV паттерном для баз данных — там тоже особо никаких деревьев знать не надо, хотя понимать сложность запросов было б и не плохо, но скорость современных бд+кэш все это нивелирует.
так у вас то тоже ничего не запрещает разрабу вызвать LocalDateTime.now()? кроме стайлчека..добавить к утилитному классу рестрикт и все.
https://infostart.ru/upload/iblock/330/330b8f0326f48225c8892194f8eb2241.png
Вот вроде довольно простой пример.
А можно краткий пример описания бизнес-процесса в нотации BPM и в том, что описано тут?
Я бы аналитиков заставлял рисовать схемы для себя(для начала) - если получился осьминог, то задачу точно надо упрощать до щупальца. А потом уже презентовал там команде....Да и команде оно не надо...разрабу нужно щупальце, а оно укладывается в понятие сценарий, для которого сложные инструменты обычно только вредят.
Сегодня переезд 2м людям на 4.5к в месяц, часть из которых уйдет на налоги - сомнительна, как по мне.
Что значит навигация идеи отстает от вим? Рефакторинг в виме? Это каким адоном?
Зачем ВИМ?
пс. Написание кода — это в том числе вставка бойлер принта, рефакторинг и прочие фишки, которые в виме надо реализовать с помощью почти полностью убогих плагинов. Нет, спасибо, лучше уж саблайм с мультикурсором.
Для карточки свойств уровень вложенности мы не меняем, тогда как для отображения в таблице мне делаем что то вроде того:
Теперь нам на клиенте, во-первых, надо иметь 2 модели: одну для карточки, другую для таблицы, во-вторых, если мы реализуем поиск по таблице, то мы не сможем его использовать в карточки(под реализуем я подразумеваю, что мы сможем отправить запрос на сервер с фильтрацией по ИНН), потому что ИНН находится на разных уровня и придется чуть иначе формировать запрос. И ради чего? Ради просто наличия DTO как шаблона, который в таком варианте, я вообще сомневаюсь что решает какие-то насущные проблемы.
DTO для меня имеют реальный смысл в двух случаях: если очень сложные модели на бэке и их надо упрощать для клиента; если мы используем DDD, тогда user может быть и сотрудником, и пользователем системы, из-за чего реально одна сущность будет проецироваться в разные поля на клиенте.
ERPавтоматизация этих бизнес процессов. Честно сказать, из моей практики, только в таком случае, когда люди четко осознают, что они планируют автоматизировать, а разработчики предлагают «как», после внедрения что-то выходит.