Як пояснити, чому вибір дизайну хороший? [зачинено]

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

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

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

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

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

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

Продажі не відбуваються автоматично - вам потрібно докласти злагоджених зусиль, щоб зрозуміти точку зору іншої людини , а потім розібратися, як відобразити свої ідеї у їхньому Happy Place ™. Коли вони знають, як вони особисто отримають користь від цієї нової речі, вони часто запитують: "Скільки це буде коштувати і як швидко ми можемо це зробити?" Як тільки ви почуєте ці магічні слова, ви знаєте, що ви добре виконали свою роботу з продажу.

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

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

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

Ну, я ніколи не знайшов відповіді, але кілька днів тому я переглядав Lean Development Software: Agile Toolkit, Я натрапив на щось цікаве, що може підказати, що відповідь насправді не існує. У розділі книги було розказано про лідерів інших галузей, особливо у відділах реагування на надзвичайні ситуації, та про те, як ці керівники приймали рішення. Коли у вас вогонь чи хтось стріляє на вас, ці керівники ніколи не сідають і не сперечаються за / проти своїх товаришів по команді. Натомість вони використовують інтуїцію, яка була розроблена завдяки навчанню та досвіду, щоб допомогти їм приймати рішення. Це ж стосується і нашої професії: як ви можете прийняти цілком логічне рішення, зіткнувшись з цілою точкою невідомих та мінливих варіантів, які так часто зустрічаються в розробці програмного забезпечення? Автори стверджують, що замість того, щоб намагатися виправдати кожне рішення, розробникам слід заохочувати навчати та вдосконалювати свої інстинкти, щоб, зрештою, вони просто «знали», що робити.

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

1. Ви можете спробувати підняти ранг (я закінчився, коли я йшов до свого начальника і просив про звання, тому що мені так набридли ці тупикові аргументи)
2. Ви можете спробувати лобіювати більшість команди, яка вас підтримує.
3. Якщо проект може дозволити собі (тобто не надто велику втрату продуктивності), що, на вашу думку, є поганим рішенням, нехай інша людина виграє аргумент. Відбудеться одна з двох речей:
   • У деяких випадках (сподіваємось, дуже мала частина) ваша інтуїція буде помилятися, і ви в кінцевому підсумку чогось навчитеся. Добре вам.
   • У більшості випадків (знову ... сподіваємось), ви ТА людина, яка виступала за "поганий" дизайн, зрозумієте саме, чому це погано; адже задні огляди завжди 20/20. Сподіваємось, це буде урок для цієї людини, який, можливо, ви знаєте, про що говорите, і наступного разу вони подумають двічі, аргументуючи свою справу.

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

Якщо це щось на зразок складу над спадщиною, ви, мабуть, просто повинні сказати, що наразі, можливо, 90% розробників вважають це найкращою практикою (дикий здогад, заснований частково на тому, що 100% розробників майже нічого не погоджуються), і ви погодьтесь і радий би розібратися в чому.

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

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

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

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

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

Я знаходжу хороший спосіб пояснити людям через надання конкретних прикладів минулих помилок, допущених у проектах, в яких вони активно брали участь (наприклад, "Ви коли-небудь намагалися налагодити цю річ? Це було роками так, і ніхто не знає, як це зробити" Полагодь це.."). Ще краще, застосувавши ці «нові» дизайнерські ідеї та принципи до малого / пробного проекту та зможете показати, наскільки це було успішно в кінці.

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

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

Залежить від аудиторії! Як розробники ми розробили інтуїцію хорошого та поганого коду та використовували розпливчасті емоційні терміни, такі як «запах коду», «некрасивий код», «прекрасне рішення». Це працює лише під час спілкування з іншими розробниками з тим же способом мислення. Спробуйте пояснити своєму нетехнічному керівнику, що вам слід вкласти x man-годин у те, щоб зробити якийсь код "красивішим", ви, швидше за все, виграєте ефектно.

Вам потрібно вміти зробити так, що будь-яке вдосконалення дизайну буде або

• заощадити гроші для компанії
• заробляти гроші для компанії

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