Я не говорю только о том, как распределяется память и управление памятью (вещи, которые вы можете узнать из C, например), а скорее об аппаратном аспекте и о том, как каждый компонент аппаратного обеспечения компьютера работает внутри и как они взаимодействуют друг с другом.
Кто из вас знает все это?
Ответы:
Это зависит от того, что вы делаете.
Если вы разработчик встраиваемых систем (и вы пишете очень близко к железу на очень маленьком устройстве), вам необходимо знать каждый вход и выход каждого компонента в системе.
Если вы системный разработчик (и пишете операционные системы, драйверы устройств или, может быть, даже базы данных), то вам нужно знать почти все, что нужно знать о низкоуровневых аппаратных интерфейсах.
Если вы разработчик игр и опаздываете в своем проекте (где вы оптимизируете вещи), вам необходимо знать все тонкости кеш-памяти процессора и графических архитектур, которые вы будете использовать.
Если вы разработчик приложений, вам не нужно ничего знать об этом, кроме как поддерживать использование памяти на разумных уровнях.
Если вы веб-разработчик, вам удобно знать интернет-протоколы, но ничего другого из этого не требуется, кроме как решать проблемы с памятью.
Я думаю, что комментарии о разработчиках приложений и веб-разработчиках неверны.
Например, если кто-то разрабатывает веб-приложение, которое включает в себя множество мер безопасности, таких как ssh или какой-либо другой алгоритм шифрования, очень важно, чтобы они знали, на каком типе оборудования они работают, чтобы они могли определить, может ли машина на самом деле обрабатывать рабочая нагрузка. Другой пример может включать сервер, на котором размещен какой-то загруженный контент. Вы лучше знаете возможности дисковода и интерфейс шины, к которому он подключен, если ожидаете достаточно большое количество запросов.
С точки зрения приложения, если вы разрабатываете какую-то программу САПР или что-то, что делает 3D-рендеринг, вы можете ожидать, что эти приложения будут интенсивно вычисляться как алгоритмически, так и графически. Было бы разумно понять аппаратное обеспечение, чтобы приложение было отзывчивым и работоспособным.
Я не говорю, что вам нужно идти до того, чтобы понять все тонкости чего-то вроде протокола PCI, но вы лучше понимаете, на что способен интерфейс и оборудование.
В конечном счете, это важно независимо от того, какой тип разработки вы делаете. Уровень детализации, необходимый для понимания, спорен.
Для профессионального программиста я рассматриваю это как целостный подход к пониманию всей системы , а не просто знание синтаксиса данного языка программирования du jour . Я считаю, что это помогает программистам (и аналитикам) принимать умные дизайнерские решения и делать более осознанный выбор алгоритма и структуры данных.
Из моего собственного опыта лучшие программисты, как правило, в разной степени знают о внутренней работе, будь то понимание набора инструкций по сборке для целевой платформы, вводный курс по организации работы с компьютером в школе, элементарная цифровая электроника или способность разбираться в деталях. Описания процессорных и графических процессоров в последних моделях, лучшие из них имеют более полные знания, чем их менее звездные сверстники.
Я не уверен, поможет ли это, но я чувствую себя более комфортно, когда знаю больше о системе, над которой я работаю, чем мне действительно нужно. Когда я был моложе, мне не нравилось не знать язык ассемблера системы, над которой я работал; либо я изменился, либо я узнал достаточно много, что еще один не сильно расширит мое восприятие системы. Я никогда не сильно разбирался в оборудовании, но я могу разобрать компьютер и назвать разные подсистемы и то, как они взаимодействуют.
То немногое, что я знаю, я узнал на уроке компьютерной архитектуры почти 25 лет назад, и в то же время о нереальной архитектуре.
В основном я занимаюсь разработкой приложений на различных платформах. Был период, когда я разрабатывал код для работы не только на аппаратном x86-оборудовании, но и на Sparc, PA-RISC и других серверных архитектурах. Знания на этом уровне просто не требуются для работы, которую я делаю.
Я преподаю программирование на Java в классе AP. Я обнаружил, что когда студенты знают что-то о внутренней работе компьютера, это помогает им понять концепции программирования.
Я не зацикливаюсь - простые понятия, такие как то, как вещи хранятся в памяти, помогают студентам.
Я собираюсь ответить на этот вопрос в заголовке:
Да, разработчик должен знать внутреннюю работу оборудования. Сколько зависит от типа разработчика и его целей, доступного времени и личных интересов. Разумеется, приоритет должен быть отдан непосредственным инструментам, методам и т. Д., Которые они используют в своей области. Это мнение похоже на то, чтобы быть хорошо округленным человеком. Чем больше вы знаете о вещах вне вашего ремесла, не жертвуя своим ремеслом, тем лучше.
Это не значит, что вам нужно сходить с ума от Cheese Whiz. Иметь хороший обзор оборудования, как части взаимодействуют, как их используют операционные системы. В связи с этим я предлагаю прочитать концептуальную книгу об операционных системах для всех разработчиков.
Знаю ли я все это? Черт возьми нет. Я забыл столько бесполезной информации о SCSI, что это даже не смешно. Однако узнать об этом было бесценным опытом. Я также забыл много других деталей, связанных с аппаратным обеспечением, но вспомнил важные концепции, которые я узнал из этих знаний.
Итак, я, конечно, предлагаю узнать об оборудовании. Делайте это в разумном темпе, в зависимости от ваших потребностей. Изучите как можно больше деталей, но сосредоточьтесь на концепциях.
Каждый разработчик должен знать основные понятия, связанные с компьютерной инженерией: двоичная арифметика, базовое преобразование, логическая алгебра, логические элементы, состав ЦП (и что делают компоненты), кэш, виртуальная память, сжатие, обнаружение и исправление ошибок ...
Степень, в которой они должны быть известны, зависит от работы программиста. Как уже говорили другие, разработчик встраиваемых систем должен быть гораздо лучше знаком с аппаратными возможностями и тем, как писать программное обеспечение, которое лучше всего использует аппаратное обеспечение, чем, скажем, веб-разработчик.