Как не запутаться в том, что уже написал

docstrings, говорящие имена методов и переменных, сущности разделенные по соответствующим пакетам и модулям

Сейчас кода на 3 тыс. строк и на горизонте мне видится еще примерно столько же. Все это на питоне.

Кмк, ты делаешь что-то не так.

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

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

Стараюсь использовать всякие примочки, чтобы снизить количество кода (использую меньше переменных, переменной присваиваю выводы сразу нескольких модулей или методов, использую классы и инстансы в подходящих случаях и тд)

Я думаю, стоит пересмотреть архитектуру приложения. Сделать его модульным, отделить «ядро» от примочек.

Ну и как сказали выше - документация.

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

когда к этому возвращаешься после перерыва, есть такое странное желание взять и переписать все заново

Гони это сразу от себя. Заведи трекер, продумай заранее функциональность, составь план. Задай себе правило, пока не будет готова вся функциональность, не рефакторить код.

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

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

Я думаю, стоит пересмотреть архитектуру приложения. Сделать его модульным, отделить «ядро» от примочек.

Ну оно вроде как и так модульное. Т.е. я делаю так, чтобы я могу использовать один модуль независимо от большинства других, только используя основную логику в main(). Но кстати я не делил проект на отдельные файлы. Я делаю все в одном, потому что мне так удобнее смотреть.

Я делаю все в одном, потому что мне так удобнее смотреть.

3000 строк? Вот, не поверю. Кмк, как раз в этом и проблема.

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

С нуля все пишешь или же фреймворки какие используешь? Может вновь очередной велосипед делаешь?

чтобы снизить количество кода (использую меньше переменных, переменной присваиваю выводы сразу нескольких модулей или методов, использую классы и инстансы в подходящих случаях и тд)

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

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

Это не то. Вот, из вики:

Организация программы как совокупности небольших независимых блоков… позволяет упростить тестирование программы и обнаружение ошибок.

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

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

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

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

Перемещаться по отдельным файлам достаточно просто даже в vim. У тебя же работает что-нибудь вроде ctags для перехода к definitions/usage за пределами файла?

Питоновый lsp прикручен, кстати?

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

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

у меня больше простая автоматизация

В Си это называется:

pmccabe -v *.c*

Смотришь на показатели и пытаешься снизить, деля код. Как снизил, так сразу видишь, что код стал значительно проще. Есть ли такая фитча по пайтон? Не знаю.

У меня сейчас проект на питоне в 8k SLOC (т.е. без комментариев и пустых строк), использую голый vim, проблем не знаю, даже когда не трогаю его месяц. Тебе же не нужно держать весь код проекта в голове - написал модуль, тесты к нему, отладил и забыл, переходишь к следующему модулю. Может у тебя с этим проблема?

У меня 130 .py файлов, медианный занимает 33 LOC или 65 строк (+шапка с лицензией, комментарии, пустые строки), хотя ключевые модули конечно в несколько раз объёмнее. В корне главного пакета 20 модулей/пакетов, т.е. эти 130 файлов распределены по иерархии, итого из всего проекта мне нужно помнить только общую информацию о 20 сущностях.

Плюс этот репозиторий неоднократно разбивался на части и отдельные самостоятельны модули выносились на PyPI - всего в рамках проекта написано больше 20k SLOC, однако обо всём этом мне тоже не нужно ничего помнить.

Стараюсь использовать всякие примочки, чтобы снизить количество кода (использую меньше переменных, переменной присваиваю выводы сразу нескольких модулей или методов, использую классы и инстансы в подходящих случаях и тд), но все равно выходит много, особенно с комментариями

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

посчитал ЛОК у себя в лисапеде - 14к, и не касался я его месяца 3-4, как доберусь отпишусь тут как быстро я в него вьехал с такого перерыва.

GIT (cherry pick, subrepo), TDD, declarative programming, specs, emacs ((GIT) annotation tools)

youtube + python code organize для вдохновения

Сейчас кода на 3 тыс. строк и на горизонте мне видится еще примерно столько же.

Значит, впору задуматься о том, правильный ли инструментарий выбран для решения задачи.

«Коде-конвеншонс» и «Архитектурный концепт» себе напиши :) Ну или хотябы «вики проекта». Часто применяй квадратно-гнездовые «бест-практики» структурирования кода, чтоб видя кусочек иметь представление «да там все такое же» :)

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

Имена файлов можешь делать как в джаве, когда каждый файл содержит только один класс, тогда проще ориентироваться в проекте из допотопных окружение типа vim.

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

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

Можешь упороться и для каждого модуля сделать отдельное версионирование и отдельный контроль версий.

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

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

Разбивай их на более мелкие.

Полезно помнить о лишних деталях при обратной сборке и бесконечном делении атомов )

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

Сейчас кода на 3 тыс. строк и на горизонте мне видится еще примерно столько же

Это же очень маленький проект. в 3 тысячах даже ide не нужно, если написано не рукожопно.

Но кстати я не делил проект на отдельные файлы.

А так у тебя все 3к строк в одном файле, тогда

потому что мне так удобнее смотреть.

Это не правда.

Да-да. Не забыть скрам-митинг с самим собой, груминг, стэндап, гринлайт и мастурбейтинг.

записывал имена переменных и функций на листочках.

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

