Бути дурним для підвищення продуктивності?

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

if(xxx) {
    doSomething();
}

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

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

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

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

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

Чи може цей підхід призвести до позитивного чистого прибутку для програмного проекту, чи це марна трата часу?

хороший код, який може робити лише A, є гіршим, ніж поганий код, який можуть робити A, B, C, D.

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

Тому:

Хороший код, який може робити лише A (але це робиться лише одне і просто) - КРАЩЕ, ніж поганий код, який може робити A, B, C, D (деякі з яких можуть знадобитися колись у майбутньому).

Час анекдоту:

У мене були два розробники, які таким чином схилялися до надмірної інженерії.

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

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

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

Тож не варто.

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

Принципи SOLID та KISS / YAGNI є майже полярними протилежностями. Один вам скаже, що якщо doSomething () не може бути виправданим як невід'ємною частиною завдання клас, який викликає його, він повинен бути в іншому класі, який слабко з'єднаний та введений. Інший скаже вам, що якщо це єдине місце doSomething використовується, навіть вилучення його в метод може бути надмірним.

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

Мені подобається дотримуватися цієї простої триетапної методології.

• На першому проході змусьте його працювати.
• На другому проході зробіть його чистим.
• На третьому проході зробіть це ТВЕРДО.

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

Приклад: Вам потрібно написати простий рядок тексту на консоль. Перший раз, коли це трапляється, Console.WriteLine () просто чудово. Потім ви повертаєтесь до цього коду після того, як нові вимоги також диктують написання того ж рядка до журналу виводу. У цьому простому прикладі може не бути багато повторюваного копіювального кодування (або, можливо, є), але ви все одно можете зробити базове очищення, можливо, витягнути метод або два, щоб уникнути вбудовування операцій вводу-виводу в більш глибоку бізнес-логіку . Потім ви повертаєтесь, коли клієнт хоче той самий текст виводити на названу трубку для сервера моніторингу. Тепер ця вихідна процедура є великою справою; ви транслюєте той самий текст трьома способами. Це приклад підручника алгоритму, який би виграв від складеного шаблону; розробити простий інтерфейс IWriter методом Write (), реалізуйте цей інтерфейс для створення класів ConsoleWriter, FileWriter і NamedPipeWriter та ще один раз, щоб створити складений клас "MultiWriter", а потім розкрийте залежність IWriter від вашого класу, встановіть композицію MultiWriter з трьома фактичними записами та підключіть її. Зараз це досить ТВЕРДО; з цього моменту, щоразу, коли вимоги диктують, що вихід повинен перейти будь-де новий, ви просто створите новий IWriter і підключите його до MultiWriter, не потрібно торкатися жодного існуючого робочого коду.

хороший код, який може робити лише A, є гіршим, ніж поганий код, який можуть робити A, B, C, D.

1) Мати код, який робить лише те, що належить робити.

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

2) Якщо ви плануєте свій код робити A, B, C і D, клієнт, нарешті, запитає вас у E.

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

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

Також Code Complete - це чудовий ресурс, повний корисної інформації, який повинен читати кожен розробник (не тільки програміст).

дуже часу мені потрібно написати простий фрагмент коду, я думаю про майбутнє

Можливо, тут проблема.

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

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

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

Пам’ятайте: більша база коду означає більше обслуговування. Не пишіть більше коду, коли зможете його уникнути.

Ваш підхід також шкідливий для інших сторін:

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

• Під час налагодження чи не простіше мати невеликий слід стека, чи ви вважаєте за краще прочитати десятки рядків, щоб зрозуміти, що викликається чим?

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

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

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

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

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

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

Усвідомлення того, що може статися (майбутнє), НІКОЛИ не погано. Думка про те, що може бути кращим способом зробити щось, є частиною того, що робить тебе гарним у своїй роботі. Важча частина - визначення того, чи виправдано співвідношення витраченого часу: Ми всі бачили ситуації, коли люди роблять "легко, якщо", щоб зупинити негайну кровотечу (та / або кричати), і, коли ті складаються, ви отримуєте заплутаний код. Багато хто з нас також пережили надмірне абстрагування, яке є таємницею, коли оригінальний кодер рухається далі, що також створює заплутаний код.

