Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
Как говорилось уже выше, главный плюс спецификаций в том, что логика получения данных теперь находится там, где она должна быть - на уровне домена.
А что в этом хорошего? На какие потребительские характеристики это влияет? Как влияет на совокупные трудозатраты и стоимость поддержки кода? Желательно в примерах.
ваше приложение будет более гибким
Как расположение кода в проекте влияет на гибкость?
В бытовой логике люди не выигрыш максимизируют, а минимизируют проигрыш.
То есть в ситуации с красно-зеленной кнопкой вероятность потерять миллион 0% в первом случае и 50% во втором. Понятно что выберут большинство людей особенно если нажимают кнопку всего один раз, а не 50 раз в день, как трейдеры.
Минимизация проигрыша не абсолютный закон и зависит от суммы. Если это будет не миллионы, а просто рубли, то многие рискнут одним рублем чтобы получить 50 с вероятностью 50%. Многие и 100₽ рискнут для 50% выиграть 5000. Но у всех есть граница, выше которой выберут красную кнопку. Эта граница зависит не только от соотношения риска и прибыли, но и от непосредственного количества денег, которыми ты готов рисковать.
Нигде и никогда бизнес-пользователи \не читают код. Для пользователя абсолютно неважно в каком методе у вас проверка уникальности.
В реальной жизни будет ключ уникальности в базе, если базу создаете вы сами, то не сделать ключ уникальности - преступление.
Эвенты это неявный вызов, что гораздо хуже, чем явный вызов. Потому что эвенты из вызывающего кода не читаются никак и рано или поздно случится ситуация, когда эвент просто не вызовется.
У вас же UI или WebAPI вызывает в итоге какую-то функцию (контроллер\команда\handler), она свою очередь вызывает репозиторий и выполняет сохранение пользователя. Вот в эту функцию и добавьте проверку уникальности перед тем как добавлять.
Это будет явный вызов, очень читаемый и оптимальный, так как для проверки уникальности можно сделать оптимальный запрос.
Такая реализация не отменяет п2 про уникальность, потому что при всех оптимистичных проверках, не блокируя всю таблицу, можно сделать дубль.
Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Децентрализация в общем смысле значит только то, что у системы нет точки централизации, всё
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 80% того, что позволяет плодить новые блоки, сконцентрировано в одних руках теряет все преимущества децентрализации. Так как эти одни руки вполне могут переписать блокчейн, внеся любые свои правки и отменив запись любого участника.
Получается что бокчейн - плохое решение для любых баз данных, где участником может быть кто угодно. Например может быть оправдан блокчейн для банков, чтобы осуществлять межбанковские переводы, но блокчейн для выборов - профанация в чистом виде.
Блокчейн это открытое (то есть кто угодно может посмотреть все данные) и децентрализованное (то есть кто угодно может внести изменение) хранилище. Оба свойства обязательны, нельзя как-то убрать или уменьшить одно из них, чтобы блокчейн оставался оправданным.
Традиционная база данных это централизованное хранилище, которое может быть как открытым, так и ограниченным.
Что нужно от хранилища для паспортов? Однозначно оно не должно быть открытым, иначе множество злоумышленников смогут выдавать себя за других граждан. Поэтому увы, блокчейн тут не подойдет.
Чтобы посчитать проблему стоит тогда начинать сначала, с того сколько заработал бизнес пока эта проблема существовала
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
Хотя при этом есть стандарты и законы предписывающие соблюдать их. Только, пока, не в IT
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
по вечерам, выходным итд
А ты что думал?
Классическая путаница.
Тимлид должен уметь писать код, но совершенно необязательно должен писать код для проекта, командой которого он руководит. По моему опыту наличие 7+ программистов уровня middle в команде приведет к тому, что тимлид вообще перестанет код писать.
Тимлид обязательно должен читать код, чтобы понимать что делают его подчинённые.
Тимлид, очевидно, должен поддерживать квалификацию, чтобы его умение писать, читать и понимать код не устарело. Поэтому очень даже неплохо если тимлид таки пишет иногда код своего проекта, иначе ему придется еще как-то в нерабочее время поддерживать квалификацию.
Единственный вариант тимлиду не писать код, если он за время устаревания навыков разовьет менеджерские скилы настолько, что перескочит на следующий уровень - тимлид-тимлидов или как он там называется.
А что в этом хорошего? На какие потребительские характеристики это влияет? Как влияет на совокупные трудозатраты и стоимость поддержки кода?
Желательно в примерах.
Как расположение кода в проекте влияет на гибкость?
Когда пример более сложный все остальные способы тоже так себе работают.
zig и отчасти rust
а также, внезапно, C# - Собираем автономную игру на C# в 2 килобайтах / Хабр (habr.com)
Бытовая логика работает не так.
В бытовой логике люди не выигрыш максимизируют, а минимизируют проигрыш.
То есть в ситуации с красно-зеленной кнопкой вероятность потерять миллион 0% в первом случае и 50% во втором. Понятно что выберут большинство людей особенно если нажимают кнопку всего один раз, а не 50 раз в день, как трейдеры.
Минимизация проигрыша не абсолютный закон и зависит от суммы. Если это будет не миллионы, а просто рубли, то многие рискнут одним рублем чтобы получить 50 с вероятностью 50%. Многие и 100₽ рискнут для 50% выиграть 5000. Но у всех есть граница, выше которой выберут красную кнопку. Эта граница зависит не только от соотношения риска и прибыли, но и от непосредственного количества денег, которыми ты готов рисковать.
Нигде и никогда бизнес-пользователи \не читают код. Для пользователя абсолютно неважно в каком методе у вас проверка уникальности.
В реальной жизни будет ключ уникальности в базе, если базу создаете вы сами, то не сделать ключ уникальности - преступление.
Эвенты это неявный вызов, что гораздо хуже, чем явный вызов. Потому что эвенты из вызывающего кода не читаются никак и рано или поздно случится ситуация, когда эвент просто не вызовется.
У вас же UI или WebAPI вызывает в итоге какую-то функцию (контроллер\команда\handler), она свою очередь вызывает репозиторий и выполняет сохранение пользователя. Вот в эту функцию и добавьте проверку уникальности перед тем как добавлять.
Это будет явный вызов, очень читаемый и оптимальный, так как для проверки уникальности можно сделать оптимальный запрос.
Такая реализация не отменяет п2 про уникальность, потому что при всех оптимистичных проверках, не блокируя всю таблицу, можно сделать дубль.
Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Как говорится code talks, bullshit walks
Люди не понимают ООП, в том числе автор этой статьи
Наверное лучшая статья на хабре всех времен и народов
Посмотрите на сами запросы, там предикаты джоинов заставляют плакать query planner.
Buzzword driven development
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 80% того, что позволяет плодить новые блоки, сконцентрировано в одних руках теряет все преимущества децентрализации. Так как эти одни руки вполне могут переписать блокчейн, внеся любые свои правки и отменив запись любого участника.
Получается что бокчейн - плохое решение для любых баз данных, где участником может быть кто угодно. Например может быть оправдан блокчейн для банков, чтобы осуществлять межбанковские переводы, но блокчейн для выборов - профанация в чистом виде.
Как это связано?
Блокчейн это открытое (то есть кто угодно может посмотреть все данные) и децентрализованное (то есть кто угодно может внести изменение) хранилище. Оба свойства обязательны, нельзя как-то убрать или уменьшить одно из них, чтобы блокчейн оставался оправданным.
Традиционная база данных это централизованное хранилище, которое может быть как открытым, так и ограниченным.
Что нужно от хранилища для паспортов? Однозначно оно не должно быть открытым, иначе множество злоумышленников смогут выдавать себя за других граждан. Поэтому увы, блокчейн тут не подойдет.
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
С в CAP это A в ACID
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.