tl;dr:

не, не става.

дълга форма:

За мен

Работя върху монолитно репо с › 700 000 реда код плюс над дузина различни услуги с тегло между 10 000 и 100 000 реда код. Програмирах професионално от 15 години на редица езици (C++, PHP, Javascript, Actionscript, Perl, Python, Ruby) и съм работил както в малък бутиков магазин, където бях буквално единственият разработчик, така и за голяма мултинационална компания корпорация, в която бях един от стотиците разработчици.

Виждам горния цитат, под една или друга форма, повтарян многократно от хора ден след ден след ден.

Това изобщо не е моето преживяно преживяване.

Какво прави кода четим?

Кодът обикновено е най-четлив, когато са изпълнени следните условия:

  1. имената на променливите са точни и смислени.
  2. имената на методите са точни и смислени.
  3. Имената на клас/модул/именно пространство/обект са точни и смислени.
  4. свързани части от код са близо един до друг.
  5. няма твърде много свързани разнородни части от код във всяка дадена „група“ код.

Мисля, че 1–3 е доста ясно: наименуването е основна основа на доброто програмиране и се съмнявам, че някой няма да се съгласи. Там, където мненията се различават и където виждам най-големия проблем, е, че хората или не смятат елемент #4 за полезен, или не вземат предвид елемент #4, когато работят върху елемент #5.

Какво всъщност се случва, когато имате много специализирани класове?

Преди всичко имате проблем с откриването. По-конкретно, става трудно да се свърже наблюдаваното поведение с кода, който води до това поведение.

Твърде много класове или твърде много файлове или твърде много малки едноцелеви методи, независимо от това колко добре са наименувани, ще доведат до това, че разработчикът прекарва прекалено много време в „проследяване“ на страничен ефект или поведение.

Помислете за това по следния начин: когато разработчикът работи за коригиране на грешка, той знае както какво се случва, така и какво трябва да се случи вместо това. Най-лесният начин да определите къде възниква грешката е да знаете какъв код причинява ефекта и да можете да го свържете обратно с очаквания ефект. Ако обаче има твърде много сегментирани части от код, вероятността както ефектът да се появи като част от поведението на множество места се увеличава, така и вероятността пътят от повърхността (т.е. API слой, контролен слой и т.н. ) е много нива премахнати от ефекта. И двете правят това трудно за работа.

На второ място, имате проблем с увереността. По-конкретно, става трудно да се установи дали дадена промяна в даден файл ще има непредвидени странични ефекти на друго място, защото има твърде много различни елементи на кода за ръчен преглед.

Когато разработчикът работи за внедряване на нова функция, той обикновено получава базово местоположение или място — добавете тази крайна точка, добавете този потребителски интерфейс, добавете този бутон за изтегляне, извършете това изчисление тук, пишете на регистратора там. С твърде много файлове/класове/модули за създаване става по-трудно да се организира връзката между бизнес очакванията и изразения код (въпреки че с твърде малко файлове имаме друг уникален проблем).

Кодът съществува, за да се изпълнява върху реални процеси в реалния свят и ако вашият спретнато сегментиран код не предоставя никакви улики за това защо е там — какви реални процеси решава тази част от кода — тогава крайният резултат над времето ще бъде разминаване и дублиране, тъй като различни разработчици прилагат малко по-различни решения около вече съществуващия код, защото или не са могли да намерят, или не са били уверени в докосването на вашия код.

По-добра евристика за кодова архитектура

Често, когато хората питат „този код добре ли е архитектурен“, те разглеждат нещата, които могат надеждно да бъдат обективно установени: неща като условна сложност, обхват, размер на класовете, брой методи и т.н. Това са неща, които трябва да ви интересуват, но за наше щастие имаме линтъри, които ни казват, когато не успяваме да изпълним нашите стандарти.

Вместо да изграждате своята архитектура под формата на „ето добре разделения общ агностичен интерфейс за многократна употреба“, опитайте вместо това да зададете и след това да разрешите тези въпроси:

  • Каква бизнес цел решава този код? Мога ли да поставя този код на място (файл, клас или пространство от имена), което ми помага да разбера бизнес целта? (дръжте споделения код наблизо)
  • Ако този код решава много основни проблеми, как мога да го използвам, така че да имам голяма увереност, че промените в него няма да причинят отрицателни нежелани странични ефекти? (направете връзките между вашия код очевидни)
  • Колко стъпки са необходими, за да стигнете от външна крайна точка до този код? (Избягвайте ненужната дълбочина)
  • Колко стъпки са необходими, за да стигнете от този код до всеки възможен път за повикване? (Избягвайте ненужната широта)