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

14

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

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

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

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

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

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

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

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

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

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

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

Гэри Роу
источник
2
Во многих областях, помимо науки, люди требуют эмпирических данных? По моим наблюдениям, не так много, как хотелось бы.
Дэвид Торнли
1
Как насчет комментариев по поводу закрытых голосов? «Слишком локализованный» и «Не настоящий вопрос» в данном контексте не говорят сами за себя.
Инамати
1
Да, я тоже хотел бы узнать причину закрытия голосования.
Роберт Харви
@ Роберт Спасибо за редактирование. Гораздо менее подстрекательские к размышлению
Гэри Роу
1
Отличный вопрос Я видел, как профессор Уилсон выступал в CUSEC в прошлом году, и на меня также сильно повлияло то, что он сказал. Лучшая часть была, когда студент бросил ему вызов, чтобы он сослался на его утверждение о том, что требования должны быть приведены, и он сделал это, не пропуская ни секунды.
Мэтью Прочитал

Ответы:

3

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

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

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

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

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

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

Билл
источник
+1 за тщательный анализ примера утверждения. Вы действительно думаете, что все научные исследования имеют коммерческий аспект, который нужно использовать, хотя? (Простите за мою наивность, но мне искренне интересно это)
Гари Роу,
@ Гэри: Нет ничего идеального, но очень сложно, если не невозможно, определить предвзятость исследования со стороны. Вдвойне, когда нет согласованных показателей, охватывающих всю ситуацию
Билл
8
Если кто-то предлагает вам непроверенное утверждение относительно практики разработки программного обеспечения, отвечаете ли вы «необходимостью цитирования»?

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

Стивен А. Лоу
источник
2
Вы можете получить что-нибудь с этой моделью, но я содрогнулся при мысли о работе со ссылкой на программистов. SE в качестве источника.
Инамати
@Inaimathi: это по крайней мере так же надежно, как Википедия, если не больше!
Стивен А. Лоу
+1 за поиск доказательств - всегда хороший совет. Сколько возражений, прежде чем вы в это поверите? ;-)
Гари Роу
1
@ Гэри: на ТАК, десять. на этом сайте двадцать. на мета, сотня - если это не включает единорогов и вафель, и в этом случае это должно быть правдой
Стивен А. Лоу
Люблю ссылку на единорога - должен дать мне один из них
Гари Роу
4

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

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

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

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

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

Роберт Харви
источник
Ах, старый добрый человеческий капитал и человеческие ресурсы, эти замечательные фразы-близнецы, способствующие продолжающейся дегуманизации рабочих повсюду ...
Aaronaught
@Aaronaught: реализация концепции иногда может не соответствовать высокой лексике, используемой для ее описания. Вот почему скептические люди иногда просят доказательства.
Роберт Харви
Разве не было бы хорошо, чтобы выполнение этих конкретных концепций не дало результатов?
Aaronaught
+1 за правильное использование защиты «нужна цитата» против догматического программиста - очень полезно
Гари Роу
4

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

Carlosfocker
источник
+1 за вопрос "зачем тебе что-то усыновлять". Иногда отойти от переднего края это хорошо.
Гэри Роу
Я нахожу, что слишком часто разработчики увлекаются следующей лучшей вещью, не анализируя ее и не понимая, как это может как принести пользу, так и сдержать их. Я видел ситуации, когда организации применяют что-то вроде Asp.Net MVC вместо Asp.Net Webforms, но не принимают TDD.
Carlosfocker
3

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

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

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

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

Адам Кроссленд
источник
Хорошие моменты. =)
Пабло
1

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

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

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

limist
источник
1
Это зависит, но даже примеры полного кода зависят от вашей ситуации. Например: если у вас есть средство форматирования при разборе, а ваш инструмент сравнения игнорирует пробелы, то аргумент отступа становится довольно тривиальным
Bill
1
+1 для примера Code Complete (также верно для Rapid Development того же автора Стива Макконнелла).
Гари Роу
@ Билл Интересно, что с развитием технологий проблемы, которые требовали доказательства ранее, исчезают. Интересно, снижает ли это эффект, который заставляет нас требовать доказательств?
Гари Роу
1
@ Гэри Я не думаю, что это (в общем смысле) - это скорее улучшение, чем изменение. Примеры полного кода определенно ссылаются на определенный набор инструментов в определенный момент времени, поэтому они оба, но тип «когда проводить рефакторинг» имеет гораздо больше общего с ситуацией, чем с технологией. Подумайте о критически важном для безопасности программном обеспечении в автомобиле, а не в решении для обработки данных. Требования к тестированию в системе безопасности будут намного выше, поэтому точка рефакторинга всегда будет намного выше, прежде чем будет достигнут чистый выигрыш.
Билл
1

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

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

Pablo
источник
1
+1 за интересный взгляд на это. Если оставить в стороне (намеренно) неуклюжий пример, если бы кто-то сказал вам, что Rails является лучшей средой, чем SpringMVC, как бы вы решили определить ее валидность?
Гари Роу
Как Бенджамин Грэм утверждает в своей классической книге об инвестировании («Анализ безопасности»), эти (инвестиционные) инструменты должны оцениваться в двух разных, но одиноких аспектах: качественный (нематериальный, чувства) и количественный (действительные числа, математика) вычисления, логика).
Пабло
Количественное - это то, что вы измеряете с помощью научного метода. Качественный - это то, что вы измеряете своим собственным инстинктом. Невозможно судить о эмоциях и эмоциях, не имея эмоций по поводу анализа.
Пабло
По меньшей мере, когда мы говорим о мнениях и различиях в них, мы просто не можем договориться о разумном, научном и осязаемом методе измерения абстрактности.
Пабло
Мой ответ заключается в том, что мы можем измерять только технические аспекты, а не абстрактные мысли / мнения. Кроме того, я не хочу звучать как задница. Эти посты не были предназначены для какой-то глупой реакции.
Пабло