Прем'єр-міністр вибирає занадто складну установку, з якою ніхто не має досвіду [закритий]

Нещодавно я розпочав проект, який не здавався надто важким зробити, концепція - це досить просте додаток, яке доводилося раз у раз приймати вхід (можливо, 10 разів на день) і намагатися виконувати деякі операції над ними та збирати всі результати в кінці. Потім ця програма отримає перехідний веб-портал, який клієнти могли б використовувати для перегляду результатів, а не зовсім про ракетну науку.

Для цього я спочатку розумно використовував вбудовані бібліотеки паралельних можливостей Python ( ThreadPoolExecutor) і використовував просту у користуванні бібліотеку для передової частини (я вибрав Flask, як це легко для початківців і порівняно простий в обслуговуванні та тестуванні).

Після того, як ми опинилися на півдорозі проекту, прем'єр-міністр заявив, що треба використовувати можливості черги повідомлень сторонніх повідомлень замість ниток і потрібно реалізувати балансування навантаження, що в підсумку закінчилося, що ми врешті почали працювати з Celery, Redis, RabbitMQ, Nginx, uWSGI і купа інших великих сторонніх послуг, з якими ніхто не мав реального досвіду.

Врешті-решт це призведе до купою коду спагетті, нестабільних завдань (через складність бібліотек сторонніх організацій, виправлення коду навіть не спрацювало) та купі головних болів, бо ніхто навіть не знав, яка додаткова цінність цих послуг .

Перш ніж сказати "Так, ви повинні користуватися цими послугами", майте на увазі, ніхто не знає, як ними користуватися, а навіть не знає, що вони роблять, окрім введення коду, що спричиняє гонку.

Що мені робити з цього приводу? На даний момент просто повернутись до того, що у нас було, і прем'єр-міністр не може використовувати ці послуги, навіть якщо кінцевий продукт зараз гірший, ніж був на початку. Чи є навіть користь в обговоренні цього з ним? Прошу більше часу? Або сувора відповідь, я просто занадто дурний за свою роботу?

Після того, як ми опинилися на півдорозі проекту, прем'єр-міністр заявив, що нам потрібно використовувати можливості черги повідомлень сторонніх осіб замість ниток, і потрібно було виконати балансування навантаження

Це не є підходящою річчю для прем'єр-міністра "держава" в односторонньому порядку. Дві причини:

1. Проектні рішення повинні прийматися технічним ресурсом і лише у відповідь на НФР . Тому ввічливо запитайте у прем'єр-міністра, чи є новий НФР і чи можете ви, будь ласка, деталізувати.

2. Якщо НФР впроваджується на півдорозі проекту, це, мабуть, слід зробити через контроль змін . Контроль змін є дуже важливим з точки зору управління; це не тільки є вкладом у ваші вимоги, але й є важливим вкладом до тестових випадків QA, розгортання операцій та посібника з підтримки, а також (ось справді важлива частина) розкладу ПМ . Якщо нова вимога запровадить більше роботи, команда розробників повинна мати можливість повідомляти нові оцінки розвитку, і прем'єр-міністру доведеться вирішити, чи зможуть вони жити з новою датою, додавати більше ресурсів чи відштовхуватися від зацікавленого боку, який представив NFR.

Тепер, якщо дійсно є добросовісний NFR, і його не обійти, можливо, також буде доречним запит на нові або різні ресурси, які знайомі з технологіями, що впроваджуються, або запитувати бюджет на навчання для деяких існуючих ресурси. Тож є і аспект витрат .

Якщо ви розмовляєте мовою прем'єр-міністра - графік і вартість - я думаю, ви отримаєте більше тяги, ніж говорити про те, як розробники почуваються щодо отриманого дизайну. Ці речі мають реальний вплив.

Прем'єр-міністр повинен знати краще, ніж вводити подібні речі на льоту, без управління, без контролю та консенсусу. Якщо вони просто цього не отримають, вам, можливо, доведеться перейти до управління продуктами або управління програмами, оскільки він (і) не підлягає ризику якості та графіку.

Що було б дурним - це дозволити собі піти на смерть .

Ви описуєте те, що втратили критичне почуття. Немає почуття контролю та чіткого шляху до нього.

Останнє, що вам слід зробити, - це наполегливо працювати, опустити голову і тихо страждати, поки вони нарешті не визнають, що проект приречений.

Що вам слід зробити, це дуже важко подумати над тим, що ви маєте всі права очікувати.

