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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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