Чи повинна програмна компанія мати спеціальний колектив для досліджень та / або бібліотек?

Я працюю в компанії, яка робить веб-додатки для різних банків та деякі менші електронні магазини. У нас працює близько 20 розробників і в один момент розробляється 4-5 проектів. Наші команди розвитку не взаємодіють багато, і багато тих же проблем робляться різними способами (від хорошого до поганого).

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

Наскільки має бути така команда?

Чи повинен він мати постійних членів, які навчають інших, чи він повинен обертати людей?

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

Важливим моментом є те, що неможливо розробити хорошу основу в тотальній ізоляції. Хороші рамки органічно вирощуються : коли програміст помічає, що йому потрібна певна функціональність, він додає його в рамки, і тому рамка зростає потроху - на відміну від створення «ідеального каркаса» на передній частині, який ніколи не працює, тому що архітектор не може знати про всі зрештою випадки використання.

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

Моє відчуття - ні.

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

Існують різні проблеми з типовою командою, яку ви описуєте, але для мене головне в тому, що вона не стосується проблеми, яку ви насправді маєте.

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

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

Я б запропонував:

• обертати команди між проектами
• проводити міжкімнатні обіди та дискусійні групи
• розміщувати огляди проекту, де переглядаються шляхи вирішення проблем (брали участь інші команди)
• встановіть область викісного коду, який може бути багаторазовим (і з ким про це говорити)
• подумайте про стимулювання хорошого повторного використання - серйозно насправді платите людям додатково за це. Якщо повторне використання компонента економить 5 днів і $ 2000, то чому б не дати 200 доларів від того, що зараз є додатковою прибутком для команди за ніч у кінці проекту (коли ви підтвердили, що заощадження було справжнім)

Підозрюю, колектив бібліотек не матиме жодних вигод.

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

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

Це робота архітектора .

Основні обов'язки архітектора програмного забезпечення включають:

• Обмеження варіантів, доступних під час розробки, шляхом вибору стандартного способу розвитку програми
• створення, визначення або вибір рамки для програми
• Визнання потенційного повторного використання в організації або в додатку шляхом дотримання та розуміння більш широкого системного середовища
• Створення компонентного дизайну Маючи знання про інші програми в організації

Детальніше про: - Архітектор програмного забезпечення - Архітектор рішень - Архітектор підприємств .

Приказка « Їсти власну собачу їжу » вирішує це питання. Якщо ваш кодек-класний рок-зірка народжує бібліотеку, яку він ніколи не використовував на практиці, як він може сказати, що вона хороша?

Основними причинами розвитку функціональних можливостей є рамкові

1. Це корисно для розробника
2. Є кілька випадків, коли це було корисно
3. Може бути корисним іншим

Коли ви натиснули 2, функціональність вже є, як ви можете передати її комусь іншому?

Я трохи запізнююся на гру, але мені здалося, що ніхто до цього не звертається:

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

У більшості випадків я вважаю це «ядром» вашої лінійки продуктів, а іноді є команда, яка відповідає за її підтримку, на чолі з (як запропонував Амір) архітектор. Це, як правило, ви зможете знайти способи використання або створити рамку, яка відповідає найсуворішим стандартам, встановленим у вашій організації, але надає лише найпростіші функціональні можливості, які можуть або не потребуватимуть поширення на повноцінні програми що пропонують ваші індивідуальні групи продуктів. Це дозволяє вам отримати перевагу "dogfooding" вашого основного коду, застосовуючи його в кожному окремому місці, яке ви використовуєте, а потім також розгалужувати різні продукти, які можуть мати абсолютно різні реалізації. Це дозволяє всім вашим командам внести свій внесок у основні бібліотеки, але не заблокувати їх функціоналом, який потрібен лише їм.

Я думаю, що це НЕ ДОБРИЙ ІДЕЯ , адже бібліотеки, щоб бути корисними, вони повинні допомогти вам вирішити реальні проблеми з проектами, і ви їх знайомите лише, добре ... працюючи в реальних проектах.

Інакше ви можете закінчити «теоретично» дуже гарну бібліотеку!

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

Я очікував, що це станеться, це те, що група інструментів перетвориться на свою маленьку програму, виробляючи функції, які насправді не такі корисні, але які захаращували API і звикли достатньо, щоб їх не було легко вилучено. Вони не мали б документально адекватно документувати.

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

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