В кінці моєї мотузки [закрито]

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

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

• Вони не розуміють найкращих практик технології, яку ми використовуємо. Через 6 місяців мене та інших, хто наводить їх приклади, застосовуються жахливі анти-шаблони.
• Вони - "копіювати та вставляти" програмістів, які виробляють насамперед код спагетті.
• Вони постійно ламають речі, впроваджуючи зміни, але не роблять базового тесту на дим, щоб побачити, чи все добре
• Вони відмовляються / рідко просять кодові огляди.
• Вони відмовляються / рідко навіть роблять основні речі, такі як код форматування.
• Немає документації щодо будь-яких класів (jsdocs)
• Бояться видалити код, який нічого не робить
• Залишайте коментовані кодові блоки всюди, навіть якщо ми маємо контроль над версіями.

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

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

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

Чи є тонкий / не настільки тонкий спосіб пояснити, скільки речей я фіксую?

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

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

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

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

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

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

По-перше, я хочу сказати, що деякий час тому я натрапив на блог, який належить одному з наших власних членів SE програмістів, Мартіну Блору та IMO, цей конкретний пост про самоактуалізацію TDD дуже точний. TDD - це останній, найвищий рівень, який пов'язує все разом, але без попередніх рівнів, особливо найбільшого, принципів і практик створення чіткого і читабельного коду, буде дуже важко, якщо не неможливо, щоб TDD працював.

У моїй компанії і Agile, і TDD нам нав'язували менеджмент, і спочатку ми просто їх робили, тому що нам сказали (що протилежне спритному). Ми двічі пробували TDD, і, хоча я величезний прихильник використання автоматизованих тестів, я особисто викинув усі ті, які команда плескала разом в останньому випуску. Вони були тендітними, гігантськими, копіювали / приклеювали вазу і пронизували твердженнями про сон, які змушували їх працювати по-справжньому повільно і непередбачувано. Моя порада для вашої команди: НЕ робіть TDD ... поки.

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

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

Тож припускаючи, що ви маєте повагу та увагу своєї команди. А тепер що?

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

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

