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

1. Тесты.

• Автоматические Unit-тесты.
• Автоматические End-to-end (когда функциональность приложения тестируется на конечном бинарнике) тесты.

2. Запрет коммита в master до тех пор, пока тесты не пройдут.

От потери в коде это не спасет, но от ошибок вследствие этой потерянности избавит.

TDD реально работает - можно в любой момент оставить и возобновить работы: позволяет быстро восстановить контекст, вспомнить детали. Фактически решает задачу как не забывать.

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

Понравился совет ведения журнала проекта - реально захватывающая вещь ))

документирование/комментирование узких мест

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

всякие примочки, чтобы снизить количество кода

Вот это вот самое зло.

Надо писать так, чтобы код читался как книга. А не экономить переменные и строчки какими-то примочками и хаками.

Был у нас любитель называть переменные a,b,c,d,e, где a - артефакт, b - build, c - collection, d - dist, а e - environment.

А слово test сокращал до tst.

Как вспомню так вздрогну.

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

Вот я взялся на досуге писать для себя одну полезную программу

ты уверен что это так нужно для пет проектов? )) я думаю если соблюдать основные принципы то сильно документировать свой личный код не стоит

подарите ему книгу Макконелла ))

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

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

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

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

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

В таких языках как Java использование IDE делает навигацию по коду, программирование и рефакторинг в 7000 удобнее. Для питона jetbrains ide тоже полезно. Про вим я мало знаю.

пишу в vim

не делил проект на отдельные файлы

Копать тут.

А чем это отличается от git log?

Вопрос открытый, да.

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

Поэтому надо самому себе слать патчи через pull-request, писать нормальные комментарии к этим pull-request-ам, ревьюить, требовать у себя сопроводительной документации, настраивать автотесты, и мерджить только после того как всё будет ок и согласно style guide.

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

самостоятельную разработку надо вести так же как разработку в команде

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

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

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

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

что-то наподобие обзорного файла архитектуры проекта?

Стараюсь использовать всякие примочки, чтобы снизить количество кода

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

Планирую сделать фичу, пишу задачу в журнал (на листок, в онлайн сервис, на лбу etc), возможно с пояснениями реализации… Реализовывать эту фичу я могу день, неделю, месяц… Куча коммитов типа xxx manager refactoring… db object fix… Ты уверен что лог гита сильно поможет быть в контексте задачи? А если я параллельно несколько фич пилю… А я еще хочу что то спланировать на будущее… Ну ты понял?

Реализовывать эту фичу я могу день, неделю, месяц…

И всё это время она у тебя без живёт гита?

А если я параллельно несколько фич пилю…

Для этого есть ветки.

А я еще хочу что то спланировать на будущее…

Есть issues, к которым привязываются соответствующие опять же ветки и PR.

В приницпе да, может быть какой-то текстовый документ, например Roadmap или docs/designs, или как-то ещё, в котором пишутся именно пространные заметки и планы по проекту.

Но такие документы и журнал - это разные вещи. В доках описываются планы, идеи и архитектура, в журнале - выполненные действия. Поэтому журнал - это git log.

И всё это время она у тебя без живёт гита?

в 2020 году кто-то без гит/свн/etc что-то делает разве? я даже упоминать это не стал, ибо дефолт

Для этого есть ветки. Есть issues, к которым привязываются соответствующие опять же ветки и PR.

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

под словом журнал проекта я подразумевал документ по менеджменту задач

Мне кажется это не я путаю инструменты.

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

А слово «журнал» вообще в этом контексте не используется.

разговор ни о чем, придираться к словам нет смысла, я в ответе ТСу описал что подразумевал под этим

Мне кажется это не я путаю инструменты. Для этого есть ветки. Есть issues, к которым привязываются соответствующие опять же ветки и PR.

ну да, ну да

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

улавливаешь разницу между «менеджмент задач» и «багтрекер»? ))

ну тебе ещё слово «обычно» надо расшифровать?

ну ты можешь обычно и в гит все делать )) я предпочитаю более удобные инструменты

Да, менеджмент задач в текстовом документе. Это я поняла.

ты фантазируешь ))

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

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

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

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

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

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

https://www.youtube.com/watch?v=qmFlCcXBIzo Пилите код пилите
https://www.youtube.com/watch?v=RlWv2qrUGI4 Пилите, код, пилите, он золотой!

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

благодарю - полезные подходы, особенно в плане целенаправленных мер чтобы быстрее всего вспомнить ситуацию, нюансы

Про arch, кстати упоминается в книге «Expert Python Programming» (раздел про документирование)