Якщо вони хочуть, щоб ви використовували технології, які ви не розумієте, вам слід очікувати часу, щоб їх вивчити. Не соромся того, чого не знаєш. Використовуйте своє незнання як дуби. Коли вони вимагають, ви використовуєте щось, запитайте, чому. Не приймайте "тому що". Не приймайте "сучасні кращі практики". Не приймайте "здатність до масштабу", не отримуючи реальних, перевірених очікувань.

Під тестуванням я маю на увазі, що вони ХОЧУТЬ сказати вам, скільки запитів на день / годину / хвилину вони хочуть зробити. Поясніть, що ви маєте намір створити щось для здійснення цієї системи відповідно до цих специфікацій.

Таким чином, ви можете використовувати 30-денну безкоштовну пробну версію, щоб довести, що остання річ, яку вони хочуть отримати, або якщо вам краще дотримуватися того, що ви вже знаєте.

Тепер майте на увазі. Це не інструменти, які запровадили вразливий кодовий стан. Ви, хлопці, зробили це. Вам потрібно навчитися, як ви це зробили, щоб ви могли скасувати це.

І ні. Повернутися до того, що у вас було, не надто дорого. Прем'єр-міністр не може мати того, чого хоче, лише вимагаючи цього. Вам потрібно відштовхуватися, поки ви не зможете ефективно використовувати те, що хоче прем'єр-міністр або довести, що це не те, що потрібно проекту.

Якщо серйозно, просто поступитися цим непрофесійно і смертельно.

Я тут був, людина. Більше одного разу. Це робить тебе дурним. Це справді не так. Ти просто загубився.

Поговоріть з прем’єр-міністром. Чесно. Викладіть все це. Покажіть, що ви готові вчитися, але не хочете їздити на поїздку. Ніколи ніколи не розробляючи або кодуючи на основі віри. Запропонуйте прем'єр-міністру показати вам, як робити те, що вони хочуть. Не робіть вигляд, що розумієте, коли цього не зробите. Не кажіть, що це буде зроблено, коли це не буде. Якщо ви збираєтесь вірити в щось, повірте в себе. Ви повинні бути готові сказати "НІ".

Якщо це не спрацьовує, відшліфуйте резюме, оскільки вам це знадобиться незабаром. Так чи інакше.

Це дійсно має бути на робочому місці.stackexchange.com, оскільки проблема полягає не у питанні щодо розробки програмного забезпечення, а у відносинах на робочому місці.

Якщо ви впевнені, що ваш простий підхід спрацював і дав би робочий результат досить швидко, то ваш прем'єр-міністр - це руйнівна сила у вашій компанії, яку слід усунути. З'ясуйте, як домогтися новин до рівня вище: Щоб ваша команда мала просте, робоче рішення, яке добре прогресувало, і з тих причин, що ніхто не може пояснити, ваш прем'єр-міністр змусив вас спробувати набагато складніше рішення, використовуючи безліч Інструменти, про які ніхто не знає, ніхто не розуміє, ніхто не знає, чи корисні вони взагалі, і це незбагненне рішення вашого прем'єр-міністра завдало вам усіх клопотів і призвело до запізнення та непрацювання проекту.

Не знаючи контексту та товарної стратегії, яку проводить ваше керівництво, важко об'єктивно відповісти на ваше запитання.

Ось кілька об’єктивних аргументів. Однак можливо, що це не те, чого ви очікували:

• « Майте на увазі , що ніхто не знає , як використовувати ці продукти ще ».
• Використання лише інструментів та прийомів, відомих ідеально, забезпечить високу продуктивність. Але це значно обмежить можливість інновацій. На деяких ринках це може бути фатальним для вашого продукту. Наприклад, майже 30 років тому я запропонував використовувати Windows 3.0 для розробки нової версії продукту CAD, який був успішним в MS-DOS. Керівник продукту заперечував, що це не перевірене середовище, що було б занадто складним і занадто важким для навчання команді, і все одно, що " Windows ніколи не буде основним середовищем " ... Я дозволяю вам здогадатися про успіх його продукт через 2 роки.
• Все це питання витрат і вигод. Вартість експериментів порівняно з перевагою масштабованості та розгорнутості забезпечується третьою стороною, яка має величезні установки та велике навантаження.
• Недоліки додавання нових технологій можуть бути усунені відповідним навчанням або початковою підтримкою / інструктажем досвідченим консультантом.

Зрештою, економічний вибір - це відповідальність вашого менеджера продуктів. Обговоріть з ним плюси і мінуси, щоб він прийняв добре обґрунтоване рішення і не занижував додаткову складність. І якщо він залишиться на своєму шляху, постарайтеся досягти все можливе: ви нічого не втрачаєте, а в гіршому - у вашому резюме з’явиться нова техніка.

