Как запоминать код, который писал две недели назад?
=====================================================

 Друзья! Есть проблема... Расскажите кто как решает ее.   
  

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

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

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

Думаю начать рисовать майнд мапы к проекту и описывать весь функционал которые писал кодом в визуальном виде. Чтобы можно было в любой момент глянуть и сразу понять что к чему и где присоединяется.   
  

Но может есть и еще какие-то лайфхаки? Поможете? А то с ума схожу уже))))) 

1. [Как писать много кода, оставляя его простым, как в начале?](https://toster.ru/q/388489)
2. Также советую прочесть "Совершенный код" С.Макконнелла.
3. Качественный код не требует того, чтобы его запоминали. Качественный код может быть забыт сразу после того, как он начнет проходить все тесты. Держать в голове нужно только программные интерфейсы, но даже не все, а только, используемые на текущем уровне абстракции.

 

 Это потому что вы просто тупо пишете код, а вам нужно разрабатывать (проектировать) приложение. 

 Это блин эпично, не, ну я понимаю там методы когда я предаю туда по 4-6 пременных, не всегда помню что и в каком порядке, но уж зачем функция getCollectionAsArray() уж точно понимаю. И через 3 года вряд ли забуду. Или именуете коротко и непонятно, или что-то бесструктурно-хаотично захардкориваете, пытаясь накатить фикс поверх бага, и их много. Код как то упорядочен? Ну хотя бы по какой-то там парадигме типа мвц или евент модел? Или фигачу функционал, а там посмотрим? 

 Значит вы ещё не программист, а кодер. Это не страшно, вопрос опыта.  

Главное отличие программиста от кодера - программмист пишет код в голове - набивание кода в IDE это самое нудное в программировании, весь смак - в проектировании. А вот кодер пишет код кусочками, которые берёт из интернета или из собственных внезапных озарений.  
  

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

ПРОФИТ! 

 Писать проект не на чистом листе, а натягивать на какой-то грамотный фреймворк, играя по его правилам. Это поможет освоить и понять некоторые паттерны, принципы [SOLID](https://ru.wikipedia.org/wiki/SOLID_(%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)) / [GRASP](https://ru.wikipedia.org/wiki/GRASP), которые вам уже порекомендовали, и избежать совсем неразборчивой каши в архитектуре.  
  

Давайте понятные названия методам/функциям/классам. Избегайте длинных кусков кода – бейте на меньшие. Многие «правильные» практики сами встанут на место, если начнёте работать над проектом не в одно лицо, а с кем-то.  
  

Делите сложность на [уровни абстракции](https://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B0%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%86%D0%B8%D0%B8_(%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)). Самый верхний, как в общем функционирует ваше приложение, без деталей, всего несколько компнентов – например, веб-клиент, backend сервер и третий сервис. Эти 1-2-3 несложно запомнить/вспомнить ) Далее, как работает backend – с чем взаимодействует (БД, Redis). И т.д. вглубь, в детали. 

> В общем основная проблема, что не могу уложить в голову всю целостную картину и логика проекта.

  

так она (логика проекта) должна быть в голове изначально, а не потом, когда написан код. как это вообще у вас выходит наоборот делать? 

 Две недели? И весь проект от начала до текущего состояния - Ваш? OMG, я чего-то наверное не понимаю...   
  

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

 То есть архитектуры как такой изначально не было?  
  

Вам по-любому надо документировать не только код, а и так называемые use-case и user-story, описывать взаимодействия модулей между собой.  
  

Така абстрактная документация очень важна. Правда, очень желательно, чтобы она была до написания имплементаций. 

 ТДД  

+  

[Как отлично запоминать прочитанный материал?](https://toster.ru/q/206466#answer_558835)  
  

Человек вообще мало может держать в уме вещей - 3-5 абстракций  
  

Начинающим еще приходится держать в уме конструкции 

<https://www.youtube.com/watch?v=z5WkDQVeYU4> 

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

 Конкретно по коду, лично мне - помогает git  

По коммитам и ревестам вполне можно освежить память по проделанной работе, ну и конечно же просмотреть работу других программистов  
  

По поводу майнд мапов - их лучше рисовать изначально, до написания кода, т.е. на этапе проектирования приложения, т.е. описывать, что и как будет взаимодействовать - это собственно и будет Разработка  

В пример - обычный дизайн - сначала рисуется прототип - а уже потом сам дизайн  

По теме - сначала рисуем схему работы приложения, потом пишем код  
  

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

  
  

Это говорит лишь об отсутствии опыта и наличии мышления обычного программиста, а не разработчика/архитектора приложения. Т.е. в голове лежит лишь конкретная задача, а не работа приложения в целом.  
  

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

 Не знаю конечо про лайфхаки, но 2 недели?  

Совсем уж короткая память.  
  

Делал 3-4 года допустим проект, всё помню/знаю. "Забываю" только если нужно уточнить какую-то глубокую мелочь в логике, и то не всегда конечно.  

А за это время еще и всякой другой фигней занимался не только одним проектом.  
  

Если код есть, доки есть, что еще поможет не представляю.  

Записывать еще куда-то? Так вы и там забудете что писали, какой смысл еще работу придумывать?  
  

Уже ответили про SOLID/GRASP, но это не для говнокодеров вроде меня, но таки надо какую-то структуру/логику иметь общую, если вы не помните базовые вещи наверно они меняются постоянно или не очень логично построены.  

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

 Писать хорошо структурированный, модульный, loose coupling / high cohesion код с комментариями, а не спагетти-месиво нагромождения.   

Тогда Вы сможете за несколько секунд понять, что идет куда.  

Если проект рельсо-ориентированный, то есть такая штука как **mountable engine** - очень сильно помогает.   

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

Еще можно разбивать бизнес-логику на сервисы (Service Object pattern) - тоже помогает. 

 Мой совет - спать лучше, есть мясо и отдыхать не забывать 

 Во первых необходима годная архитектура приложения. Я за счет жеско opinionated структуры путей в своем нано-фреймворке на 90% снизил оверхед на "подумать" а где у меня что.  
  

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

В третьих иммутабельность. Если ты меняешь в одно месте, а сломалось/упало в другом, то поздравляю, поциент, у вас мутабельность третьей степени и это фатально. Все что можно перевести в pure functions и immutable structures (тут с осторожностью, ибо можно выстрелить себе в ногу и уронить производительность ниже плинтуса).  
  

Опять же, единственный source of truth спасает.   
  

И самое главное, код надо писать так, чтобы он был понятен с первого взгляда, максимум со второго. Не надо в коде выеживаться и быть многословным. Код должен быть простым и лаконичным. Говоря что snake\_case более читабельный, чем километровыйКамелКейс. Я, пожалуй, соглашусь, хотя использую в коде последний в основном.  
  

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

По крайней мере в последние годы я с ходу понимаю что я там намудрил в проекте и через месяц, и через 6, и через 2 года. А раньше да, бывало через 3 месяца хотелось убить того ишака, который это написал, а потом вспоминаешь, что это был ты сам... :D  
  

Еще момент - хорошо структурированные данные помогают писать более прозрачный код.