1. Отримавши підтримку управління. Ви можете почати впроваджувати безліч практик / процесів, які диктуються централізовано, які запропонувала MainMa у відповідь на моє запитання . Ми зробили їх багато (крім парного програмування), і ви точно бачите переваги. Огляди коду особливо допомагали стандартизувати стилізацію, документацію, а також дозволяли нам ділитися знаннями та технікою між командою. Незважаючи на те, що огляди коду були продиктовані, команда насправді їм подобається, і ми переглядаємо кожен функціонал, який зареєстрований. Однак ...
2. Ви помічаєте, що звичайно написаний код все ще занадто пов'язаний, дизайн поганий або зовсім не вистачає. Огляди коду вловлюють деякі з них, але є лише стільки, що ви можете переписати. Чому дизайн поганий в першу чергу? - Дуже багато розробників ніколи не були знайомі з передовою практикою і ніколи офіційно не навчалися OOD. Дуже багато людей "просто кодували" будь-яке завдання, яке їм було надано.
3. За підтримки керівництва ви можете ввести більше процесів, таких як обговорення дизайну до того, як відбудеться будь-яке кодування. Але ви лише одна людина, і здається, що як тільки ви не звернете уваги, команда повертається до того, що вони завжди робили. Чому?
4. Чи можна вводити та навчати кращих практик чи звичок, щоб вам не довелося постійно контролювати? - Виявляється ця частина не така проста.
5. Чому інші члени команди неохоче вивчають та підбирають нові практики та чому вони настільки стійкі до твердого або сухого, коли про це так багато написано в сучасній методичній літературі? При всіх позитивних змінах , які ми мали в моїй команді, 2 тижні тому у мене був аргумент , якщо б я перероблені 2 функції , які мали однакові 15 рядків коди і рецензент назвав його героїчним, непотрібні зусилля , тому що немає нічого поганого в копіюванні / вставка тільки 15 рядків. Я категорично не згоден з такими поглядами, але поки що ми домовились про згоду. - То тепер що? Зараз ми дійшли до теми мого іншого допису .
6. Як вказали maple_shaft та nikie у своїх відповідях (вибачте, MainMa , ви отримали найбільше голосів, але ви настільки на 5 кроків позаду :)), ви досягли етапу, коли "процес" вже не може допомогти вам і нікому на цьому форумі може сказати вам, що таке "виправлення". Наступним кроком є ​​підхід до людей, може бути один на один, може бути як команда, можливо, обидва в той чи інший час і поговорити з ними. Запитайте їх, що працює, а що ні. Єдиний спосіб визначити першопричину того, що їх спонукає, - зараз поговорити з ними окремо і знайти це. У рамках цього кроку я нещодавно зіткнувся з зовсім іншою проблемою команди, але думаю, що відповідь Джоела тут, яка є дуже детальною та проникливою, стосуватиметься і цієї справи. Підсумовуючи це, використовуючи управління як "короткий повідок" - це можливий підхід до майже будь-чого, нам потрібно пам’ятати, що ми маємо справу з людьми, щоб справді зрозуміти мотивацію, ми повинні перейти більше на психоаналіз, ніж на чисте управління чи технічне керівництво.
7. Отже, тепер ви розмовляєте зі своїми товаришами по команді? Що ви їх запитуєте? Я не впевнений у цій наступній частині, бо ніколи тут не бував. Ось можливий сценарій: Питання: як не можна твердого? A: Мені це не потрібно. З: Це може допомогти. A: Я все в порядку, як є. - якимось чином потрібно генерувати серію звуків, які б залишали ваш рот і змушували слухача усвідомити, що речі можуть бути кращими, якщо вони дадуть шанс на те, що ви розбираєтеся. Якщо ви не зможете тут, вони ніколи не будуть переконані, що будь-який "процес" змушує їх робити насправді має якесь значення. З іншого боку, якщо ви пройдете цю точку, ви, ймовірно, виявите, що вам навіть більше не потрібен "процес".
8. ІМО в самому корені, ваші товариші по команді не навчаться, якщо вони не бачать нічого поганого у своїх нинішніх звичках / практиках. Тому, можливо, наступним кроком у всьому цьому є пошук способу проілюструвати, виділити проблеми та зробити їх очевидними. Зрештою, ми не пишемо читабельний код, використовуючи принципи SOLID / DRY або підтримуючи документацію лише тому, що це дає нам тепле та нечітке відчуття. Ми робимо це, тому що він дає кращу якість коду і, чесно кажучи, робить нас швидшими. Чи можна це виміряти? Можливо, саме тут надходять метрики програмного забезпечення?
9. Ось божевільна ідея, і я не маю уявлення, чи справді це буде спрацьовувати (це може бути звичайна галузева практика, або може бути абсолютно недійсною. Я щойно вигадав це за останні 24 години), але дуже спокушаюсь її донести до столу, як тільки починається наступний рік:
   • Проти думок багатьох інших , введіть ідею автора / власника для всіх вихідних файлів. Як стверджує Прагматичний програміст, це створить відчуття власності та відповідальності для однієї людини, яка відповідатиме за фрагмент вихідного коду. Це не означає, що інші люди не можуть змінювати код, ми всі працюємо як команда, але в кінці дня людина, яка володіє кодом, несе відповідальність за перегляд змін.
   • Створіть тригер джерела сховища, який слідкує за всіма реєстраціями та спеціально шукає ті, що є виправленнями помилок. Зробіть це таким чином, щоб кожен виправлення помилок мав опорний ідентифікатор прямо вперед в описі реєстрації. Тепер напишіть сценарій, який би розібрав список файлів, які були змінені, і викресліть "Автор" з блоку коментарів у заголовку файлу. Створіть базу даних SQL, яка б відстежувала кількість дефектів, зареєстрованих у файлі / проекті / на автора.
   • Коли у вас буде достатньо статистичних даних, сподіваємось, ви помітите, що ваш код має менше дефектів / змін, ніж деякі інші. Це важкі дані, якими ви можете скористатися. Якщо в одному проекті значно перевищує середній показник дефектів, підберіть його як кандидата для наступних робіт з очищення / реконструкції, щоб погасити частину технічної заборгованості.
   • Якщо проект чи файл має значно вище середнього показника дефектів і у нього є один власник, поговоріть один на один із цією людиною. Запитайте їх, дуже ввічливо, безконфліктно, що вони можуть зробити для вирішення цього питання. Оскільки вони є власником, вони повинні рухати зміни, але пропонувати будь-яку допомогу з вашого боку. Будемо сподіватися, що власник простежить багато причин до власного коду спагетті, і як тільки вони попросять про допомогу, саме тоді ви вступаєте в дію і відкладаєте трохи СОЛІДА.

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

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

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