AlexLeonov
+1
Вы невнимательно читали первоисточники и делаете неверный вывод.

Вкратце: если деньги от клиента поступают вам путем оплаты картой онлайн (неважно, через агрегатора или вы напрямик общаетесь с эквайрингом) — касса нужна, если клиент платит безналично — не нужна, даже если он физик.
AlexLeonov
+1
Спорить и не надо, надо внимательно читать нормативные акты и требовать от налоговой разъяснений, если вам что-то неясно.
AlexLeonov
+1
даже пришёл ножками в отделение банка, чтобы заплатить

Вот тут вы неправы. Если клиент распечатал с сайта квитанцию и заплатил через банк по реквизитам — касса не нужна.
AlexLeonov
0
Есть DataGrip и он хорош. Но не бесплатен.
AlexLeonov
0
«Ненужный» может быть задействован. ОК.
AlexLeonov
0
Про enum в кастомных типах забыли: https://www.postgresql.org/docs/current/static/datatype-enum.html
Это один из самых частых вопросов от свитчеров.
AlexLeonov
+1
и содержащий ещё 400% кода, который использовать в обозримом будущем не планируется


А вы что конкретно экономите-то? Место в пять мегабайт на диске под «неиспользуемый» код?

И нужно ли его экономить?
AlexLeonov
0
Внимательно прочел, нашел одну принципиальную ошибку — что мешает разным сервисам пользоваться одной (ОК, физически разными, но реплицируемыми или federated) базами данных? Ответ: ничто не мешает.

Сервис — это превращатель request в response. Какую он там БД использует — исключительно его дело, не так ли?
AlexLeonov
0
Я случаев возмещения убытков в рамках формальных процедур лично не знаю. Но это не значит, что их нет.

Случаи увольнения за профнепригодность (дада, с той самой комиссией и аттестацией) по итогам внешнего аудита мне известны.
AlexLeonov
0
Как это в реальности выглядит?


Это выглядит как документ. На бумаге. Который фиксирует должностные обязанности, скажем, некоего «Ведущего разработчика». В котором написано «Исполняет роль DBA, включая следующие обязанности: ...».

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

И что от этого изменится?

Появляется понятие «ответственность». Если аудит покажет, что решение было неверным, но принятым Васей в рамках его обязанностей (которые он на себя принял), то Вася может пострадать материально (возмещение убытков) или морально (увольнение).
AlexLeonov
0
Нужны отдельные люди на много новых ролей

Я нигде не утверждал, что роль == должность или что каждая роль — это отдельный человек. Напротив, если вы внимательно почитаете мои комментарии, то найдете прямо противоположные утверждения.

Один человек вполне может сочетать несколько ролей, не вижу никаких проблем. Важно только, чтобы роли были выделены, формализован список обязанностей и зафиксирована ответственность по каждой роли.

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

Плохой пример, потому что никто в здравом уме не будет выбирать sharepoint :)) Но в целом да, решение можно подать, как якобы принятое коллективно.
AlexLeonov
0
Вы с другой стороны, уважаемый коллега.

Со стороны бизнеса «поиграться» равносильно «выкинуть деньги в никуда». Когда бизнес нанимает разработчика, он полагает, что нанял профессионала, который знает решение его (бизнеса) проблем, и что разработчику не нужно «играться», но он может сесть и сделать.

Вы же предлагаете немного по-детски наивный подход: «дайте нам бабла, мы поиграемся и сделаем, как нам нравится, и пофигу на ТЗ».

В реальной жизни не нужно делать лучше, чем в ТЗ. Нужно сделать то, что написано и как можно быстрее.

Мотивация? Ну да, отчасти здесь я с вами соглашусь. Однако существует множество методик управления, которые создадут у разработчиков иллюзию их причастности к принимаемым решениям. Так что не вижу большой проблемы.
AlexLeonov
+2
Вася, сколько тебе нужно на этот таск? — Два ч/д… Вася, прошло два ч/д, где коммит?


Какая прекрасная в своей нелепости ошибка.

Вася сказал честно — два человеко-дня, примерно 15 часов работы.
Тот, кто спрашивал, не сумел превратить оценку трудозатрат в календарный срок, составив план-график, и теперь сваливает вину за свою некомпетентность, как PM-а, на бедного Василия.

А ведь Вася срок не говорил!
AlexLeonov
0
Посчитаны кем? Разработчиками? С чего вдруг?

С того, что в любой методике разработки первичная оценка дается исполнителем. Это совершенно нормальная часть любого процесса.

— Тут надо применить Монгу
— ОК, сколько тебе примерно надо времени, чтобы попробовать и решить точно?
— Ну дня три…
— Хорошо, пишем 40 часов на research

Выплаченная ЗП — это и есть подтверждение согласия, увольнение — неподтверждение.

Как-то у вас всё категорично :)
AlexLeonov
0
А я призываю смотреть на процесс честнее и объяснять тому, чьи деньги вы собрались тратить — на что именно они будут потрачены.

