Forwarded from C# Short Posts 🔞
🗄 Оперативное 1: shared_buffers — личный кэш Postgres
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
😂 Что это вообще
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.(Напомню, что даже на самых мощных SSD разница скорость чтения 10-20 микросекунд, тогда как из оперативки это 50-60 НАНОсекунд, то есть капец как дешево)
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце😰 : память заранее отведена под кэш и работает на тебя.
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
🟢 сама таблица заняла 47 MB
🟢 индекс по email — 39 MB
🟢 индекс первичного ключа — 21 MB.
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
В обзорном посте про оперативку постгресса мы насчитали трёх «едоков» памяти. Начнём с первого: shared_buffers. Разберёмся, что это такое и почему он всегда выглядит занятым.
Как многие знают, Postgres не бегает на диск в каждом запросе. У него есть свой кэш — кусок оперативки, куда он складывает страницы (напомню, что это кусочки по 8 Kb), которые недавно понадобились, чтобы в следующий раз взять их из памяти. Вот этот кэш и есть shared_buffers.
Слово shared («общий») тут ключевое: буферы общие для всех соединений. Один запрос читает страницу с диска и кладет в shared_buffers, а следующий возьмёт её уже из памяти и диск не тронет.
📏 Сколько его
Размер задаёт параметр shared_buffers, и фиксируется он при старте сервера. По умолчанию в Postgres это всего 128 MB — наследство времён, когда памяти было мало. На боевом сервере его обычно поднимают примерно до четверти всей оперативки. Текущее значение покажет команда SHOW shared_buffers;
⚙️ Почему он всегда «занят»
Эти 128 MB (или сколько ты выставил) Postgres резервирует под кэш сразу при запуске и держит за собой всё время работы. Поэтому в мониторинге shared_buffers всегда показывает себя занятой памятью. Это не утечка и не повод хвататься за сердце
🔬 Что внутри
Что именно сейчас лежит в shared_buffers, показывает расширение pg_buffercache (его надо один раз подключить командой CREATE EXTENSION pg_buffercache).
На прогретой таблице users из миллиона строк (прогретой — значит по ней уже погоняли запросы, и её страницы успели осесть в кэше) у меня вышло так:
Два индекса вместе съели больше кэша, чем данные! Это частый сюрприз: спрашиваешь «куда ушла память под базу», а ответ нередко оказывается простым — в индексы.
🅰️ Что унести с собой
🟢 shared_buffers — это собственный кэш Postgres в оперативке, общий для всех соединений.
🟢 Его размер фиксируется при старте: по умолчанию 128 MB, на проде обычно около четверти RAM.
🟢 Он всегда выглядит занятым, и это нормально: память заранее отведена под кэш.
🟢 Индексы живут в том же кэше, что и данные, и порой занимают даже больше места.
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2
Кажется, #ИИшница постепенно убирает естественные барьеры между работой и отдыхом 🚧
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики🟥 , кайфуешь. Пока ешь — не пишешь код. Чтобы программировать, нужно сесть за компьютер и сосредоточиться.
Теперь можно есть и одновременно смотреть, как Клавдий😒 пишет код. Иногда что-то ему подсказать, написать пару строк самому, дать следующее задание — и снова вернуться к обеду. Вроде бы отдыхаешь, но одновременно работаешь.
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения⚡️
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Раньше, если ты идешь обедать, то просто обедаешь, смотришь видосики
Теперь можно есть и одновременно смотреть, как Клавдий
Ещё появилась возможность упралять AI-агентом с телефона. Он выполняет задачи на твоём компьютере, пока ты находишься где угодно: на кухне, в постели, на скамейке в парке. В любой момент можно открыть телефон, дать новую команду, посмотреть результат, что-то поправить.
То же самое происходит и с другими паузами в течение дня. Раньше они были настоящими перерывами. Сейчас почти любой из них можно превратить в ещё несколько минут работы.
В результате появляется странный эффект😳
Кодить ты действительно начинаешь больше. Но полноценно отдыхать — меньше. Работа всегда находится на расстоянии одного сообщения. Даже сидя в кресле-коконе, ловишь себя на мысли, что думаешь не о том, как отвлечься и перезагрузиться, а о следующей задаче.
Не уверен, хорошо это или плохо. Наверняка правильный ответ, как обычно, "зависит". Возможно, мы просто учимся использовать время эффективнее.
Но есть ощущение, что эти «пустые» промежутки были нужны не просто так. Именно в них мозг успевал переключиться, а вместе с этим часто приходили новые идеи и решения
Похоже, теперь отдых тоже становится навыком, который надо уметь вовремя применить
Please open Telegram to view this post
VIEW IN TELEGRAM
Последние три дня был в Самаре, приехал по делам.
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
🔹
🔹 Ну и базовые методы вроде
Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома🏠
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений✨
Поймал себя на интересной мысли: каждый город можно представить как платформу. Если он реализует определённый интерфейс, то становится совместимым с моим образом жизни🥁🧑💻
Какие методы должны быть у такого интерфейса?
🔹
RehearsalBase() — должна быть репетиционная база, чтобы можно было подготовиться к выступлению.🔹
Workspace() — место, где можно спокойно поработать: удобный стол, стабильный интернет (Wi-Fi или хороший мобильный): коворкинг или просто удачный номер в отеле.🔹 Ну и базовые методы вроде
Sleep() и Eat(). Без них тоже никуда.Если все эти «эндпоинты» реализованы, то для меня город становится совместимым. Я могу жить в нём почти так же, как дома: работать, репетировать, отдыхать, не ломая привычный распорядок.
В прошлом году у меня было такое же ощущение в Батуми🇬🇪 Другой город, другая страна, но все нужные «ручки» оказались на месте. В итоге я продолжал работать в привычном режиме и почти не чувствовал, что нахожусь вдали от дома
Получается, что я не так сильно привязан к конкретному месту. Скорее, я привязан к интерфейсу. Если новый город его реализует, то моя жизнь и работа просто продолжают выполняться без изменений
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4🫡1
❤2
Декомпозировать всё 🧩
Это уже не столько про #поиск_работы, сколько в целом про полезный навык💪
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам🖥
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками📈
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом👣
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение✨
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной😱
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Это уже не столько про #поиск_работы, сколько в целом про полезный навык
Не знаю, как в других профессиях, но в разработке часто встречается понятие декомпозиции — разделения одной большой задачи на множество маленьких. Это про то, что можно съесть слона по кусочкам
В идеале, эти кусочки должны представлять собой инкремент (прирост) функциональности и измеряться какими-нибудь метриками
Когда я готовился к смене работы, этот подход помог мне подступиться к такой большое задаче и разделить её на несколько более простых и понятных:
🧩 написать резюме (инкремент: артефакт в виде резюме, метрика: наполненность ключевыми навыками)
🧩 регулярно откликаться на вакансии (инкремент: отклик, метрика: кол-во моих откликов и ответов на них)
🧩 последовательно освежать знания (инкремент: знания, метрика: насколько подробно и уверенно отвечаю на вопросы по теме: субъективно, но всё-таки измеримо)
Последний пункт тоже надо было декомпозировать: тем для повторения было много, поэтому я отсортировал их по уровню работы, от низкоуровневых (ОС, проц, память) до верхнеуровневых (архитектурные паттерны) и проходил одну за другой. Не пытался охватить всё сразу - просто двигался шаг за шагом
Точно так же, кстати, учу новые песни на барабанах🥁
Сначала разбираю основные ритмы, потом прорабатываю сложные места. Дальше размечаю структуру песни, и после этого собираю всё вместе. По сути, песня - это тоже набор небольших блоков: ритмы, сбивки, переходы, повторяющиеся паттерны. Когда каждый кусочек уже освоен, остаётся соединить их и отточить исполнение
Ещё декомпозиция зачастую является тем самым первым шагом, который надо сделать, чтобы подступиться к сложной задаче, после которой она уже не кажется такой большой и страшной
Иногда самый важный прогресс — это не сделать всю работу сразу, а правильно разделить её на части и составить план работы
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1🔥1
Forwarded from C# Short Posts 🔞
🗄Оперативное 2: Кэш ОС — ещё один уровень кэша, которым Postgres не управляет
Второй едок памяти из обзорного поста — кэш операционной системы. Именно с ним связана классическая паника «на сервере с базой вся оперативка занята, памагити, ААА!»😂
📚 Откуда он берётся
shared_buffers — это кэш самого Postgres. Но есть ещё один уровень кэша, который живёт своей жизнью. Когда любая программа читает файл с диска, операционная система запоминает прочитанные блоки в свободной оперативке. В следующий раз тот же файл прилетит уже из памяти, без похода на диск. Этот общесистемный кэш называется страничным кэшем (или же page cache) 📃
Postgres читает свои файлы — и кучу с данными, и файлы индексов — как все, через операционную систему. Значит, его страницы попадают ещё и в кэш ОС. Получается двойное кэширование: одна и та же страница может одновременно лежать и в shared_buffers, и в страничном кэше ОС📄
🍽 Почему «вся память занята»
Операционная система не любит, когда оперативка простаивает впустую, поэтому забивает всё свободное место кэшем файлов. На Linux, например, при помощи утилиты🧠 )
Пугаться этого не нужно. Память под кэшем ОС считается освобождаемой. То есть, правильно говорить не «память кончилась», а «сейчас память используется под кэш, но как только она понадобится другому приложению, система тут же готова уступить оперативку по первому требованию, чесслово💯 »
🔗 read ≠ чтение с диска
Напомню, что в посте про чтение страниц мы видели в плане запроса слово
🅰️ Что унести с собой
🟢 Кроме кэша Postgres есть кэш операционной системы: он общий для всей машины, и Postgres им не управляет
🟢 Одна страница может лежать сразу в двух кэшах — это и есть двойное кэширование
🟢 Когда вся память используется под файловый кэш — это нормально: такая память освобождается по первому требованию других приложений
🟢
🧑💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday
Второй едок памяти из обзорного поста — кэш операционной системы. Именно с ним связана классическая паника «на сервере с базой вся оперативка занята, памагити, ААА!»
📚 Откуда он берётся
shared_buffers — это кэш самого Postgres. Но есть ещё один уровень кэша, который живёт своей жизнью. Когда любая программа читает файл с диска, операционная система запоминает прочитанные блоки в свободной оперативке. В следующий раз тот же файл прилетит уже из памяти, без похода на диск. Этот общесистемный кэш называется страничным кэшем (или же page cache) 📃
Postgres читает свои файлы — и кучу с данными, и файлы индексов — как все, через операционную систему. Значит, его страницы попадают ещё и в кэш ОС. Получается двойное кэширование: одна и та же страница может одновременно лежать и в shared_buffers, и в страничном кэше ОС
🍽 Почему «вся память занята»
Операционная система не любит, когда оперативка простаивает впустую, поэтому забивает всё свободное место кэшем файлов. На Linux, например, при помощи утилиты
free (которая показывает, как используется ОЗУ и пространство подкачки (swap) в системе) зачастую можно увидеть, что свободной памяти почти не осталось, а здоровенный кусок помечен как buff/cache (если, конечно, в системе активно происходит чтение файлов Пугаться этого не нужно. Память под кэшем ОС считается освобождаемой. То есть, правильно говорить не «память кончилась», а «сейчас память используется под кэш, но как только она понадобится другому приложению, система тут же готова уступить оперативку по первому требованию, чесслово
🔗 read ≠ чтение с диска
Напомню, что в посте про чтение страниц мы видели в плане запроса слово
read — «страницы не было в shared_buffers, пришлось дочитывать». Там же мы выяснили, что read не обязательно означает поход на диск: страница вполне могла быть прочитана из кэша ОС. Поэтому read иногда оказывается почти таким же быстрым, как hit (чтение из shared_buffers, то есть, по сути, тоже из оперативки).🅰️ Что унести с собой
🟢 Кроме кэша Postgres есть кэш операционной системы: он общий для всей машины, и Postgres им не управляет
🟢 Одна страница может лежать сразу в двух кэшах — это и есть двойное кэширование
🟢 Когда вся память используется под файловый кэш — это нормально: такая память освобождается по первому требованию других приложений
🟢
read в плане запроса значит «не нашлось в shared_buffers», а не обязательно прочитано с диска»🧑💻dp🥁
#бд #postgresql #инженерныештучки #heavywednesday
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4
This media is not supported in your browser
VIEW IN TELEGRAM
Продолжаю нерегулярную рубрику лайфхаков для барабанщиков 🥁
Рассказываю важный и полезный лайфхак про барабанный стул🪑 , смотри до конца👆
Рассказываю важный и полезный лайфхак про барабанный стул
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4🔥1
#RocknMob в Москве состоится 22 августа!
Москва, Северный речной вокзал, 14:00
Сет-лист:
PINK FLOYD – Another Brick in the Wall
BLACK SABBATH – Paranoid
LINKIN PARK – The Emptiness Machine
БРАВО – Любите девушки
Для участия регистрируйся по ссылке:
https://rocknmob.com/rocknmob-moscow-12/
#движ
Москва, Северный речной вокзал, 14:00
Сет-лист:
PINK FLOYD – Another Brick in the Wall
BLACK SABBATH – Paranoid
LINKIN PARK – The Emptiness Machine
БРАВО – Любите девушки
Для участия регистрируйся по ссылке:
https://rocknmob.com/rocknmob-moscow-12/
#движ
🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3😱2❤1
Так выглядела моя "кухня" на выступлении с #хитпоинт, сейчас дома уже, делаю видосы 🎥
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
Многие жалуются на то, что #ИИшница не телепат и не делает сразу хорошо. Но не многие знают, что ей, как и любому новому разработчику в проекте, надо дать немного общего контекста и правил, которые не всегда можно понять непосредственно из кода. Да, какие-то вещи есть и в коде, но если твой ИИ-помощник будет перед каждой задачей полностью сканировать кодовую базу проекта, у тебя не останется доступных лимитов на непосредственное выполнение задачи🧠
Так что сделай для него хотя бы базовые инструкции, чтобы вы были "на одной волне" 🌊
Ещё я для себя выработал такую формулу:
Раньше я добавлял её ко всем запросам, а потом занёс в глобальные правила. Теперь мои ассистенты чуть меньше выдумывают, и чуть больше уточняют, что, во многом, экономит время на старте. Рекомендую к использованию👆
А так тут вот хорошо пишут о базовой подготовке проекта к работе с ИИ. Хоть и речь в основном про Claude😒 , но некоторые другие инструменты тоже по умолчанию ориентируются на эти файлы, или можно явно попросить об этом. В общем, тоже рекомендую👇
Так что сделай для него хотя бы базовые инструкции, чтобы вы были "на одной волне" 🌊
Ещё я для себя выработал такую формулу:
Не додумывай, перепроверяй, уточняй
Раньше я добавлял её ко всем запросам, а потом занёс в глобальные правила. Теперь мои ассистенты чуть меньше выдумывают, и чуть больше уточняют, что, во многом, экономит время на старте. Рекомендую к использованию👆
А так тут вот хорошо пишут о базовой подготовке проекта к работе с ИИ. Хоть и речь в основном про Claude
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from .NET Разработчик
День 2721. #ЗаметкиНаПолях #AI
Превращаем Claude из Автодополнителя в Коллегу. Начало
Claude не «плохо разбирается в .NET». Он слеп. Вы просите его «добавить конечную точку», а он уверенно:
- изобретает структуру папок, которая не соответствует вашему репозиторию;
- добавляет шаблоны, которые вы не используете;
- пропускает ваш рабочий процесс сборки/тестирования;
- нарушает соглашения и заставляет вас убирать за ним.
Это не проблема ИИ. Это проблема адаптации.
Решение — один файл, который становится системой оперирования вашим проектом для Claude:
В Claude Code файлы памяти, такие как
Что на самом деле делает CLAUDE.md
Представьте
- последовательно следовать вашим инструкциям,
- запоминать их между сессиями,
- перестанет каждый раз заново изобретать вашу архитектуру.
В документации Claude Code файл
И что важно: вам не нужно начинать с нуля. Claude Code поддерживает команду
Правило: ваш CLAUDE.md должен предотвращать дорогостоящие ошибки
Если
- неправильные шаблоны (репозитории, AutoMapper, случайные абстракции, которые вы не используете);
- неправильный рабочий процесс (изменения без плана, отсутствие тестов, отсутствие валидации);
- неправильные значения по умолчанию (тайм-ауты, отмена, повторные попытки, фоновая работа, время жизни DI).
Поэтому не пишите его как документацию. Пишите его как: ограничители + карта + команды.
Структура памяти Claude Code
Claude Code поддерживает небольшую иерархию файлов памяти, включая:
-
-
-
-
Это означает, что вы можете:
- держать краткий корневой файл
- поместить подробные правила в
- хранить ваши личные данные в
Минимально необходимый CLAUDE.md для бэкенда на .NET 10
Создайте
Этого достаточно, чтобы избежать 80% гаданий Claude.
Далее сделаем его жутко эффективным.
Окончание следует…
Источник: https://medium.com/codetodeploy/claude-md-for-net-10-turn-claude-from-autocomplete-into-a-teammate-5ae9d5ad0b92
Превращаем Claude из Автодополнителя в Коллегу. Начало
Claude не «плохо разбирается в .NET». Он слеп. Вы просите его «добавить конечную точку», а он уверенно:
- изобретает структуру папок, которая не соответствует вашему репозиторию;
- добавляет шаблоны, которые вы не используете;
- пропускает ваш рабочий процесс сборки/тестирования;
- нарушает соглашения и заставляет вас убирать за ним.
Это не проблема ИИ. Это проблема адаптации.
Решение — один файл, который становится системой оперирования вашим проектом для Claude:
CLAUDE.md.В Claude Code файлы памяти, такие как
./CLAUDE.md (и модульные правила в ./.claude/rules/*.md), автоматически загружаются в качестве контекста при запуске инструмента, поэтому Claude начинает каждую сессию с картой вашего проекта и правилами, вместо того чтобы гадать.Что на самом деле делает CLAUDE.md
Представьте
CLAUDE.md как вводные инструкции для нового старшего разработчика. Однако этот «разработчик» будет:- последовательно следовать вашим инструкциям,
- запоминать их между сессиями,
- перестанет каждый раз заново изобретать вашу архитектуру.
В документации Claude Code файл
CLAUDE.md описывается как файл конфигурации проекта, который находится в вашем репозитории и автоматически загружается в контекст.И что важно: вам не нужно начинать с нуля. Claude Code поддерживает команду
/init для генерации стартового файла CLAUDE.md путём сканирования вашего репозитория — затем вы его дорабатываете.Правило: ваш CLAUDE.md должен предотвращать дорогостоящие ошибки
Если
CLAUDE.md не предотвращает одну из следующих ошибок, он не выполняет свою работу:- неправильные шаблоны (репозитории, AutoMapper, случайные абстракции, которые вы не используете);
- неправильный рабочий процесс (изменения без плана, отсутствие тестов, отсутствие валидации);
- неправильные значения по умолчанию (тайм-ауты, отмена, повторные попытки, фоновая работа, время жизни DI).
Поэтому не пишите его как документацию. Пишите его как: ограничители + карта + команды.
Структура памяти Claude Code
Claude Code поддерживает небольшую иерархию файлов памяти, включая:
-
./CLAUDE.md для общей памяти проекта,-
./.claude/rules/*.md для модульных правил,-
~/.claude/CLAUDE.md для ваших личных глобальных настроек,-
./CLAUDE.local.md для ваших личных заметок по проекту (и он НЕ предназначен для того, чтобы его коммитили).Это означает, что вы можете:
- держать краткий корневой файл
CLAUDE.md,- поместить подробные правила в
.claude/rules/,- хранить ваши личные данные в
CLAUDE.local.md, не засоряя репозиторий.Минимально необходимый CLAUDE.md для бэкенда на .NET 10
Создайте
CLAUDE.md в корневом каталоге вашего репозитория:## What this repo is
- .NET 10 backend API focused on scalability, p95/p99 latency, and production reliability.
- Prefer simple, copy/pasteable patterns over "clever architecture".
## Tech stack --> Зависит от ваших условий
- .NET 10 / C# (modern style)
- ASP.NET Core (Minimal APIs)
- Dapper (NOT EF Core)
- Redis (IDistributedCache / StackExchange.Redis depending on project)
- Azure hosting (App Service / Containers)
- Observability: Application Insights (logs + metrics)
## Repo map --> Измените, чтоб соответствовало вашим папкам
- src/Api/ → endpoints, DI, middleware, startup
- src/App/ → use-cases/services (business orchestration)
- src/Infra/ → DB, Redis, HTTP clients, external integrations
- tests/ → unit + integration tests
## Hard rules (do not violate)
- NEVER add new framework layers or "Clean Architecture cosplay".
- NEVER introduce patterns we don't use (AutoMapper, repositories, magic abstractions).
- Always pass CancellationToken through all async calls.
- No sync-over-async (no .Result/.Wait).
- No Task.Run inside request handlers.
- Outbound HTTP MUST have timeouts + cancellation.
- Caching MUST have: time budget, stampede protection strategy, and key versioning.
## Default workflow
1) Ask for missing requirements before changing code.
2) Propose a plan + list files to touch.
3) Implement smallest change that works.
4) Add/update tests when relevant.
5) Provide commands to verify (build/test/run).
## Commands --> Измените на нужные вам
- Build: `dotnet build`
- Test: `dotnet test`
- Run API: `dotnet run --project src/Api`
- Format: `dotnet format`
## Output format
- Prefer short sections, small code blocks, and explain trade-offs.
- When making changes: show diff-level guidance + why.
Этого достаточно, чтобы избежать 80% гаданий Claude.
Далее сделаем его жутко эффективным.
Окончание следует…
Источник: https://medium.com/codetodeploy/claude-md-for-net-10-turn-claude-from-autocomplete-into-a-teammate-5ae9d5ad0b92