Існують два підходи до сторонніх бібліотек (та інших компонентів):

1. Використовуйте якомога більше їх
2. Використовуйте якомога менше їх

Мій підхід (2). Здається, що ваш підхід теж є (2), але керівнику проекту подобається підхід (1).

Є три способи вирішити цю ситуацію. Або ви дозволите прем'єр-міністру робити все, що хоче прем'єр-міністр, ви намагаєтесь переконати прем'єр-міністра змінити підхід до сторонніх бібліотек, або ви голосуєте ногами і вибираєте іншу роботу.

Якщо ви хочете переконати прем’єр-міністра змінити підхід, врахуйте ці аргументи:

• Час вчитися. Кожна зовнішня бібліотека потребує часу на вивчення, в цей час грамотний програміст може записати потрібну функціональність, особливо якщо величезна бібліотека була обрана просто для того, щоб зробити дуже просту річ, яку можна зробити за кілька сотень рядків коду.
• Заміна.Якщо у вас є зовнішня бібліотека, як ви гарантуєте, що якщо її розвиток припинено, ви можете замінити її на іншу подібну бібліотеку? Моє рішення - уникати зовнішніх бібліотек, коли я можу, і коли це неможливо, я пишу просту обгортку, щоб абстрагувати частину потрібного інтерфейсу програмування. Зазвичай інтерфейс, який я хочу, набагато простіший, ніж інтерфейс, який пропонує бібліотека. Тоді мій код отримує доступ до зовнішньої бібліотеки лише через цю обгортку, що робить заміну легкою. Побудова всієї вашої програми на якійсь основі - це велика ні-ні. Сервлець? Так, вони тут вже давно і продовжують перебувати тут в осяжному майбутньому. Двигуни шаблонів? Так, хоча вони не зовсім замінні (ви зазвичай вибираєте один і залишаєтесь з цим), цінність, яку вони приносять, величезна, тому обережно вибирайте - і майте на увазі, що при переключенні двигунів шаблонів ви можете мати два двигуни шаблону в одній програмі, але у вас не може бути дві рамки в одній програмі. Apache Struts? Ні, рамки приходять у моду і швидко виходять з моди, і зазвичай у вас не може бути дві рамки в одному додатку.
• Версія пекла. Вибравши зовнішню бібліотеку, вам доведеться оновити її, щоб уникнути вразливості безпеки, і її оновлення може порушити ситуацію. Добре розроблені компоненти (наприклад, Java JRE) сумісні з різними версіями, але мій досвід полягає в тому, що більшість бібліотек лайно через накладення величезної пекло версії. Також компонент X може вимагати Z версії 1, а компонент Y може вимагати Z версії 2, і ви не обов'язково зможете зв’язати Z версії 1 і Z версії 2 в одній програмі.
• Уразливості безпеки. Вибравши зовнішню бібліотеку, збільшується кількість легкозабезпечених уразливостей безпеки щодо вашого додатка. Дехто може стверджувати, що власний розроблений код нагадує безпеку через невідомість, але знову ж таки, я б сказав, що це все-таки форма безпеки.
• Проблеми з ліцензією. Кожна зовнішня бібліотека накладає власну ліцензію на частини вашої програми. Наприклад, бібліотеки GPL не можна використовувати в програмах, що не належать GPL, а бібліотекам LGPL також потрібен розподіл вихідного коду разом із бінарними файлами, що може зайняти значну кількість пропускної здатності.
• Час запуску програми. Кожна велика зовнішня бібліотека уповільнює час запуску вашої програми. Написавши просту домашню бібліотеку, ви можете значно швидше зробити час запуску програми.
• Слід пам’яті. Якщо X вимагає Y, що вимагає Z, вимагає A, що вимагає B, вам потрібно одночасно X + Y + Z + A + B в пам'яті. Реалізуючи лише еквівалент X, давайте назвемо його X ', власне, вам потрібно просто X' в пам'яті. І зазвичай слід пам'яті X 'менше, ніж слід пам'яті X.
• Небезпека помилок. Чим більше рядків у зовнішньому компоненті, тим вищий ризик, що ви зіткнетеся з помилкою, яку буде важко виправити через величезну кількість коду, який вам потрібно зрозуміти. Якщо ви робите цю справу вдома, ви зазвичай робите це з меншими рядками коду (щоб робити саме те, що вам потрібно, нічого іншого), і, таким чином, менший ризик появи помилок.
• Налаштування. Якщо я самостійно пишу SQL запити, я знаю, як виглядає запит і наскільки добре він працює в заданому двигуні бази даних та заданому наборі індексів. Якщо, з іншого боку, запит SQL написаний зовнішнім компонентом, я нічого не знаю про його ефективність. Я працював у компанії, де кожна веб-сторінка займала кілька секунд, щоб отримати. Я підозрював, що причиною стала бібліотека в сплячому режимі, вони автоматично використовували надто велику кількість даних із бази даних, коли все, що вам потрібно, було одним елементом, а не всіма предметами, пов'язаними з цим конкретним елементом. Я покинув компанію, перш ніж виявити справжню причину повільності, тому що мені не сподобався підхід використання величезної кількості існуючих бібліотек.

