Як ви ставитесь до розуміння абстракції в коді?

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

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

Чи є краща стратегія вирішення цієї ситуації?

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

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

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

Перше, що потрібно вимагати, коли ви намагаєтесь відпустити ці деталі - це хороші імена. Гарне ім’я гарантує, що ви не здивуєтесь, коли заглянете всередину. Ось чому ви не були здивовані тим, що printщось помістили на ваш екран, і не дуже цікаво, як. foo "Hello world"була б інша історія.

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

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

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

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

Мабуть, я не один, коли справа доходить до цього:

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

Майкл Пір'я - помаранчевий код

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

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

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

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

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

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

Отже, що ти можеш зробити?

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

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

Це я не кажу, продовжуйте і пишіть лайний код, який не працює або нічого не поважає, але те, що я кажу:

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

2) Світ наповнений безліччю дуже розумних людей, які не дуже розумні. Вони також часто бувають дуже емоційними, і вони схильні до посилення упередженості з боку зовнішніх сил. Вони дуже хороші в тому, що роблять, але те, що вони, як учасники поширення інформації, забувають: ідеї / інформація, навіть якщо підкріплені "логікою", мають контекст того, хто їх надсилає, що є вирішальним для розуміння того, чи це інформація корисна і для вас. Що для вас має сенс, ви можете мати сенс для інших, і вони їм сподобаються, але інформацію не слід сприймати як абсолютну, і, знову ж таки, слід розглядати або хоча б намагатися з'ясувати контекст, звідки вона прийшла, і перевірити її власний контекст, щоб побачити, чи він відповідає. Це дійсно те саме, що мільярдери дають нам ці "шматочки знань, щоб випереджати"

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

Час успіху стартапів.

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

Ось редакція через 6 місяців:

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

Не розумійте мене неправильно: якщо ви пишете свій код щільно поєднаний, ви будете сильно боліти, чи ненавидите ви SOLID чи ні, навіть розуміння та застосування його на базовому рівні дозволяє велику розв'язку, що, чесно кажучи, є єдине, в чому дійсно допомагає ООП. OOP також повинен був говорити про повторне використання коду, і це відбувається тут і там, вам не вдасться повторно використовувати багато створених вами об’єктів, тому зосередьтеся на тому, щоб ваша система була добре розділена. Як тільки ви досягнете зрілості і припустимо, що дядько Боб приходить і бере на себе керівництво вашим проектом, він скаже: «Добре, це глухо як пекло, але принаймні все розділено, добре названо і задокументовано, так що принаймні я знаю, про що це " (Я сподіваюсь). Для мене це працює. Мій LOC постійно змінюється, але на момент написання це 110k рядків коду, 110k рядків виконання коду, який працює в гармонії для однієї людини - це багато.

Ось редакція, через 3 місяці, на 8-місячний код, який я переробляю:

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