Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 79
Согласен, но не стоит, впрочем, всегда уповать не железо. Все равно программисты, умеющие заменить "for(x=0; x<1000000..." на что-то более красивое (решая тем самым задачу в духе олимпиад по программированию) цениться будут всегда!
ну в спортивном программировании оптимизировать лишний раз никто не будет, если проходит по входным данным, там тоже время программера стоит дороже машинного, в разумных пределах конечно +)
Насколько я знаю на большинстве олимпиад необходимо решить задачу, а не решить задачу так, что бы она работала как можно быстрее, хотя может есть и другие олимпиады :)
Как правило, на таких олимпиадах практически единственное решение задачи - наиболее оптимальное по скорости, т.к., насколько я помню, входные данные так подгоняют под выделяемые вычислительные мощности и выделенное время, что только самое быстрое решение и проходит.
Поправочка.
Вроде все правильно - и ограничения по времени есть, и по вычислительным мощностям.
Естественно решения должны укладываться в рамки, чтобы пройти в зачет.
Но выигрывает все же то решение, которое поступило на сервер раньше остальных.
Пусть даже остальные прошедшие в зачет работают в 2 раза быстрее.
Вроде все правильно - и ограничения по времени есть, и по вычислительным мощностям.
Естественно решения должны укладываться в рамки, чтобы пройти в зачет.
Но выигрывает все же то решение, которое поступило на сервер раньше остальных.
Пусть даже остальные прошедшие в зачет работают в 2 раза быстрее.
Code-monkey тоже нужны, да, но их и так предостаточно на рынке аутсорсинга.
Всё в конечном итоге упирается во время разработки. А время - деньги.
Пока одни мегапрограммеры будут вылизывать каждый бит, другие не побоятся расхода ресурсов, неизбежно возникающего при создании громоздкой но понятной структуры, и в более сжатые сроки напишут готовый продукт, который тут же начнут продавать. И это преимущество будет сказываться каждый раз, когда нужно будет исправить баг, добавить фичу или просто выпустить новую версию.
Это печально, но такова действительность.
Пока одни мегапрограммеры будут вылизывать каждый бит, другие не побоятся расхода ресурсов, неизбежно возникающего при создании громоздкой но понятной структуры, и в более сжатые сроки напишут готовый продукт, который тут же начнут продавать. И это преимущество будет сказываться каждый раз, когда нужно будет исправить баг, добавить фичу или просто выпустить новую версию.
Это печально, но такова действительность.
Код должен писаться понятным для человека = для компилятора. Современные компиляторы имеют оптимирующие алгоритмы, которые как раз улучшают производительность/объем человеку понятного кода. Иногда код написанный в лоб, работает быстрее чем тот что "оптимирован" человеком. Ключевые слова: кеш, скалярность, RISC CISC и многое другое чего человек ну никак в полном объеме учесть не может.
Нужно находить средину между оптимизацией и понятной структурой, золотая середина так сказать…
Тенденцию вы подчеркнули абсолютно правильно - смещение к оптимизации под программиста и процесс дальнейшей разработки. Но вот аргумент,
(цитата)2. При тех же финансовых ограничениях, мощность железа выросла настолько, что неоптимизированные алгоритмы на новом железе работаю быстрее оптимизированных на старом.
далеко не всегда верен в общем случае. Разница между оптимальным и неоптимальным алгоритмом может быть куда больше, чем преимущества нового железа. Простой, хотя и искусственный пример: если вам надо отсортировать грандиозный массив данных, сортировка пузырьком вместо qsort - это дни расчётов вместо минут. Никакое железо тут не поможет.
Очень жаль, когда программист, написав как получится несколько раз, привыкает (или, никогда и не пробует по-другому). И вот наступает момент, когда железо уже не поможет, а у программиста получается тормознутая программа-монстр.
Между тем, ведь даже когда это совсем не нужно, приятно потратить лишних 10 минут и сделать оптимальней. Приятно себе сказать "я написал красиво". Потренироваться заодно, когда-нибудь пригодится. Да, честно говоря, хотя и приходится иногда писать кое-как (дедлайны, а часто и действительно оптимизация слишком долго займёт), просто стыдно как-то. Даже если заказчик никогда и не узнает и никто не заметит.
Я к тому, что "напишем попростому - железо потянет" ни в коем случае не должно возводится в принцип.
(цитата)2. При тех же финансовых ограничениях, мощность железа выросла настолько, что неоптимизированные алгоритмы на новом железе работаю быстрее оптимизированных на старом.
далеко не всегда верен в общем случае. Разница между оптимальным и неоптимальным алгоритмом может быть куда больше, чем преимущества нового железа. Простой, хотя и искусственный пример: если вам надо отсортировать грандиозный массив данных, сортировка пузырьком вместо qsort - это дни расчётов вместо минут. Никакое железо тут не поможет.
Очень жаль, когда программист, написав как получится несколько раз, привыкает (или, никогда и не пробует по-другому). И вот наступает момент, когда железо уже не поможет, а у программиста получается тормознутая программа-монстр.
Между тем, ведь даже когда это совсем не нужно, приятно потратить лишних 10 минут и сделать оптимальней. Приятно себе сказать "я написал красиво". Потренироваться заодно, когда-нибудь пригодится. Да, честно говоря, хотя и приходится иногда писать кое-как (дедлайны, а часто и действительно оптимизация слишком долго займёт), просто стыдно как-то. Даже если заказчик никогда и не узнает и никто не заметит.
Я к тому, что "напишем попростому - железо потянет" ни в коем случае не должно возводится в принцип.
Я меня паранойя или в статье действительно слишком часто употребляется слово "показатель"? :)
Как здесь уже было сказано, нужно всегда находить "золотою середину". Конечно, код нужно оптимизировать, но не надо проводить за оптимизацией больше времени чем за написанием нового кода, особенно когда эта самая оптимизация заключается, к примеру, в уменьшении пары итераций в цикле.
На самом деле, все приходит с опытом. В то время когда я только начинал програмить коммерческие проекты, я писал "абы работало", теперь же, перед тем как написать что-то я сто раз подумаю как бы сделать так, что бы уменьшить кол-во запросов к базе/к серверу, как бы получше спроектировать базу так, что бы не приходилось создавать болшое кол-во записей/полей, ну и все в таком духе.
Как здесь уже было сказано, нужно всегда находить "золотою середину". Конечно, код нужно оптимизировать, но не надо проводить за оптимизацией больше времени чем за написанием нового кода, особенно когда эта самая оптимизация заключается, к примеру, в уменьшении пары итераций в цикле.
На самом деле, все приходит с опытом. В то время когда я только начинал програмить коммерческие проекты, я писал "абы работало", теперь же, перед тем как написать что-то я сто раз подумаю как бы сделать так, что бы уменьшить кол-во запросов к базе/к серверу, как бы получше спроектировать базу так, что бы не приходилось создавать болшое кол-во записей/полей, ну и все в таком духе.
Вот только объясните мне, почему же Oracle в своей СУБД бьется над быстродействием, Adobe в своем Photoshop бьется над быстродействием, куча народа в разных фирмах пытается сделать более быстрый декодер H.264, Microsoft бьтеся над быстродействием вплоть до того, что ускоряет банальный казалось бы mutex в ядре, а Google пишет для себя новый аллокатор памяти?
Да, бывает и так, как Вы пишите - но не всегда.
Как Вы считаете, почему Oracle в своей СУБД бьется над быстродействием, Adobe в своем Photoshop бьется над быстродействием, куча народа в разных фирмах пытается сделать более быстрый декодер H.264, Microsoft бьется над быстродействием вплоть до того, что ускоряет банальный казалось бы mutex в ядре Windows, Google пишет для себя новый аллокатор памяти, а IBM оптимизирует вычисление БПФ таким образом, чтобы оно лучше использовало процессорный кэш. Они все сошли с ума и не понимают, что прогресс железа делает ненужной оптимизацию?
Oracle, Adobe, MS, IBM и прочие монстры индустрии умеют считать деньги. И если они занимаются оптимизацией на всех уровнях, то значит это экономически оправдано и востребовано. Список областей, где оптимизация имеет значение, меняется со временем, но потребность в оптимальном коде существовала всегда, и она будет существовать еще долгое время.
Да, где-то пофик, сколько времени выполняется код. А в другом месте оптимизация этого кода позволяет одному серверу обслужить 300 каналов вместо 100 и в 3 раза снижает затраты на закупку железа и total cost of ownership. Или вместо 100000 транзакций мы на той же машине получаем 150000 транзакций, и вместо 6 мэйнфреймов ценой в 10M$ каждый покупаем 4 штуки. Ну конечно по чьим-то меркам 20M$ не деньги. :)
Да, бывает и так, как Вы пишите - но не всегда.
Как Вы считаете, почему Oracle в своей СУБД бьется над быстродействием, Adobe в своем Photoshop бьется над быстродействием, куча народа в разных фирмах пытается сделать более быстрый декодер H.264, Microsoft бьется над быстродействием вплоть до того, что ускоряет банальный казалось бы mutex в ядре Windows, Google пишет для себя новый аллокатор памяти, а IBM оптимизирует вычисление БПФ таким образом, чтобы оно лучше использовало процессорный кэш. Они все сошли с ума и не понимают, что прогресс железа делает ненужной оптимизацию?
Oracle, Adobe, MS, IBM и прочие монстры индустрии умеют считать деньги. И если они занимаются оптимизацией на всех уровнях, то значит это экономически оправдано и востребовано. Список областей, где оптимизация имеет значение, меняется со временем, но потребность в оптимальном коде существовала всегда, и она будет существовать еще долгое время.
Да, где-то пофик, сколько времени выполняется код. А в другом месте оптимизация этого кода позволяет одному серверу обслужить 300 каналов вместо 100 и в 3 раза снижает затраты на закупку железа и total cost of ownership. Или вместо 100000 транзакций мы на той же машине получаем 150000 транзакций, и вместо 6 мэйнфреймов ценой в 10M$ каждый покупаем 4 штуки. Ну конечно по чьим-то меркам 20M$ не деньги. :)
У меня глюкнул copy-paste но смысл возражения понятен, я думаю.
А это очень просто объясняется. Photoshop очень большая система, там используется очень много алгоритмов(для фильтров например), которые жрут немерено памяти и проц. времени, и конечно в такой системе даже мелкая оптимизация будет существенно ускорять работу приложения. Про гугл вообще без коментов, их системы рассчитаны на миллионы пользователей, кончено при такой нагрузке необходима оптимизация. Точно так же и со всеми остальными приведенными Вами примерами. Все они очень прожорливы(в следствии большого кол-ва запросов или априори как, например, декодер) и оптимизация им необходима. Просто смотря чего хотите Вы или Ваш заказчик, или еще кто-то там. Если проект рассчитан на большое кол-во юзеров, то все его части надо тщательно оптимизировать, если нужно сделать относительно простенький проект за небольшое время, то оптимизировать надо только "узкие" места, а остальные — просто грамотно писать, тогда и оптимизация не потребуется
Собственно я об этом и говорю - для больших проектов оптимизация все так же востребована, как и в старые добрые. Не всегда низкоуровневая (акценты смещаются со временем) - но бывает и такая.
И кстати, не стоит сравнивать такого гиганта как Гугл, который может себе позволить тратить время своих прогеров на оптимизацию, и простого прогера(команду прогеров), которым нужно сдать проект в определенные сроки. Повторюсь, если грамотно писать код, то проводить часы за оптимизацей просто не понадобится, если, конечно, Вы не пишете систему рассчитанную на сотни юзеров
А какой интерес работать там, где не пишут систему, рассчитанную на миллионы юзеров? :)
Ну например фриланс :) Тут вроде бы интересно :)
Без обид - но понятно же, что в серьезном проекте фрилансеру закажут только такую рутину, которую самим писать лень или жалко расходовать на нее время более квалифицированных программистов, работающих штатно. Во-первых, отношения с фрилансером непостоянные и поэтому нельзя заказывать у него критически важные части кода. Этот код в любой момент может остаться без поддержки или же фрилансер просто сорвет сроки непредсказуемым образом. Плюс возможна утечка ценных знаний к конкурентам. Поэтому важные части системы никто не будет отдавать на сторону. Во-вторых, в сложных проектах нужно время на включение человека в команду, а в случае найма фрилансера этого времени нет. Он вообще работает один, вне команды. Поэтому фрилансерам спихивают в 99% случаев рутину, где нужны погонные метры кода или же нанимают их на стадии прототипа - это уже интересней, но понятно, что на стадии прототипа оптимизация не нужна, а в будущем (если проект пойдет) весь этот код выкинут. Поэтому я не понимаю - в чем прикол именно для hardcore-программиста работать фрилансером? Не в теории, а учитывая специфику заказов, которые он сможет получить. Разве что, если нужно набраться опыта...
Без обид :). Возможно, вы абсолютно правы. Но ведь фрилансеры бывают разные :). И заказчики тоже. Вот, например, тот заказчик с которым мы(я работаю в команде из 3-х таких же фрилансеров) сейчас работаем заказал нам просто огромный проект, очень сложный и очень интересный. Так что при желании, связях и умении на фрилансе можно получать только интересные заказы, а вот в какой-нибудь аутсорсинговой компании над чем сказали работать, над тем и приходится работать — не интересно.
Вы уж простите, но это чушь собачья. Фрилансеры бывают очень разные, равно как бывают очень разные заказчики и заказы.
К сожалению, не видел выше ответ 
znvPredatoR
znvPredatoR1. Как я ненавижу эти фантазии про фрилансеров, якобы не работающих “на дядю”. А на кого же они работают? На тетю? Не работает на дядю Стив Джобс или Билл Гейтс. Они работают на себя - потому, что они сами придумывают задачи, которыми будут заниматься. При этом даже они вынуждены каждодневно считаться с интересами своих инвесторов, и они зависят от потребителей - от простых юзеров, которым нужно угодить с новым товаром, чтобы в следующем квартале были хорошие показатели. Начинающий предприниматель со своей компанией тоже может претендовать на то, что он не работает “на дядю”. Но никак не фрилансер - которого именно “дядя” нанимает за деньги.
2. Фрилансер может выбирать, какой проект ему делать? Да, согласен. Если у него есть на что жить, то он может выбирать из имеющихся предложений (если их несколько) и если его не опередит другой фрилансер (который попросит меньше денег или пообещает меньшие сроки заказчику).
3. Программист, работающий по постоянному контракту, тоже имеет свободу выбора - во-первых, он ведь не случайно работает именно в этой фирме, а не в другой - он уже как-то ее выбрал, когда искал работу. Во-вторых, если ему не нравится, он может уйти в другую компанию.
4. Поспорьте содержательно с тезисом о том, что фрилансеру не поручат ни одну критическую часть системы, потому, что есть очень высокий риск остаться в будущем без поддержки, нет возможности контролировать ход выполнения работ, нельзя сообщать стороннему человеку секретную информацию, нельзя мгновенно включить человека в работу в крупном проекте, где все части связаны друг с другом, не “инвестировав” в него несколько месяцев (и зарплат), и еще потому, что сложные проекты делаются командой, а фрилансер по определению стоит вне команды компании.
5. Возвращаясь к основной теме - фрилансер может делать прототип, это да. Но понятно, что в прототипе оптимизация действительно не критична. Есть смысл его оптимизировать разве что в том случае, если фрилансер хочет таким образом зарекомендовать себя, чтобы его взяли в штатные программисты фирмы. :)
6. Есть уникальные ситуации штучные, когда кто-то закажет фрилансеру действительно сложную инженерную разработку с мощной алгоритмической начинкой. Но сколько таких предложений?
2. Фрилансер может выбирать, какой проект ему делать? Да, согласен. Если у него есть на что жить, то он может выбирать из имеющихся предложений (если их несколько) и если его не опередит другой фрилансер (который попросит меньше денег или пообещает меньшие сроки заказчику).
3. Программист, работающий по постоянному контракту, тоже имеет свободу выбора - во-первых, он ведь не случайно работает именно в этой фирме, а не в другой - он уже как-то ее выбрал, когда искал работу. Во-вторых, если ему не нравится, он может уйти в другую компанию.
4. Поспорьте содержательно с тезисом о том, что фрилансеру не поручат ни одну критическую часть системы, потому, что есть очень высокий риск остаться в будущем без поддержки, нет возможности контролировать ход выполнения работ, нельзя сообщать стороннему человеку секретную информацию, нельзя мгновенно включить человека в работу в крупном проекте, где все части связаны друг с другом, не “инвестировав” в него несколько месяцев (и зарплат), и еще потому, что сложные проекты делаются командой, а фрилансер по определению стоит вне команды компании.
5. Возвращаясь к основной теме - фрилансер может делать прототип, это да. Но понятно, что в прототипе оптимизация действительно не критична. Есть смысл его оптимизировать разве что в том случае, если фрилансер хочет таким образом зарекомендовать себя, чтобы его взяли в штатные программисты фирмы. :)
6. Есть уникальные ситуации штучные, когда кто-то закажет фрилансеру действительно сложную инженерную разработку с мощной алгоритмической начинкой. Но сколько таких предложений?
Честно говоря, я не вижу смысла Вас переубеждать, если Вам нравится верить в то, что Вы пишете. В этом случае можем эту дискуссию свернуть. Если же Вы готовы "узнать правду" (с) :) то я могу ответить по пунктам:
- Чтобы у Вас появились деньги — их Вам должен кто-то дать. Понятно, что если он даёт Вам деньги не за красивые глаза, а за работу — Вы должны с ним считаться. И кто он — начальник, заказчик или инвестор — значения не имеет. Тем не менее, на разных ролях (уборщик, программист, тимлидер, менеджер, директор, фрилансер, etc.) у Вас разные возможности и разные свободы.
- Насчёт денег — правда. Поэтому я всегда стараюсь оставлять финансовый буфер — чтобы я мог два-три месяца побездельничать если нет рабочего настроения или интересного проекта. В крайнем случае, если Вы сильный программист освоивший кунг-фу "Get Things Done" — можно на этот период занять денег, т.к. начав работать Вы их без проблем отработаете. Насчёт "опередит другой фрилансер" — это чушь. Клиенты, которые ведутся на быстро/дёшево мне самому не нужны, с ними проблем больше чем пользы. Я предпочитаю работать с теми, кто уже на быстро/дёшево обжёгся, и предпочитает получать качественный продукт за адекватные деньги и сроки. Да, таких клиентов значительно меньше... но ведь и сильных программистов тоже значительно меньше чем студентов "быстро/дёшево". Так что система вполне сбалансирована.
- Выбор фирмы сильно отличается от выбора проекта и клиента. Очень сильно. Для людей, которым важно что и как они делают — большая удача и редкость найти фирму, в которой эта их потребность не будет конфликтовать с требованиями фирмы. Обычно такую фирму найти не удаётся, и приходится либо уходить в фриланс, либо делать что и как скажут в фирме.
- Ясен пень, если фирма делает большой проект, не справляется своими силами, и подключает незнакомых фрилансеров — им не дадут делать ключевые части проекта. С другой стороны, если заказчик изначально поручает большой проект фрилансеру — он делает в этом проекте в том числе и ключевые части. :) Только не надо рассказывать, что такого не бывает — я сам таким проектом занимаюсь уже много лет.
- Фрилансер может делать что угодно, не только прототипы. А с помощью ненужной оптимизации себя можно зарекомендовать исключительно отрицательно. Лучше писать простой и понятный код, с тестами и документацией, который работает эффективно, безглючно и не содержит дыр в безопасности — это будет значительно лучшей рекомендацией, чем преждевременная оптимизация (которая корень всех зол :)).
- А сколько Вам надо? Мне вот одного такого хватило уже на шесть лет, и не знаю насколько ещё хватит... Просто если Вы будете соревноваться со студентами на рынке быстро/дёшево — Вы не будете видеть нормальные проекты и будете считать что их нет в природе.
- Свобода понятие очень многогранное. Не будем сейчас говорить о свободе как высшей ценности, поговорим о более приземленных понятиях. Для людей, вынужденных работать за деньги (не важно, в офисе или дома) та свобода, о которой Вы говорите, является элементарным следствием дохода. По-моему очевидно, что как правило человек, работающий на постоянном контракте, имеет более стабильный доход и больше уверен в своем будущем. Начнем хотя бы с того, что ему скорее дадут в банке большой кредит на покупку квартиры на хороших условиях. Бывают и исключения, например, адвокат или дантист. Но я вижу очень много табличек с именами адвокатов и дантистов в дорогих резиденциях, и как-то не замечаю, чтобы там висели таблички фрилансеров-программистов.
- Что же, поздравляю - Вы нашли такую область, где есть хорошие клиенты с интересными заказами и нет жесткой конкуренции. Но и я тоже не абстрактно пишу свои слова. Я видел и вижу ситуацию со стороны компании, которая нанимает фрилансеров и критерий отдачи им работы - рутинность и не критичность для проекта в целом, готовность к взаимозаменяемости исполнителей по этой работе, быстрое получение прототипа, пусть и в ущерб качеству.
- Да, согласен. Хорошую работу я обычно искал полгода.
- Ваш случай исключение из правила. Просто поставьте себя мысленно на место заказчика. Вы бы сами стали завязывать успех собственного предприятия на отношения с человеком, которого Вы не контролируете вообще никак? Конечно, и штатный программист может уйти из компании и для стартапа это может обернуться чем угодно, вплоть до полного краха. Но все-таки, когда Вы видите человека каждый день у себя в офисе, общаетесь с ним, когда он имеет опционы компании, когда он получает хорошую зарплату - Ваше доверие и Ваша уверенность намного выше. Будете с этим спорить?
- Согласен.
- А если, не дай Бог, с ним что-то случится - я имею в виду не несчастье, а, например, банкротство его компании, закрытие конкретного отдела или проекта в ней, или резкая перемена направления деятельности. Вы видите потенциальные альтернативы?
1. Вы как-то очень вольно перескакиваете с темы на тему. В этом пункте изначально речь шла о том, что такое работа "на дядю", и чем фриланс от неё отличается. Вы заявили что ничем, я не согласился, и сказал что отличаются "свободы". Например, в офисе сложно отказаться делать конкретный проект или делать его за конкретные ресурсы или работать с конкретным заказчиком — и ничего при этом не потерять. А во фрилансе это — норма. С другой стороны в офисе другие свободы — например можно не искать проекты, не общаться с клиентом, не думать будет ли зарплата в этом месяце, etc. а просто сидеть и программировать. А теперь Вы перескочили на то, что адвокаты зарабатывают больше программистов. Ну да, это факт. И что с того? Я программированием занимаюсь не для того, чтобы зарабатывать больше адвокатов, а потому, что мне это нравится. Фактически, я вообще не работаю, а делаю что хочу, занимаюсь хобби, развлекаюсь... а мне за это ещё и платят, причём мне хватает того, что платят. Честно говоря, я адвокатским гонорарам не завидую абсолютно!
2. Да, описанная Вами область работ для фрилансеров существует, не спорю. Но она не единственная, вот в чём фокус. Мир большой, интернет тоже большой... есть самые разные и проекты, и заказчики, и фрилансеры. Самые разные.
4. Спорить не буду. Риски есть, и они выше. Но и стоимость работ, даже с учётом моей почасовки, всё-равно ниже, чем было бы в фирме. А качество, я уверен, выше. Кроме того я не один — проект большой, пришлось подключать знакомых фрилансеров, так что работает целая группа. И с клиентом лично общались, так что он знает нас в лицо и уверен что это не виртуалы неизвестные. В общем, риски хоть и выше, но не настолько чтобы это было действительно критично.
6. Опыт показывает, что работа ищет меня, а не я её. Если что-то случится с этим проектом — появится другая работа, не менее сложная и интересная. И, боюсь, раньше, чем я успею отдохнуть от этого проекта. В самом крайнем случае засвечусь на фрилансерских аукционах, сделаю пару простых проектов чтобы развлечься... а за это время меня найдёт следующий интересный проект. :)
2. Да, описанная Вами область работ для фрилансеров существует, не спорю. Но она не единственная, вот в чём фокус. Мир большой, интернет тоже большой... есть самые разные и проекты, и заказчики, и фрилансеры. Самые разные.
4. Спорить не буду. Риски есть, и они выше. Но и стоимость работ, даже с учётом моей почасовки, всё-равно ниже, чем было бы в фирме. А качество, я уверен, выше. Кроме того я не один — проект большой, пришлось подключать знакомых фрилансеров, так что работает целая группа. И с клиентом лично общались, так что он знает нас в лицо и уверен что это не виртуалы неизвестные. В общем, риски хоть и выше, но не настолько чтобы это было действительно критично.
6. Опыт показывает, что работа ищет меня, а не я её. Если что-то случится с этим проектом — появится другая работа, не менее сложная и интересная. И, боюсь, раньше, чем я успею отдохнуть от этого проекта. В самом крайнем случае засвечусь на фрилансерских аукционах, сделаю пару простых проектов чтобы развлечься... а за это время меня найдёт следующий интересный проект. :)
Просто пытаюсь показать, что нет принципиальной разницы между штатным программистом и фрилансером в степени свободы. Разница в деталях. И тот и другой зависят от денег, которые им платит "дядя". Вы сами демонстрируете, что каждый из вариантов имеет свои плюсы и минусы. Объединяет их одно - зависимость от денег работодателя (нужных для жизни), и поэтому отсутствие полной свободы в творчестве. Да, фрилансер имеет большую гибкость в выборе проектов. Но он сам их не придумывает, он выбирает из имеющихся - к тому же, его самого должны выбрать с той стороны.
Адвокатов я упоминаю как редкий пример исключения - людей, имеющих стабильно высокий доход и не боящихся его потерять, не смотря на то, что многие из них работают как фрилансеры (а не в компаниях).
Адвокатов я упоминаю как редкий пример исключения - людей, имеющих стабильно высокий доход и не боящихся его потерять, не смотря на то, что многие из них работают как фрилансеры (а не в компаниях).
Да, и ещё. По поводу "исключений из правила". Да, мой случай "исключение", наверное можно так сказать. Вообще хорошие клиенты это "исключение". И хорошие проекты... И даже хорошие программисты (я имею в виду реально сильных профи) — тоже исключение. Тот же Спольски, да и не только он, пишет, что найти сильного профи без работы, типа на фрилансерском аукционе — редкое везение.
Тем не менее, всё это существует. И если для кого-то это "исключение", то для кого-то другого это "норма". И Вы сами выбираете, в каком мире Вы живёте. Если Вам нравится жить в мире, где хороший проект/заказчик — исключение, с которым Вы, скорее всего, никогда не столкнётесь — Вы и не столкнётесь... но это был Ваш выбор. Я живу в другом мире, где это — норма, а исключения — это делать проекты быстро/дёшево в условиях сильной конкуренции с новичками/студентами. Понимаете, ведь хорошие проекты и заказчики реально существуют, и кто-то с ними работает... так почему не Вы?
P.S. Да, это эзотерика, магия, самовнушение... называйте как хотите, какая разница, как называть, если это работает! Я это называю — жизнь. :)
Тем не менее, всё это существует. И если для кого-то это "исключение", то для кого-то другого это "норма". И Вы сами выбираете, в каком мире Вы живёте. Если Вам нравится жить в мире, где хороший проект/заказчик — исключение, с которым Вы, скорее всего, никогда не столкнётесь — Вы и не столкнётесь... но это был Ваш выбор. Я живу в другом мире, где это — норма, а исключения — это делать проекты быстро/дёшево в условиях сильной конкуренции с новичками/студентами. Понимаете, ведь хорошие проекты и заказчики реально существуют, и кто-то с ними работает... так почему не Вы?
P.S. Да, это эзотерика, магия, самовнушение... называйте как хотите, какая разница, как называть, если это работает! Я это называю — жизнь. :)
Да, хорошие проекты, программисты, компании - исключение. Вам нравится работать с профессионалами? Если найти хорошую компанию (да, это очень-очень сложно) Вы попадаете в коллектив, с которым приятно иметь дело. Если компания маленькая (стартап или какая-то технологическая ниша) Вас не будут бросать из проекта в проект, не связанные друг с другом. И Вы сможете получить все бонусы от коллективной работы вместе над общими проблемами, причем не только по принципу дележа относительно независимых кусков работы. И общение.
Так что найти интересную работу можно не только через фрилансерство. Поэтому меня и раздражают эти модные в России сейчас байки про работу "на себя" в противовес работе "на дядю".
В любом нормальном стартапе нормальные люди работают в каком-то смысле именно что на себя, во вторую очередь (в силу эгоизма человека - все-таки во вторую) - ради общего дела, реализации идеи. И только в третью - "на дядю". Когда третья тема выходит на первый план - компанию пора закрывать.
Так что найти интересную работу можно не только через фрилансерство. Поэтому меня и раздражают эти модные в России сейчас байки про работу "на себя" в противовес работе "на дядю".
В любом нормальном стартапе нормальные люди работают в каком-то смысле именно что на себя, во вторую очередь (в силу эгоизма человека - все-таки во вторую) - ради общего дела, реализации идеи. И только в третью - "на дядю". Когда третья тема выходит на первый план - компанию пора закрывать.
А вы прочтите пост еще раз ;) Хотя это вовсе не обязательно — я занимаюсь разработкой прибора, программная часть стоит на "простом компьютере", с этим прибором одновременно работает один оператор и возможно наблюдают еще несколько. Если надо будет второго юзера — поставим еще один прибор :) если конечно заплатят денег. Вот весь интерес...
Я смайлик в конце не зря поставил - есть, конечно же, такие области, где не имеет значения количество юзеров.
У меня тоже полно смайлов в комменте, вашу иронию я уловил ;) Но с крайним комментом не согласен — практически в любом софте бОльшее количество юзеров является одной из наиважнейших целей (продажа софта, девайсов, рекламных мест...). Только в одном случае они пользуются результатами оптимизации параллельно, в другом последовательно 8)
Согласен. Вообще в реальном мире всякое возможно. Например, есть кодек, который встроен в смартфон. Если мощности современного процессора хватает на 30 каналов с таким кодеком, то зачем его оптимизировать дальше - даже если бы это было возможно... Юзеров у смартфона миллионы - но дальнейшая оптимизация уже не нужна. Но! Если бы там вообще никакой оптимизации не было, посадили бы школьника написать этот кодек по базовым формулам, то может быть и нынешний процессор его бы не вытянул. Во всяком случае, не осталось бы ресурсов CPU ни на что другое.
Не надо возводить оптимизацию в самоцель.
Понимают, кроме того они понимают, что оптимизировать нужно тогда, когда есть проблемы, и там, где они есть. Вот это оправдано.
Неоправдано заниматься оптимизацией прежде, чем в ней появится необходимость. Оптимизировать необходимо критические участки кода, выигрыш от оптимизации которых будет заметен. Например, нет смысла тратить время на оптимизацию загрузки настроек программы, которая запускается несколько раз в день. С другой стороны, в Delphi VCL которые участки кода реализованы на ASM, например, менеджер памяти, обработка сообщений.
Они все сошли с ума и не понимают, что прогресс железа делает ненужной оптимизацию?
Понимают, кроме того они понимают, что оптимизировать нужно тогда, когда есть проблемы, и там, где они есть. Вот это оправдано.
Неоправдано заниматься оптимизацией прежде, чем в ней появится необходимость. Оптимизировать необходимо критические участки кода, выигрыш от оптимизации которых будет заметен. Например, нет смысла тратить время на оптимизацию загрузки настроек программы, которая запускается несколько раз в день. С другой стороны, в Delphi VCL которые участки кода реализованы на ASM, например, менеджер памяти, обработка сообщений.
У меня плохая паять на имена. Я 20 минут заставлял себя запомнить имя Станислава Кауфмана, а потом забыл его имя. Не суть.
Не помню кто, но кто-то сказал, что преждевременная оптимизация — зло. Да и вообще, в последнее время архитектура проектов далека от KISS, а значит и оптимизировать конкретную область кода все сложнее.
Попробую допустить, если вы разобьете ваш софт на ядро и несколько подпрограмм, оптимизировать конкретную часть станет намного проще. Хороший пример — unix системы. Другу дали задание — посчитать кол-во и объем фалов каждого пользователя одного фотохостинга. Движек не писал в базу объем файлов, а местоположение определялось директорией с именем пользователя + вложенность.
Сначала он оценил время работы стандартной утилиты линуха (забыл её имя =)))), она ответила, что будет работать порядка недели. Он сел и в течении вечера переписал её, оптимизировав под нужды. В итоге она посчитала все что нужно в течении 12 часов.
Конечно, это лишь мое мнение, но оно основывается на опыте. KISS рулит
Не помню кто, но кто-то сказал, что преждевременная оптимизация — зло. Да и вообще, в последнее время архитектура проектов далека от KISS, а значит и оптимизировать конкретную область кода все сложнее.
Попробую допустить, если вы разобьете ваш софт на ядро и несколько подпрограмм, оптимизировать конкретную часть станет намного проще. Хороший пример — unix системы. Другу дали задание — посчитать кол-во и объем фалов каждого пользователя одного фотохостинга. Движек не писал в базу объем файлов, а местоположение определялось директорией с именем пользователя + вложенность.
Сначала он оценил время работы стандартной утилиты линуха (забыл её имя =)))), она ответила, что будет работать порядка недели. Он сел и в течении вечера переписал её, оптимизировав под нужды. В итоге она посчитала все что нужно в течении 12 часов.
Конечно, это лишь мое мнение, но оно основывается на опыте. KISS рулит
Оптимизация, ЛЮБАЯ - это есть хорошо! т.к. заставляет ВСЕГДА думать об оптимизации
дисциплина
есть умники, которые говорят, надо оптимизировать лишь hot spots, это действительно умная мысль, но они просто уже не знают где проходит граница этих самых hot spots...
недавно разговорился с одним челом, они делают в принципе простой проект и он говорит: "мои клиенты купили сервер с 16Gbytes памяти, ха-ха-ха" и я тоже "ха-ха-ха :-)" Оказывается он смеялся, что МАЛО памяти купили, а я наоборот, за свои 15 лет программирования таких тачек с ТАКИМ количеством Gbytes не видел... уебаны одним словом
Respect всем кто оптимизирует ЛЮБОЙ код!
дисциплина
есть умники, которые говорят, надо оптимизировать лишь hot spots, это действительно умная мысль, но они просто уже не знают где проходит граница этих самых hot spots...
недавно разговорился с одним челом, они делают в принципе простой проект и он говорит: "мои клиенты купили сервер с 16Gbytes памяти, ха-ха-ха" и я тоже "ха-ха-ха :-)" Оказывается он смеялся, что МАЛО памяти купили, а я наоборот, за свои 15 лет программирования таких тачек с ТАКИМ количеством Gbytes не видел... уебаны одним словом
Respect всем кто оптимизирует ЛЮБОЙ код!
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." (Knuth, Donald)
А ещё Кнут выяснил что 50% производительности определяется 4% кода. Hot spots реально существуют и в большинстве проектов найти их профайлером не так сложно.
Кнут — теоретик, программирование — это практика. Не надо путать эти две совершенно разные вещи. Если кто-нибудь когда-нибудь в жизни использовал Кнута кроме уроков информатики — respect! Таких людей, к сожалению, осталось мало.
Проблема чисто психологическая, процитировал Кнута — мысль остановилась, так сойдёт, нахер думать и что-то там оптимизировать. Как результат получаем плохой soft. Большинство программ на приличных компах тормозят, мой мозг работает быстрее чем открываются окна практически любого современного приложения. А кто-нибудь видел любой soft от IBM или последний Outlook 2007 или J2EE (где каждый модуль таскает с собой всe пакеты, когда-либо было написанные на Java, и весь CPU и память тратятся на parsing XML чтобы извлечь пару Business параметров)? Это же вообще ппц — куда мир катится.
Поэтому не надо, пожалуйста, цитировать Кнута, а пытайтесь применить его алгоритмы, глядишь больше людей будет с нормальными ориентирами.
Повторюсь, что дело не в потраченном времени на глупую оптимизацию, а дело в том, что благодаря этому люди будут замечать «брёвна» в своих программах и жизнь будет лучше.
Проблема чисто психологическая, процитировал Кнута — мысль остановилась, так сойдёт, нахер думать и что-то там оптимизировать. Как результат получаем плохой soft. Большинство программ на приличных компах тормозят, мой мозг работает быстрее чем открываются окна практически любого современного приложения. А кто-нибудь видел любой soft от IBM или последний Outlook 2007 или J2EE (где каждый модуль таскает с собой всe пакеты, когда-либо было написанные на Java, и весь CPU и память тратятся на parsing XML чтобы извлечь пару Business параметров)? Это же вообще ппц — куда мир катится.
Поэтому не надо, пожалуйста, цитировать Кнута, а пытайтесь применить его алгоритмы, глядишь больше людей будет с нормальными ориентирами.
Повторюсь, что дело не в потраченном времени на глупую оптимизацию, а дело в том, что благодаря этому люди будут замечать «брёвна» в своих программах и жизнь будет лучше.
Много умных людей приводят в своих книгах эту цитату Кнута - Steve McConnell например. Надеюсь он-то хоть не уебан?
с творчеством McConnell-a не знаком - не могу судить, а уебаны те, которые потеряли ориентиры хороших программ, к сожалению, таких становится все больше и больше... да и откуда им взяться ориентирам, если основная цель - это хоть как-то сдать проект, так и получается, что все склепано хуями и весь современный soft - унылое гавно, как сказал бы СамиЗнаетеКто
редкий случай на этом фоне Firefox 3, который вдруг стал работать быстрее чем его вторая версия, обычно случается наоборот
оптимизируйте и думайте - это единственное к чему пытаюсь призвать
редкий случай на этом фоне Firefox 3, который вдруг стал работать быстрее чем его вторая версия, обычно случается наоборот
оптимизируйте и думайте - это единственное к чему пытаюсь призвать
Ну Кнут во первых не такой уж и теоретик. За свою жизнь, я думаю, он немало программ написал, например, известный TEX.
Вы понимаете смысл того что говорит Кнут, и другие известные программисты?
Они не утверждают, что программы должны быть медленными, они не говорят, что оптимизация не нужна или бесполезна.
Все эти цитаты о том, как её правильно проводить.
Нет смысла тратить усилия, и разрушать код (а оптимизация на уровне кода неминуемо делает его менее понятным) по всему проекту, если это даёт лишь жалкие десятые процентов прироста. Надо искать корень проблем с производительностью.
Конечно, можно постоянно заниматься оптимизацией в качестве интеллектуального упражнения, как предлагаете вы. Но в профессиональной разработке программ это не серьезно (пожалейте ваших коллег по команде, и тех кто будет разбираться в коде после вас).
Вы понимаете смысл того что говорит Кнут, и другие известные программисты?
Они не утверждают, что программы должны быть медленными, они не говорят, что оптимизация не нужна или бесполезна.
Все эти цитаты о том, как её правильно проводить.
Нет смысла тратить усилия, и разрушать код (а оптимизация на уровне кода неминуемо делает его менее понятным) по всему проекту, если это даёт лишь жалкие десятые процентов прироста. Надо искать корень проблем с производительностью.
Конечно, можно постоянно заниматься оптимизацией в качестве интеллектуального упражнения, как предлагаете вы. Но в профессиональной разработке программ это не серьезно (пожалейте ваших коллег по команде, и тех кто будет разбираться в коде после вас).
Абсолютно солидарен :) Жаль карму не могу вам поправить.
ну прям Америка)
Вот потому я и засел плотно за функциональное программирование. В следующем десятилетии все там будем. :)
«Преждевременная оптимизация — корень всех зол» © Кнут
За то после того как все написано можно и размять мозг.
1. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified."
2. Да и вообще, выборочно цитируя знаменитых личностей при обсуждении обших вопросов можно найти подтверждение любому своему тезису, а затем - антитезису. Поэтому не стоит ссылаться на классиков, когда обсуждаются вещи мировоззренческие, а не доказательство теоремы.
2. Да и вообще, выборочно цитируя знаменитых личностей при обсуждении обших вопросов можно найти подтверждение любому своему тезису, а затем - антитезису. Поэтому не стоит ссылаться на классиков, когда обсуждаются вещи мировоззренческие, а не доказательство теоремы.
Интересно, почему нет ни одного комментария про разницу между оптимизацией вычислительной сложности алгоритма и оптимизацией скорости этого алгоритма?
Сортировка пузырьком, как её ни оптимизируй, как железо ни апгрейдь, всегда будет работать за O(n^2).
Сортировка пузырьком, как её ни оптимизируй, как железо ни апгрейдь, всегда будет работать за O(n^2).
да, но если железо способно этим алгоритмом сортировать 10^10 записей в секунду, то...
вообще правильно не писать свои алгоритмы, если существуют библиотечные.
вообще правильно не писать свои алгоритмы, если существуют библиотечные.
> если железо способно этим алгоритмом сортировать 10^10 записей в секунду, то...
.. оно будет способно отсортировать правильным алгоритмом это же количество записей за время порядка 10^-9 секунды. За одну НАНОсекунду, я бы сказал.
Кроме того, проблемы с использованием алгоритмов сложности n^2 вместо n log n или n вместо log n (а то и вообще C) сортировкой не ограничиваются. Частенько они могут вылезти в даже абсолютно безобидных вещах.
.. оно будет способно отсортировать правильным алгоритмом это же количество записей за время порядка 10^-9 секунды. За одну НАНОсекунду, я бы сказал.
Кроме того, проблемы с использованием алгоритмов сложности n^2 вместо n log n или n вместо log n (а то и вообще C) сортировкой не ограничиваются. Частенько они могут вылезти в даже абсолютно безобидных вещах.
А где вы такое железо возьмёте?
Как правило, сложность [плохих] алгоритмов растет экспоненциально, так что увеличивая мощности железа вы ничего не добьетесь. Поставите еще один шкаф за мильён баксов и в место часа выполнения будет, ну скажем, 55 минут. Вместо того чтобы посидеть и покрутить прогу.
В клиентских приложениях, где используются готовые библиотеки, не нужна параноидальная оптимизация. Так как основные тяжёлые вычисления выполняют тяжёлые и оптимизированные библиотеки. Но всё же головой нужно думать, дабы небыло логических ошибок (мегациклов, зацикливаний и т.п.). Поэтому сейчас нет большой разницы писать код на C++ или Руби, разница скорости в синтетических тестах в 20 с лишним раз, в реальной программе 10%. Но вот библиотеки лучше всего маниакально оптимизировать (тотже Адобе оптимизирует не программу, а как таковые библиотеки обработки (например фотографий в фотошопе)).
Разработчики железа сыграли злую шутку с пользователями истребив программистов.
Навеяно геморроем с дровами для видеокарты. Качаю очередную версию весом 166 Мбайт. Уже не верится что все нормально заработает.
А вы все об оптимизации… Хоть как-то бы работало.
Навеяно геморроем с дровами для видеокарты. Качаю очередную версию весом 166 Мбайт. Уже не верится что все нормально заработает.
А вы все об оптимизации… Хоть как-то бы работало.
Вообще-то обычно сначала пишут просто работающий код, а уже потом приступают к оптимизации, используя при этом профайлер.
Хм. Не понятны радужные надежды Bobos'а на то, что железо можно ускорять бесконечно долго. Процессоры уже достигли, похоже, некоторого предела сложности в организации OoOE. И у разработчиков не выходит сделать их шире, а даже если бы и вышло, то производительности это особо не добавило. Добавьте сюда всё возрастающую сложность в добывании дополнительных мегагерцев. Да, IBM добилась 4 гигагерцев на за счёт существенного упрощения процессорных ядер. Да и гигаерцы у них - это метод борьбы с токами утечки, за энергопотребление, и за быстрые кэши, а не за производительность процессорных ядер. Добавьте сюда ещё ОЧЕНЬ медленную по сравнению с процессорами память.
Так что вот... Вскоре на автомате из нового железа получать прирост призводительности не выйдет. Придётся по крайней мере оптимизировать софт под многоядерные NUMA, ведь потребности пользователей растут как и прежде. Так что, не время расслабляться, господа программисты.
Так что вот... Вскоре на автомате из нового железа получать прирост призводительности не выйдет. Придётся по крайней мере оптимизировать софт под многоядерные NUMA, ведь потребности пользователей растут как и прежде. Так что, не время расслабляться, господа программисты.
Вы слишком поверхностно читали пост и совсем не поняли, про что я писал. Не в железе дело и не о железе пост — дело в задачах и в оптимизации под задачи. А задачи в каждом конкретном случае разные — где-то предельное быстродействие, где-то — понятная и простая архитектура. Я могу оптимизировать девайс так, что он будет жрать не 20%, а 15, но что мне это даст? Что это даст пользователям? Кому от этого будет лучше? Единственное, что в результате этих оптимизаций получится — это код, в котором человек с низким уровнем программирования при необходимости доработок вряд ли разберется, код, в котором изменение системы расчетов каких-нибудь базовых показателей потянет за собой перелопачивания всего математического аппарата. Ну и конечно это затраты времени на дополнительную оптимизацию, тестирование и отладку.
Это тот случай, который я описал в посте. Если вы найдете причину, по которой мне нужно сейчас сесть и перелопатить весь код для того, чтобы он летал быстрее, я это сделаю (причины, типа "ты не тру программер" не предлагать — самоутверждение для меня в этом проекте стоит на последнем месте)
Это тот случай, который я описал в посте. Если вы найдете причину, по которой мне нужно сейчас сесть и перелопатить весь код для того, чтобы он летал быстрее, я это сделаю (причины, типа "ты не тру программер" не предлагать — самоутверждение для меня в этом проекте стоит на последнем месте)
Да я вроде и не претендовал на глобальный анализ вашей задачи. Вам лучше знать, как её и когда оптимизировать. Я лишь обратил внимание на фразу о лёгкости поднятия производительности системы за счёт агрейда железа. На Хабре часто такая мысль проскальзывает, что мол не нужно ничего оптимизировать, дешевле купить Core 2^N, и всё само собой начнёт работать быстрее. Хотелось немного поумерить оптимизм присутсвующих относительно этого.
А насчёт вашей программы - понятия не имею, что и как в ней можно оптимизировать. То, что вы во многих местах заново расчитываете какие-то значения, ещё не означает, что существует способ сделать это оптимальнее. Кроме того, у вас же там есть оптимизирующий компилятор, который может при агрессивной оптимизации многие неоптимальности исходного кода сгладить.
Но вообще... Если абстрактно. Совершенно непонятно, чего такого страшного в том, чтобы постепенно избавлятся от неоптимальностей, где-то сохраняя вычисленные значения. Такой подход даже может иметь плюс, если его оценивать с позиций дальнейшего развития вашей системы - не нужно по сто раз писать код вычисления тех или иных параметров. Если к тому же придумать хорошие названия переменным, то читабельность кода от этого не пострадает. Более того, вполне возможно, вы сможете увидеть некоторые новые закономерности в своей математической модели, которые позволят её упростить. У меня такое нередко случалось. Просто не поверите, какие порой происходили упрощения моделей именно благодаря тому, что старался их оптимально запрограммировать.
А насчёт вашей программы - понятия не имею, что и как в ней можно оптимизировать. То, что вы во многих местах заново расчитываете какие-то значения, ещё не означает, что существует способ сделать это оптимальнее. Кроме того, у вас же там есть оптимизирующий компилятор, который может при агрессивной оптимизации многие неоптимальности исходного кода сгладить.
Но вообще... Если абстрактно. Совершенно непонятно, чего такого страшного в том, чтобы постепенно избавлятся от неоптимальностей, где-то сохраняя вычисленные значения. Такой подход даже может иметь плюс, если его оценивать с позиций дальнейшего развития вашей системы - не нужно по сто раз писать код вычисления тех или иных параметров. Если к тому же придумать хорошие названия переменным, то читабельность кода от этого не пострадает. Более того, вполне возможно, вы сможете увидеть некоторые новые закономерности в своей математической модели, которые позволят её упростить. У меня такое нередко случалось. Просто не поверите, какие порой происходили упрощения моделей именно благодаря тому, что старался их оптимально запрограммировать.
Из собственного опыта могу сказать, что преждевременная оптимизация - это как и преждевременная эякуляция - удел в основном начинающих программистов. Умные дяди пишут умные книги, в которых пишут, что низкоуровневая оптимизация - это зло и они правы. Преждевременная низкоуровневая оптимизация делает очень сложными процесс поддержки (support) и развития программы и часто не дает ничего. А для многих компаний цена support и развития больше цены начального написания программы в десятки и сотни раз, а значит надо оптимизировать расходы на support, а не увеличивать его стоимость, делая ненужные оптимизации. А лучшее уменьшение стоимости support - это написание простого и понятного кода, без всяких ассемблерных вставок и т.п..
Далеко не все программы надо оптимизировать - об этом в основном говорят классики в книгах.
Собственно, об этом говорит и опыт автора топика - его задачу можно сделать без оптимизации, потому она и не нужна, совсем. Не надо тратить время на то, от чего не будет финансовой выгоды.
Тут в коментариях есть примеры фотошопа, windows и т.п. - это те программы и ОС, которые безусловно надо оптимизировать, т.к. кастомеры готовы платить за их скорость. Но абсолютному большинству программ это не надо.
Ну и никто не отменял также понятие преждевременной пессимизации. Это когда, например, для сортировки применяют самописный пузырек вместо обычного quicksort. Но это тоже проходит обычно с опытом и опытный программист сразу пишет достаточно оптимальный код уже на высоком уровне, без всяких низкоуровневых оптимизаций, но зато и без пессимизаций.
Далеко не все программы надо оптимизировать - об этом в основном говорят классики в книгах.
Собственно, об этом говорит и опыт автора топика - его задачу можно сделать без оптимизации, потому она и не нужна, совсем. Не надо тратить время на то, от чего не будет финансовой выгоды.
Тут в коментариях есть примеры фотошопа, windows и т.п. - это те программы и ОС, которые безусловно надо оптимизировать, т.к. кастомеры готовы платить за их скорость. Но абсолютному большинству программ это не надо.
Ну и никто не отменял также понятие преждевременной пессимизации. Это когда, например, для сортировки применяют самописный пузырек вместо обычного quicksort. Но это тоже проходит обычно с опытом и опытный программист сразу пишет достаточно оптимальный код уже на высоком уровне, без всяких низкоуровневых оптимизаций, но зато и без пессимизаций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оптимальный код?