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

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

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

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

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

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

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

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

Навчіть і практикуйте те, що ви проповідуєте.

Ви знаєте, що цей матеріал важливий. Ви знаєте мінус, коли це не зроблено правильно.

Тепер завдання - переконати інших. Це не буде зроблено шляхом однієї бесіди, зустрічі, бесіди в передпокої, підказки або в рамках запиту на виклик.

Для цього потрібно:

• Громадське визнання керівництвом, що ці пункти є важливими
• Вкладиші, щоб люди могли зібратися, розібратися і домовитись про стиль, а потім дозволити комп’ютерам займатися поліцією
• Провідні розробники, які повністю купують і готові навчати інших
• Зустрічі, демонстрації, обід та навчання тощо для викладання цих підходів
• Люди вимірюються якісними предметами, які ви згадуєте під час їх оглядів
• Задокументовані та опубліковані стандарти
• Затягуйте запити, що мають багато рецензентів
• Витягнути запити не об'єднуються, поки якість коду не буде високою
• Часте сполучення коду
• Огляди коду групи для складних PR

Словом, це вимагає

Лідерство

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

Раніше я багато писав на цю тему на SoftwareEngineering.SE, і сам був у подібних ситуаціях. Тому я спробую дати декілька підказок і висвітлити кілька питань, які я зазначив, читаючи ваше запитання.

Але спочатку поговоримо про важливий аспект: вашу роль у компанії.

Ваша роль

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

В обох випадках важливо менше вашого місця в ієрархії та іншого:

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

• Наскільки міцна ваша команда і що їх мотивує. Уявіть собі компанію, де кожен розробник платить за KLOC / місяць. Чи хотіли б ви сказати про стиль стилю своїм колегам? Напевно, ні, тому що рідко зустрічаються особи, які хочуть платити менше. Загалом, якщо це не команда, а лише група людей, що працюють над одним проектом, ви нічого не зможете покращити.

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

У всіх випадках важливо не тиснути на вашу команду. Працюйте з ними, а не проти них. Не дайте їм наказів, а направляйте їх до мети.

Тепер, підказки.

Стиль

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

Звичайно, це не так, оскільки це не так, як слід робити.

• Стиль нудний .

• Наступний стиль нудний .

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

• Документ про стиль читання нудний .

• Перегляд коду на помилки стилю є нудним .

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

Тому:

• Не робіть оглядів стилів. Це робота перевіряльників стилів. Ці милі програми мають кілька переваг перед вашим мозком: вони перевіряють весь проект за лічені мілісекунди, а не години чи дні, і вони не роблять помилок і не пропускають помилок стилю.

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

• Не змушуйте розробників виправляти 2 000 помилок стилю.

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

• Зробіть це з початку проекту. Встановити контроль стилів у існуючому проекті важко неможливо.

Більш детальну інформацію про те, що прочитав першу частину цього іншої відповіді на SE.SE .

Також:

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

Код оглядів

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

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

• Робіть огляди коду приватно, особливо коли розробник є молодшим і пише справді поганий код.

• Покажіть, що немає нічого особистого: ви переглядаєте код, а не вміння людини.

• Покажіть фактичну мету огляду коду. Мета - не показати, наскільки поганий розробник. Мета - надання можливостей для вдосконалення.

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

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

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

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

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

Навчання

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

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

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

Зосередьтеся на контексті, а не на особах

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

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

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

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

Налаштуйте свої показники правильно

Як саме ви вимірюєте код прямо зараз? Чи вимірюєте ви кількість комісій в день на одного розробника? Або KLOC на місяць на програміста? А може, покриття коду? Або кількість знайдених та виправлених помилок? Або кількість потенційних помилок, виявлених регресійними тестами? Або кількість ревертів, виконаних сервером безперервного розгортання?

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

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

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

Наприклад, розглянемо, що члени команди роблять занадто багато орфографічних помилок у назвах класів, членів класу та змінних. Це дратує. Як ти міг це виміряти? За допомогою аналізатора ви можете витягнути всі слова з коду, а за допомогою перевірки орфографії визначити співвідношення слів, що містять помилки та помилки, скажімо, 16,7%.

Наступним вашим кроком є ​​узгодження з вашою командою щодо цільового співвідношення. Це може становити 15% для наступного спринту, 10% для наступного, 5% за шість тижнів і 0% за два місяці. Ці показники перераховуються автоматично під час кожного здійснення і відображаються на великому екрані в офісі.

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

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

Висновок

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

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

  Вам довелося накладати стиль автоматично на фіксацію.

• і часто не використовують сучасні мовні функції, такі як аксесуари властивостей (це відносно нове в Objective-C).

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

• Іноді вони могли б вигадувати власні велосипеди замість того, щоб використовувати подібні функції рамок

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

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

  Це відмінна річ. Вам здається можливістю вчитися у них.

