Які популярні «найкращі практики» не завжди є найкращими, і чому? [зачинено]

"Кращі практики" є всюди в нашій галузі. Пошук Google на «кодуванні кращих практик» з'являється близько 1,5 мільйона результатів. Ідея, здається, приносить комфорт багатьом; просто дотримуйтесь інструкцій, і все вийде нормально.

Коли я читаю про кращу практику - наприклад, нещодавно я читав декілька в « Чистому кодексі» - я нервую. Чи означає це, що я завжди повинен використовувати цю практику? Чи додані умови? Існують ситуації , в яких може НЕ бути хорошою практикою? Як я можу точно знати, поки не дізнаюся більше про проблему?

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

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

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

Я хотів би почути про конкретні приклади та досвід.

Я думаю, що ти вдарив цвяхом по голові цим твердженням

Мені б не хотілося сприймати речі за номінал і не думати про них критично

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

Реймонд Чен найкраще вказує в цій статті, коли говорить

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

Можна також кинути це на ринг:

Premature optimization is the root of all evil.

Ні це не так.

Повна цитата:

"Ми повинні забути про невелику ефективність, скажімо, про 97% часу: передчасна оптимізація - корінь усього зла. Але ми не повинні пропускати свої можливості в цих критичних 3%".

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

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

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

Одне повернення на функцію / метод.

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

Проблема полягає в тому, що 100% підходящий розчин рідко існує. Можливо, існує 80% рішення, і використовувати його, мабуть, добре. Але як приблизно 60% підходить? 40%? Де ви проводите лінію? Якщо ви не намалюєте лінію, ви можете ввімкнути включену в проект проектну бібліотеку, оскільки ви використовуєте 10% її функцій - просто тому, що ви хочете уникнути "винаходити колесо".

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

"Тест все."

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

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

Завжди програмуйте на інтерфейси.

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

Не використовуйте нічого з відкритим кодом (або не для Microsoft для ваших розробників .NET)

Якщо Microsoft не розробила його - ми не використовуємо його тут. Хочете використовувати ORM - EF, хочете використовувати IOC - Unity, хочете увійти - блок застосунків журналу підприємств. Стільки кращих бібліотек існує - але я завжди дотримуюся замовлень із доларового меню світу розвитку. Я клянусь, щоразу, коли я чую кращі практики Microsoft, я думаю, що "рекомендації щодо харчувань McDonald's". Звичайно, ви, ймовірно, будете жити, якщо будете дотримуватися їх, але ви також будете недоїданими та зайвою вагою.

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

Орієнтація на об'єкт

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

Весь код слід коментувати.

Ні, цього не повинно бути. Деякий час у вас є очевидний код, наприклад, сетери не слід коментувати, поки вони не роблять щось особливе. Також, чому я повинен коментувати це:

/** hey you, if didn't get, it's logger. */
private static Logger logger = LoggerFactory.getLogger(MyClass.class);

Методології, особливо scrum. Я не можу тримати прямо обличчя, коли чую, як дорослі люди використовують словосполучення "Scrum Master". Мені набридло чути, як розробники протестують, що якийсь аспект методології X не працює для їхньої компанії, щоб сказати лише Гуру «Так і тому», що причина не працює в тому, що вони насправді не є справжніми практиками методології X. "Побільше важче, ти повинен, мій учень Падаван!"

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

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

Дійсно? Свині та кури, кажете? Захоплююче! Не можу зачекати, щоб передати цей мій босу ...

Реляційна карта об’єктів ... http://en.wikipedia.org/wiki/Object-relational_mapping

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

Написання імен функцій так, ніби вони були англійськими реченнями:

Draw_Foo()
Write_Foo()
Create_Foo()

і т.д. Це може виглядати чудово, але це біль, коли ви вивчаєте API. Наскільки простіше шукати в індексі "Все, що починається з Foo"?

Foo_Draw()
Foo_Write()
Foo_Create()