Вполне возможно, что бизнес просто не захочет оплачивать избыточность, осознав, что она ему не нужна. А вы, не сказав про альтернативу и заложив в архитектуру эту избыточность, фактически просто обманете заказчика.

Смысл всех моих комментов можно свести к фразе «Обманывать — нехорошо».
AlexLeonov
0
Вступайте в дискуссию, обсудим. Если я неправ, я способен это признать.

Но пока считаю ровно так, как написал выше: архитектор и разработчик это разные роли, и тот, кто пишет код, не может нести ответственность за выбор архитектурного решения.

Выбор — это ответственность прежде всего. А ответственность может быть только персональной.
AlexLeonov
+1
О, выходные закончились, прибежали отдохнувшие «архитекторы», начали ставить минусы. Не понравилось про «CRM на mongoDb»? Так это суровая правда жизни. Мне и CRM с монгой, как с основной базой приводилось видеть, и интернет-магазины и много еще чего. С реализацией left join и constraints в коде приложения :)

И всегда эти истории заканчивались печально. «Архитекторы» увольнялись, кому-то приходилось, употребляя весьма непечатные выражения, наводить порядок в их хозяйстве и объяснять бизнесу, что решение фактически придется написать заново…
AlexLeonov
0
Вы опять путаете причину со следствием. Бизнесу обычно не нужны никакие «крупные распределенные системы». Им нужны продажи, расширение рынков, поле для маркетинговых экспериментов, новые каналы продаж, обратная связь с клиентами и так далее.

То, что эти потребности бизнеса будут удовлетворяться «распределенной системой» — это уже техническое решение. И не факт, что верное.
AlexLeonov
–4
Сверстать шаблон? Причем тут разработчик backend-а?

Шаблоны в отдельный репозиторий, описываем в документации объекты, передающиеся в шаблоны, отдаем верстку на аутсорс в менее развитый регион, при сборке объединяем с основным репозиторием.
AlexLeonov
+6
Совсем недавно была ситуация полного обоюдного непонимания:

— А представьте, что вот на эту вашу архитектуру придёт миллион rps?
— Откуда они возьмутся?
— Ну неважно, вдруг так случилось? Что тогда? Как масштабироваться будем?

Смотрю на собеседника и не понимаю — то ли он шутит, то ли серьезно рассуждает, что его планово-убыточный магазин никому не нужной обуви должен работать в условиях миллионов реквестов в секунду…
AlexLeonov
0
Архитектор — это роль.
Если ресурсы позволяют вам иметь выделенного «освобожденного» архитектора — я вас поздравляю, такое случается нечастно.

я заложу масштабирование, даже если заказчик не хочет

Об этом и был мой самый первый коммент. Удовлетворение своего любопытства за чужой счет. Имхо, один из самых страшных грехов «разработчиков», которые никак не хотят понять, что «творцы тут не нужны» (с)
AlexLeonov
+2
А если задача ставится так, что оптимально использовать незнакомые платформы, по сравнению с знакомыми? Например, вы всегда работали с postgresql, а тут вам нужен полнотекстовый поиск с кучей других параметров.


Найдите специалиста по незнакомой платформе и оплатите консультацию. Это будет на порядки дешевле, чем по вляпаться в зря потерянное время по причине своей некомпетентности и нежелания эту некомпетентность признавать.

И опять же таки, в подавляющем большинстве случаев vision проекта (а его может и не быть) может кардинально менятся

Меняются требования — перепроектируем. Это нормальный процесс.
AlexLeonov
+6
Я бы посоветовал удалить вам эту статью. Всё равно она будет набирать только минусы. А кому-то начинающему может стать сборником вредных советов, если он случайно придёт на эту статью из поисковика.
AlexLeonov
+1
Зачем?

Вменяемый архитектор сначала уточнит бизнес-требования, а затем превратит их в технические.

У вменяемого архитектора не может быть своих интересов, не обусловленных требованиями бизнеса, ведь вполне может стать так, что бизнесу просто не нужно никакое масштабирование. И отказоустойчивостью в разумных пределах тоже можно пренебречь.

Если он это не понимает — он не архитектор пока еще.
AlexLeonov
+1
Разницы между «отдать страничку с данными» и «отдать эти же данные в JSON» для вменяемого backend-разработчика почти нет. Разве что заголовок про content-type правильный не забыть.

Весь адъ начинает твориться уже на фронте. Это какой-то отдельный мир :)
AlexLeonov
+3
CTO, к сожалению, может преследовать свои цели, перпендикулярные целям бизнеса. Например «имитировать бурную деятельность и занятость, чтобы не сокращался поток бабла».

Поверьте, так тоже бывает.
AlexLeonov
+3
Если смотреть на современный JS — лучше бы маятник действительно пошел в другую сторону.
AlexLeonov
+3
Вы не можете не знать должностных обязанностей, потому что обязаны с ними ознакомиться под роспись.
Если не знакомились — считайте, что никаких обязанностей у вас нет :)
AlexLeonov
0
Вы правы, конечно, но разница на практике не настолько принципиальна.
AlexLeonov
+1
Хороший вопрос, но, думаю, не для обсуждения здесь.
Вкратце: поверили вместо «проверили». Более подробно вряд ли смогу здесь рассказать.
AlexLeonov
+2
Да не вопрос. Пожалуйста. Но при соблюдении двух условий:

