Pull to refresh
0
Дмитрий Янковский@Yankee2d

User

Send message

Только логика в вашей статье совершенно от другого.

На вопрос «в каком виде хранить номер паспорта» ответ не text, а встречный вопрос «какие ограничения, требования, сценарии использования, регуляторка». Номер паспорта является персданными и должен шифроваться.

Ваш ответ, данный в статье, не ответ сеньора.

Спасибо, статья агонь!

Для непосвящённого читателя очень интересно.

Спорно, потому что вам нужно очищать тоггда данные от пробелов и спецсимволов. И также везде при вводе.

Далее, в большинстве систем, особенно в банковских, паспорт может быть иностранным.

Если вы говорите про семантику, то у паспорта НОМЕР, а не символьный или числовой идентификатор.

Номер это numeric. То, что в отображении используется форма с заполнением нулями слева не играет роли. Это отображение. Иногда это передача во внешние системы.

Не только лишь семантика рулит выбором, а вся совокупность сценариев использования. К примеру, телефонный номер это число, но есть код страны, а коды страны пересекаются. Есть +37, есть +373. Для логинов проще хранить единый номер. Но отобразить в форме код и номер ты не сможешь, выбрать по странам не сможешь.

Нормальный сеньор на ваш вопрос бы задал другой «а что за система и что вы собираетесь делать с этими номерами? Какие ограничения? Это только российские паспорта?»

Сеньор решает задачу системы, а не задачу хранения отдельно. В постгресе есть вычислимые на лету поля. Если номера паспортов и серий в числовом виде не пересекаются и в будущем не предполагается вводить иностранные паспорта и население рф не собирается выпрыгивать за диапазон в ближайшие сто лет, тогда, например, числовой тип на весь номер и две вычислимые колонки серии и номера с lpad абсолютно не являются криминалом.

То есть, вместо написания 10 строк dsl используем llm?

Про dsl всё прекрасно, но зачем ии тут?

Поздравляю вас с вступлением в этот мир боли :)

Неприятно, конечно, как Кафка писать «в стол».

Но могу вам дать ещё парочку советов с точки зрения РП и техлида:

  • договоритесь с тимлидом и пусть он настаивает и проверяет - в каждой задаче должна быть ссылка на вики

  • В функциональных методах должна быть ссылка на вики или задачу

  • В папках проекта должен быть read.me файл либо с описанием содержимого, либо снова с ссылкой нс документ.

  • Введите structurizr для С4. программистам намного проще сопровождать архитектуру с подходом architecture as code

  • В том же dsl описываются deployment инфраструктура стендов. Можно делать сетевые карты, в props писать порты и ip

Вы сами сказали проблему — вас спрашивают, где искать документ, потому что про его существование либо не знают, либо он не под рукой. Быть «справочным бюро» и бесит и создаётся ощущение, что работа аналитика не важна и не ценится.

Но проблема именно в этой связке - нет никаких проблем создавая метод в коменте к нему добавлять ссылку на задачу. Ничего не стоит при декомпозиции добавлять ссылку на вики в задачу. Сопровождать диаграммы в виде кода, а не тыкаясь в редакторе графическом намного проще и их потом можно парсить и выдавать удобно таблицы сетевых связей, например, компонентов, списки ролей и к чему у них есть доступ. Их все равно потом требует ИБ, а программисты ленивы, если они поймут, что проще такие задачи решать имея С4 в виде кода, они будут так делать.

Забавно, как такие ревью пишут далёкие от понимания технологии. Весь прогресс в ии за счёт скоростных шин передачи данных между процессорами. Разделение кластера даже на десяток кусков ведёт к деградации производительности не в 10 раз, а на два порядка. Кто не верит, может спросить ии.

Поэтому сказки про тысячи небольших цодов на орбите для ии сказки для хомячков.

Вы совершенно правильно описали практику. Я отвечал на другое - у вас прямо в заголовке статьи "как спасать команду от бесконечных митингов". Кто вообще вводит эту практику бесконечных митингов? Именно менеджеры, которые никогда не учились менеджменту, которые "чайка-менеджеры" и вместо помощи в работе и её организации создают ИБД (имитацию бурной деятельности).

К сожалению, "зрелой культуры" сейчас мало где найдёшь. Проблема некомпетентного менеджмента повсеместно.

А на вопрос "как спасать команду от бесконечных митингов" находится совсем в другой плоскости. Если эти митинги организуете вы (не лично вы, не принимайте на свой счёт), то тогда вам не место в менеджменте и нужно пойти подтянуть базу, понять, что проект это время-ресурсы-качество и т.д. По-любому такого менеджера нужно увольнять из проекта, а не учить агенду на митинг писать. Если он не понимает базы, ну научите вы его писать агенду и записывать результаты, но у него пробелы глобальные.

А вот если на своём месте вы всё понимаете, но эти бесконечные ВКС собирают люди повыше типа заказчиков, руководителей и т.д. и приглашают на них по 25 человек, включая разработчиков, тогда это, к сожалению, вопрос из области психотерапии и принятия, ибо уволить своего руководителя и заказчика вы не можете. Тогда вам нужно "лавировать", освобождать своих подчинённых от этих звонков, доносить организаторам, что присутствие всей вашей команды на ВКС это бездарная трата ресурса. И, к сожалению, очень не редко это встречается в штыки этими людьми. Опять по той же причине, что управлять они не умеют, написать письмо, где кратко объяснить суть они не умеют. Им нужно собрать большую конференцию, пятнадцать раз одно и то же проговорить разными способами, услышать вопросы, которые их направят в нужное русло и они родят то, что забыли упомянуть и после этого пойдут домой успокоенными, что "вроде донесли до команды". Хотя на самом деле им нужно было просто сесть и написать документ. Но они просто не умеют формулировать.

Да вы прикалываетесь?

Господа менеджеры с двумя классами образования, вам не в техлидов учиться надо, а идти принимать заказы на гамбургеры. Умение организовывать работу это на целое образование.

Эта статья для кого? По принципам этой же статьи? Для тех менеджеров, которые элементарных вещей не понимают?

Тогда пункт 1. - увольняйтесь и не мешайте работать.

Или вы этой статьёй хотите помочь «людям с особенностями в развитии» подольше удерживаться на месте, которое они занимают по чистой случайности?

Information

Rating
7,136-th
Registered
Activity

Specialization

Фулстек разработчик, Разработчик мобильных приложений
Ведущий