Как держать в голове проект по программированию над которым работаешь не каждый день?

Добрый день, ситуация следующая...
Несколько месяцев работаю над неким проектом. Программирую штуку связанную с численными методами решения диффуров и физикой. Когда начинал - все было просто и легко удерживалось в голове. Далее проект стал разрастаться - из за того, что в самом начале не представлял всех сложностей с которыми столкнусь. Над проектом работаю не каждый день, и обнаружилась следующая проблема - если не позаниматься проектом несколько дней - то потом трудно вспомнить на чем я остановился, зачем введены те или или иные куски кода. Пишу комментарии - но не хватает, ощущение, что надо писать развернутые письма самому себе (почти как в фильме "Memento"). В результате день уходит на то, чтобы разобраться что же я делал неделю назад - а на следующий день можно уже писать нормально.
Я не программист, а физик, поэтому могу не знать каких-то типичных и очевидных методов решение таких организационных вопросов. Посоветуйте как быть!
  • Вопрос задан
  • 3489 просмотров
Пригласить эксперта
Ответы на вопрос 10
1. Писать самодокументирующийся код.
2. Щедро добавлять стандартизированные комментарии к каждой функции и переменной.
3. Рефакторить структуру до полной очевидности.
4. Использовать git с подробными описаниями коммитов - с помощью аннотаций будет легко понять зачем написан тот или иной кусок
5. Вести TODO отдельно либо используя @todo комментарии прямо в коде.
Ответ написан
xmoonlight
@xmoonlight
https://sitecoder.blogspot.com
То же самое что и zoom на карте:
1. делаете общую схему с функциональными блоками и их связями. блоки - нумеруются.
2. каждый блок - детализируете в новой схеме.
* тут делаете текстовые описание связей и все, что относится к схеме/к процессу в отдельном docx/xlsx-документе. (google docs)
* на основе этого - не составит труда описать функции для кодинга, если позволяет уровень детализации данной схемы.
3. goto 2.

(разумно использовать draw.io и подключить к google docs/google disk)
Ответ написан
@asd111
Желательно использовать ООП.
При использовании ООП можно сначала нарисовать схемы - так называемые диаграммы UML — в них обычно написано что какой класс делает и нарисовано как он связан с другими.

Сначала рисуете диаграммки что с чем как связано и потом пишете код.

Выглядит примерно так:
p3_9.gif
pvti.ru/data/image/pages/webkurs/p3_9.gif

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

В целом для получения общей картины очень удобно использовать диаграммы, чтобы не забыть что где как устроено если программа большая. Во многих IDE есть возможность получить полное дерево классов.
Ответ написан
IonDen
@IonDen
JavaScript developer. IonDen.com
Нарисовать схему.
+ вести TODO со списком уже сделанных и планируемых задач.
Ответ написан
UnknownHero
@UnknownHero
Если пишите тесты, то перед окончанием работы создавайте нерабочий тест.
Когда сядите заново, запускаете тесты и вспоминаете , что хотели сделать в последнйи раз.
Ответ написан
ColCh
@ColCh
Веб разработчик
Есть поверье - если коду требуется комментарий, его нужно вынести в функцию с говорящим за себя именем
Ответ написан
@argumentum
Кажется, автору вопроса надо внимательно проработать книги:
1) Стив Макконнелл - "Совершенный код"
2) Мартин Фаулер и др. - "Рефакторинг. Улучшение существующего кода."

А по поводу "потом трудно вспомнить на чем я остановился, зачем введены те или или иные куски кода" - помогут системы управления версиями при условии комментирования изменений.
Ответ написан
heksen
@heksen
В голове не удержать, а напоминать себе как-то надо.
Ответ написан
Mrrl
@Mrrl
Заводчик кардиганов
Можно просто периодически читать/просматривать код, вспоминая, что к чему, как оно выглядит, откуда вызывается и кого вызывает, в каких ситуациях работает та или иная часть кода... Чтобы ориентироваться на местности, надо по ней иногда гулять, и не бояться заблудиться :)
Ответ написан
@Dum_spiro_spero Автор вопроса
Попробую резюмировать.
1. Надо изначально хорошо продумать и расписать/разрисовать структуру проекта.
-увы - иногда она начинает меняться по ходу пьесы - значит плохо продумали.
2. Разбивать программу на мелкие блоки.
3. Комментировать все что можно и нельзя.
4. Видимо писать письма самому себе и художественные размышления зачем здесь то или иное.
Большое спасибо всем за ответы!
Кстати - я один такой - страдающий программистким склерозом или это распространено?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы