Комментарии 6
Блистательный текст, так же, как и предыдущий.
Не хватает рецепта, как же себя-то проверить: оптимист Даннинга-Крюгера ты предвзято дрожащий, или право имеешь?
А проверить несложно, на самом деле. Нужно просто начинать с «давай вместе поковыряемся» с коллегами, которые уткнулись в стену. Потом позвать коллегу, когда сам уткнулся в стену. А потом уже само получится и в сроках не ошибаться, и непосильное на себя не взваливать.
A можно ссылку на первую статью?
Можно даже на все три, написанные этим автором. Пожалуйста: https://habr.com/ru/users/GlacialExpert/articles/
При написании документации часто бывает искажение - кажется все таким очевидным, что не стоит и объяснять, а через полгода сам не понимаешь как работает и надо копаться в коде, зато это лучшее время для документирования, когда на себе осознаешь какие вопросы возникнут.
С тестированием с свои искажения - вот написал я сложный алгоритм, сделал несколько тестов, чтоб убедиться что все работает, но покрытие 10%. Теперь надо потратить недели на скучные тесты, чтобы проверить все возможные варианты. В идеале разбить задачу между сеньером и мидлом, чтоб мидл из просто алгоритма сделал завершенную задачу.
С готовыми решениями есть нюанс - большая часть таких либ не держит нагрузку. Увеличиваешь количество потоков и упирается в алокатор или синхронизации. Даже в популярных движках есть проблема с синхронизациями на GPU либо излиншие синхронизации CPU с GPU. Так что пришло время заменить старые решения на новые, более оптимизированные и лучше протестированные.
Психология разработки: как когнитивные искажения влияют на архитектурные решения и качество кода (часть 2)