Если кто-то предлагает вам непроверенное утверждение относительно практики разработки программного обеспечения, отвечаете ли вы «необходимостью цитирования»? [закрыто]

Недавно я посетил лекцию, которую прочитал Грег Уилсон (главный научный сотрудник Software Carpentry). Из аннотации:

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

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

Говоря прямо, я был доверчив .

Вот пример, взятый из лекции:

«Если более 25% кода нуждается в рефакторинге, его быстрее переписать».

Звучит правдоподобно, но правда ли это? Где исследование подтверждает это? Это правда для всех языков? И так далее.

Хорошо, вполне возможно довести это до крайности и никому не верить, если вы сами не поняли это из первых принципов. В этом и заключается безумие (или, может быть, математика ;-)). Но если кто-то придет к вам с заявлением в духе «Привет, сделав это на [момент выбора языка], мы сможем повысить производительность на [выбор кратных 10]%», если вы склонны просто принять это, или вы собираетесь запросить доказанные доказательства?

Если это последнее (и я надеюсь, что это так), то

1. Куда бы вы пошли, чтобы найти это доказательство?
2. насколько строгой вы были бы?

Короче говоря, если кто-то предложит вам непроверенное утверждение, вы ответите «нужна цитата»?

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

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

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

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

Если бы кто-то сказал вам: «Если более 2% кода нуждается в рефакторинге, его быстрее переписать», вы бы знали, что это ложно, как если бы кто-то сказал вам «Только если более 98% кода требует рефакторинга, это быстрее переписать это ". Где фактическое число зависит от того, что вы делаете, и насколько далеко от идеала текущий код.

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

Если кто-то предлагает вам непроверенное утверждение относительно практики разработки программного обеспечения, отвечаете ли вы «необходимостью цитирования»?

Нет, я публикую это здесь и посмотрю, получит ли он какие-либо отзывы. Социальное доказательство лучше, чем отсутствие доказательств!

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

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

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

Не кажется справедливым или даже практичным просить опытных разработчиков представить исследование и эмпирические данные в качестве доказательства того, что их методы верны. Опыт не работает таким образом. Напротив, опыт - это что-то вроде «ощущаемого чувства». В мире рефакторинга мы часто называем это «запах».

В конечном счете, утверждение типа «Если более 25% кода нуждается в рефакторинге, его быстрее переписать» не может быть доказано, что оно работает при любых обстоятельствах, поэтому утверждение [citation-required] действительно является способом информирования догматического программиста, который стремится навязать свои взгляды другим, что это не всегда «Его Путь или Шоссе».

Я думаю с чем-то, что ты никогда не узнаешь, пока не попробуешь. Даже имея доказательства, подтверждающие утверждение, всегда можно согнуть факты в пользу вашей точки зрения. Тем не менее, вы не должны пробовать каждую новую вещь, которая попадает в сети. Сделай свое лучшее суждение. Помните, если что-то звучит слишком хорошо, чтобы быть правдой, это, вероятно, так. Всегда спрашивайте себя, почему вы должны принять что-то? Что вы должны получить? Имеет ли это смысл с точки зрения бизнеса? Никогда не ослеп, кроме чего-то на вере

Пример из лекции - эвристика, эмпирическое правило и ничего более. Это должно быть безоговорочно очевидно.

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

Значит ли это, что они не стоят? Я бы так не сказал.

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

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

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

С другой стороны, когда производитель заявляет, что какая-то новая IDE на 50% более продуктивна, моя первая реакция - бык $% ^ &!

Разве это не то, что зависит от целого ряда нематериальных переменных (переменных, которые невозможно измерить с научной точки зрения)?

На мой взгляд, речь идет об эмпирическом методе измерения эмоций. Что-то, чего не мог сделать даже Спок. знак равно