тощо.

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

клас на базі ОО - на мій погляд, заохочує складні структури змінного стану. єдині переконливі випадки, які я виявив для ОО на основі класу протягом багатьох років, - банальні приклади "форма-> прямокутник-> квадрат", які утворюють главу 1 будь-якої книги OO

ЯГНІ

( Вам це не потрібно )

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

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

(Звичайно, можна стверджувати, що добре розроблена база коду також дозволить додавати функції згодом, але реальність інша)

Для SQL

1. Не використовуйте тригери
2. Завжди ховайте таблиці за видами

В порядку:

1. Вони є особливістю, яка має своє місце. У вас є кілька шляхів оновлення до таблиці, або вам потрібен 100% аудит?

2. Тільки чому? Я б, якби я відмовився від підтримки контракту, але не тоді, коли я прочитав, що фолк змінить погляд, щоб відповідати будь-яким змінам таблиці

Редагувати:

Число 3: Уникання * з ІСНУЮЧИМИ. Спробуйте 1/0. Це працює. Список стовпців не оцінюється відповідно до стандарту SQL. Сторінка 191

В основному шаблони дизайну. Вони надмірно використані та недостатньо використані.

Принцип єдиної відповідальності

^{("кожен клас повинен мати лише одну відповідальність; іншими словами, кожен клас повинен мати одну, і лише одну, причину для зміни")}

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

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

Уявіть, якби у творців API .Net був такий менталітет: а не List.Sort (), List.Reverse (), List.Find () тощо, ми мали б класи ListSorter, ListReverser та ListSearcher!

Замість того, щоб більше сперечатися проти СРП (що само по собі не є страшним в теорії) , я поділюся кількома моїми довгими анекдотичними переживаннями:

В одному місці, де я працював, я написав дуже простий вирішувач максимального потоку, який складався з п’яти класів: вузол, графік, графік-творець, графік-вирішувач і клас, щоб використовувати графік-творець / розв'язувачі для вирішення реальна проблема. Жоден не був особливо складним або довгим (вирішувач був на сьогодні найдовшим на ~ 150 рядків). Однак було вирішено, що в класах було занадто багато "обов'язків", тому мої колеги взялися за рефакторинг коду. Коли вони закінчилися, мої 5 класів були розширені до 25 класів, загальна кількість кодових рядків яких була більш ніж втричі вище, ніж вони були спочатку. Потік коду вже не був очевидним, а також не було метою нових одиничних тестів; Мені зараз важко було зрозуміти, що робив мій власний код.

Там же майже кожен клас мав лише єдиний метод (його єдина «відповідальність»). Слідкувати за потоком програми було майже неможливо, і більшість одиничних тестів складалися з тестування, яке цей клас називав кодом з іншого класу , обидва цілі якого для мене були однаково загадкою. Було буквально сотні занять, де мали бути (ІМО) лише десятки. Кожен клас робив лише одну "річ" , але навіть з умовами іменування типу "AdminUserCreationAttemptorFactory" було складно сказати взаємозв'язок між класами.

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

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

У моєму проханні відновити ці 13 класи в один клас було відхилено.

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

Також заміни простих елементарних речей, таких як

0 == memberArray.length

в межах класу з викликом до власного методу класу, такого як

isEmpty()

це сумнівне "поліпшення" ІМХО. Додавання: Різниця полягає в тому, що перша перевірка виконує саме те, що вона каже: перевіряє, чи довжина масиву дорівнює 0. Гаразд, isEmpty()може також перевірити довжину масиву. Але вона також може бути реалізована так:

return null != memberArray ? 0 == memberArray.length : true;

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

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

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

"Будьте ліберальні з коментарями"

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

GoTo вважається шкідливим

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

Будь-яка «найкраща практика», яка не допускає розумних та задокументованих винятків із її правил, просто жахлива.

Жертви, які ми робимо, щоб зробити код перевіряючим

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

