Як завадити колезі ввести надзвичайну складність та абстракцію?

Мені дуже важко, тому що, здається, мій колега демонструє

1. Передчасні / зайві оптимізаційні зусилля
2. Передчасна дедупликація із сумнівними абстракціями
   Наприклад, ми використовуємо модифіковану архітектуру VIPER. Він представив базовий клас для компонента Router (використовуючи generics) як частину реалізації першого стека viper, не знаючи, що саме буде дублюватися в інших маршрутизаторах. Тепер нам загрожує надання типу, UseCaseякий містить випадки використання, але у більшості маршрутизаторів немає випадків багаторазового використання, лише один.
3. Винайдення рішень загального призначення для спекулятивних потенційних можливостей у майбутньому
   Наприклад, він написав менеджера для заповнення статичних переглядів стільникових комірок, коли у нас було лише два екрани на зразок цього в додатку, і він не знав, що дизайн перейде від нудних вертикальних форм до більш спеціальних Інтерфейси користувача, тому менеджер марний.
4. Вибираючи випадкову складність

Як я можу боротися з цим, коли він також виставляє мовний бар'єр з паршивою англійською?

Ваш опис звучить як кодування, яке я зробив у 1990-х. Виступити належним чином для сучасного світу непросто. Рекомендую зосередитись на наступних факторах:

• Спарювання. Два набори очей можуть допомогти захистити від однієї людини велику, але складну реалізацію.
• Огляд коду. Сучасні магазини переглядають 100% всіх змін коду кількома людьми
• Тестове покриття. Переконайтеся, що є прості тести. Надмірно складні тести можуть відображати надто складний код
• Багато дискусій про мінімально життєздатний продукт. Розбийте функції на найменші можливі компоненти. Добре мати один квиток для зміни бази даних, інший для заповнення довідкових таблиць, а потім третій для оновлення інтерфейсу користувача (тієї частини, яка насправді буде видно кінцевим користувачам), але це буде відчувати контр-інтуїтивність, як спочатку, як опір ймовірно.
• Часті дискусії про те, як мати менші квитки та зміни.
• Історія голосування всією командою, щоб відкрити дискусії про складність та підхід.
• Освіта. Переконайтеся, що у вас є обід та навчання, навчальні заняття тощо, щоб люди могли зазнати передового досвіду та чому вони хороші.

З усього вищесказаного моїми основними основними напрямками уваги будуть огляди коду та невеликі історії.

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