Як боротися з ще не реалізованим методом, який буде виконувати співпрограміст?

Це питання про те, як працювати в командах.

Нещодавно я працював над своїм першим більшим проектом програмування (~ 80 класів, Java) з командою з 6 чоловік, хоча над цим кодом постійно працювали лише 4 людини. Ми розповсюдили роботу, яку потрібно виконати на ранніх стадіях, і в якийсь момент мені потрібно було викликати метод, який ще не був реалізований одним із моїх співпрограмістів. Як рекомендований спосіб боротьби з цим?

Я побачив варіанти, хоча жоден з них мені не подобається:

1. Написання себе //TODOта перегляд цього рядка коду пізніше, щоб перевірити, чи метод тим часом був реалізований.

2. Попросити відповідного члена команди реалізувати це зараз .

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

4. Додавання потрібного методу до свого класу та записування їх //TODOу тіло повідомлень, можливо, також надсилайте їм швидке повідомлення про цю зміну. (Зараз це вже не моя проблема, але це може спричинити дратівливі конфлікти злиття, якщо вони тим часом працювали над цим методом)

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

Це цікаве питання, і відповідь може бути простішим, ніж ви думаєте.

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

Довга відповідь.

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

• Коментарі повинні бути прочитані та оброблені вашим колегою, відповідальним за впровадження. Тим часом ваш код неможливо скласти. Якщо ви перевіряєте такий стан у сховищі коду, ваш конвеєр безперервної інтеграції не працюватиме, і все одно погана практика ... ніколи не перевіряйте зламаний код
• Винятки з виконання роботи здаються кращими, але все ще є токсичними, оскільки ваш колега-програміст міг припустити, що впровадження вже було здійснено без перевірки, залишаючи систему в нестабільному стані. Якщо метод запускається не так часто, це може призвести до порушеного виробничого коду ... також погана практика ... ніколи не перевіряйте винятки "не реалізовані"
• Чекати своїх колег-програмістів для впровадження методів чи заглушки теж непросто. Це порушує ваш робочий процес і робочий процес ваших колег-програмістів. Що станеться, якщо вони хворі, на зустрічі, на перерві на каву, ви хочете витратити час на очікування? ... не чекай когось, якщо тобі не доведеться
• реалізувати відсутні методи, безумовно, найкращий спосіб йти вперед. Але що станеться, якщо ваша реалізація не задовольняє весь випадок використання, і вашим колегам-програмістам потрібно змінити чи змінити її? Як ви та вони переконуєтесь, що він все ще сумісний із наміченим? Відповідь знову легка. Пишіть тести, які підтверджують, описують та документують ваші наміри. Якщо тести зламаються, це легко помітити. Якщо потрібні зміни в цьому методі, які порушують вашу функцію ... ви бачите це негайно. У вас обох є причина спілкуватися і вирішувати, що робити. Розділити функціональність? Змініть свою реалізацію тощо ... ніколи не перевіряйте код, який недостатньо задокументований тестами

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

1. TDD - тестова розробка - це дозволить вам описати свій намір і достатньо перевірити його. Це також дає можливість глузувати або підробляти методи та класи (також за допомогою інтерфейсів), які ще не реалізовані. Код і тести все ще збиратимуться і дозволять вам протестувати власний код у відриві від коду ваших колег-програмістів. (див .: https://en.wikipedia.org/wiki/Test-driven_development )

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

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

Це дозволить вам помістити свій код у конвеєр безперервної інтеграції та створити високонадійну реалізацію.

Якщо ви хочете пройти далі в цій темі, перевірте наступні посилання:

• https://martinfowler.com/bliki/TestDrivenDevelopment.html
• https://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
• https://www.amazon.de/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=sr_1_1?s=books-intl-de&ie=UTF8&qid=1514648927&sr=1-1&keywords=refactoring

Попросіть заглушки.

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

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

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