Как мне убедить сверстника, что алгоритмы важны?

Question

Мой коллега работает над отчетом, который отображает еженедельный (с воскресенья по субботу) аванс каждого сотрудника в нашей небольшой консалтинговой фирме. Он написал фрагмент кода, который показывает столбцы, соответствующие дням целевой недели. Его алгоритм следующий:

1. Получите, какой день недели является первым днем ​​месяца. Если это воскресенье, установите флаг на ноль; в противном случае установите его на единицу.
2. Итерация по всем дням месяца. Если это воскресенье, увеличьте флаг. Затем, если значение флага равно отображаемой неделе, покажите столбец, соответствующий текущему дню; в противном случае скрыть столбец.

Конечно, флаг указывает текущую неделю.

Я предложил другой алгоритм:

1. Получите, какие дни месяца являются первыми (F) и последними (L) днями указанной недели. Например, первая неделя октября 2009 года начинается 1-го вторника и заканчивается 3-й субботы.
2. Перебирать столбцы, соответствующие дням с 1 по F-1, и скрывать их.
3. Перебирать столбцы, соответствующие дням F - L, и показывать их.
4. Перебирать столбцы, соответствующие дням от L + 1 до DaysOfMonth, и скрывать их.

«Трудная» часть в моем алгоритме - это часть 1. Я имею в виду «сложную», как в «трудной для понимания», потому что алгоритмическая сложность ее выполнения постоянна. И у моего алгоритма есть преимущество, заключающееся в том, что у него более плотный цикл Мой круг сверстников делает сравнение для каждого дня месяца. Мой нет.

Это был небольшой пример, и вы могли бы сказать, что чрезмерная оптимизация здесь слишком параноидальна. Но его стиль программирования не меняется, когда мы пишем действительно критичный к производительности код.

Его код также полон этих тестов:

/* doSomething() doesn't change the state of the relevant variables. */
if (condition)
{
    flag++;
    if (flag > test)
        doSomething();
}
else
    if (flag >= test)
        doSomething();

Когда, конечно, это можно сделать так:

if (flag >= test);
    doSomething();
if (condition)
    flag++;

Что мне делать?!?!?!

РЕДАКТИРОВАТЬ: я исправил сравнения в примерах кода.

Answer 1

Я думаю, у вашего друга правильная идея. Возьмите алгоритм, который, очевидно, верен алгоритму, объяснение которого заняло бы час, но без особой цели производительности - быстрее.

Если у вас есть конкретные требования к производительности, например, «код должен быть в состоянии дать правильные результаты для всех месяцев в течение следующих десяти лет в течение 200 микросекунд на компьютере X», и , более простой код не работает требование, то вы можете рассмотреть возможность использования вашей версии.

(Пример кода, который вы опубликовали, действительно лучше на вашем пути, потому что он менее запутанный.)

Answer 2

Из вашего описания я не уверен, что не согласен с вашим коллегой. Ключевой вопрос здесь заключается в том, является ли этот фрагмент кода узким местом производительности .

Чтобы убедить меня переключиться на ваш алгоритм, вам необходимо профилировать рассматриваемое приложение и показать мне, что этот фрагмент кода критичен по производительности. Затем внесите изменения и запишите их снова. Таким образом, у вас есть объективная основа для сравнения .

Если между двумя алгоритмами есть существенное различие, то вы оба можете обсудить, стоит ли переходить на другое.

Если вас беспокоит время загрузки страниц веб-приложения, помните уроки Высокопроизводительные веб-сайты и Рекомендации по производительности Yahoo - как вы обрабатываете CSS, javascript и Кэширование окажет гораздо большее влияние, чем оптимизация алгоритмов, работающих на вашем сервере.

Пропаганда оптимизации без измерения столь же опасна, как и игнорирование последствий для производительности наивных алгоритмов.

Answer 3

