Недавно я запустил проект, который не казался слишком сложным, концепция представляла собой довольно простое приложение, которое время от времени должно было принимать входные данные (возможно, 10 раз в день), и пытаться выполнять над ними некоторые операции и собирать все результаты. в конце. Это приложение затем получило бы интерфейсный веб-портал, который клиенты могли бы использовать для просмотра результатов, а не просто ракетостроение.
Для этого я изначально умело использовал встроенные библиотеки параллелизма Python ( ThreadPoolExecutor
) и использовал простую в использовании библиотеку для внешнего интерфейса (я выбрал Flask, поскольку он прост для начинающих и относительно прост в обслуживании и тестировании).
Как только мы оказались на полпути к проекту, премьер-министр заявил, что нам нужно использовать сторонние возможности очереди сообщений вместо потоков и реализовать балансировку нагрузки, что в итоге привело к тому, что мы в итоге начали работать с Celery, Redis, RabbitMQ, Nginx, uWSGI. и куча других крупных сторонних сервисов, с которыми никто не имел никакого реального опыта.
В конце концов это привело к куче спагетти-кода, непроверяемым задачам (из-за сложности сторонних библиотек, исправление кода даже не работало) и куче головных болей, потому что никто даже не знал, какова дополнительная ценность этих сервисов. ,
Прежде чем сказать «Да, вы должны использовать эти сервисы», имейте в виду, что никто не знает, как использовать эти сервисы, и даже не знает, что они делают, кроме как вводить код, сопровождающий состояние гонки.
Что мне с этим делать? На этом этапе было бы просто слишком дорого возвращаться к тому, что у нас было, и премьер-министр абсолютно не хочет использовать эти сервисы, даже если конечный продукт сейчас хуже, чем был в начале. Есть ли смысл обсуждать это с ним? Я прошу больше времени? Или грубый ответ, я просто слишком глуп для своей работы?
источник
Ответы:
Это неуместно для премьер-министра "заявлять" в одностороннем порядке. Две причины:
Проектные решения должны приниматься техническим ресурсом и только в ответ на NFR . Так что вежливо спросите своего премьер-министра, есть ли новый NFR и не могли бы вы сообщить подробности.
Если NFR вводится на полпути через проект, это, вероятно, должно быть сделано через контроль изменений . Контроль изменений очень важен с точки зрения управления; это будет не только вклад в ваши требования, но и важный вклад в контрольные примеры QA, руководство по развертыванию и поддержке операций и (здесь действительно важная часть) расписание PM . Если новое требование вводит больше работы, команда разработчиков должна иметь возможность сообщать новые оценки развития, и премьер-министр должен будет решить, смогут ли они жить с новой датой, добавить больше ресурсов или оттолкнуть заинтересованную сторону, которая представила НФР.
Теперь, если действительно есть добросовестный NFR, и нет возможности обойти его, может также быть целесообразным запросить новые или другие ресурсы, которые знакомы с внедряемыми технологиями, или запросить бюджет на обучение для некоторых из ваших существующих Ресурсы. Так что есть и аспект затрат .
Если вы говорите на языке премьер-министра - график и стоимость - я думаю, вы получите больше тяги, чем говорить о том, как разработчики относятся к полученному проекту. Эти вещи имеют реальное влияние.
Премьер-министр должен знать лучше, чем представлять подобные вещи на лету, без управления, контроля и консенсуса. Если они просто не понимают этого, вам, возможно, придется перейти к управлению продуктами или программам, поскольку он (а) подвергает риску качество и график излишне.
источник
Что было бы глупо - это позволить себе пройти смертью .
То, что вы описываете, это то, что вы потеряли критическое чувство. Нет чувства контроля и нет ясного пути к нему.
Последнее, что вы должны сделать, это усердно работать, не поднимать голову и тихо страдать, пока они наконец не признают, что проект обречен.
Что вы должны сделать, так это подумать о том, что вы имеете полное право ожидать.
Если они хотят, чтобы вы использовали технологии, которые вы не понимаете, вы должны ожидать времени, чтобы изучить их. Не стыдись того, чего не знаешь. Используйте свое невежество как дубину. Когда они требуют, вы используете что-то, спросите почему. Не принимай «потому что». Не принимайте «современные лучшие практики». Не принимайте «масштабируемость» без получения реальных, проверяемых ожиданий.
Под тестируемым я имею в виду, что они ДОЛЖНЫ сообщать вам, сколько запросов в день / час / минуту они хотят, чтобы они могли выполнять. Дайте понять, что вы намереваетесь построить что-то для этой системы в соответствии с этими спецификациями.
Таким образом, вы можете использовать 30-дневную бесплатную пробную версию, чтобы доказать, что последняя вещь, которую они хотят, стоит того или если вам лучше придерживаться того, что вы уже знаете.
Теперь имейте в виду. Это не инструменты, которые вводили код, страдающий от состояния гонки. Вы, ребята, сделали это. Вы должны узнать, КАК вы это сделали, чтобы вы могли отменить это.
И нет. Это не слишком дорого, чтобы вернуться к тому, что у вас было. Премьер-министр не может иметь то, что они хотят, просто требуя этого. Вы должны отступить, пока не сможете эффективно использовать то, что хочет премьер-министр, или доказать, что это не то, что нужно проекту.
Серьезно, просто поддаваться этому непрофессионально и смертельно для проекта.
Я был здесь, чувак. Более одного раза. Это заставляет вас чувствовать себя глупо. Это действительно не так. Вы просто потерялись.
Поговори в личку. Честно. Выложи все это. Покажите, что вы готовы учиться, но не хотите, чтобы вас прокатили. Никогда когда-либо разрабатывать или кодировать на основе веры. Заставьте PM показать вам, как делать то, что они хотят. Не притворяйся, что понимаешь, когда не понимаешь. Не говори, что это будет сделано, когда это не будет. Если вы собираетесь верить во что-то, верьте в себя. Вы должны быть готовы сказать НЕТ.
Если это не сработает, отполируйте резюме, потому что оно вам скоро понадобится. Тем или иным способом.
источник
Now keep in mind. It isn't the tools that introduced race-condition plagued code. You guys did that. You need to learn HOW you did that so you can undo that.
Да, эта часть особенно выделяется на мне. Будь то сельдерей или нити, любой тип параллелизма может создать условия гонки. Те же проблемы вполне могли существовать в коде на основе потоков.Это действительно должно быть на workplace.stackexchange.com, потому что проблема заключается не в разработке программного обеспечения, а в отношениях на рабочем месте.
Если вы уверены, что ваш простой подход сработал бы и дал бы рабочий результат довольно быстро, тогда ваш PM - это разрушительная сила в вашей компании, которую следует устранить. Выясните, как получить новости на уровень выше его: чтобы ваша команда имела простое, работающее решение, которое добилось хорошего прогресса, и по причинам, которые никто не может объяснить, ваш премьер-министр заставил вас попробовать гораздо более сложное решение, используя множество инструментов, которые никто не знает, никто не понимает, никто не знает, полезны ли они вообще, и это непостижимое решение вашего премьер-министра вызвало у вас все проблемы и заставило проект опоздать и не работать.
источник
Не зная контекста и стратегии продукта, используемой вашим руководством, трудно объективно ответить на ваш вопрос.
Вот несколько объективных аргументов. Однако возможно, что это не то, что вы ожидали:
В конечном счете, за экономический выбор отвечает менеджер вашего продукта. Обсудите с ним плюсы и минусы, чтобы убедиться, что он принимает хорошо обоснованное решение и не недооценивает сложность. И если он останется на своем пути, постарайтесь сделать все возможное: вам нечего терять, и в худшем случае у вас будет новая технология в вашем резюме.
источник
Существует два подхода к сторонним библиотекам (и другим компонентам):
Мой подход (2). Похоже, ваш подход тоже (2), но руководителю проекта этот подход нравится (1).
Есть три способа справиться с этой ситуацией. Либо вы позволяете премьер-министру делать то, что хочет премьер-министр, вы пытаетесь убедить премьер-министра изменить подход к сторонним библиотекам, либо вы голосуете ногами и выбираете другую работу.
Если вы хотите убедить премьер-министра изменить подход, рассмотрите следующие аргументы:
Будьте осторожны, особенно если библиотека называет себя фреймворком . Это означает, что библиотека требует от вас построения всего приложения вокруг себя. Как правило, у вас не может быть двух фреймворков в одном приложении; они будут сражаться друг с другом без мирного сосуществования. Утилита для веб-разработки? Да, пожалуйста, их слишком мало. Если я когда-нибудь найду библиотеку лучше, чем я использую сейчас, я могу использовать вновь найденную библиотеку в новом коде, продолжая использовать старую библиотеку в старом коде. Фреймворк веб-разработки? Большой гудок НЕТ!
источник
Я думаю, что ваш премьер-министр стремится создать сложную в управлении систему, которая будет выполнять большую часть работ по техническому обслуживанию, пока она работает, поэтому она обеспечит ваш доход.
Лично вам кажется, что вы застряли на python, просто на некоторое время забудьте о python, не программируйте на python на год, изучайте новые вещи, вы увидите, что есть другие языки, которые могут делать то же самое, и, вероятно, лучше.
Как уже говорили другие, изучите инструменты, прежде чем начинать программировать с ними. Возможно предположить, что было бы хорошо, чтобы оценить необходимый стек вместе, основываясь на исследовании различных инструментов, которые кажутся подходящими для этой задачи. Или, может быть, спросить, как он составил этот список, он мог бы получить помощь от кого-то, кто в курсе.
источник
Разработчики не должны бояться научиться использовать новые библиотеки, платформы, технологии и т. Д. Это является основной частью описания работы разработчика, и совершенно разумно предложить кому-то работать с сторонними вещами, которых никто не имеет. опыт или даже требование, чтобы команда сделала это, если они в состоянии принимать авторитетные технические решения для команды.
Тем не менее, не стоит ожидать, что вы можете просто использовать новую технологию (не говоря уже о нескольких новых технологиях одновременно).) в свой стек и продолжайте делать успехи. Должно было быть запланировано значительное время, чтобы изучить все тонкости нового подхода и придумать хороший дизайн для включения новых элементов, в течение которых не ожидается никакого реального прогресса по фактическому продукту (от людей, занимающихся этой учебной / конструкторской работой). , которая может быть, а может и не быть всей командой, хотя, если это не так, вероятно, нужно больше запланированного времени в будущем для людей, которые научились передавать знания остальной части команды). Это стоимость внесения такого рода серьезных изменений. Изучение новых технологий является частью работы разработчика, но это не то, что просто происходит без затрат времени.
Похоже, этого не произошло из-за вопроса. Люди правы, пытаясь каким-то образом создать хорошие реализации на основе технологий, которые они сами не понимали. Конечно, полученный код ужасен.
Постарайтесь убедить ПМ , что компания будет нужно тратить больше времени на это. Это либо придет в форму остановки сейчас, изучения и оценки новых технологий, определения хорошего дизайна и устранения текущей путаницы в реализации. Или это придет в виде большего количества времени, потраченного на ошибки, обслуживание, дорогостоящие разработки и т. Д.
Невозможно сказать, насколько уместны технические варианты, описанные в вопросе (балансировка нагрузки, очереди сообщений и т. Д.). Я не думаю , что «ни один из команды не имеет опыта работы с этим , прежде чем» хорошая причина , чтобы абсолютно исключает решение, но это действительно увеличивает стоимость краткосрочной перспективе сделать это решение (которое может изменить " «лучшее решение для контекста», и если ваш премьер-министр не учитывает это и ожидает, что команда сразу же станет настолько продуктивной, насколько опытными будут люди, тогда вам следует отступить на этом основании; они будут устанавливать крайне нереалистичные графики проектов, что не в чьих-либо интересах.
источник