В чем оцениваешь задачи?

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

На что я смотрю, когда мне суют какую-нибудь хрень на C++:

1. Что за алгоритмы и структуры данных?

   • Сразу смотрю на сложность. Если там O(n²) намешано, это уже повод задуматься, а не пиздопроебибна ли задача. Ну вот смотри: если просто std::unordered_map запилить — это одно, а если своё красно-чёрное дерево с нуля пилить — это уже совсем другой разговор, тут можно и на овердохуища времени угрохать. Э бошка думай сразу.

2. Память и ресурсы — это отдельная песня, ёпта.

   • Самый главный вопрос: будем париться с голыми new/delete или можно взять умные указатели и жить спокойно? Если нужно своё управление памятью, аллокаторы кастомные — это сразу плюс день к оценке, а то и два. Потому что отловить потом утечку — это тот ещё квест, волнение ебать просто.

3. С чем это всё едят и во что упрётся.

   • Зависимости от других библиотек? От легаси-кода, который писал какой-то пидарас шерстяной десять лет назад? Если да, то подозрение ебать чувствую сразу. Потому что интеграция — это всегда лотерея. Может, всё встанет как влитое, а может, придётся весь день вникать, какого хуя оно не линкуется.

4. Ошибки, исключения и прочая херня.

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

5. Тесты, отладка и прочие радости жизни.

   • Окей, код написан. А теперь его надо проверить. Написать юнит-тесты — это время. Отладить шаблонную хрень, где компилятор выдаёт ошибку на три экрана — это время и нервы. Запустить санитайзеры или вальгринд, чтобы найти какую-нибудь дичь — опять время. Это в оценку обязательно закладывать, иначе будет тебе хиросима и нигерсраки перед релизом.

Ну и пример, чтобы было совсем понятно, чувак.

• Задача: «Сделай потокобезопасный LRU-кэш с лимитом по размеру».
• Как я думаю:
  • Алгоритм: Ясно, надо std::unordered_map и std::list скрестить, чтобы get/put были за O(1). Идея стандартная, но детали — это пиздец.
  • Память: Ладно, std::unique_ptr в помощь, чтобы не париться с удалением. Главное — не накосячить.
  • Многопоточность: Вот тут самое интересное. Можно тупо std::mutex навесить на всё — просто, но медленно. А можно std::shared_mutex, чтобы читатели не мешали друг другу. А если lock-free захотеть — это вообще отдельная история, там можно с ума сойти. Сам от себя охуеешь, пока делаешь.
  • Интеграция: Ну, шаблонный класс сделать, чтобы для любого типа работало. Вроде мелочь, но тоже время.
  • Тестирование: Это, бля, обязательно. Штук 15 тестов на логику вытеснения старых записей. И парочку стресс-тестов, где 10 потоков одновременно долбят кэш — посмотреть, не развалится ли всё и не будет ли deadlock.
  • Итог: Ну, если без особых закидонов и lock-free, то дня 2-3. Это с учётом, чтобы не только написать, но и проверить, и оформить, и на ревью отдать. Меньше — нереально, если хочешь сделать нормально, а не через жопу.