Влияет ли использование новых методов на производительность? [закрыто]

20

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

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

Теперь я заметил, что появляется все больше и больше случаев, когда для данной проблемы я знаю, что, вероятно , существует лучшее решение «там», и обнаружение его, вероятно, улучшит код. Однако, учитывая мои теперь глубокие знания базы кода, гораздо проще использовать имеющиеся у нас неоптимальные инструменты и получить решение (включая тесты), чем найти что-то новое, «лучшее» и «улучшить» кодовую базу.

Так что есть напряжение: «делай это правильно» против «сделай работу достойно ».

Это то, что происходит со многими разработчиками? Это известная конкретная проблема? (Это настоящая проблема в конце концов?) Это на самом деле связано с увеличением уровня опыта?

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

Мартин Ба
источник
3
краткосрочный: да - долгосрочный: хорошо, мы все можем застрять на
КОБОЛЕ
Прилично сделано тоже может быть уместно.
QuanhD

Ответы:

17

Часто рискованно пробовать новые вещи. Иногда мы попадаем в неприятности, потому что мы склонны делать две вещи:

  1. Переоценить, насколько полезна классная / новая / шикарная вещь. Мы видим какой-то классный пример, какой-то код, брошенный онлайн. Очень круто мы думаем. Очень круто! В XI можно выполнить задачу Y в десять раз быстрее. Это явно лучше. Мы еще не видим всех «неизвестных неизвестных». Мы не были сбиты с толку проблемами, которые пропускают продавцы новой вещи. У нас недостаточно опыта в этой новой штуке, чтобы увидеть мины, ожидающие в будущем.

  2. Недооценивать, насколько полезны существующие инструменты / рамки / программное обеспечение / вещи. Мы часто не были там, когда нынешняя система была изначально построена. Мы не ценим тонкие компромиссы, которые были сделаны. Легко играть в защитник понедельника утром на существующей системе, но это работает . Вероятно, он получил много странностей из-за очень специфических компромиссов между поддержанием его в обслуживании, работой и производительностью. Да, конечно, это странно. Может быть, самое главное, команда является экспертом по текущей странности и знает, как обойти эту странность. Они знают мины, ловушки и ловушки, которых следует избегать. На самом деле это именно потому, что мы видим все бородавки в нынешнем способе делать вещи, которые мы даже заинтересованы в игре с новыми вещами.

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

Так что да, нам нужно сбалансировать поддержание и доставку текущей вещи с некоторым уровнем игровых / образовательных экспериментов с новыми способами решения проблем, имея в виду, что многие из этих новых способов являются тупиковыми, в то время как другие могут окупиться. ИМО Это веская причина, по которой многие компании имеют 20% времени, чтобы поиграть с новыми вещами. Они часто знают, что у них ничего не получается, но многие идеи, которые приходят из 20% времени, становятся вполне успешными. Без времени, чтобы поиграть и поэкспериментировать, вы легко можете застрять как компания и по-настоящему облажаться.

Дуг Т.
источник
1
Я думаю, это зависит от типа "нового", который вы исследуете. Я исследовал концепции программирования 60-х, 70-х, 80-х годов, и все они кажутся новыми, поскольку немногие программисты действительно изучают историю этой области.
Рудольф Олах
Еще одна хорошая вещь в «исследованиях» заключается в том, что даже если вы, наконец, не используете инструменты, которые вы исследовали, вы могли бы извлечь из них некоторые интересные концепции ... Теперь есть некоторые компании (говоря о том, что я знаю: например, банки) которые конкретно не хотят использовать «новые вещи», но подождите, пока они не будут хорошо установлены. Иногда разумно ... есть компании, которые вложили много средств в создание прототипов, mootools, scriptaculous и т. Д. ... чтобы потом понять, что эти фреймворки "проиграли" битву и не получили большой поддержки.
Лоран С.
8

Это происходит все время . Я говорил об этом в других статьях, но чаще вы не заняты разработкой элегантного кода, вы заняты поставкой продукта. Таким образом, вам будет трудно найти любого менеджера, который готов выделить nчасы для вас, чтобы починить что-то, что не сломано и действительно (в конце дня) не сильно улучшит работу конечного пользователя. Вам будет так же трудно найти менеджера, готового выделить nчасы на исследования (без четкой конечной цели), кроме «возможно, есть что-то лучше», чем то, что делается.

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

Демиан Брехт
источник
+1, хотя я и говорю, что «доставка функции» часто является оправданием для ленивости (тесты, сопровождение и т. Д.)
Martin Ba
Хотя я согласен со многим из того, что вы говорите в своем ответе, я бы сказал, что разработчики в некоторой степени занимаются разработкой элегантного кода. Отправленный код бесполезен, если он не работает без простого способа исправить / поддержать его. Именно здесь рефакторинг кода для достижения «элегантности», тратя сегодня n часов, завтра экономит n * 10 часов.
hspain
@hspain: Я абсолютно согласен, и это теоретический путь, однако, как правило, этого не происходит в реальном мире (по крайней мере, по моему опыту), если только ваша работа - это библиотеки, а не сам продукт.
Демиан Брехт
На самом деле, некоторые люди в Agile сообществе рекомендуют отслеживать эти проблемы как нефункциональные требования. Требование должно быть «код должен быть гибким и легко изменяемым» (или что-то в этом роде). Таким образом, вы можете создавать истории, которые касаются конкретных проблем. Преимущество состоит в том, что они становятся видимыми для заинтересованных сторон и могут быть запланированы / запланированы. Смотрите, например,
sleske
@sleske: ... А потом они падают во время расстановки приоритетов;)
Демиан Брехт
4

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

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

