как программисты запоминают код
Как читать код: 8 принципов, которые стоит запомнить
«Ненавижу читать чужой код», — эту мантру часто можно услышать от разработчиков любого уровня. Тем не менее, это необходимое умение, особенно для разработчиков, которым предстоит освоиться в существующей кодовой базе, и если вы подойдете к этой работе с правильным настроем и правильными инструментами, это может быть весьма приятным и просветляющим опытом.
Мы не любим читать чужой код по той причине, что он написан не нами. Само собой разумеется, что в глубине души мы считаем себя лучшими программистами на планете и никто не сможет написать такой крутой код, как мы. Написание кода — это интенсивный мыслительный процесс, а пассивный читатель не испытывает ничего подобного.
Код, который вы видите на экране, мог быть написан несколькими людьми. Возможно, в процессе споров и сотрудничества. Возможно, им потребовались недели, чтобы выдать код, который обходил какие-то недокументированные ограничения, о которых вам неизвестно, и это знание осталось только в головах тех, кто его писал.
Все, что вы увидите как читатель — это законченный продукт. И если не провести некоторых раскопок, единственный контекст, с которым вы будете работать — это тот самый код на вашем экране.
1. Учитесь копать
Когда вы впервые знакомитесь с серьезной кодовой базой, возможно, вы не будете чувствовать себя разработчиком. Скорее вы будете себя чувствовать археологом, частным сыщиком, или исследователем религиозных книг. Это вполне нормально, ведь в вашем распоряжении есть несколько инструментов для «раскопок». Если вам повезло, и ваши предшественники использовали контроль версий, это стоит отпраздновать! У вас есть доступ к богатству метаданных, и это очень сильно облегчит вам понимание контекста, в котором создавался код. Далее я исхожу из того, что вы используете Git, но в случае с SVN, все будет примерно так же.
git blame
git log
2. Вернитесь в прошлое
Вы можете переключиться на какой угодно коммит и запустить проект так, как будто бы этот коммит был последним. Вам может понадобиться переключиться на коммит, который был последним перед появлением какой-нибудь сложно отслеживаемой проблемы. А может вам просто станет скучно и вы захотите покопаться в истории кода и увидеть, каким был проект за годы до того, как вы туда пришли.
Если проект хранится на GitHub или подобном сервисе, вы можете получить уйму информации, читая тикеты, пулл-реквесты и код-ревью. Обращайте внимание на тикеты, в которых было больше всего обсуждений. Там могут быть «болевые точки», с которыми вы можете столкнуться в будущем, поэтому хорошо бы заранее иметь о них представление.
3. Читайте спецификации
Спецификации — это новые комментарии. Читайте юнит-спецификации, чтобы выяснить предназначение функций и модулей, и возможные пограничные случаи (edge-cases), которые они обрабатывают. Читайте интеграционные спецификации, чтобы выяснить, как пользователи будут взаимодействовать с вашим приложением и какие процессы поддерживает ваше приложение.
4. Думайте о комментариях, как о подсказках
Если вы наткнулись на непонятную функцию и прочли комментарий к ней, который еще больше вас запутал, возможно, что этот комментарий просто устарел и не обновлялся.
Глаза программиста имеют способность пропускать пропускать зеленый текст комментариев, и возможно, что этот поставивший вас в тупик комментарий относился к функции, которая исчезла уже много месяцев (или лет) назад, и никто, кроме вас, этого не заметил.
5. Найдите Main
Это может казаться очевидным, но в первую очередь убедитесь, что вы понимаете, где код начинает исполнение и что происходит в процессе запуска. Посмотрите, какие файлы подключаются, какие классы инстанцируются, какие опции конфига устанавливаются.
Скорее всего, вы будете постоянно сталкиваться с ними и в остальном коде. Некоторые модули будут иметь очень общее назначение, и будут выделяться из остального кода. Они представляют собой более маленькие и понятные кусочки функционала, с которыми вам следует познакомиться перед тем, как пытаться разобраться со всем приложением полностью.
Выполните git blame на этом файле и посмотрите, какие части основного файла были изменены недавно. Недавно измененный код может подсказать вам, над какими проблемами работала команда в последнее время. Возможно, они представили новую библиотеку, или долго пытались наладить библиотеку, которая не слишком хорошо работала. А может быть, там просто какой-то бойлерплейт код, который нужно регулярно обновлять.
Попробуйте найти отсылки к этим модулям в других частях кода, чтобы понять, как и когда они используются. Это может помочь вам понять место и роль модулей в основном приложении.
6. Обращайте внимание на стиль.
Вы ведь изучаете это приложение не просто так, и рано или поздно ваш код тоже туда попадет, поэтому обращайте внимание на стиль. Это включает в себя такие вещи как соглашение о стандартах оформления кода: именование, пробелы, скобки, а также соглашение о написании кода.
Каков общий уровень абстракции? Если это высокоабстрактный код со многими уровнями абстракции, то вам следует писать так же. Если вы хорошенько покопались в истории, то наверное сможете найти момент, когда один из разработчиков решил абстрагировать часть кода. Как он выглядел до этого, и что стало с ним после выноса на новый уровень абстракции? Пытайтесь следовать тем же соглашениям, когда пишете свой код.
7. Ожидайте встретить мусор
Вам могут встретиться функции, а может, и целые файлы, которые никогда не используются. Вы можете встретить закомментированный код, который простоял нетронутым несколько лет ( git blame в помощь). Не тратьте на это слишком много времени, и не бойтесь избавляться от подобных артефактов.
Если этот код был нужен, кто-нибудь отметит это на код-ревью. А вы сделаете доброе дело, уменьшив количество умственной нагрузки для следующего, кто будет читать этот код.
8. Не отчаивайтесь
Держите предыдущие пункты в голове, и не падайте духом, если чувствуете, что совершенно запутались. Изучение кода — это не линейный процесс, не ожидайте сразу понять все на 100%. Обращайте внимание на важные детали и знайте, как копать, чтобы найти ответы на вопросы, и вы довольно быстро обнаружите, что все становится понятно.
Автор: Уильям Шон, консультант и разработчик в Ann Arbor. Оригинал здесь.
Самый эффективный способ изучать программирование (но он не для всех)
Когда я преподавал программирование в ВУЗе, то в начале семестра я приглашал лучших учеников на кафедру и предлагал им следующий вариант изучения курса: «Можете не ходить на лекции. Я поставлю вам зачет автоматом и пять баллов на экзамене, если к концу семестра вы сделаете…»
Как я сам узнал этот секрет
Дальше я рассказывал студентам секрет быстрого изучения программирования. Но как я сам узнал его?
Это было давно, когда я еще работал программистом в космической отрасли. У меня был приятель, который работал переводчиком. Мы иногда пересекались и обсуждали всякие IT-темы. Он был гуманитарий и слабо разбирался в компьютерах. Но он купил компьютер и у него было много вопросов.
Как-то во время очередной встречи он мне неожиданно сказал: «Я тут написал драйвер для джойстика!» Я поразился, написание драйверов — это весьма сложная задача. Как мог человек, который не знал программирования, написать драйвер?
А дело было так. Он купил джойстик, чтобы играть в компьютерные игры. Но в те времена была проблема драйверов. Не каждое устройство можно было запустить на компьютере, если не было соответствующего драйвера.
Мой приятель попал именно в такую ситуацию. Драйвера для его материнской платы не было. Но на дискете с драйверами прилагался текст драйвера на языке Си.
Хотя он не был программистом, но играть очень хотелось. Он взял инструкцию к материнской плате и стал сравнивать коды в инструкции с текстом программы драйвера. Он обнаружил, что отличаются только последовательность команд, а сами команды были похожи.
Дальше он стал разбираться с тем, как можно скомпилировать программу на Си, как она отлаживается. Все это было очень трудно. Но когда первый раз джойстик вдруг среагировал на нажатие кнопки, это была победа!
Шаг за шагом он добавил обработку всех команд и джойстик полностью заработал!
Весь этот процесс у него занял полгода. То есть гуманитарий, который и с компьютером-то разобрался только недавно, за полгода написал сложную программу.
Когда я его спросил:
— Как же ты так во всем самостоятельно разобрался?
— Играть очень хотелось!
Так я узнал секрет быстрого изучения программирования.
Что я говорил студентам?
Полная фраза звучала так: «Я поставлю пятерку автоматом, если в конце семестра вы принесете мне программу, которую сделаете для себя».
Что за программа, значения не имеет. Главное, чтобы студент сам ею пользовался. Обычно студенты писали базы данных, проигрыватели аудио, простые игры.
И у всех, кто брался, получалось превосходно. Они знали программирование намного лучше тех студентов, кто решал учебные задачи.
В чем же секрет этого способа изучения программирования?
Когда новичок прослушал курс и пытается написать свою программу, то он вдруг понимает, насколько сложное это дело и сколько он еще не знает.
В этот момент начинает казаться, что программирование — это безумно сложное дело и ему с этим никак не справиться.
Совсем другое дело, если новичок сразу начал с программы, которая ему нужно. В этот момент включается мотивация: «Играть очень хочется!» и тогда новичок пишет пусть криво и косо работающую программу, которая хоть как-то шевелится.
Но хитрость в том, что если традиционный студент изучает все подряд, а потом все это забывает, то продвинутый студент изучает ровно то, что нужно для конкретной программы и сразу это пускает в дело. А то, что сделал своими руками — это не забудешь.
Знания про запас
Большая проблема традиционного обучения в том, что знания получаются в надежде их будущего применения. Поэтому студенту трудно различить, где что-то важное, а где то, что никогда не пригодится.
Поэтому обычная стратегия такая: накопить побольше знаний в надежде, что они когда-либо пригодятся.
Продвинутые ученики, напротив, прямо сейчас ищут и изучают то, что нужно для решения задачи. Они ищут ответы в Интернете, задают вопросы на форумах, спрашивают на StackOverflow. То есть они активно накапливают знания, которые сразу применяют и получают пользу.
Но есть и еще один важный момент. Те знания, которые запасены на будущее, могут иметь пробелы, то есть студент думает, что понял какую-либо тему, но на самом деле он ее только «прослушал», а конкретно применить все равно не сможет.
А вот те знания, которые прямо сейчас используются, уже не могут быть с пробелами. Любое непонимание приводит к тому, что надо детально разобраться. Причем в программировании нужно разобраться вплоть до последней запятой, иначе программа не заработает.
Методика обучения пошагово
Итак, как же выглядит самый эффективный путь изучения программирования?
Шаг 1. Выберите программу, которую будет сами использовать.
Не нужно замахиваться на что-то сложное. Смотрите те ситуации, с которыми вы сталкиваетесь. Например, вам не хватает программы для заметок — напишите ее. Или вам хочется заметки автоматически публиковать в своем твиттере — сделайте это.
Главное — не думайте о том, что вы сейчас приступаете к проекту на миллиард долларов. Стартап вас еще ждет, но не сейчас. Программа должна быть самой обычной.
Шаг 2. Поищите аналоги и посмотрите, как они сделаны
Проведите небольшое исследование на тему того, какие программы используются для решения вашей задачи. Потом узнайте на каком языке эти программы написаны, и какие библиотеки были при этом использованы. Можете расспросить опытных программистов на форумах, они подскажут.
Шаг 3. Сразу начните писать программу
Ни завтра, ни через полгода, а вот прямо сегодня. На том уровне знаний, который у вас сейчас есть. Написали текст и запустили на компиляцию. Вы можете возразить: «Да я даже не знаю, что такое компиляция?» Отлично, самое время узнать, что это такое.
Не ждите идеала. Пишите кривой, но работающий код. Запомните: сначала — результат, а потом — оптимизация.
Шаг 4. Заминка
Может получиться так, что некоторые моменты программы заработали сразу, а вот с другими случилась заминка. Тут надо поступать так: параллельно пишите то, то получается и одновременно разбираетесь с тем, что не получается. То есть работу над программой не останавливаете ни на минуту.
Шаг 5. В зачет идет только код
Это одно из главных правил программиста. Вы можете что-либо изучать, искать информацию, задавать вопросы, но главное — это кодирование. Каждый день пишите код.
Шаг 6. Пользуйтесь программой
Каждый день после кодирования начинайте пользоваться своей программой. Записывайте баги и пожелания. Вы будете своим заказчиком. В этом и состоит мотивация.
Шаг 7. Друзья-тестировщики
Если ваши друзья тоже хотят данный функционал, то передавайте им версии программ. Пусть они тоже станут бета-тестерами и генераторами идей.
Твердость и упорство
Конечно же, предлагаемый путь очень сложный. Как только вы начнете писать первую реальную программу на вас обрушится такое количество трудностей, что захочется сдаться и опустить руки.
Но я предупреждал в самом начале, что это путь не для всех, только для самых упорных.
Как программисту улучшить свою память — отвечают эксперты
Как программисту улучшить свою память — отвечают эксперты
В IT-сфере огромное количество информации, и с каждым днём становится только больше. Чтобы ориентироваться в этом объёме данных, нужно иметь хорошую память, ведь даже чтобы поискать что-то в интернете, нужно помнить о том, что это что-то существует. Как улучшить свою память, чтобы идти в ногу со временем? Узнаем у экспертов.
ведущий разработчик MediaSoft
Это может показаться странным, но программисту сейчас нет нужды запоминать множество вещей — IT настолько быстро развивающаяся индустрия, что то, что вы запомнили сегодня, может оказаться морально устаревшим уже к концу этого года. Особенно ярко это проявляется в мире фронтенд-разработки.
Куда более полезным для современного разработчика является умение быстро находить нужную информацию и грамотно формулировать поисковые запросы, а также способность выбирать из огромного потока информации только нужную и достоверную часть. Как развить эти навыки? На мой взгляд, они могут прийти только с опытом, есть лишь несколько небольших советов:
Действительно важная информация, которую нужно помнить разработчику, всегда очень абстрактна и описывает не конкретные реализации, а основные концепции. Этой информации не так много, и запомнить её может каждый без особых усилий, а всякие мелочи вы всё равно забудете через пару недель после того, как перестанете с ними работать. Можно, конечно, упражнения разные поделать, их в сети описано бесчисленное множество, осталось только найти и выбрать, но зачем?
инженер-программист 1 категории компании ICL Services
Программирование как сфера деятельности — это прекрасный образец каждодневной тренировки памяти. Помнить синтаксис и алгоритмы — ежедневная рутина, которая перерастает в механическую память, когда мозг не включается, а «руки помнят». Естественно, это происходит не за один день и даже не за неделю, этот механический опыт передаётся тщательными тренировками и практическими заданиями.
Поэтому, по моему мнению, для программиста забыть синтаксис, операторы, способы объявления функций и т. д. — это как для строителя забыть, как пользоваться молотком.
Трудности возникают тогда, когда разработчик должен взаимодействовать с несколькими языками программирования каждый день. В этом случае получается путаница и беспорядок. В таких ситуациях на помощь приходят мнемонические правила или ассоциативная память. Например, при объявлении функций на языке C# используются знаки «<>», которые мне напоминают консервы — консервированный C#. Для запоминания некоторых команд мне иногда достаточно повторить их вслух, без правил английского языка (Publish-AppvPackage для PowerShell: публиш апп-в пакет).
Для профилактики некоторые упражнения для памяти всё-таки лучше попрактиковать: в моём случае это посмотреть мельком на телефон и вспомнить, сколько там было времени; также по ходу движения запоминать номерные знаки автомобилей — чем больше, тем лучше; вспомнить, что было вчера — тоже отличный вариант!
Память это, конечно, очень важно, и прекрасно помнить всё, но на случай тотального забытья всегда есть Google!
декан факультета веб-разработки в GeekUniversity
Хотелось бы сразу предостеречь начинающих программистов от зубрёжки. В отличие от языков, на которых мы разговариваем, в языках программирования очень мало исключений из правил, а количество ключевых слов и конструкций редко превышает сотню. Более того, при написании программ, если вы, конечно, не собираетесь работать в блокноте, всегда можно воспользоваться современными редакторами кода и IDE, которые анализируют код, делают подсказки, отмечают ваши ошибки, тем самым ускоряя разработку.
Но существуют вещи в программировании, которые действительно необходимо выучить по двум причинам. Во-первых, чтобы успешно пройти собеседование, продемонстрировав свои навыки, а во-вторых, просто для того, чтобы не тратить своё время на поиск одной и той же информации. К таким вещам относятся, например, основные алгоритмы и шаблоны (паттерны) проектирования, а также синтаксис и основные функции языка программирования, на котором вы собираетесь писать основную часть времени.
Как же лучше всего выучить эти вещи? Просто вызубрить, не вникая в суть? Вряд ли. Можно либо найти в интернете тренировки для памяти и выполнять упражнения «запомни ряд слов и повтори», «запомни цифры и повтори», либо учить стихи. Да, это бесспорно пойдёт вам и вашему мозгу на пользу, но сделает ли это из вас великого программиста? Скорее всего, нет. А вот что действительно может помочь, так это постоянная практика. Если вы будете каждый день хотя бы по паре часов писать код на своём любимом языке программирования (или на том, с которым вы хотите работать в дальнейшем) и не просто бездумно копировать код с таких сайтов, как StackOverflow, а именно писать, понимая, что делает каждый символ вашего кода, то очень скоро вы поймаете себя на мысли, что пишете по памяти, и вам не приходится каждую конструкцию подсматривать в учебнике/документации.
Кроме того, могу посоветовать «сохранять себе в копилку» интересные конструкции и фрагменты кода для того, чтобы в будущем не писать повторно тот же алгоритм, а подсмотреть у себя же. Такие кусочки принято называть сниппетами кода, от английского snippet — отрывок, фрагмент. Существуют и бесплатные сервисы для хранения таких кусочков кода, например GitHub Gist.
Подводя итог, хочу порекомендовать не заучивать всё подряд, а в первую очередь понимать, что вы пишете и почему ваш код работает именно так, а не иначе. Достаточно выучить самые основные и наиболее часто используемые вещи, и, скорее всего, они сами быстро запомнятся. Остальное важно уметь быстро найти в учебнике или в документации.
генеральный директор PR Partner
руководитель группы разработки проектов Тверского технологического центра Accenture
Про улучшение памяти написано столько книг и методик, что если их все прочесть, то забудется последнее. На фоне популярности биохагинга с его ноотропами, мнемонических техник, интервальных повторений, эффекта Зейгарник, методов Цицерона и Айвазовского, программисты часто забывают об основе когнитивной функции — здоровье мозга. А оно неразрывно связано со здоровым образом жизни. Поэтому хорошую память следует искать не в психологии, а в физиологии нашего тела. Без умеренной физической нагрузки, хорошего питания, качественного сна и отсутствия вредных привычек вряд ли удастся запомнить что-то надолго.
Вторая основа хорошей памяти — это отсутствие стресса, при котором процесс освоения новой информации теряет в качестве. Перегрузка и режим постоянной многозадачности также ухудшают способность к запоминанию. Для такой психологически напряженной области как программирование это особенно актуальные проблемы. Поэтому следует ответственно относиться к планированию времени, дипломатичности общения с коллегами, активному отдыху и поддержанию work-life баланса.
Модификация памяти — это формирование связей и спецификаций нейронов. А нейрофизиология — очень молодая наука, теоретическая база которой во многом строится на эмпирических наблюдениях. Это значит, что все существующие продвинутые методики запоминания ничего под собой не имеют и на длительном промежутке времени не изучались. К любому методу и совету в этой области нужно относиться с осторожностью.
руководитель направления обучения и развития персонала в DINS
Наша память — уникальный механизм работы с информацией, который имеет ряд особенностей, например:
Как же использовать эти особенности для более эффективного запоминания? Рекомендую применять 3 простых принципа:
Для того чтобы глубже погрузиться в тему развития памяти и исследований относительно особенностей мышления, рекомендую посмотреть на YouTube лекции психолога Татьяны Черниговской или прочитать книги «Помнить всё» Артура Думчева, «Как запоминать (почти) всё и всегда» Роба Иставэй. Именно эти материалы мы используем сами для подготовки внутреннего обучающего курса «Работа с информацией», который призван помочь коллегам организовать входящий поток задач, звонков, писем, документов, научиться быстро и качественно выделять главное, запоминать нужное и забывать ненужное.
Нутрициолог, диетолог, специалист по детскому питанию
Память необходима программисту для выполнения его профессиональных обязанностей. Но из-за специфики работы именно память становится уязвимой. Сидячая работа, ненормированная загруженность, нервное напряжение, невозможность полноценно принять пищу не лучшим образом влияют на способность к запоминанию.
Несколько простых правил помогут сохранить и улучшить память.
Улучшение памяти — это труд, требующий времени, сил и осознанности. Но награда за усилия достойная.
Будьте здоровы!
Итак, как программисту улучшить свою память?
И помните, что программисту не под силу выучить всё, тем более что это «всё» постоянно расширяется. Есть основные вещи вроде синтаксиса языка или шаблонов проектирования, которые нужно держать в голове, чтобы эффективнее выполнять свою работу. Запомнить такие вещи лучше всего поможет практика. Для остального есть Google.
Как запоминать код, который писал две недели назад?
Друзья! Есть проблема. Расскажите кто как решает ее.
Короче проект, который я делаю разрастается и постепенно обретает формы огромного животного, которое трудно уместить у себя в голове. Начинаю забывать какой код за что отвечает, как работает и с кем взаимодействует.
Комментарии пишу, стараюсь все структуризировать, по функциям раскидываю однообразные задачи и тому подобное, но целостной картины всего проекта в голове нет, что-то забываю. тем самым могу написать какой-то модуль, которые через хрен знает сколько строк кода неожиданно может повлиять на другой кусок кода и что-то сломать.
В общем основная проблема, что не могу уложить в голову всю целостную картину и логика проекта.
Думаю начать рисовать майнд мапы к проекту и описывать весь функционал которые писал кодом в визуальном виде. Чтобы можно было в любой момент глянуть и сразу понять что к чему и где присоединяется.
Но может есть и еще какие-то лайфхаки? Поможете? А то с ума схожу уже)))))
В общем основная проблема, что не могу уложить в голову всю целостную картину и логика проекта.
Писать проект не на чистом листе, а натягивать на какой-то грамотный фреймворк, играя по его правилам. Это поможет освоить и понять некоторые паттерны, принципы SOLID / GRASP, которые вам уже порекомендовали, и избежать совсем неразборчивой каши в архитектуре.
Давайте понятные названия методам/функциям/классам. Избегайте длинных кусков кода – бейте на меньшие. Многие «правильные» практики сами встанут на место, если начнёте работать над проектом не в одно лицо, а с кем-то.
Делите сложность на уровни абстракции. Самый верхний, как в общем функционирует ваше приложение, без деталей, всего несколько компнентов – например, веб-клиент, backend сервер и третий сервис. Эти 1-2-3 несложно запомнить/вспомнить ) Далее, как работает backend – с чем взаимодействует (БД, Redis). И т.д. вглубь, в детали.
В общем основная проблема, что не могу уложить в голову всю целостную картину и логика проекта.
То есть архитектуры как такой изначально не было?
Вам по-любому надо документировать не только код, а и так называемые use-case и user-story, описывать взаимодействия модулей между собой.
Така абстрактная документация очень важна. Правда, очень желательно, чтобы она была до написания имплементаций.
Начинающим еще приходится держать в уме конструкции
Комментарии пишу, стараюсь все структуризировать, по функциям раскидываю однообразные задачи и тому подобное, но целостной картины всего проекта в голове нет, что-то забываю. тем самым могу написать какой-то модуль, которые через хрен знает сколько строк кода неожиданно может повлиять на другой кусок кода и что-то сломать.
Это говорит лишь об отсутствии опыта и наличии мышления обычного программиста, а не разработчика/архитектора приложения. Т.е. в голове лежит лишь конкретная задача, а не работа приложения в целом.
Не знаю конечо про лайфхаки, но 2 недели?
Совсем уж короткая память.
Делал 3-4 года допустим проект, всё помню/знаю. «Забываю» только если нужно уточнить какую-то глубокую мелочь в логике, и то не всегда конечно.
А за это время еще и всякой другой фигней занимался не только одним проектом.
Если код есть, доки есть, что еще поможет не представляю.
Записывать еще куда-то? Так вы и там забудете что писали, какой смысл еще работу придумывать?
Уже ответили про SOLID/GRASP, но это не для говнокодеров вроде меня, но таки надо какую-то структуру/логику иметь общую, если вы не помните базовые вещи наверно они меняются постоянно или не очень логично построены.
Так же забывается если код не используется долго, и если что-то ломается от нового/новый от старого надо писать лучше, чтобы такое было в принципе невозможно.
Во первых необходима годная архитектура приложения. Я за счет жеско opinionated структуры путей в своем нано-фреймворке на 90% снизил оверхед на «подумать» а где у меня что.
Во вторых модульность, в идеале один модуль отвечает за одну таску. Не надо городить швейцарские ножи, это плохо кончается.
В третьих иммутабельность. Если ты меняешь в одно месте, а сломалось/упало в другом, то поздравляю, поциент, у вас мутабельность третьей степени и это фатально. Все что можно перевести в pure functions и immutable structures (тут с осторожностью, ибо можно выстрелить себе в ногу и уронить производительность ниже плинтуса).
Опять же, единственный source of truth спасает.
И самое главное, код надо писать так, чтобы он был понятен с первого взгляда, максимум со второго. Не надо в коде выеживаться и быть многословным. Код должен быть простым и лаконичным. Говоря что snake_case более читабельный, чем километровыйКамелКейс. Я, пожалуй, соглашусь, хотя использую в коде последний в основном.
Я часто встречаю весьма изящный хитрый код, который невозможно понять даже после часовой медитации над ним. Вот я так стараюсь не делать. Я стараюсь писать код, чтобы понял любой джун (очевидно который в контексте проекта). Получается не всегда, но достаточно часто.