Как вы справляетесь с пониманием абстракции в коде?

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

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

Есть ли лучшая стратегия для решения этой ситуации?

Должен ли я просто забыть о деталях более низкого уровня и принять их как данность? Но даже тогда, во многих случаях, требуется предварительное понимание абстракции нижнего уровня, чтобы понять, что делает текущая абстракция.

Конкретное программирование - это побуждение подтягивать детали к себе, чтобы вы могли закрепить их все в одном месте. Мы все начинаем так, и это трудно отпустить.

Абстрактное программирование определенно «забывает о деталях более низкого уровня». Иногда даже детали высокого уровня. Вы отталкиваете детали и позволяете им заниматься чем-то другим. Хитрость в том, что ты делал это все время. Вы действительно понимаете, что все происходит между, print "Hello world"и это появляется на вашем экране?

Первое, что нужно требовать, когда вы изо всех сил пытаетесь отпустить эти детали, - это добрые имена. Хорошее имя гарантирует, что вы не будете удивлены, когда посмотрите внутрь. Вот почему вы не были удивлены, что printпоместили что-то на экран, и вам было все равно, как. foo "Hello world"была бы другая история.

Кроме того, уровни абстракции должны быть согласованы. Если вы находитесь на уровне, касающемся вычисления числа пи, вам также не следует беспокоиться о том, как отображать число пи. Эта деталь просочилась в абстракцию, где она не принадлежит.

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

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

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

Видимо, я не одинок, когда дело доходит до работы таким образом:

Всякий раз, когда я работаю с незнакомым кодом, я начинаю извлекать методы. Когда я делаю это, я ищу куски кода, которые я могу назвать, а затем извлекаю. Даже если я в конечном итоге добавлю методы, которые я извлек позже, по крайней мере, у меня есть способ временно скрыть детали, чтобы я мог видеть общую структуру.

Майкл Перья - оранжевый код

Внизу, есть некоторые обновления того, как это происходило для меня каждый квартал или около того, я думаю, что они ценны.

Хорошее наименование. Или, если это чей-то код, попытка приписать хорошие имена / обязанности на основе даже плохих имен классам / функциям этой системы, так что это имеет смысл в моей голове. Как только это произойдет, реализации низкого уровня станут намного легче запомнить.

Это все, что у меня есть. На этом сайте есть много пуристов, которые, клянусь богом, знают, какие шаблоны или объекты любого типа, но хорошее именование поможет вам далеко. Я сделал более чем хорошо, создав минимально документированный / хорошо названный / хорошо отделенный код, и он никогда не возвращался, чтобы укусить меня, даже если мой код использовался во многих местах многими людьми, но Единственное, что я сделал правильно, - это потратил много времени на хорошее именование, хорошие комментарии и схемы, которые объясняли ход моего кода. Низкоуровневая реализация необходима, чтобы понять, хотите ли вы углубиться в мой код. Хорошо написанный код может быть расширен разумными способами, поэтому вполне нормально, что кто-то или вы не понимаете / не помните низкоуровневые реализации.

Если вас интересует небольшая полемика о том, что люди в моей области, а также я знаю правду, но, если вы послушаете, что здесь написано, вы научитесь соглашаться и не соглашаться с этим ответом. , читайте дальше:

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

Мои друзья работали с большими системами, и они просто смеялись над людьми, которые слишком мало заботятся об условностях и шаблонах, и по уважительной причине, я бы тоже так сделал - я могу найти свое обоснование для этого из моей основной области анализа данных, так как я не такой опытный разработчик: большинство вещей, которые вы считаете важными, не имеют значения, и в этом смысле существует сильная корреляция с вашим эго.Часто человек из-за своего эго получал знание, которое он, скорее всего, неправильно понял из-за его предубеждений, которые теперь вновь подтверждаются властью, которая, по его мнению, просто сказала «то же, что и я». Это очень известная ловушка, в которую вы никогда не попадете. Это не значит, что он не использует это правильно или для блага, но часто эти люди обещают, что все, что они говорят, является золотым призом.

