Робота з колегами при розробці потребує консультації [закрито]

Я розробив нашу поточну архітектуру проектів і почав самостійно її розробляти (досягнувши чогось подібного, revision 40) .

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

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

Тепер, що було зроблено:

• Я запустив кілька реалізацій відповідних інтерфейсів, переніс декілька зручних бібліотек і написав заглушки реалізації для деяких частин програми.
• У мене був документ, що описує стиль кодування та приклади використання цього стилю кодування (мій власний письмовий код).
• Я змусив використовувати більш-менш сучасні C++методи розробки, включаючи no-deleteкод (обернутий через смарт-покажчики) тощо.
• Я задокументував мету конкретних реалізацій інтерфейсу та те, як їх слід використовувати.
• Одиничні тести (в основному, інтеграційні тести, оскільки не було багато "фактичного" коду) та набір макетів для всіх основних абстракцій.

Я був відсутній 12 днів .

Що ми маємо зараз (проект розробили 4 інші члени команди):

• 3 різних стилів кодування в усьому проекті (я думаю, два з них погодилися використовувати той самий стиль :) , це ж стосується іменування наших абстракцій (наприклад CommonPathData.h, SubwaySchemeStructures.h) , які в основному є заголовками, декларуючи деякі структури даних.
• Абсолютна відсутність документації для нещодавно реалізованих деталей.
• Те, що я нещодавно міг назвати single-purpose-abstractionзараз, займається принаймні двома різними типами подій, має тісну взаємодію з іншими частинами тощо.
• Половина використовуваних інтерфейсів тепер містить змінні учасника (sic!).
• Використання сирого вказівника майже скрізь.
• Тести блоку вимкнено, оскільки " (Rev.57) They are unnecessary for this project".
• ... (це, мабуть, не все) .

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

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

Чи можна зробити щось у цьому випадку?

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

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

Рефактор нещадно вибратися з безладу!

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

Найгірше те, що вам доведеться повернутись до редакції 40, а ваші програмісти провели 12-денне заняття, що дало їм краще зрозуміти тему.

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

Перефразовуючи ваше запитання - "Я пішов на пару тижнів і не погоджуюся з тим, що робила моя команда, коли мене не було, як змусити їх робити те, що я хочу, коли мене тут немає?"

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

Якщо для того, щоб завдати стільки шкоди вашому дизайну, потрібно 12 днів, то повинна бути причина. Чи конструкція неміцна? це над інженером? чи команда просто зробила це на зло? Які ваші терміни та поставки? Тісно? вони просто намагалися зустріти одного?

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

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

Пара.

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

Що ж, ваша команда щойно повідомила вам, досить звучно. Вони сказали: "Ей, Іпі, ти не спілкуєшся!" Найпотужнішою формою спілкування, яку я знаю, є спарювання. Пара. Поки вони не отримають його, або поки вони не переконають вас зробити це по-іншому.

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

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

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

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

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

Я не бачив однієї речі, але останнім часом, де я працюю, з'явилися проблеми "розробників силосів" та "купівлі".

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

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

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

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

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

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

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

Редагувати:

Нещодавно я зіткнувся з подібною ситуацією. Керівництво моєї компанії наполягало на тому, щоб ми використовували розробників контрактів для написання більшої частини заявки. Код, який вони створили, був жахливим (якщо говорити ласкаво), але ми були змушені ним користуватися. На сьогоднішній день я переписав 80% коду, який нам написали підрядники. Це було багато помилок і неможливо поширити за допомогою нових функцій. Ще через пару місяців моя команда переписує все це, фактично перетворюючи гроші, вкладені в розробку контрактів, марно.

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

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

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

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