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

Question

[Александр Петров]

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

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

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

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

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

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

Comments

[Tyranron]

Есть как минимум 2 лайфхака - SOLID и GRASP.

[vasIvas]

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

[tomatho]

Распечатай и читай на ночь перед сном.

[devstudent]

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

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

[Сергей delphinpro]

Документацию к коду пишите. Говорят помогает.

Answer 1

[nirvimel]

1. Как писать много кода, оставляя его простым, как в начале?
   
2. Также советую прочесть "Совершенный код" С.Макконнелла.
   
3. Качественный код не требует того, чтобы его запоминали. Качественный код может быть забыт сразу после того, как он начнет проходить все тесты. Держать в голове нужно только программные интерфейсы, но даже не все, а только, используемые на текущем уровне абстракции.
   

Answer 2

[evgeniy_lm]

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

Answer 3

[danSamara]

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

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

ПРОФИТ!

Answer 4

[ThunderCat]

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

Answer 5

[Сергей Соколов]

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

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

Делите сложность на уровни абстракции. Самый верхний, как в общем функционирует ваше приложение, без деталей, всего несколько компнентов – например, веб-клиент, backend сервер и третий сервис. Эти 1-2-3 несложно запомнить/вспомнить ) Далее, как работает backend – с чем взаимодействует (БД, Redis). И т.д. вглубь, в детали.

Answer 6

[CityCat4]

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

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

Answer 7

[devstudent]

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

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

Comments

[vsuhachev]

ну есть такой способ разработки "с низу вверх", бывает полезен в определенных условиях. Но видимо у ТС не тот случай...

Answer 8

[Negwereth]

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

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

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

Answer 9

[sim3x]

ТДД
+
Как отлично запоминать прочитанный материал?

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

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

Answer 10

[Dimonchik]

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

Comments

[Vicom]

отлично материал, спасибо

Answer 11

[TheTalion]

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

Answer 12

[Денис Артамонов]

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

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

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

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

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

Answer 13

[Александр Аксентьев]

Не знаю конечо про лайфхаки, но 2 недели?
Совсем уж короткая память.

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

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

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

Answer 14

[Dmitri Sinitsa]

Писать хорошо структурированный, модульный, loose coupling / high cohesion код с комментариями, а не спагетти-месиво нагромождения.
Тогда Вы сможете за несколько секунд понять, что идет куда.
Если проект рельсо-ориентированный, то есть такая штука как mountable engine - очень сильно помогает.
Разбейте проект на такие монтируемые движки - не поверите, насколько сильно это упрощает жизнь, я без них вообще не представляю, как можно работать со сколько угодно крупными проектами, не прибегая к микросервисам.
Еще можно разбивать бизнес-логику на сервисы (Service Object pattern) - тоже помогает.

Answer 15

[vsuhachev]

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

Comments

[Антон Мудренок]

а мясо тут при чем?)

[vsuhachev]

Антон Мудренок: объяснить не могу, непонятно почему, но работает :)) Еще можно пивом запивать в умеренных количествах..

Answer 16

[Андрей]

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

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

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

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

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

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

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

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