Стараюсь использовать всякие примочки, чтобы снизить количество кода (использую меньше переменных, переменной присваиваю выводы сразу нескольких модулей или методов, использую классы и инстансы в подходящих случаях и тд)

Ерунду делаешь. На, возьми это: https://refactoring.guru/ru

Кстати, писать большой проект на динамически типизированном языке это ССЗБ.

а если такое тз поставили? сделай нам большой проект да еще с графиками... А под рукой ничего кроме питона не было.

Тогда страдание неизбежно.

Используйте метод дедукции. Вот и всё. Интеллект человека подобен ножу – он разрезает всё. Вот и режьте. А если обмазать его говном, типа говнокода или огромного монотонно-нарастющего монолита – то тогда даже гениальный ум начнёт тупить. Пытаться решить следствие проблемы путём подпорок – это фигня полная. Любая задача просто делится на мелкие подзадачи. Но для этого нужно и идти от общего – т.е. общая картина должна уже быть. Хотя бы какая-то. Вот и всё.

плюс за упоминание TDD

Когда после этого открываю код что-то дописать - теряюсь.

Потому, что пока ваш проект - «каша-малаша».
Вам уже много советов дали …

Владимир

Так вот какие вы используете приемы чтобы не теряться в собственном проекте?

IDE, автоматизированные тесты (которые также служат заменой документации), атомарность изменений кодовой базы. Задокументированные интерфейсы классов (а ля doxygen или что там в Питоне используется).

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

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

переодически переписывая

достигнутся два эффекта

ещё более полное понимание программы

упрощение(в авторском понимании) кода

Ты занимаешься мазохизмом, вот откуда проблема. Поставь PyCharm или VSCode и не будет проблем. При правильном разбитии на пакеты и модули удобно ориентироваться в проекте, а графические IDE позволяют держать открытыми много вкладок (возможно в каком-нибудь консольном emacs тоже так можно, не знаю). А твой файлик станет не поддерживаемым с ростом количества строк.

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

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

Где твой проект. Лучше покажи его. И мы всё поймем.

Кмк, ты делаешь что-то не так

Как можно запутаться во всего лишь 5-10 тысячах строк кода? Он что функции классы не использует? Наконец закладки в редакторе

1. Архитектура.
2. Тесты (через них можно изучать код).
3. Документация (README и docs/).

Веди лог проекта на бумаге. Рисуешь кружочек, пишешь большую задачу, слов 5-10. Под ней еще кружочки поменьше - подзадачи. Все это нумеруй и подшивай в прозрачный файлик. Мелочи пиши прямо в сорец комментариями # TODO йцукен # FIXME фыва. Коммить промежуточное с пометкой промежуточное, готовое без нее, старайся не бросать микрозадачи на половине, закрывай все горячие TODO FIXME. В файле ARCH.txt записывай структуру папки проекта, а также овервью классов/как что связано и планы, которые не помещаются в TODO или на бумагу. Все нюансы также пиши в лог проекта, например если задача решена, то ставишь галку в кружок, а если отменена, то крестик и стрелку на новый кружок и под ней краткое описание нафиг так. Рисуй прям схемы на отдельных листах, когда думаешь над проектом, не держи все в голове. Пиши ключевые идеи/выводы. Все подшивай, ничего не выкидывай, на обороте не пиши, как черновик не юзай.

Как делить бумагу/ARCH? Бумага write-only, туда идет оперативное и поток сознания. В арч идет то, что меняется (например при рефакторинге арч сильно поменяется), и то, что долго писать или переписывать от руки, “aftermath” того, что на бумаге.

После паузы читаешь ARCH.txt и лог проекта и все вспоминаешь еще до чтения кода.

Отличный план для штамповочных проектов, которые уже сто раз делал, очень наивный для r&d-style.

Как можно запутаться во всего лишь 5-10 тысячах строк кода?

Если оценивать сложность проекта количеством строк, то вполне.

плюс за упоминание TDD

благодарю

Веди лог проекта на бумаге. …

Здравая мысль, и мне кажется может подойти просто файл, например в org-mode. Отметил для себя: главный момент - вести лог проекта.

Интересно так-же получше понять насчет ARCH.

Спасибо.

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

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

ЗЫ

Увидел что всё в одном файле, да ещё в виме. Питон в виме ужасен. Бери Pycharm и не страдай фигнёй. Вим я конечно люблю и уважаю, но нельзя над собой издеваться.

хм, ну у меня не питон а ява, но ради интереса посмотрел статистику только по ява файлам (т.е. исходникам), на основном проекте которому около 5 лет - больше 240 тыс. строк кода, на пет проекте - 70 тыс. (где то год писал с переменным успехом)

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

1. правильная архитектура приложения, на старте проектов долго держал на бумаге основную схему/концепцию, пока не отложилась в голове, раньше uml всякие применял, счас лень стало ))
2. документирование/комментирование узких мест, хотя если есть какие-то подобные случаи, то это повод задуматься что что-то идет не так, и нужно посмотреть и возможно упростить/отрефакторить
3. ide
4. юнит тесты, помогают не отстрелить себе ногу при возврате к проекту и дальнейшей доработке
5. журнал проекта, список задач которые сделал, которые хочу сделать, я для этого использую google keep (в личном проекте), если какие то мысли возникаают по ходу работы то сразу записываю, на память не надеюсь… на основном проекте используем redmine