Занимались ли вы разработкой технической документации?

А, ну да, конечно, я ж постоянно эту писанину техническую сочиняю, без неё никуда, блядь. Это ж как без инструкции к хуёвому шведскому шкафу — соберёшь криво, а потом вся конструкция жизни нахуй развалится.

Вот чем конкретно мозг выношу, оформляя мысли в текст:

1. Документация для этих ваших API. Тут, блядь, главный фокус — чтобы не пришлось каждому долбоёбу по десять раз одно и то же объяснять. Использую Swagger/OpenAPI, он сам почти всё генерирует, красота. Напишешь пару аннотаций в коде — и вот тебе, сука, готовый интерактивный справочник, где можно ткнуть кнопочку и посмотреть, что вернётся.

   @RestController
   @RequestMapping("/api/users")
   @Tag(name = "User Management", description = "APIs for managing users")
   public class UserController {
       @GetMapping("/{id}")
       @Operation(summary = "Retrieve a user by their unique ID")
       @ApiResponse(responseCode = "200", description = "User found")
       @ApiResponse(responseCode = "404", description = "User not found")
       public ResponseEntity<UserResponse> getUser(@Parameter(description = "ID of the user") @PathVariable Long id) {
           // ...
       }
   }

   Видишь? Написал @ApiResponse(responseCode = "404", description = "User not found") — и все сразу понимают, что если юзера нет, то будет не просто какая-то хуйня, а конкретно «не найден». Экономия времени — овердохуищная.

2. README.md — это, блядь, святое. Это как лицо проекта. Зашёл новый чел, открыл файлик — и должен сразу понять: а) что это за зверь такой, б) как его собрать, чтобы не вышло «ой, а у меня не компилится», в) как запустить, чтобы не взорвалось. Если там пусто или написано «ну тут всё понятно» — автор конченый мудак, простите за мой французский.

3. Записки про архитектурные решения (ADR). Это когда вся команда три дня спорила, какую хуйню использовать — Kafka или RabbitMQ, — и наконец пришли к консенсусу. А через полгода приходит новый тимлид и спрашивает: «А хули вы тут RabbitMQ впилили, он же для этого не годится?». И тут ты, такой весь из себя, достаёшь ADR и говоришь: «Читай, пизда, вот список причин, почему мы так сделали. Не нравится — иди нахуй со своими свежими идеями».

4. Инструкции для эксплуатации. Как эту бандуру задеплоить в Docker, как в Kubernetes запихнуть, как миграции базы данных через Liquibase прогнать. Это чтоб дежурный инженер в три часа ночи, с похмелья, не начинал гадать на кофейной гуще, а тупо следовал шагам и не угробил всё к ебеням.

А главный принцип у меня какой? Документация должна быть живой, ёб твою мать. Не пылиться в каком-нибудь «Confluence», который последний раз открывали при царе Горохе. Она должна быть короткой, по делу и реально помогать тем, кому нужна: новичкам, которые только в проект пришли, девопсам, которые всё это хозяйство разворачивают, или мне самому через полгода, когда я уже забуду, какую гениальную хуйню я тут написал. Всё остальное — словоблудие, нахуй не нужное.