Сам по себе шаблон вряд ли может быть медленный. Скорее медленной может быть конкретная реализация. Т.е. я бы в первую очередь пооптимизировал библиотеку, если такая проблема возникла.
Та библиотека, на которую я давал ссылку, реализована на корутинах, т.е. допускает асинхронную и многопоточную обработку. В общем, она неплохо масштабируется по ядрам, при необходимости.
У нас на этом шаблоне работает видеообработка на Python со скоростью 30 кадров в секунду. За все время работы с ним я ни разу не сталкивался с проблемами производительности.
Очевидно, что, чем сложнее бизнес-логика, тем больше нагрузка на ЦПУ. И вряд ли имеет существенное значение в каком виде эта логика реализована. Она все равно будет жрать ресурсы.
Часто помогает алгоритмическая оптимизация бизнес-логики. Например, когда вместо 500 if мы реализуем машину состояний, которая отрабатывает за наносекунды.
Дошло. Вы, вероятно, думаете, что аналитик каким-то чудом может спрогнозировать все нюансы бизнес-логики и благодаря его работе переделки не потребуются. Это не так по вполне объективным причинам.
Заказчик.
Далеко не всегда представляет как оно должно выглядеть и что все-таки требуется. И, даже если вы вытрясете из него конкретное решение и закрепите в договоре, далеко не всегда в итоге окажется это решение верным и тем, что ему нужно. Формально пункт договора выполнен, реально - нет.
Разные должностные лица заказчика, как правило, имеют собственные мнения, а требования разных лиц часто противоречат. Давно известно как с этим работать. Вопрос лишь во времени. Потому что это классический долгий водопад. И за год такими методами проект не сделать.
Аналитики.
Аналитик - это не эксперт предметной области. Это две разные должности. Так что не стоит от него ждать чудес владения предметной областью.
Как и разработчики, аналитики бывают разных квалификаций. И далеко не всегда лид-аналитик способен отследить все косяки джуна-/мидла-аналитика.
Даже программист доводит программу до рабочего состояния с 3-5-й итерации. А у аналитика нет никаких средств тестирования его документации. Все ошибки аналитики выплывают только на других стадиях ввода в эксплуатацию.
Все это давно всем известно, именно поэтому и существуют все эти этапы ввода в эксплуатацию: разработка, тестирование, внедрение, испытания, тестовая эксплуатация и только потом уже штатная эксплуатация. И на каждом этапе возникают баги, требующие порой значительных переделок системы.
Если бы вы сделали сравнительный анализ языков, было бы полезно.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается? И не он один хороший. Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Америку не открывали. Просто разные микросервисы. Какие - описано в "Распределение обязанностей". Совмещение тоже просто - OpenAPI, который тоже упомянут в тексте.
Проекты - это отдельные бизнес-проекты. Каждый проект состоял примерно из десятка микросервисов.
Я не знаю что такого у Нвидиа в драйвере. Наверное, если бы все знали, то не было бы смысла его закрывать.
Но, видимо, им есть что терять.
На это намекает уже то, что именно Нвидиа является лидером в графических картах. Не Интел и АМД с их отрытыми драйверами, а Нвидиа.
Кто вообще такие это самое «сообщество OpenSource»? Типа сидят такие добрые дядечки и из чисто альтруистских целей даруют Человечеству бесплатно код. А сами, как бестелесные существа, питаются исключительно чистой энергией Солнца, не живут в квартирах, не ездят на автомобилях и вообще не получают зарплату. Смешно.
Большая часть ядра Линукс написана не каким-то там «сообществом», а вполне конкретными компаниями, прежде всего Google, Nvidia, Intel, etc. В общем, теми самыми компаниями, которые и производят проприетарный код в большом количестве. И открывают они код под OpenSource не из великого альтруизма, а по вполне меркантильным причинам.
Так вот, если GPL не будет дружить с проприетарщиной, то просто лишится поддержки основных доноров кода. После этого можно будет закрывать проект «Линукс» и дружно пересаживаться на какой-нибудь FreeBSD.
С этим-то как раз все понятно. Непонятно другое.
Для того, чтобы поставить due-дату, нужно задачу декомпозировать, оценить время исполнения всех подзадач, вычислить общее время выполнения, заложить всякие митинги и походы в туалет, а после этого нужно еще распланировать другие конкурентные задачи. Просто потому, что они могут конфликтовать по срокам. А могут быть незапланированные задачи поддержки и т.д.
Сдается мне, что это вы, как менеджер, просто сняли с себя некую головную боль и переложили ее на разрабов.
И куча подводных камней тут выглядят следующим образом.
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы. Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Вот и хочется узнать как это происходит на самом деле. А то для меня выглядит такой подход очень рисковым, от которого может и команда разбежаться.
По вопросу донесения до команды бизнесового контекста выполняемой ими задачи — полностью поддерживаю. По поводу due-даты хочу пояснений.
Эксперт — это человек, который в теме, скажем, десяток лет, знает все по ней от… и до…
Например, эксперт по фондовому рынку — это человек, который много лет торгует на фондовом рынке, знает все инструменты, знает много приемов и т.д.
Где вы видели таких аналитиков?
Работа аналитика гораздо проще: получил задание, пошел в интернет читать что пишут, задокументировал вещи, которые относятся к теме, потом пошел к разным разработчикам, узнал у них как что делать, тоже задокументировал. В итоге передает документацию, с которой разработчики и работают. При этом постоянно приходят с дополнительными вопросами, просто потому что аналитик не предусмотрел что-то. И это что-то вылазит только при разработке.
Я очень редко видел в компаниях экспертов, но очень часто видел именно аналитиков. Т.е. аналитик — это человек, который обходится компании дешевле, чем разраб, поэтому он всего лишь снимает с разраба рутинную работу по сбору информации.
Смотря о каком разработчике мы говорим. Если это джун, который делает только то, что ему говорят, то да. Будет слушать аналитика и выполнять его указания.
Если же это самостоятельный разраб, способный спланировать и реализовать проект, то он вполне способен погрузиться в предметную область не хуже аналитика.
Возможно вы имеете в виду не аналитика, а эксперта. Вот эксперта в соответствующей области действительно глупо пытаться переплевывать. Но аналитик, как правило, таковым не является.
Пожалуйста, отличайте прототип от MVP. Цель MVP — это продажа. MVP — minimal Viable product. Прототип действительно никто не собирается продавать, его цель — подтверждение технической возможности создания продукта, либо получение инвестиций.
Хотел сослаться на ваш комментарий в теле статьи, но Хабр не позволяет таким «подонкам» как я редактировать собственную статью из-за низкой кармы. При том, что сама статья в плюсе более чем на 120 единиц рейтинга.
Так что придется отложить.
Поразительная осведомленность. Спасибо за пояснения.
Может вы заодно сможете пояснить что Греф мог иметь в виду под словами «боремся с программистами»?
:) Хороший анализ. Но есть кое-какие нюансы.
Да, при переходе от каждого изделия к следующему, приходится много чего переделывать в самом изделии. Но…
1. Когда вы запустили в производство скейтборд, у вас пошли живые деньги. Не через 5 лет, а через полгода. И это совсем не то же самое, что делать с нуля автомобиль без денег, на одних обещаниях инвесторам.
2. Когда вы сделали скейтборд и начались продажи, вы уже не «тот придурок», который строит звездолет на пустом месте, а человек с опытом запуска бизнеса, которому инвесторы более охотно дают деньги. Это и корпораций касается. Там свои «инвесторы».
3. Да, для самоката нужно делать фактически новую конструкцию, но часть оборудования для производства подойдет от самоката, поставщики частично уже есть, сеть сбыта уже налажена, каналы продаж протестированы и известны. Кроме того, есть уже сработавшаяся команда, методы управления, постановки и решения задач и много чего еще.
4. Если для скейтборда достаточно команды из пары человек, то автомобиль уже может разрабатывать команда из пары тысяч человек. В итоге, мы вполне можем уложиться в те же полгода, условно говоря.
Если посмотрите на Маска, то он сначала сделал Paypa, потом Tesla, а уже потом замахнулся на Space X. И даже со Space X у него сначала простая ракета появилась, а уж потом он стал спасать первую ступень.
Тут целый ряд нюансов
Сам по себе шаблон вряд ли может быть медленный. Скорее медленной может быть конкретная реализация. Т.е. я бы в первую очередь пооптимизировал библиотеку, если такая проблема возникла.
Та библиотека, на которую я давал ссылку, реализована на корутинах, т.е. допускает асинхронную и многопоточную обработку. В общем, она неплохо масштабируется по ядрам, при необходимости.
У нас на этом шаблоне работает видеообработка на Python со скоростью 30 кадров в секунду. За все время работы с ним я ни разу не сталкивался с проблемами производительности.
Очевидно, что, чем сложнее бизнес-логика, тем больше нагрузка на ЦПУ. И вряд ли имеет существенное значение в каком виде эта логика реализована. Она все равно будет жрать ресурсы.
Часто помогает алгоритмическая оптимизация бизнес-логики. Например, когда вместо 500 if мы реализуем машину состояний, которая отрабатывает за наносекунды.
Дошло. Вы, вероятно, думаете, что аналитик каким-то чудом может спрогнозировать все нюансы бизнес-логики и благодаря его работе переделки не потребуются. Это не так по вполне объективным причинам.
Заказчик.
Далеко не всегда представляет как оно должно выглядеть и что все-таки требуется. И, даже если вы вытрясете из него конкретное решение и закрепите в договоре, далеко не всегда в итоге окажется это решение верным и тем, что ему нужно. Формально пункт договора выполнен, реально - нет.
Разные должностные лица заказчика, как правило, имеют собственные мнения, а требования разных лиц часто противоречат. Давно известно как с этим работать. Вопрос лишь во времени. Потому что это классический долгий водопад. И за год такими методами проект не сделать.
Аналитики.
Аналитик - это не эксперт предметной области. Это две разные должности. Так что не стоит от него ждать чудес владения предметной областью.
Как и разработчики, аналитики бывают разных квалификаций. И далеко не всегда лид-аналитик способен отследить все косяки джуна-/мидла-аналитика.
Даже программист доводит программу до рабочего состояния с 3-5-й итерации. А у аналитика нет никаких средств тестирования его документации. Все ошибки аналитики выплывают только на других стадиях ввода в эксплуатацию.
Все это давно всем известно, именно поэтому и существуют все эти этапы ввода в эксплуатацию: разработка, тестирование, внедрение, испытания, тестовая эксплуатация и только потом уже штатная эксплуатация. И на каждом этапе возникают баги, требующие порой значительных переделок системы.
Обычная, нормальная команда. Помимо 6 разработчиков множество других ролей, включая аналитиков, аналитиков данных, тестировщиков и пр.
Если бы вы сделали сравнительный анализ языков, было бы полезно.
А что вы пытаетесь доказать в этой статье - не ясно. Что питон хороший? А кто-то сомневается? И не он один хороший. Полно хороших языков, включая упомянутые здесь уже Assembler, c, c++, java, c#.
Но, чтоб нахваливать какие-то фичи, неплохо бы знать как то же решается в других экосистемах.
Америку не открывали. Просто разные микросервисы. Какие - описано в "Распределение обязанностей". Совмещение тоже просто - OpenAPI, который тоже упомянут в тексте.
Проекты - это отдельные бизнес-проекты. Каждый проект состоял примерно из десятка микросервисов.
Точно, спасибо, перепутал
Проприеритарный код не обязан продаваться.
Но, видимо, им есть что терять.
На это намекает уже то, что именно Нвидиа является лидером в графических картах. Не Интел и АМД с их отрытыми драйверами, а Нвидиа.
Большая часть ядра Линукс написана не каким-то там «сообществом», а вполне конкретными компаниями, прежде всего Google, Nvidia, Intel, etc. В общем, теми самыми компаниями, которые и производят проприетарный код в большом количестве. И открывают они код под OpenSource не из великого альтруизма, а по вполне меркантильным причинам.
Так вот, если GPL не будет дружить с проприетарщиной, то просто лишится поддержки основных доноров кода. После этого можно будет закрывать проект «Линукс» и дружно пересаживаться на какой-нибудь FreeBSD.
Ничего личного, просто бизнес.
Спасибо. Действительно было бы интересно посмотреть на это новшество с другой стороны.
Для того, чтобы поставить due-дату, нужно задачу декомпозировать, оценить время исполнения всех подзадач, вычислить общее время выполнения, заложить всякие митинги и походы в туалет, а после этого нужно еще распланировать другие конкурентные задачи. Просто потому, что они могут конфликтовать по срокам. А могут быть незапланированные задачи поддержки и т.д.
Сдается мне, что это вы, как менеджер, просто сняли с себя некую головную боль и переложили ее на разрабов.
И куча подводных камней тут выглядят следующим образом.
1. На разрабов увеличилась нагрузка на планирование. Т.е., если раньше эту работу выполняли вы, то сейчас — разрабы. Скорее всего дорогой лид с зарплатой около 200, на котором и так висит контроль за полчищем джунов. Т.е. лид просто перестал заниматься разработкой и стал менеджером.
2. Если раньше они не вписывались в сроки одной задачи, то просто переносили ее на следующий спринт, а за срыв сроков отдувались менеджеры, то сейчас разрабы просто тупо сидят на переработках. Т.е. упала внеплановая задача или из-за ошибки оценки сроков, и они просто сидят на работе несколько дополнительных часов. И хорошо, если это время покрывается финансово. Чаще всего бесплатно сидят.
Вот и хочется узнать как это происходит на самом деле. А то для меня выглядит такой подход очень рисковым, от которого может и команда разбежаться.
По вопросу донесения до команды бизнесового контекста выполняемой ими задачи — полностью поддерживаю. По поводу due-даты хочу пояснений.
Как вы работаете с due-датами? Можно подробнее? Вижу в этом подходе много подводных камней.
Например, эксперт по фондовому рынку — это человек, который много лет торгует на фондовом рынке, знает все инструменты, знает много приемов и т.д.
Где вы видели таких аналитиков?
Работа аналитика гораздо проще: получил задание, пошел в интернет читать что пишут, задокументировал вещи, которые относятся к теме, потом пошел к разным разработчикам, узнал у них как что делать, тоже задокументировал. В итоге передает документацию, с которой разработчики и работают. При этом постоянно приходят с дополнительными вопросами, просто потому что аналитик не предусмотрел что-то. И это что-то вылазит только при разработке.
Я очень редко видел в компаниях экспертов, но очень часто видел именно аналитиков. Т.е. аналитик — это человек, который обходится компании дешевле, чем разраб, поэтому он всего лишь снимает с разраба рутинную работу по сбору информации.
Если же это самостоятельный разраб, способный спланировать и реализовать проект, то он вполне способен погрузиться в предметную область не хуже аналитика.
Возможно вы имеете в виду не аналитика, а эксперта. Вот эксперта в соответствующей области действительно глупо пытаться переплевывать. Но аналитик, как правило, таковым не является.
Так что придется отложить.
Может вы заодно сможете пояснить что Греф мог иметь в виду под словами «боремся с программистами»?
Да, при переходе от каждого изделия к следующему, приходится много чего переделывать в самом изделии. Но…
1. Когда вы запустили в производство скейтборд, у вас пошли живые деньги. Не через 5 лет, а через полгода. И это совсем не то же самое, что делать с нуля автомобиль без денег, на одних обещаниях инвесторам.
2. Когда вы сделали скейтборд и начались продажи, вы уже не «тот придурок», который строит звездолет на пустом месте, а человек с опытом запуска бизнеса, которому инвесторы более охотно дают деньги. Это и корпораций касается. Там свои «инвесторы».
3. Да, для самоката нужно делать фактически новую конструкцию, но часть оборудования для производства подойдет от самоката, поставщики частично уже есть, сеть сбыта уже налажена, каналы продаж протестированы и известны. Кроме того, есть уже сработавшаяся команда, методы управления, постановки и решения задач и много чего еще.
4. Если для скейтборда достаточно команды из пары человек, то автомобиль уже может разрабатывать команда из пары тысяч человек. В итоге, мы вполне можем уложиться в те же полгода, условно говоря.
Если посмотрите на Маска, то он сначала сделал Paypa, потом Tesla, а уже потом замахнулся на Space X. И даже со Space X у него сначала простая ракета появилась, а уж потом он стал спасать первую ступень.