Ну, вы не должны вмешиваться, потому что, очевидно, вы ошибаетесь ... Два куска кода не эквивалентны. Просто возьмите условие = 1, флаг = 0 и тест = 1

Answer 4

G'day,

Я бы посоветовал вам отдать предпочтение алгоритмической простоте , которая работает в рамках ваших ограничений , а не умным, слишком сложным алгоритмам, которые не дают реального выигрыша. По моему опыту, такие хитроумные трюки, скорее всего, станут кошмаром для будущего технического обслуживания!

Эту идею лучше выразить следующей цитатой:

«Компетентный программист полностью осведомлен о строго ограниченном размере своего черепа; поэтому он подходит к задаче программирования в полной скромности и среди прочего избегает хитрых уловок, таких как чума». - Эдсгер Дейкстра в своей лекции ACM Тьюринга 1972 года " Смиренный программист "

Кстати, эта статья отлично читается! Наряду со многими другими его работами, которые доступны онлайн в E.W.Dijkstra Archive

НТН

ура

Answer 5

Это ваша задача или его? Если это его, пусть он это сделает. Я человек, который преуспевает в эффективности, на самом деле я очень расстраиваюсь, когда что-то кажется неэффективным и находится вне моего контроля.

В SO более 200 человек, которые могли бы посрамить мои самые «эффективные» идеи, алгоритмы и код. Вероятно, больше, вы не можете идти одним респом. Если бы сам Линус Торвальдс подписался, он начал бы с 1, как и все мы.

Что вам нужно учитывать, так это то, что люди должны иметь возможность поддерживать код, который они пишут. Это означает, что они должны понимать это так, как будто они это родили. Даже если бы кто-то продемонстрировал другой алгоритм, более эффективный, чем мой, я бы не стал использовать его, если бы мне не было удобно .

Если это совместный проект, напишите его по-своему, продемонстрируйте ускорение, а затем проведите очень, очень терпеливые часы со своим сверстником, чтобы помочь ему действительно понять его.

Оглядываясь назад на материал, который вы написали 5 лет назад, каждый должен учиться, выполняя , и все делают вещи со своей скоростью, особенно в процессе обучения.

Answer 6

Я согласен с преобладающим мнением здесь: если повышение производительности сделает код значительно более трудным для чтения, то должна быть веская причина для внесения этого изменения.

С другой стороны, это не значит, что мы должны всегда соглашаться на первое, что приходит на ум . Иногда есть однозначно превосходящие альтернативы, которые одинаково читабельны или почти одинаковы.

Если вы хотите убедить своего коллегу серьезно относиться к его выбору алгоритмов, вам следует тщательно выбирать битвы. Не пытайтесь перевернуть его мир с ног на голову и навязать проблему в каждом отдельном случае, который вы найдете. Начните с того, что делайте свои предложения только тогда, когда вы можете придумать алгоритм замены, который явно превосходен и также ясен, и будьте готовы отступить, если он сопротивляется.

Если вы чувствуете себя обманчивым, вы можете даже дать ему подсказки, задать наводящие вопросы или любую другую технику, о которой вы можете подумать, чтобы помочь ему самому разобраться в этом.

Answer 7

Я не вижу здесь проблемы ... хотя в его версии есть небольшой обходной путь к цели, он туда добирается.

Это утверждение, которое я собираюсь сказать, не должно быть вырвано из контекста: но всегда найдутся люди, которые делают это таким образом - и это не так, скорее наоборот ... он, возможно, не знает хороший способ сделать что-то, но он знает, как получить результат, независимо от того, насколько уродлив его метод.
Это может стать настоящим спасением, когда никто не знает правильный алгоритм для чего-то ... есть вероятность, что он все равно наклеит на пленку .

Answer 8

Я чувствую твою боль. Программисты действительно упрямы по своей природе. У каждого свои принципы и правила построения программ. Если другие мнения вступают в противоречие с некоторыми из них, то изменение мнения программиста похоже на перемещение фундаментальных основ здания небоскреба. :)