• Часто вони не можуть правильно назвати методи або змінні через погану англійську мову

  Огляди коду повинні також зосереджуватися на правильному іменуванні. У деяких ІДЕ є також перевірки орфографії.

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

  Звичайно, вони б. Стиль нудний і його слід автоматизувати.

• В основному я ненавиджу код, який вони пишуть.

  Запам’ятайте з частини відгуків про код: “Мета - не показати, наскільки поганий розробник. Мета - забезпечити можливості для вдосконалення ».

• Він погано відформатований / організований, а іноді кардинально відрізняється від решти проекту.

  Автоматизована перевірка стилю .

• Я дуже засмучений, коли вони додають спагетті до мого витвору мистецтва

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

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

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

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

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

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

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

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

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

Описані вами симптоми наголошують на недостатній згуртованості команди .

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

Симптоми:

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

Ви невелика команда: використовуйте цю перевагу! Деякі ідеї для початку:

• Приймайте важливі рішення колективно. Обговорюйте відкрито незгоду. "Обговорити" - це не нав’язувати одну точку зору, а слухати та намагатися знайти спільну мову.
• Ви відремонтували важливі частини коду, тому у вас є справді сильне право власності. Нехай вони купують. Нехай вони мають слово сказати.
• А для дуже чутливих, але дуже суб'єктивних тем, таких як форматування коду, просто передайте обов'язок автоматизованому симпатичному принтеру, який буде переформатуватися відповідно до стандарту та не відчувати себе при кожному заїзді.

Цитата дня:

Якщо ви хочете їхати швидко, йдіть наодинці. Якщо ви хочете зайти далеко, йдіть разом

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

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

Що вам потрібно зробити, це змінити людей. Думаючи, що вони зламані, і їх потрібно виправити, не вийде. Люди - емоційні істоти. Це може легко перерости в особисті війни. Так...

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

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

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

Тоді є управління. Чи керівництво не знає про ситуацію чи просто не хвилює? З'ясуйте. Вам абсолютно потрібно мати підтримку управління, якщо ви хочете вдосконалити речі. Якщо щось, на що знадобилося 3 місяці, раптом починає займати 4 місяці, тому що вам зараз потрібно писати тести, робити огляди коду, обговорювати на дошці з командою, щоб визначитися з хорошими рішеннями, паровою програмою тощо, ви можете бути впевнений, що керівництво помітить різницю в часі. Щось, що змінюється від 3 до 4 місяців, легко спостерігати і вимірювати. Маючи солідну кодову базу, ремонтопридатний продукт, гарну стабільну архітектуру, речі, які сприяють кращій структурі продукту, виміряти не так просто. Скільки часу найкращі практики купують вас у довгостроковій перспективі, неможливо оцінити заздалегідь, можливо, навіть після факту. З іншої сторони, затримка на місяць - це не мозок. Тож майте підтримку управління з цього приводу. Підготуйтеся зробити нелегкий розпродаж.

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

Давайте на хвилину змінимо перспективу.

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

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

Раніше я працював з хлопцем, який із задоволенням кине команду, проект та компанію під автобус, аби нав’язати всім своє «мистецтво». Він був "власником істини", і, за визначенням, кожен був просто недосвідченим, сліпим, не бажаючим вчитися, не хвилювався, або просто дурним. Не став тим хлопцем. Як розробник програмного забезпечення ваше завдання полягає в тому, щоб написати хороший код, перевірений код, підтримуваний код, код, який додає ділової цінності і може продовжувати це робити в постійних майбутніх змінах. І ви повинні все це робити за бюджетних та часових обмежень. Ось що означає бути професійним розробником програмного забезпечення. Якщо ви не художня галерея, мистецтво погано для бізнесу. Будьте прагматичними і дотримуйтесь збалансованого погляду на речі. " Як ігнорувати поганий код, який пишуть мої колеги, і просто зосередитися на роботі"Ваше питання було закрито через те, як ви вирішили проблему. Відступіть і подивіться на всю справу.

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

TL; DR: Уважно подивіться на ситуацію, щоб з’ясувати, чому все закінчилося в цій ситуації. Прийміть, що ситуація така, і подивіться, як ви можете покращитись звідти. Дізнайтеся, яка думка всіх щодо цього. Виберіть свої битви. Примусові зміни не працюють. Співпрацюйте, щоб внести зміни. Вам слід спробувати показати, як можна покращити речі, а не вказувати, наскільки вони погані. Переконайте всіх, що те, що ви хочете зробити, - для більшої користі в довгостроковій перспективі. Отримайте їх на борту.

І робіть це невеликими кроками.

Якщо ви привнесете занадто багато змін, відразу люди почуватимуться розгубленими і здадуть. Зміни потребують часу. Змініть свою компанію або змініть свою компанію. Удачі!