Я за 20 лет практически не видел руководителя низшего и среднего звена, который бы четко понимал, что первая его задача - НЕ МЕШАТЬ.
Дельного менеджера с таким пониманием собственной роли быть не может. Ибо если этим его функции исчерпываются, то умный человек должен сознавать, что эта должность вовсе не нужна, и искать другую работу. Я своим всегда говорю, что моя работа – им помогать. Согласитесь, совсем не одно и то же.
для моделей данных такой подход на мой взгляд вполне оправдан
Да, в таком ограниченном варианте использования – вполне возможно. Но мечталось-то, что весь проект можно будет держать в понятной визуальной модели 🙂 Не получилось.
Я лет через 10 после того, как сам бросил это дело, был на каком-то митапе, и одна из лекций была как раз по моделированию – заглянул по старой памяти. Мужик долго рассказывал, какой UML чудесный, а закончил тем, что его повсеместному внедрению пока мешает одно мелкое, но досадное обстоятельство: отсутствие средств переноса изменений кода в модель. Надо кому-то это быстренько сделать (желательно, для всех основных языков) , и сразу наступит всеобщее щастье.
Был у меня недолгий период увлечения UML. На практике оказалось, что поддерживать модель в актуальном состоянии практически невозможно. Не было (и насколько я знаю, до сих пор нет) ни одного инструмента, способного её качественно перегенерить согласно изменениям в коде. Даже такие очевидные разновидности, как диаграмма классов – не говоря уж о более высоких абстракциях типа use cases. А без этого оно бесполезно.
Ещё как-то случилось чуток поработать с IBM Visual Age C++. Воспоминания жуткие, любой сколько-нибудь сложный проект тут же превращается с месиво из стрелочек, которое даже авторы вскоре перестают понимать – не говоря уж о всех остальных.
Что думаете вы о девушках в IT и в разработке в частности?
Я девушек очень люблю – везде, в IT в том числе, и думаю о них всегда хорошо 🙂 Соответственно, никаких предрассудков нет – а вот опыт есть. Как это объяснить, я не знаю, потому что женщины в среднем точно не тупее мужчин – но по моему опыту женщины-программисты в среднем заметно слабее. Единственное более или менее внятное объяснение, которое приходит в голову – их таки значительно меньше, и возможно, на столь малой выборке сложнее встретить действительно выдающихся специалистов. Хотя, вспоминая ещё советские времена – случалось работать в коллективах, где пропорция был примерно пополам – и даже тогда лидерами всё равно были парни. Девчонки писали неплохо – но как-то без изюминки, что ли. Сложно объяснить. В любом случае, умных девушек мы любим и всегда им рады 🙂
При чём тут это? И вообще, мы тут что, полную систему проектируем? Причём в ситуации, когда
бизнес-логика попросту неизвестна.
Я так не умею. И базы проектировать, не зная, для чего – тоже. Что я знаю точно – в хорошо спроектированной системе строковые ключи нужны крайне редко, и их нужно по возможности избегать.
Я, наконец, понял! Вы просто захардкодили привилегии доступа к полям в класс с именем ACL
Неа, ничего Вы не поняли. Например, я ведь писал:
Можно развить как угодно – например, добавить проверку привилегий залогиненного юзера, и если он админ, показывать всё.
Это прямой ответ на
Сделайте так, что у пользователя с name="Pronin" привилегии есть, а у пользователя с name="Poopkin" привилегий нет.
То же самое с "хардкодом" ACL – в реальном проекте нет ничего легче, чем заставить его читать список привилегий из конфигурации в базе. Но согласитесь, не буду же я здесь целый проект выкладывать. Включите воображение, додумайте хотя бы совсем уж очевидные вещи.
Очень хорошо, но откуда вы берёте значение этого поля name и как понимаете, что это именно name?
Странный вопрос. Я пишу программу, которой по логике необходимо получить имя юзера. Я знаю, что это значение лежит в User.name. Что ещё тут нужно понимать?
Вы считаете лишним любое поле, лексически похожее своим именем на другое?
При чём тут вообще это? Речь об опечатках, которые в одном случае со 100% гарантией предотвращаются, а в другом выявляются только в рантайме.
Так вы прямо в код геттера собираетесь захардкодить привилегии доступа?
🤦♂️ Ну зачем же сразу в глупости-то меня обвинять?
enum Privilege {private, public}
...
class ACL {
static Privilege name = public;
static Privilege dob = private;
}
...
class User {
String name;
Date dob;
const String denied = "access denied";
String get name =>
ACL.name == Privilege.public ? name : denied;
Date get dob =>
ACL.dob == Privilege.public ? dob : denied;
}
Годится? Можно развить как угодно – например, добавить проверку привилегий залогиненного юзера, и если он админ, показывать всё.
UPD:
Кстати, у меня в коде баг – на который IDE мне тоже, несомненно, указало бы 😁
Эта структура ведь не возникает по волшебству внутри вашей программы, а каким-то образом заполняется из исходных данных.
Неверно. Исходные данные тут вообще ни при чём. Я один раз описываю в коде программы структуру User, которая имеет поле name – и далее в любом месте программы, где эта структура используется, попытка обратиться к полю mane подсветит этот код как ошибочный в IDE и не позволит ему скомпилиться. Если же имя поля передаётся строкой, как ключ ассоциативного списка – эта ошибка вылезет только в рантайме.
Уж не буду спрашивать, что будет, если у структуры действительно есть поля и name, и mane.
Откуда они возьмутся? Когда я определяю эту структуру, я знаю, какие поля там необходимы, и ничего лишнего в ней появиться не может.
Ну вам же не мешает работать то, что в компиляторе C++ английское слово structure ошибочно написано как struct?
Простите, речь совершенно о другом.
Однако это может быть не равно бизнес-требованиям.
Может – если программист решил поразвлекаться вместо работы, или просто не понял эти требования. В обоих случаях его вскоре уволят.
Контроль доступа к информации и бизнес-логика – две никак не связанные между собой вещи.
Здрасьте, приехали.
И на список свойств-то ещё и атрибуты ACL или мандатные метки повесить совершенно элементарно, а вот дискретизировать доступ к полям структуры вам будет сложнее.
Чем сложнее-то? Про геттеры слышали что-нибудь? Да и атрибутов в структуру я могу набить сколько угодно.
___
Я в целом понимаю, в чём причина разногласий – если Ваш основной язык лисп, да ещё и в течение длительного времени – это очень сильно меняет картину мира. Мне несколько раз приходилось к нему возвращаться после длительных перерывов – и каждый раз требовалось несколько дней, чтобы заново въехать в эту парадигму. Это никоим образом не язык общего назначения, он предназначен для решения специфичного круга задач и многие вещи в нём решаются весьма нетрадиционными путями. Что совершенно не говорит о том, что остальные языки должны следовать такому же подходу, или о том, что он чем-то лучше. В частности, обсуждаемый кейс гораздо лучше решается в рамках объектной модели. Мапы и списки – очень плохая замена для стандартизованных структур данных. Увы, лисп ничего другого не предлагает.
Извините, нет пользователей со свойством 'mane', попробуйте поискать по-другому
Это и есть нарушение работоспособности программы. Потому что 'mane' прислал другой модуль той же программы – ну опечатался человек, бывает. Или наоборот: прислали 'name', а у Вас в parlist опечатка: 'mane'. А вот если мы работаем с обеих сторон со структурой User с заданным набором полей, то такая ситуация невозможна в принципе.
Что касается принципа YAGNI, то он исходит из презумпции, что сценарии использования программы понятны до её разработки.
Из этого исходит сама возможность начинать разработку. Как можно программировать, не зная, что требуется в результате? Эти знания могут уточняться, и даже очень сильно изменяться в процессе, но когда мы пишем код, всегда знаем, что именно в данный момент хотим от него получить.
Ну и возвращаясь чуть назад:
Если я говорю: "Алиса, назови мне имя этого пользователя" или "Алиса, назови мне дату рождения этого пользователя", то это ведь одно и то же с точки зрения логики.
Нет. Это абсолютно разные бизнес кейсы и должны обрабатываться отдельно. Простой пример: имя может быть открытой, а дата рождения закрытой информацией. И логика там в этом случае разная.
Это ошибочная концепция, мне не нужна обработка произвольных свойств – только тех, которые предусмотрены бизнес-логикой. YAGNI. Причём я хочу, чтобы в коде было очень конкретно видно, что именно каждый его фрагмент обрабатывает.
В примере нет структуры в вашем понимании, есть ассоциативный список (аналог map).
Чтобы достать элемент из такого списка, есть только один способ: передать ему ассоциированный с данным элементом ключ. Таким образом мы снова приходим к тому же самому: опечатка в имени ключа, которая не отслеживается методами статического анализа, приведёт к нарушению работоспособности программы.
В моём мире такое невежество даже для джуна недопустимо.
Может быть, это повод вернуться в реальный мир? Я на лиспе (одном из, явно не этом) писал в последний раз лет 40 назад. Было подозрение, что он, но уверен не был.
Только это всё неважно: какой бы ни была глубина моего невежества, представленный пример никак не демонстрирует возможности доступа к данным, не используя явной ссылки на элемент структуры, и все мои замечания остаются в силе.
Я поставил вопрос о том, что предлагаемый Вами подход неэффективен и потенциально ведёт к необнаруживаемым на ранних этапах ошибкам. Пока ни одного обоснованного возражения не прочитал.
это вы заявили, что не знаете, что это такое.
Да, и что? Это как-то доказывает Вашу правоту, или свидетельствует о том, что после этого со мной и обсуждать нечего?
Собственно, не настаиваю – представление в результате дискуссии получил, а что-то доказывать, убеждать мне не надо. Так что можем и завершить.
Экзотично. Я не понимаю даже, на каком языке написан пример – не говоря уж о том, что он делает и как отвечает на заданный вопрос. Могу только отметить несколько очевидных моментов:
В отличие от простенького user.name этот код абсолютно нечитаем и с моей точки зрения попросту недопустим – если он заменяет элементарную операцию получения значения.
Из примера абсолютно неочевидно, каким образом он получает доступ в заданному полю структуры, не указывая его в явном виде. Чисто теоретически и независимо от языка программирования, есть только два способа получить такой доступ: явной ссылкой на него или через рефлексию. Ну разве что ещё по заданному смещению в памяти. Какой используется у Вас и где то место в коде?
Входные данные – штука крайне ненадёжная, требует тщательной валидации. Если же эти данные должны содержать ещё и информацию о внутренних структурах программы, чтобы сообщить ей, из какого поля брать данные – то это просто трэш какой-то, Вы прибиваете внутреннюю реализацию к клиенту гвоздями.
Вкратце: не вижу ни ответа на свой вопрос, ни тем более, преимуществ Вашего подхода. Напишите мне, пожалуйста, коротенький пример получения имени юзера без использования ссылки на содержащее его поле структуры. Чтобы вот прямо заканчивалось чем-то вроде
Как только вы подниметесь на определённую ступеньку абстракции, то там не останется никаких конкретных полей.
Примерчик можно? Как Вы получаете доступ к значению конкретного поля структуры, ни разу на само поле конкретно не ссылаясь? Прямо аж интересно – может, я что-то важное упустил в этой жизни.
Не надо стесняться. Всё просто: в известных мне языках такого понятия нет – соответственно, делаю вывод, что это особенность незнакомого мне, но пропагандируемого Вами эрланга. Ну или может, эликсира.
Дельного менеджера с таким пониманием собственной роли быть не может. Ибо если этим его функции исчерпываются, то умный человек должен сознавать, что эта должность вовсе не нужна, и искать другую работу. Я своим всегда говорю, что моя работа – им помогать. Согласитесь, совсем не одно и то же.
Паблик Морозов? 😲
Да, в таком ограниченном варианте использования – вполне возможно. Но мечталось-то, что весь проект можно будет держать в понятной визуальной модели 🙂 Не получилось.
Я лет через 10 после того, как сам бросил это дело, был на каком-то митапе, и одна из лекций была как раз по моделированию – заглянул по старой памяти. Мужик долго рассказывал, какой UML чудесный, а закончил тем, что его повсеместному внедрению пока мешает одно мелкое, но досадное обстоятельство: отсутствие средств переноса изменений кода в модель. Надо кому-то это быстренько сделать (желательно, для всех основных языков) , и сразу наступит всеобщее щастье.
Был у меня недолгий период увлечения UML. На практике оказалось, что поддерживать модель в актуальном состоянии практически невозможно. Не было (и насколько я знаю, до сих пор нет) ни одного инструмента, способного её качественно перегенерить согласно изменениям в коде. Даже такие очевидные разновидности, как диаграмма классов – не говоря уж о более высоких абстракциях типа use cases. А без этого оно бесполезно.
Ещё как-то случилось чуток поработать с IBM Visual Age C++. Воспоминания жуткие, любой сколько-нибудь сложный проект тут же превращается с месиво из стрелочек, которое даже авторы вскоре перестают понимать – не говоря уж о всех остальных.
Я девушек очень люблю – везде, в IT в том числе, и думаю о них всегда хорошо 🙂 Соответственно, никаких предрассудков нет – а вот опыт есть. Как это объяснить, я не знаю, потому что женщины в среднем точно не тупее мужчин – но по моему опыту женщины-программисты в среднем заметно слабее. Единственное более или менее внятное объяснение, которое приходит в голову – их таки значительно меньше, и возможно, на столь малой выборке сложнее встретить действительно выдающихся специалистов. Хотя, вспоминая ещё советские времена – случалось работать в коллективах, где пропорция был примерно пополам – и даже тогда лидерами всё равно были парни. Девчонки писали неплохо – но как-то без изюминки, что ли. Сложно объяснить. В любом случае, умных девушек мы любим и всегда им рады 🙂
или возможно, с ключом юзер ид из базы, не знаю:
При чём тут это? И вообще, мы тут что, полную систему проектируем? Причём в ситуации, когда
Я так не умею. И базы проектировать, не зная, для чего – тоже. Что я знаю точно – в хорошо спроектированной системе строковые ключи нужны крайне редко, и их нужно по возможности избегать.
🤦♂️ Да что ж Вы такое пишете-то.... Почему?! Это будет
User.role– которое, в свою очередь, нечто вродеПоразительно.
Неа, ничего Вы не поняли. Например, я ведь писал:
Это прямой ответ на
То же самое с "хардкодом" ACL – в реальном проекте нет ничего легче, чем заставить его читать список привилегий из конфигурации в базе. Но согласитесь, не буду же я здесь целый проект выкладывать. Включите воображение, додумайте хотя бы совсем уж очевидные вещи.
Тут ничем не помогу – более очевидный код мне сложно себе представить.
Нет, потому что у меня доступ к значениям не по строковым ключам, а по именам полей – обращение к несуществующему полю невозможно.
Зачем? Этому фрагменту кода совершенно не нужно.
Странный вопрос. Я пишу программу, которой по логике необходимо получить имя юзера. Я знаю, что это значение лежит в
User.name. Что ещё тут нужно понимать?При чём тут вообще это? Речь об опечатках, которые в одном случае со 100% гарантией предотвращаются, а в другом выявляются только в рантайме.
🤦♂️ Ну зачем же сразу в глупости-то меня обвинять?
Годится? Можно развить как угодно – например, добавить проверку привилегий залогиненного юзера, и если он админ, показывать всё.
UPD:
Кстати, у меня в коде баг – на который IDE мне тоже, несомненно, указало бы 😁
Неверно. Исходные данные тут вообще ни при чём. Я один раз описываю в коде программы структуру
User, которая имеет полеname– и далее в любом месте программы, где эта структура используется, попытка обратиться к полюmaneподсветит этот код как ошибочный в IDE и не позволит ему скомпилиться. Если же имя поля передаётся строкой, как ключ ассоциативного списка – эта ошибка вылезет только в рантайме.Откуда они возьмутся? Когда я определяю эту структуру, я знаю, какие поля там необходимы, и ничего лишнего в ней появиться не может.
Простите, речь совершенно о другом.
Может – если программист решил поразвлекаться вместо работы, или просто не понял эти требования. В обоих случаях его вскоре уволят.
Здрасьте, приехали.
Чем сложнее-то? Про геттеры слышали что-нибудь? Да и атрибутов в структуру я могу набить сколько угодно.
___
Я в целом понимаю, в чём причина разногласий – если Ваш основной язык лисп, да ещё и в течение длительного времени – это очень сильно меняет картину мира. Мне несколько раз приходилось к нему возвращаться после длительных перерывов – и каждый раз требовалось несколько дней, чтобы заново въехать в эту парадигму. Это никоим образом не язык общего назначения, он предназначен для решения специфичного круга задач и многие вещи в нём решаются весьма нетрадиционными путями. Что совершенно не говорит о том, что остальные языки должны следовать такому же подходу, или о том, что он чем-то лучше. В частности, обсуждаемый кейс гораздо лучше решается в рамках объектной модели. Мапы и списки – очень плохая замена для стандартизованных структур данных. Увы, лисп ничего другого не предлагает.
Это и есть нарушение работоспособности программы. Потому что 'mane' прислал другой модуль той же программы – ну опечатался человек, бывает. Или наоборот: прислали 'name', а у Вас в
parlistопечатка: 'mane'. А вот если мы работаем с обеих сторон со структурой User с заданным набором полей, то такая ситуация невозможна в принципе.Из этого исходит сама возможность начинать разработку. Как можно программировать, не зная, что требуется в результате? Эти знания могут уточняться, и даже очень сильно изменяться в процессе, но когда мы пишем код, всегда знаем, что именно в данный момент хотим от него получить.
Ну и возвращаясь чуть назад:
Нет. Это абсолютно разные бизнес кейсы и должны обрабатываться отдельно. Простой пример: имя может быть открытой, а дата рождения закрытой информацией. И логика там в этом случае разная.
Это ошибочная концепция, мне не нужна обработка произвольных свойств – только тех, которые предусмотрены бизнес-логикой. YAGNI. Причём я хочу, чтобы в коде было очень конкретно видно, что именно каждый его фрагмент обрабатывает.
Чтобы достать элемент из такого списка, есть только один способ: передать ему ассоциированный с данным элементом ключ. Таким образом мы снова приходим к тому же самому: опечатка в имени ключа, которая не отслеживается методами статического анализа, приведёт к нарушению работоспособности программы.
Может быть, это повод вернуться в реальный мир? Я на лиспе (одном из, явно не этом) писал в последний раз лет 40 назад. Было подозрение, что он, но уверен не был.
Только это всё неважно: какой бы ни была глубина моего невежества, представленный пример никак не демонстрирует возможности доступа к данным, не используя явной ссылки на элемент структуры, и все мои замечания остаются в силе.
Я поставил вопрос о том, что предлагаемый Вами подход неэффективен и потенциально ведёт к необнаруживаемым на ранних этапах ошибкам. Пока ни одного обоснованного возражения не прочитал.
Да, и что? Это как-то доказывает Вашу правоту, или свидетельствует о том, что после этого со мной и обсуждать нечего?
Собственно, не настаиваю – представление в результате дискуссии получил, а что-то доказывать, убеждать мне не надо. Так что можем и завершить.
То есть ответов на мои вопросы нет, переходим в режим ad hominem. Бывает.
Экзотично. Я не понимаю даже, на каком языке написан пример – не говоря уж о том, что он делает и как отвечает на заданный вопрос. Могу только отметить несколько очевидных моментов:
В отличие от простенького
user.nameэтот код абсолютно нечитаем и с моей точки зрения попросту недопустим – если он заменяет элементарную операцию получения значения.Из примера абсолютно неочевидно, каким образом он получает доступ в заданному полю структуры, не указывая его в явном виде. Чисто теоретически и независимо от языка программирования, есть только два способа получить такой доступ: явной ссылкой на него или через рефлексию. Ну разве что ещё по заданному смещению в памяти. Какой используется у Вас и где то место в коде?
Входные данные – штука крайне ненадёжная, требует тщательной валидации. Если же эти данные должны содержать ещё и информацию о внутренних структурах программы, чтобы сообщить ей, из какого поля брать данные – то это просто трэш какой-то, Вы прибиваете внутреннюю реализацию к клиенту гвоздями.
Вкратце: не вижу ни ответа на свой вопрос, ни тем более, преимуществ Вашего подхода. Напишите мне, пожалуйста, коротенький пример получения имени юзера без использования ссылки на содержащее его поле структуры. Чтобы вот прямо заканчивалось чем-то вроде
Примерчик можно? Как Вы получаете доступ к значению конкретного поля структуры, ни разу на само поле конкретно не ссылаясь? Прямо аж интересно – может, я что-то важное упустил в этой жизни.
Не надо стесняться. Всё просто: в известных мне языках такого понятия нет – соответственно, делаю вывод, что это особенность незнакомого мне, но пропагандируемого Вами эрланга. Ну или может, эликсира.
Нет, так читать не будем. Ибо если у меня определена вышеупомянутая структура:
то ссылка
user.name– никакой не хардкод, и никаких констант для её использования определять не требуется. Вот в случае мапы да, можно:Только зачем?