PVS-Studio corporate blog
.NET
Visual Studio
C#
Development for Windows
Comments 10
+1
Только в переводе (или оригинале?) фраза звучит как “The best is the enemy of the good.”
+7
Хочется больше подобных статей от вас, а то шаблонные проверки разных проектов это полезно, конечно, но от них быстро устаешь. А тут прям история, от начала до конца, со всякими внутренними вещами.
Вот бы вообще парочку про реализацию отлова ошибок и пр.
+1

Вообще, почему не используется динамическая шедулизация?
Ну взяли просто и загрузили 32 потока. Что проверяем — мы знаем. Запускаем любой проект какой можем из очереди (не другая версия текущего и вот это вот все).

+1
Первая наша ошибка. На самом деле, вот тут уже можно было решить проблему раз и навсегда. Как? Было понятно, что ошибка вызвана новой оптимизацией. Ведь до неё все работало хорошо, да и переиспользованный код явно не может быть настолько плох. К тому же, эта оптимизация не принесла никакой выгоды. Так что же надо было сделать? Удалить эту оптимизацию.

Вот это не очень однозначный момент. Вы:


  • сделали потенциально полезную оптимизацию;
  • выявили явный баг в ПО.

Но вместо того чтобы найти и исправить баг в ПО, давайте просто удалим оптимизацию (читай удалим тесткейс, воспроизводящий баг). Как-то выглядит как совет закопать голову в песок, вместо решения проблемы.
И не надо только про "но столько ресурсов потрачено, нам надо х… ть фичи, а не баги править". Если аргумент в этом, то тогда я действительно, видимо, не понимаю "современную" разработку ПО.

0
Это называется прагматизм. Есть внутренняя утилита, используемая однообразным образом. Эта утилита никогда не выйдет в свет. Её не будут использовать сторонние пользователи в 100 разнообразных сценариях. Добавляется фича, которая всё ломает, но не приносит пользы. На тот момент неизвестно, ошибка в фиче или где-то ещё. Неважно. С прагматичной точки зрения, надо было просто откатить изменения и жить счастливо дальше. Если ошибка была в фиче, тем самым мы бы её исправили (нет фичи — нет проблемы :). Если ошибка в другом месте, то да, это маскировка проблемы. Но возможно, эта ошибка так и не проявила бы себя. А там, может, с нуля инструмент через N лет будет переписан (это уже пару раз происходило), когда потребуется тестировать больше чем сейчас.

Мы много рассказываем о качестве кода. Однако, всегда есть и другая сторона: полезность нововведений, правок и т.д. Программисты всегда всё стремятся сделать на века, даже когда это не нужно. Например, в прототипе, или внутренних скриптах, написанных для решения временной задачи. И это искусство научиться не только делать, но и не делать.
+1

Тогда к чему статья?
1) мы запилили фичу в внутреннем инструменте
2) мы нашли баг в данном инструменте с помощью этой фичи, а так же поняли что она сама по себе пользы не приносит
3) вместо того чтобы удалить фичу и замаскировать баг, мы приняли решение баг искать и фиксить
Вывод: не делайте как мы, удаляйте фичи, которые выявляют баги, но не приносят больше пользы.
P.S.: это прагматизм.


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


И вот это очень сомнительное такое… Тут же напрашивается статья с примером "мы запилили фичу, она бесполезная оказалось, но выявила баг. Мы его пофиксили, ПО стало лучше. Как же это хорошо что мы так сделали, всегда добивайтесь фикса багов, а не маскируйте проблемы".


Ну а если такой мысли нет, и я ошибаюсь, тогда сама статья не "лучшее — враг хорошего", а "как мы искали интересный баг в нашем внутреннем инструменте".

0
Думаю, решение найти баг было связано с надеждой найти «новый вид ошибки»
+1
Тогда к чему статья?

То есть как это «к чему»? PVS-Studio порекламировать, конечно же :)
А если серьезно — то, наверное, в данном случае не надо так серьезно. Просто развлекательная статья с небольшим описанием нашей внутренней кухни. Никакого особого менторства я туда не вкладывал.
Only those users with full accounts are able to leave comments. , please.