Так что ты можешь сделать?

Объясните свой код коллеге и спросите его, имеет ли он смысл с точки зрения высокого уровня.

Это все, что имеет значение. Конечно, у любого, кто читает чужой код, всегда будет фиеста alt-tab, чтобы увидеть реализацию определенных вещей, но это не имеет значения, если тот, кто читает ваш код, хорошо понимает вашу систему и понимает, «почему все происходит» «(опять же, не обязательно зная, полностью« как они происходят »), тогда ты золотой.

Это не то, что я говорю, иди и пиши дерьмовый код, который не работает или ничего не уважает, но я говорю следующее:

1) Это нормально, чтобы забыть. Со временем вы станете лучше читать код, с которым работаете. Если код, который вы читаете, требует, чтобы вы хорошо знали низкоуровневые реализации, то это код, который плохо написан и соответствует тому, что я сказал ранее: понимает ли вас коллега?

2) Мир полон очень умных людей, которые не очень умны. Они также часто бывают очень эмоциональными и склонны к усилению предвзятости со стороны внешних сил. Они очень хороши в том, что они делают, но то, что они, как субъекты распространения информации, забывают: идеи / информация, даже если они подкреплены «логикой», имеют контекст того, кто их посылает, что крайне важно для понимания того, информация тоже полезна для вас То, что имеет смысл для вас, может иметь смысл для других, и им это понравится, но информация не должна восприниматься как абсолютная, и один, опять же, должен рассмотреть или, по крайней мере, попытаться выяснить контекст, откуда она взялась, и проверить ее собственный контекст, чтобы увидеть, если он соответствует. Это действительно то же самое, что миллиардеры, дающие нам эти «кусочки знаний для продвижения вперед»

Вкратце: напишите код, который понятен, и поймите, что он все еще спорен, когда нам нужно столько шаблонов / классов и переработок, сколько говорят некоторые. По обеим сторонам спора есть очень умные люди, и это должно только укрепить идею делать все, что работает для вашей команды разумным образом - не зацикливайтесь на мелких деталях, которые не имеют значения, вы поймете их позже, помните, вы живете в чрезвычайно конкурентном мире, где время является самым важным:

Сроки успеха в стартапах.

Распределите свое время и ресурсы осмысленным, жадным способом.

Вот редактирование, 6 месяцев спустя:

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

Не поймите меня неправильно: если вы напишите свой код тесно связанный, вам будет очень больно, независимо от того, ненавидите ли вы SOLID или нет, даже понимание и применение его на базовом уровне обеспечивает отличную развязку, что, честно говоря, единственное, что ООП действительно помогает. ООП должен был также касаться повторного использования кода, и пока это происходит здесь и тамвам не нужно повторно использовать множество созданных вами объектов, поэтому сосредоточьтесь на том, чтобы ваша система была хорошо разделена. Как только вы достигнете зрелости, и давайте предположим, что дядя Боб придет и возглавит ваш проект, он скажет: «Хорошо, это чертовски глупо, но, по крайней мере, все разделено, хорошо названо и задокументировано, поэтому, по крайней мере, я знаю, о чем это все» " (Я надеюсь). Для меня это работает. Мой LOC постоянно меняется, но на момент написания, это 110 тыс. Строк кода, 110 тыс. Строк исполняемого кода, которые работают в гармонии для одного человека, это много.

Вот 3 месяца спустя редактирование кода, который я реорганизую:

Все это имеет смысл. Теперь я могу взять то, что я написал тогда, концептуально и заново переформировать код, с новыми идеями, потому что я прекрасно понимаю, что происходит и почему это работает из-за схем / хорошего именования и комментариев. Я написал некоторый код давным-давно, что меня не заботило хорошее именование и тому подобное, и мне тяжело проходить через него. Сейчас я думаю, каким может быть следующий шаг объяснения моего кода.