Как большой роль субъективность играет в программировании?

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

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

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

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

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

Обращаясь к моей жене, имеющей докторскую степень по математике, я спросил, есть ли в математике какая-то субъективность. Ее ответ - да, в основном в том, как мы, люди, получаем ответ.

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

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

Отсюда программисты могут спорить, как лучше всего добиться «правильного» результата. Хорошим примером этого является приложение FizzBuzz. Простым ответом будет просто цикл for, но Enterprise FizzBuzz также «правильный» в том смысле, что он дает правильный ответ, но его обычно осмеивают как «плохую» разработку из-за чрезмерного усложнения идеи ( в конце концов, это была шутка).

Насколько большую роль в программировании играет субъективность? Я бы сказал, что это очень большая часть того, что мы делаем, просто потому, что мы люди, и потому что есть несколько способов получить «правильный» ответ, поэтому существуют разногласия по поводу того, какой из них лучше.

Исследования показали, что определенные методы снижают уровень дефектов в программном обеспечении. Например, исследование обнаружило сильную корреляцию между цикломатической сложностью и вероятностью подверженности сбоям. Другие исследования показывают, что средняя эффективность проверки дизайна и кода составляет 55 и 60 процентов. Так что, похоже, в наших интересах поддерживать простоту, проверять метрики и делать обзоры кода.

Однако здесь мы говорим о вероятностях. Если я проверю ваш код, мне не гарантировано, что я найду 60% ваших ошибок. В разработке программного обеспечения также есть несколько абсолютов; опытные разработчики знают, что правильный ответ, как правило, «зависит от обстоятельств». При этом существует ряд практик с объективными данными в их пользу.

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

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

Все зависит от вашей точки зрения :-)

Но чтобы ответить на ваши вопросы,Я думаю, что один из способов рассматривать субъективность — это признать, что языки программного обеспечения, инструменты и лучшие практики являются общим средством общения между людьми. Да, язык программирования — это формальный способ инструктировать компьютер, как себя вести, но язык программирования также можно рассматривать как способ определения и передачи спецификаций на высоком уровне детализации (код является конечной спецификацией, не так ли?).

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

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