• Створення інтерфейсу для кожного класу. Це подвоює кількість класів (файлів) для обробки та дублює код. Так, програмування інтерфейсів добре, але саме для цього призначені державні / приватні специфікатори.
• Кожен клас, який не призначається при запуску, потребує фабрики. Ясна річ, new MyClass()набагато простіше, ніж писати фабрику, але тепер метод, який її створює, не може бути перевірений ізольовано. Якби не цей факт, я б лише 1/20-я склав кількість заводських класів, які я зараз роблю.
• Зробіть для кожного класу загальнодоступним, що перемагає мету взагалі мати специфікатори доступу для класів. Однак до непублічних класів не можна отримати доступ (і, таким чином, перевірити) з інших проектів, тому єдиним іншим варіантом є переміщення всього тестового коду до того ж проекту (і таким чином звільнення його разом із кінцевим продуктом).
• Ін'єкційна залежність Очевидно, що давати кожному другому класу, я використовую поле і конструктор-параметр - це значно більше роботи, ніж просто їх створення, коли мені це потрібно; але тоді я вже не можу перевірити цей клас ізольовано.
• Принцип єдиної відповідальності, який викликав у мене стільки головних болів, я переніс це на свою власну відповідь .

То що ми могли зробити, щоб виправити це? Нам потрібна кардинальна зміна мовної архітектури:

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

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

Розділення додатків на рівні; Шар даних, бізнес-шар, шар інтерфейсу користувача

Основна причина, що мені це не подобається, полягає в тому, що більшість місць, які дотримуються цього методу, використовують дуже крихкі рамки для його виконання. IE UI Layer кодується вручну для роботи з об'єктами бізнес-рівня, об'єкти бізнес-рівня кодуються вручну для роботи з бізнес-правилами та базою даних, база даних - SQL і вже досить крихкою та керується групою "DBA", яка не любить зміни.

Чому це погано? Найпоширеніший запит на вдосконалення, ймовірно, "мені потрібне поле на екрані X з Y." Вибух! У вас просто є нова функція, яка впливає на кожен окремий шар, і якщо ви розділяєте шари з різними програмістами, це просто стало великою проблемою, що стосується декількох людей і груп, для дуже простої зміни.

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

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

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

Мені, мабуть, за це вдаряться, але це є :)

JavaBeans

Використання JavaBeans в Java. Дивіться моє запитання Чому я не повинен використовувати незмінні POJO замість JavaBeans? на StackOverflow.

Історії користувачів / Користування справами / Особи

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

Обмеження 80 знаків / ліній німі

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

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

Звичайно, є редактори CLI, релігійно використовувані * nix динозаврами, які слідують усталеним обмеженням своїх терміналів VT220, але чому ми решта нас дотримуємось того ж стандарту?

Я кажу, прикрутіть межу 80 знаків. Якщо динозаврів достатньо епічних, щоб зламати emacs / vim цілий день, чому б не могли бути спроможні створити розширення, яке автоматично перегортає лінії або надає можливості горизонтальної прокрутки своїм IDE CLI?

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

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

Редагувати:

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

Коли монітори комп’ютерів 800х600 стали нормою для більшості користувачів, веб-розробники збільшували ширину своїх веб-сайтів, щоб пристосувати більшість ... Чому розробники не можуть зробити те саме.

Міряти, міряти, міряти

Так добре, відміряйте, але для виділення помилок продуктивності, вимірювання робіт, а також послідовного усунення. Ось метод, який я використовую.

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

Мій вчитель вимагає запустити всі свої ідентифікатори (не включаючи константи) з малих літер, наприклад myVariable.

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

Використовуйте одиночні

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

Використання неподписаного int в якості ітератора

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

Методи не повинні бути довше одного екрана

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

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

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

Ось моє правило ...

Напишіть функції / методи для досягнення чогось

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

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

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

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

Обмежте зайві абстракції і не забруднюйте автозаповнення.