Тогда вы только склонны исследовать новые проблемы или проблемы, в которых старые проверенные и истинные либо больше не работают (устарели), либо вызывают проблемы с производительностью или сбоями. Когда вы начнете понимать сложную систему более глубоко, вы знаете, что у вас нет времени, чтобы реально использовать новые методы каждый раз, когда они появляются, и вы на опыте обнаружили, что большую часть времени новая техника не живет до его обмана и создает больше проблем, чем он решил. Таким образом, вы становитесь менее склонными к использованию новых инструментов и технологий, когда вам на самом деле они не нужны для решения проблемы.

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

HLGEM
источник
4

Вот некоторые детали:

  1. Есть крайние сроки : программист должен заранее иметь все необходимые детали доступных инструментов, которые он использует. Чтение какого-то веб-сайта, поиск новой классной вещи, а затем ее использование в производственной среде - это большая проблема. Вам просто не хватает опыта работы с инструментом, и что еще более важно, у вас просто нет времени, чтобы начать изучать что-то новое. Если вы хотите новый классный материал, изучите его за полгода или год до его использования.
  2. Прежде чем использовать его, убедитесь, что вы его правильно знаете . Некоторым приятным новым инструментом может быть интересно пользоваться, но поиск решений и последующее их использование без должного изучения могут быть очень плохими. Вам просто не хватает опыта с этим. Если вам нужно было гуглить, чтобы понять это, значит, вы просто недостаточно хорошо это знаете, чтобы исправить это, когда оно сломает половину системы.
  3. Использование новейших вещей не делает это должным образом : новые вещи не проверенные технологии. В следующем году технология, вероятно, полностью исчезнет, ​​и вы будете единственным в мире, кто ее использует. Все остальные заметили, что это просто не работает. Чтобы избежать новейшей серебряной пули, нужна тяжелая работа, но оно того стоит.
  4. Сосредоточьтесь на методах, которые являются вашими основными знаниями : каждый программист знает лишь небольшую часть всех знаний программирования, доступных в мире. Та часть, где программисту достаточно комфортно пользоваться, еще меньше. Часть, которая на самом деле работает, еще меньше. Используйте только те знания, которые вы правильно усвоили, и вы знаете, что это работает. Это делает вас быстрее программистом и приводит к лучшему коду.
  5. Не изменяйте его бесконечно : совершенный код - хорошая цель, но это не значит, что вы сначала пишете какую-то ерунду, а потом бесконечно настраиваете ее, чтобы постепенно улучшать. Напишите это отлично с первого раза, используя все хорошие знания, которые у вас есть. Доверяй себе. Не верь миру. Никто другой не знает точно, что вы делаете. Их мнение не имеет значения. Вы программист, вам нужно заставить его работать. Мир не может сделать это для вас. Как только это будет сделано, Стоп. Не трогайте его, пока кто-то не пожалуется на это.
  6. Потратьте время на изучение нового : каждый должен постоянно учиться новому. Наше будущее зависит от этого. Просто откажитесь от этого! Изучайте новые вещи, но не используйте их, пока не убедитесь, что они действительно работают. Вы получите шанс использовать его в следующем году, как только он станет проверенным. Или вы просто забыли это, как и все остальные - остались только хорошие вещи ...
  7. Не теряйте хорошие вещи : после того, как вы успешно построили большие системы и исправили все проблемы в них, и изучили некоторые хорошие методы, худшее, что вы можете сделать, это просто сбросить эти знания и заняться чем-то новым. Вы уже знаете, как это работает, какие проблемы существуют и как их решить. Выбросить это просто пустая трата времени.
  8. Будьте в курсе новых технологий : одна из новых систем будет успешной. У него есть что-то принципиально лучшее, чем все остальное на рынке. Вы просто не знаете, какая из них серебряная пуля. Если вы не сможете найти его вовремя, ваши знания будут устаревшими. Мир может заставить вас потерять все хорошее, лишив доступа к старым системам.
ТР1
источник
+1 за Не дорабатывайте это бесконечно.
Сриса
3

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

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

FrustratedWithFormsDesigner
источник
3

Да, новые вещи снижают производительность

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

Нет, новые методы могут повысить производительность

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

dietbuddha
источник
1

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

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

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

Не забывайте также, что часто делать это прилично с помощью существующих инструментов - лучшее решение, чем вставлять новые. Каждый раз, когда вы добавляете новое, вы увеличиваете необходимую поверхность обслуживания, что, в свою очередь, замедляет всех остальных (и может сделать ваш код довольно грязным - я думаю о слоях «новой» технологии, которая со временем перешла в наследство, но все еще находится в нашем коде, что делает вещи ужасными. Оглядываясь назад, было бы лучше просто использовать старые способы Си вместо добавления все эти COM и все эти VB и все эти .NET, а теперь и переложение в него HTML)

gbjbaanb
источник
Сильно не согласен: кто заботится о поиске и изучении новой библиотеки, если вы можете написать свою собственную за меньшее время. & было бы лучше просто использовать старые способы C вместо того, чтобы добавлять все это ... и все это ... - Это слишком подвержено ошибкам и консервативное ИМХО.
Мартин Ба
@Martin, конечно, тоже обратное - на SO вы читаете много людей, говорящих «постоянно узнавать что-то новое», что часто означает «изобретать одни и те же колеса, но на этот раз в новом инструменте». Я придерживаюсь прагматического подхода, когда выполнение работы имеет приоритет над всем, что я хотел бы сделать, или, в конце концов, могу облегчить жизнь, я достаточно взрослый, чтобы знать, что «в конечном итоге» чаще, чем не означает «никогда», особенно с скорость изменений, где вы в конечном итоге игнорируете новые вещи для еще более новых вещей, которые приходят вместе.
gbjbaanb