Вспомнить всё - разработка

Держи в курсе.

Если IDE не открывать, то вспоминать не нужно будет. А так - ССЗБ, надо было код хороший писать, а ты писал плохой.

Да код я писал по последним стандартам разработки, дело в том что теперь нужно вспомнить как это всё работает, приложение состоит из многих модулей-частей, теперь чтобы вспомнить что и как наверно нужно будет столько же времени..сколько я отсутствовал. К примеру когда ты долго работает ты уже знаешь с какой частью ты работаешь и что нужно, а теперь хз, нужно всё заного либо тестить либо «щупать» от А до Я…

Мне уже не так важен бюджет, как просто его закончить.

Постараюсь по возможности…ибо тут не угадаешь..

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

Пример с описанием:

https://github.com/unDEFER/details

Становись вайб кодером: установи агента, используй голосовой ввод, шепчи промпты в микрофон. IDE можно будет не открывать.

трассировщик или отладчик берешь и запускаешь код. флешбеки. профит?

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

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

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

Это нормально, с опытом будет легче вспоминать :)

тестить все по новой

Заодно тесты и деплой напиши.

Возвращение легенды! Жду теперь @hateyoufeel, @Iron_Bug, и @MOPKOBKA.

легенды

Тогда уж @kompospec и @metaprog

У меня всё еще страшнее. Я больше полугода не заглядывал.
И даже знаю, где есть косяки...

по последним стандартам разработки

Навайбкодил чтоль?)

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

Ой какая замечательная тема в «Похожих» всплыла (небольшая по тогдашним меркам, но Луговский и Саныч присутствуют).

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

Почему в скриптах install и uninstall нет ни одного комментария?

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

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

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

А так - ССЗБ, надо было код хороший писать, а ты писал плохой.

+1. Самый лучший показатель того, что код говно — это когда сам открываешь его спустя какое-то время, и тебе ничего не понятно. Точно так же снова и снова он будет непонятен любому, кто его прямо сейчас не помнит наизусть.

Да код я писал по последним стандартам разработки

А надо было писать хороший.

привет всем кто через полгода смотрел на свой многострочный регексп и а****ал…

Писал регэкспы всего несколько раз, и те были вида some text [0-9]+ some more text [0-9]+ text3 [0-9]+. А для всего сложнее есть Си.

А, ещё точки в grep тоже можно регэкспами считать и конструкции вида (word1|word2) - этих было больше, но они никуда не сохранялись.

Я иногда регексп перестаю понимать ещё на стадии написания :)

Ха-ха. Я для получения визы таланта недавно заброшенное 10 лет назад приложение открыл. Странно, всё знакомо. И даже на flutter стал переносить.

1. Регекспы не считаются.

2. Сразу вопрос: а чего это он многострочный??? Возможно, задача решается не совсем правильно.

можно кратко написать регексп, можно развернуто нахерачить экран-два функций…
результат будет один и тот же :)

это было давно и на перле

Чтобы такого не было, надо делать по архитектурам MVC там, DDD может. В MVC ты одним и те же модули делаешь для каждой фючи, а в DDD по доменам.

А если тебе лазером из космоса фигачит структуру на каждый проект, то там и черт ногу сломит.

Ну и че там? У школьников каникулы начались?)

Ну, перл известен своим принципом write-only

Думаешь тракторнуть?

Ну тут два варианта: или в дурку, или в условные Альпы.

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

Я обычно после отпуска git log / git diff просматриваю. Заодно можно посмотреть, что коллеги наделали с кодом. Ну и хорошая архитектура здесь помогает, когда еще тикет не дочитал, а уже знаешь какой модуль и класс надо поправить.

Я иногда регексп перестаю понимать ещё на стадии написания :)

«Дед, пей таблетки. А то получишь по жопе!»

З.Ы. в перле и питоне можно собрать длинный регексп из отдельных логически обособленных частей (строк). И уже потом откомпилировать

Так а в чем решение? Не понимать с самого начала? %)

В следующий раз в процессе написания не забывай про документацию, тесты и, особенно, интерфейсы

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

Да!

Чувааак! Ты вернулся) За этот год случился вайб-кодинг, тебе обязательно нужно его попробовать. Это решит все твои проблемы с разработкой. Ставишь codex cli покупаешь подписку и вперед. Если денех совсем нет, можно взять gemini cli, там вроде есть какой-то халявный лимит.

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

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

Это был концептуальный троллинг. На сверхстратегическом уровне. Концепции типа «кода» в данном случае - ничто за точкой невозврата в путешествию к центру чёрной, как империализм, дыры...

Код хороший, просто его много и не один модуль.

Дело в другом, вспомнить как всё это работает.

Вот по этому сижу перечитываю таски и попутно щупаю что и где.

Открываю IDE и смотрю с большим удивлением как будто вижу это всё впервые.

Я тебя помню, ты всегда так же смотрел.

Позвольте мне вставить свои 5 копеек.

1. Была постановка задачи или задание на разработку. Можно ее глянуть. 2. В процессе разработки надо писать документацию или хотя бы ее зачатки в виде to-do, известные баги. 3. Концептуально если придумывал ты то должен помнить. Если не ты то у него и спроси. 4. Правильно сказали. Запусти ИИ - пусть он напишет документацию или даст обзор по проекту. 5. Разбираться в чужем коде тяжело. А вот свой, если он логичен то можно. 6. Не бери в голову. Спроси задачи и методом научного тыка реши их. После и весь проект поймешь или вспомнишь.

Собственно важна еще модель разработки. Мне понравился совет использовать DDD. Я обычно так и делал не зная о ее существовании. Создавал макро объекты, а уже потом с ними проводил простые манипуляции. Все понятно и читаемо.

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

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

Да код я писал по последним стандартам разработки

А надо было писать так, чтобы быстро понимать что он делает.

Это как с вещами, их нужно убирать туда где в следующий раз будешь искать.

документация и комменты пишутся для себя.
теперь ты знаешь.

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

Так я и говорю, что не надо помнить.