Як я переконаю свою команду використовувати менші класи / методи?

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

Переглядаючи наш код, я бачу деякі запахи коду та погану інженерну практику, наприклад:

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

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

Моя команда отримала наставника від основної команди (ми - супутникова команда). Потрібно першим піти до нього?

ОНОВЛЕННЯ : Оскільки деякі відповіді на запитання про проект, будь ласка, знайте, що це працюючий проект. І ІМХО, величезні класи / методи такого розміру завжди погані.

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

ОНОВЛЕННЯ : Я вирішив зробити щось на основі прийнятої відповіді: тому що я новачок, тому все бачу «свіжими очима». Я візьму на замітку всі знайдені запахи коду (позиція, чому це погано, як ми можемо це зробити краще, ...), але на даний момент я просто намагаюся привертати повагу до своєї команди: пишу "кращий код", знаю людей, знаю, чому ми це зробили ... Коли настане час, я спробую запитати мою команду про якісь нові кодові політики (назви назви, менші класи, менші методи, ...), і, якщо можливо, перефактуруйте якийсь старий код. Це має працювати, ІМХО.

Дякую.

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

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

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

Відмова: Я новий учасник (це мій третій день роботи), і більшість моєї команди є більш досвідченими, ніж я.

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

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

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

Як це йде? "Міра двічі скоротити один раз." Щось подібне.

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

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

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

Удачі.

Не варто переконувати свою команду. Як новачків вас не сприйматимуть серйозно - значить, витрачайте час.

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

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

І так, будь-ласка, всі матеріали показуйте з Code Complete.

Ось кілька хитрощів:

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

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

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

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

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

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

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

Як я переконаю свою команду використовувати менші класи / методи?

Не варто.

Придбайте собі ліцензію Resharper та наведіть приклад. [Сильно сперся на метод вилучення рефакторинг " ".]

З часом інші повинні оцінити ваш більш читабельний код і переконати його так само. *

• Так - є ймовірність, що їх не переконають; але це все-таки найкраща ставка.

IMO - Не варто ваші склади намагатися переконати своїх товаришів по команді стати кращими програмістами, читайте « Кодекс завершено ", дотримуйтесь @Uncle Bob. SOLID принципи, і станьте кращими програмістами, якщо їх вже не переконали.

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

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

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

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

Visual Studio має "Аналіз коду", який може допомогти при призначенні імен.

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

Ведення записів - також хороша ідея. Якщо члени команди просто словесно висловлюють те, що потрібно зробити, люди обов'язково забудуть. У людей дуже кволі спогади! =)

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

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

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

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

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

Тепер новий код, це інакше. Це має бути хорошим кодом.

Методи, що складають 150 рядків ... Я бачив методи з 10 000 рядків коду.

Дві ваші проблеми можна вирішити за допомогою зовнішніх інструментів :

• Дещо непослідовні вказівки щодо іменування
• Властивості не позначаються як тільки прочитані, коли це можливо

В C # Resharper можна перевірити обидва питання. Імена, які не відповідають вашим рекомендаціям, позначаються як помилки. Властивості, не позначені як прочитані, відображаються також як помилки. FxCop може також допомогти.

Ці інструменти також можуть допомогти розділити величезні методи на кілька менших, завдяки рефакторингу.

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

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

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

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

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