1. Затраты на эксперименты и «прокачку» разработчиков посчитаны, хотя бы в условных человеко-часах, что позволяет оценить себестоимость, и доведены до бизнеса.
2. Бизнес согласен на такие затраты. Причем согласие тоже зафиксировано каким-то образом, а не на уровне «Ну мне Петя сказал, что можно этим заниматься».
AlexLeonov
+11
Это отвратительная идея с точки зрения бизнеса.

Бизнесу, как ни странно, нужно решение его задач. Бизнес нанимает людей, наивно полагая, что они знают, как решать задачи бизнеса максимально эффективно.

Оказалось же, что задачу «сделать шардинг» никто не ставил, более того: она не была обоснована необходимостью решения какой-либо бизнес-задачи.

А теперь представьте себе. Скажем, три человека (тим-лид и два его подчиненных) в той или иной мере 2-3 месяца работали над реализацией этой идеи (я про ненужный шардинг, если вы не забыли). Грубый подсчет дает около полутора миллионов рублей, потраченных за это время только на их зарплату с начислениями. И это я еще не считаю стоимость аренды и оборудования рабочих мест и прочие косвенные расходы.

То есть ребята взяли и просто так, без всякой необходимости, распылили в воздухе полтора чужих миллиона. Потому что им стало любопытно.

Я думаю, что если бы им предложили возместить расходы, они бы сильно задумались в следующий раз, стоит ли проводить такие эксперименты.
AlexLeonov
–1
Поэтому я и пишу «роль», а не «должность». Даже на трех человек всегда можно выделить и формализовать роли.

Есть такой классный документ, называется «должностные обязанности». Так вот, там можно писать примерно так: «Выполняет роль инженера QA, включая следующие обязанности:… „
Только не говорите, что это “бюрократия», просто банальный порядок.
AlexLeonov
0
«Комментарий бы изменен» — добавил строчку про Битрикс.
AlexLeonov
–7
А всё потому, что программист должен писать код.
Очень жаль, что эту простую истину приходится каждый раз объяснять заново.

— Не выбирать фреймворк и не подбирать библиотеки: это роль архитектора
— Не закупать железо или облачные ресурсы: это сисадмин
— Не проектировать базу данных: это DBA
— Не заниматься выкладкой кода в бой и обновлением: это dev-ops
— Не тестировать и не писать тестовые сценарии: это QA
— и даже не настраивать себе софт на рабочем месте

А просто писать код. И всё.

К сожалению, в 95% случаев всё заканчивается на уровне «тыжпрограммист? вот иди и сделай!» и ни о каком разделении ролей внутри команды говорить не приходится. А нет разделения ролей — нет и ответственности, получается, что ответственность «коллективная», за ошибочные решения как бы никто не отвечает, виноватых нет.
AlexLeonov
+11
Архитектор, а не администратор, вы невнимательно прочли.

Системный архитектор — это роль, отвечающая как раз за обоснованный выбор технологий и архитектурных решений.

Отсутствие в команде такой роли приводит обычно к Битриксу :)
AlexLeonov
–3
Для этого в компании нужен системный архитектор. Задача разработчика — код писать, а не выбирать решения.

Даже если компания экстремально маленькая, всегда можно найти на почасовку грамотного человека, который подготовит вам архитектурное решение.

Иначе так и будут плодиться «CRM на mongoDB», которые потом приходится переписывать, тратя человеко-годы, или просто выкидывать (причем бывает, что вместе с командой, которая такое накодила)
AlexLeonov
+39
Статья напомнила одну компанию, в которой мне удалось (крайне недолго) поработать.

«Медовая» неделя, знакомлюсь с состоянием дел.

— А вот тут у нас основная база данных, мы сделали горизонтальный шард на 6 (шесть!) инстансов, запись в БД у нас делается специальной процедурой, вот тут в ней идет вычисление ключа шарда…
— Ну ОК, сделано довольно грамотно, молодцы. А сколько записей сейчас в самой большой таблице?
— 50 000…

facepalm.jpg

Я это называю «удовлетворять своё любопытство за счёт работодателя».
AlexLeonov
0
Честно говоря, единственный приведенный пример якобы пользы шаблонов — типизированная коллекция — выглядит надуманным.

То есть всё понятно в плане что это за языковая фича. Непонятно — зачем она? Какие еще есть внятные применения?

Имхо это тупик какой-то. Гораздо интереснее было бы форсить RFC про кастомные типы. Тогда бы никакие дженерики для типизированных массивов (коллекций) не потребовались бы.
AlexLeonov
–1
А зачем тогда вообще эта простыня малосвязного текста, переполненного ложными высказываниями?
Далее вы предлагаете вести разработку в стиле «Exception Drive Development (EDD)»

Я ничего вам не предлагал. Перестаньте так болезненно реагировать на существование внешнего мира не совсем совпадающего с вашими представлениями о нём.