Остерігайтеся особливо, якщо бібліотека називає себе рамкою . Це означає, що бібліотека вимагає від вас зібрати весь додаток навколо себе. Зазвичай ви не можете мати дві рамки в одній програмі; вони будуть битися між собою, не мирно співіснуючи. Бібліотека утиліт веб-розробки? Так, будь ласка, їх занадто мало. Якщо я коли-небудь знайду кращу бібліотеку, ніж те, що я зараз використовую, я можу використовувати щойно знайдену бібліотеку в новому коді, продовжуючи використовувати стару бібліотеку в старому коді. Рамка для веб-розробки? Велике хитання НІ!

Я думаю, що ваш прем'єр-міністр має на меті жорстку керувати систему, яка буде виробляти багато робіт з технічного обслуговування, поки вона живе, тому це забезпечить ваш дохід.

Особисто вам здається, що ви застрягли в python, просто забудьте python на деякий час, не кодуйте в python протягом року, вивчайте нові речі, ви побачите, що є інші мови, які можуть зробити те саме, і, можливо, краще.

Як заявили інші, вивчіть інструменти, перш ніж розпочати кодування з ними. Може підказати, що було б добре оцінити необхідний стек разом, спираючись на дослідження різних інструментів, які здаються придатними до поставленого завдання. Або, можливо, запитайте, як він придумав цей список, він міг би допомогти тому, хто є в курсі.

Розробники не повинні боятися навчитися користуватися новими бібліотеками, рамками, технологіями і т. Д. Це основна частина посадової інструкції розробника, і хтось цілком розумно може запропонувати команді працювати з сторонніми речами, які ні в кого немає. досвід або навіть вимагати, щоб команда зробила це, якщо вони можуть приймати авторитетні технічні рішення для команди.

Однак, це НЕ розумно очікувати , що ви можете просто тягнути нову технологію ( НЕ кажучи вже кілька нових технологій , відразу) у свій стек і продовжуйте прогресувати. Необхідно було запланувати значний час, щоб вивчити нові та нові можливості нового підходу та створити хороший дизайн, щоб включити нові твори, під час яких не очікується реального прогресу щодо фактичного продукту (від людей, які займаються цією навчальною / дизайнерською роботою , яка може бути, а може і не бути цілою командою, хоча, якщо її немає, можливо, потрібно запланувати більше запланованого часу вниз для людей, які навчилися передавати знання решті команди). Тобто коштують вносити подібні великі зміни. Вивчення нових технологій є частиною роботи розробника, але це не те, що відбувається лише з нульовою витратою часу.

Здається, це не сталося з питання. Люди роблять право намагатися якось зробити хороші впровадження на основі технологій, які вони самі не розуміли. Звичайно, отриманий код жахливий.

Постарайтеся переконати ПМ , що компанія буде потрібно витрачати більше часу на це. Це буде або у формі зупинки зараз, вивчення та оцінювання нових технологій, з'ясування гарного дизайну та очищення поточного безладу впровадження. Або це вийде у вигляді більше витраченого часу на помилки, обслуговування, більш дорогий розвиток тощо.

Неможливо сказати, чи є технічний вибір, описаний у запитанні (балансування завантаження, черги повідомлень тощо) насправді відповідний. Я не думаю , що «жоден з команди не має досвіду роботи з цим , перш ніж» хорошою причиною , щоб абсолютно виключає рішення, але це дійсно збільшує короткострокову вартість прийняття такого рішення (яке може змінити " найкраще "рішення в контексті), і якщо ваш прем'єр-міністр не вважає цього і очікує, що команда негайно стане настільки продуктивною, як досвідчені люди, тоді вам слід відштовхуватися від цих міркувань; вони будуть встановлювати вкрай нереальні графіки проектів, що нікому не цікавить.