Я хотів би переглянути вашу ситуацію і задати наступні питання:

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

2. Чи розглядаю я код рефакторингу, який ми замінимо через 6 місяців?

3. Чи готовий я взяти стільки часу, щоб документувати дизайн та мої міркування для майбутніх розробників, скільки я витрачу на рефакторинг?

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

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

У другому виданні Stroustrups "Мова програмування на C ++" (я не маю доступної сторінки) я читаю

Не додайте код самостійно на місце.

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

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

Але тоді ви повинні задати питання ЯГНІ: чи варто це? Чи справді це стане в нагоді? Бути досвідченим означає, що ви будете рідко помилятися, а як початківець частіше помиляєтесь.

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

Рішення не те чи те, а думати над цим. :)

"хороший код, який може робити тільки A, є гіршим, ніж поганий код, який можуть робити A, B, C і D."

Це може мати певний сенс у розробці продукту; Але більшість ІТ-фахівців працюють у «проектах», а не в розробці продуктів.

У програмах «ІТ», якщо ви запрограмуєте хороший компонент-мережу, він буде функціонувати безперебійно протягом життя проекту - який може тривати більше 5 або 10 років, тоді бізнес-сценарій може застаріти і новий проект / ERP продукт, можливо, замінив його. Протягом цього 5/10 року життя, якщо тільки у вашому коді не будуть дефекти, ніхто не помітить, що це існування і заслуги ваших найкращих думок не залишиться непоміченими! (якщо тільки ви не гарно ставите на власну трубу голосно!)

Не багато хто отримує можливість запрограмувати "Windows Ctl + Alt + Del", і ті, хто отримує такий шанс, можуть не реалізувати потенціал свого коду!

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

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

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

Побачивши такі передчасно узагальнені конструкції, які зовсім не відповідали фактичним вимогам, які з’явились пізніше, я створив для мене правило:

Для гіпотетичних вимог пишіть лише гіпотетичний код.

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

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

Багато програмістів виявили, що абстракції виникають майже самостійно, коли вони ПІДБИЛИ свій код. Шаблони дизайну та найкращі практики допомагають вам знайти можливості робити саме це, але самі по собі не є цілями, яких варто переслідувати.

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

Я вважаю, що програміст завжди в кращому становищі вирішує, як абстрагуватися, ніж аксіома.

Про інше вже розповів KeithS

Запитайте себе, які переваги хорошого дизайну:

• Легше зрозуміти
• Легше підтримує
• Портативний
• Залишається корисним протягом тривалого часу
• Легко додавати нові функції

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

Якщо ви можете додати нові функції, додавши 3 рядки коду, як це:

if (condition()) {
  doSomething()
}

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

Моє правило полягає в тому, що нові функції повинні бути реалізовані максимально мінімалістично, лише тоді, коли щось настільки велике, щоб зрозуміти наперед (скажімо, на реалізацію потрібно більше 1 дня або півдня), ви можете додати грубо глобальний дизайн. З цього моменту додайте шари абстракції лише тоді, коли розмір коду зросте. Ви потім рефактор після цього! Через деякий час це навіть стане вам природним, коли вам потрібно розробити деталь трохи більше, або піти швидкою дорогою. Ще одна вказівка, яку код може використовувати деяку очистку, - це коли ви повторно використовуєте його. Кожен раз, коли ви додаєте нову функцію або дзвоните старий код у новому місці, це найкращий час, щоб переглянути старий код і побачити, чи зможете ви його трохи покращити, перш ніж додати його знову. Таким чином, гарячий код повільно стане більш чистим, тоді як нецікаві частини повільно загнивають і не забирають жодного з ваших цінних витрат часу.

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