Благодаря OMG Essence можно за две недели освоиться с реальным проектом, который рассчитан на десятилетие разработки и внедрения
А если проект рассчитан на 1-3 месяца разработки роллаут, стоит ли заморачиваться? Например в контексте стартапа, где работа идет над внутренними проектами, которые пилятся быстро так как важен time to market.
Кто может быть заинтересован во внедрении этого стандарта в стартапе? Например я как тех. лид. не вижу как я могу заинтересовать разработчиков заниматься этим, хотя мне лично это интересно так как я являюсь техническим лидом нескольких проектов одновременно, но не являюсь менеджером.
Кто должен этим заниматься (всем тем что описано в статье)? Team Lead? Project manager? Кто несет ответственность за апдейт документов и состоянии?
Не понимаю почему минуса. Тоже интересует этот вопрос, особенно в контексте agile. Вот приходит новый человек в команду/компанию. Его самого сначала нужно научить этому методу, и потом уже возможно, оно за 2 недели разберется в проекте.
Согласовать требования? А вы точно в стартапах работали? Речь идет именно от стартапах а не обычно продукте для клиента.
Возьмите любой стартап который не умер на старте и продержался хотя бы 3-4 года... откройте сорс код в гите посмотрите коммиты... от initial и до настоящего времени. И попробуйте найти хоть какие-то документы связанные с коммитами =))
Если это не военная, атомная, или медицинская промышленность, где любой апдейт программы согласовывается месяцами если не годами по очень жестким ISO, то фичер делается очень быстро что бы дать клиенту хоть что-то, и уже потом напильником... потому что через месяц может оказаться так что не взлетело и клиенту оно уже не нужно... и потеря времени и денег будет минимальна.
Очень важную роль играет израильский менталитет. Там где американцы или немцы будут пытаться делать все по правилами и по книжечке, израильтяне найдут обходной путь, который пусть и не будет давать 100% результат, но все таки будет решать проблему хотя-бы частично.
У нас популярен вот такой рассказ. Извините что на английском (Oren-Shamir):
Imagine you're an executive in a big American company that makes home appliances. Your market research team suggests that people may want to have straight bananas, since Americans love to slice bananas up and put them in a sandwich or a cereal bowl, and straight bananas are easier to slice.
You decide to try and solve this problem using both of your R&D teams. One is located in the US and the other in Israel. You call the two team leaders and tell them what you need - a machine that bends bananas backwards to straighten them up.
The American team leader says they will get right on it. The next morning he posts a job opening on Linkedin, looking for a banana expert. He hires a guy from CalTech who knows everything there is to know about the molecular structure of bananas. He also hires two more engineers and an industrial designer. Initially.
After around 24-30 months of hard work, you have a sleek, shiny new machine that bends bananas backwards and produces perfect, straight as an arrow bananas 100% of the time, with any kind of banana that currently exists. It costs about 300 dollars and needs as much power as a small refrigerator.
At the same time, the Israeli team leader listens to you for about 3 minutes then interrupts to say that this is a really stupid idea. He doesn't know anybody who slices bananas. Israelis just eat them. Although we usually do peel them first. He suggests you might want to build a machine that peels bananas.
After a long, frustrating meeting you give up. But on his way home, the Israeli team leader thinks about what you asked him to do, and while he still thinks it's a stupid idea, he likes the challenge. The next morning he calls a couple of friends from the Kibuts who grow bananas and then he lets you know that his team will have a machine ready within a week.
After exactly 11 days the machine is indeed ready and a demonstration is scheduled. The machine is made out of spare parts of Uzi guns and costs 13$ to build. It also functions as an emergency torch. It looks like a scaled down model of a tractor accident. It also produces perfect, straight as an arrow bananas... in about 62.5% of the cases. 37% of the bananas are either broken, squashed or toasted beyond recognition. About half a percent of the bananas mysteriously disappear.
When you note these shortcomings to the Israeli team they look at you with complete puzzlement. The machine, they would tell you, does exactly what you asked for and the PRD never stated it has to do it to ALL the bananas you throw at it. Some bananas are obviously defected. Besides, it was a stupid idea to begin with.
So this is how we are:
We're really good at improvising
We think we're smarter than most
We help each other out
We prefer to cut corners, and get to the chase
We say exactly what we think (but we're not always happy with criticism)
We LOVE to argue. We argue with our commanders in the army, with our professors in the university and with our bosses at work. We have a "healthy" disrespect for authority
В монолите очень сложно следить за тем кто и что делает и кто какие модули импортит.
Все таки в трушных микросервисах кодовая база на порядок меньше, доступ к коду имеют только реальные овнеры, так что никто ничего там не изменит без открытия нового пиара и никто не заюзает твой модуль так что тебе что бы что-то изменить нужно тестировать пол системы.
Да, в монолите нужно следить за архитектурой. И в любом монолите все начинается красиво. Папочки всякие, модули.... а потом через 5 лет и +100500 разработчиков через которых прошел этот код все превращается в кашу.
Микросервисы конечно приезжают со своими проблемами, но все таки ряд проблем они решают очень хороше.
Т.е. подход "созидателя" и "разрушителя" - переключить свой образ мышления с одного подхода на другой - практически невозможно
Есть какие-то исследования что бы это утверждать? Ну джуниоры может быть и не могут в силу отсутствия опыта. Но не вижу причин что бы разработчик с 10+ лет опыта не понимал как он может сломать собственный код. Наоборот, он реально понимает что и как там работает и может накидать еще десятки кейсов как это сломать.
Другое дело что ему как разработчику не интересно заниматься QA.
Для меня QA это хакер не минималках. И я не думаю что существуют хорошие хакеры которые сами не являются программистами. Поэтому не могу согласиться с утверждением что разработчики не могут делать QA в силе разного мышления. Там много других причин.
Странно читать. Мы наоборот переходим с раббита на кафку в местах где нужны несколько консюмеров, для декаплинга доменов, где нужен order of messages например в скопе аккаунта или на более гранулярном уровне например reservation, или нужна sequence обработка что бы уменьшить оверхед работы optimistic concurrency.
Раббит попрежнему используем для round robin обработки, ритраев, роутинга и т.д.
Я думаю что все таки зависит от целей и бизнеса. Так категорично менять раббит на кафку везде мы бы не стали.
Ну вот есть у нас сервер на expressjs. Есть схемы на joi. Хочешь протестировать схемы? Довольно просто при помощи юнит тестов.
Но мы обычно просто пишем интеграционные тесты. Supertest + nock делают свою работу.
Была попытка внедрить написание контракт тестов, но никто так и не понял зачем еще раз писать какие-то тесты когда ты получаешь тоже самое out the box при написании интеграционных тестов (я имею ввиду на уровне ендпоинтов).
Мы сразу отказались от Jest на бэкенде когда фронтендисты начали его тащить к нам. Слишком много магии, слишком много открытых issues на гите. А еще он весело проглатывал ошибки...
Никто так и не смог нам объяснить зачем оно нам надо на бэкенде. А доводы типа ну это же крутой фреймворк от фейсбука нас не устроил.
Mocha + sinon + nock + chai + supertest закрывает буквально все потребности.
А также в snowflake :/
А если проект рассчитан на 1-3 месяца разработки роллаут, стоит ли заморачиваться? Например в контексте стартапа, где работа идет над внутренними проектами, которые пилятся быстро так как важен time to market.
Кто может быть заинтересован во внедрении этого стандарта в стартапе? Например я как тех. лид. не вижу как я могу заинтересовать разработчиков заниматься этим, хотя мне лично это интересно так как я являюсь техническим лидом нескольких проектов одновременно, но не являюсь менеджером.
Кто должен этим заниматься (всем тем что описано в статье)? Team Lead? Project manager? Кто несет ответственность за апдейт документов и состоянии?
Не понимаю почему минуса. Тоже интересует этот вопрос, особенно в контексте agile. Вот приходит новый человек в команду/компанию. Его самого сначала нужно научить этому методу, и потом уже возможно, оно за 2 недели разберется в проекте.
Может сразу в польскую нотацию?
https://ru.wikipedia.org/wiki/Польская_запись
Согласовать требования? А вы точно в стартапах работали? Речь идет именно от стартапах а не обычно продукте для клиента.
Возьмите любой стартап который не умер на старте и продержался хотя бы 3-4 года... откройте сорс код в гите посмотрите коммиты... от initial и до настоящего времени. И попробуйте найти хоть какие-то документы связанные с коммитами =))
Если это не военная, атомная, или медицинская промышленность, где любой апдейт программы согласовывается месяцами если не годами по очень жестким ISO, то фичер делается очень быстро что бы дать клиенту хоть что-то, и уже потом напильником... потому что через месяц может оказаться так что не взлетело и клиенту оно уже не нужно... и потеря времени и денег будет минимальна.
Очень важную роль играет израильский менталитет. Там где американцы или немцы будут пытаться делать все по правилами и по книжечке, израильтяне найдут обходной путь, который пусть и не будет давать 100% результат, но все таки будет решать проблему хотя-бы частично.
У нас популярен вот такой рассказ. Извините что на английском (Oren-Shamir):
Imagine you're an executive in a big American company that makes home appliances. Your market research team suggests that people may want to have straight bananas, since Americans love to slice bananas up and put them in a sandwich or a cereal bowl, and straight bananas are easier to slice.
You decide to try and solve this problem using both of your R&D teams. One is located in the US and the other in Israel. You call the two team leaders and tell them what you need - a machine that bends bananas backwards to straighten them up.
The American team leader says they will get right on it. The next morning he posts a job opening on Linkedin, looking for a banana expert. He hires a guy from CalTech who knows everything there is to know about the molecular structure of bananas. He also hires two more engineers and an industrial designer. Initially.
After around 24-30 months of hard work, you have a sleek, shiny new machine that bends bananas backwards and produces perfect, straight as an arrow bananas 100% of the time, with any kind of banana that currently exists. It costs about 300 dollars and needs as much power as a small refrigerator.
At the same time, the Israeli team leader listens to you for about 3 minutes then interrupts to say that this is a really stupid idea. He doesn't know anybody who slices bananas. Israelis just eat them. Although we usually do peel them first. He suggests you might want to build a machine that peels bananas.
After a long, frustrating meeting you give up. But on his way home, the Israeli team leader thinks about what you asked him to do, and while he still thinks it's a stupid idea, he likes the challenge. The next morning he calls a couple of friends from the Kibuts who grow bananas and then he lets you know that his team will have a machine ready within a week.
After exactly 11 days the machine is indeed ready and a demonstration is scheduled. The machine is made out of spare parts of Uzi guns and costs 13$ to build. It also functions as an emergency torch. It looks like a scaled down model of a tractor accident. It also produces perfect, straight as an arrow bananas... in about 62.5% of the cases. 37% of the bananas are either broken, squashed or toasted beyond recognition. About half a percent of the bananas mysteriously disappear.
When you note these shortcomings to the Israeli team they look at you with complete puzzlement. The machine, they would tell you, does exactly what you asked for and the PRD never stated it has to do it to ALL the bananas you throw at it. Some bananas are obviously defected. Besides, it was a stupid idea to begin with.
So this is how we are:
We're really good at improvising
We think we're smarter than most
We help each other out
We prefer to cut corners, and get to the chase
We say exactly what we think (but we're not always happy with criticism)
We LOVE to argue. We argue with our commanders in the army, with our professors in the university and with our bosses at work. We have a "healthy" disrespect for authority
We love challenges and dislike wasted talent
We like to tell stories
ПХП покинул лет 8 назад... в NODEJS мы используем datadog. Подключаешь библиотеку и из коробки получаешь очень много плюшек. Привем трейсинга:
Вроде как и для пхп есть либа: https://github.com/DataDog/dd-trace-php
Но, дорого...
В монолите очень сложно следить за тем кто и что делает и кто какие модули импортит.
Все таки в трушных микросервисах кодовая база на порядок меньше, доступ к коду имеют только реальные овнеры, так что никто ничего там не изменит без открытия нового пиара и никто не заюзает твой модуль так что тебе что бы что-то изменить нужно тестировать пол системы.
Да, в монолите нужно следить за архитектурой. И в любом монолите все начинается красиво. Папочки всякие, модули.... а потом через 5 лет и +100500 разработчиков через которых прошел этот код все превращается в кашу.
Микросервисы конечно приезжают со своими проблемами, но все таки ряд проблем они решают очень хороше.
Есть какие-то исследования что бы это утверждать? Ну джуниоры может быть и не могут в силу отсутствия опыта. Но не вижу причин что бы разработчик с 10+ лет опыта не понимал как он может сломать собственный код. Наоборот, он реально понимает что и как там работает и может накидать еще десятки кейсов как это сломать.
Другое дело что ему как разработчику не интересно заниматься QA.
Для меня QA это хакер не минималках. И я не думаю что существуют хорошие хакеры которые сами не являются программистами. Поэтому не могу согласиться с утверждением что разработчики не могут делать QA в силе разного мышления. Там много других причин.
Странно читать. Мы наоборот переходим с раббита на кафку в местах где нужны несколько консюмеров, для декаплинга доменов, где нужен order of messages например в скопе аккаунта или на более гранулярном уровне например reservation, или нужна sequence обработка что бы уменьшить оверхед работы optimistic concurrency.
Раббит попрежнему используем для round robin обработки, ритраев, роутинга и т.д.
Я думаю что все таки зависит от целей и бизнеса. Так категорично менять раббит на кафку везде мы бы не стали.
Но вот некоторые вещи из статьи пригодятся!
Вот я и пытаюсь понять чем обычный nock для мокинга выходящих http запросов не подходит?
Я не очень понимаю для чего все это.
Ну вот есть у нас сервер на expressjs. Есть схемы на joi. Хочешь протестировать схемы? Довольно просто при помощи юнит тестов.
Но мы обычно просто пишем интеграционные тесты. Supertest + nock делают свою работу.
Была попытка внедрить написание контракт тестов, но никто так и не понял зачем еще раз писать какие-то тесты когда ты получаешь тоже самое out the box при написании интеграционных тестов (я имею ввиду на уровне ендпоинтов).
Мы сразу отказались от Jest на бэкенде когда фронтендисты начали его тащить к нам. Слишком много магии, слишком много открытых issues на гите. А еще он весело проглатывал ошибки...
Никто так и не смог нам объяснить зачем оно нам надо на бэкенде. А доводы типа ну это же крутой фреймворк от фейсбука нас не устроил.
Mocha + sinon + nock + chai + supertest закрывает буквально все потребности.
И в том же Google Meet в хроме...
Когда спрашивают дать ETA основываясь на названии таска ?
Рассматривали ли вы облачные решения, как например snowflake?
Эта статья это стеб?
Не дай бог после таких советов студенты теперь все вычисления будут в конструктор пихать ?
А кто реально видел что бы кто-то использовал эти настройки на живой базе в продакшене ? Я вот не видел :/ А хотелось бы...
Я очень люблю табличные тесты когда не мне их отлаживать в случае поломки. Потому что это ад.
Прикольно, должно экономить время и количество букв в файле. На деле, лишь добавляет логики, усложняет дебаг.
Ну иногда не особа есть выбор. Например когда очень жесткое требование на Exactly once delivery.