Как бы вы объяснили, что разработка программного обеспечения более специализирована, чем другие области разработки? [закрыто]

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

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

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

но в некотором смысле это также упрощает профессию, как в «Codemonkey, go sling code».

Я бы сказал, совсем наоборот. Хороший инженер-программист будет способен разрабатывать, проектировать и разрабатывать программное обеспечение независимо от технологии. Противоположным концом этого спектра является «кодовая обезьяна» только для .NET, Java или PHP, которая хороша в заданных направлениях или спецификациях и использует инструмент для реализации программного обеспечения.

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

Я бы не стал доверять инженеру Ford, который не знает, как выполнять работу механика.

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

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

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

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

Версия TLDR: другим инженерным дисциплинам необходимо знание материалов, которые они используют (например, архитекторы должны знать, какую нагрузку могут выдержать материалы, которые они используют в своем проекте ). Языки и платформы, которые мы используем для разработки программного обеспечения, имеют определенные ограничения, и мы должны быть знакомы с ними, чтобы эффективно проектировать и разрабатывать их.

Есть два этапа в том, что мы делаем. Первый - это концептуальный дизайн. Это высокоуровневый и низкоуровневый дизайн системы (например, с использованием UML). Проекты высокого уровня теоретически могут не зависеть от реализации (хотя иногда проект высокого уровня должен учитывать такие особенности, как платформа базы данных, промежуточное программное обеспечение с полки и т. Д.). Проекты низкого уровня немного сложнее. Вы можете спроектировать специфику бизнес-логики, не вкладывая в них детали инфраструктуры, и опять же, теоретически они могут не зависеть от платформы.

Второй этап - актуальное программирование. В то время как некоторые рассматривают программирование как конструкцию, другие (включая меня) утверждают, что кодирование по-прежнему остается дисциплиной проектирования (в PPP Боб Мартин ссылается на статью, в которой автор выдвигает очень хороший аргумент на этот счет, у меня его нет я сейчас, но я обновлю этот ответ со ссылкой на эту статью). Фактическая конструкция происходит, когда вы нажимаете на compile и фактически свободна.

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

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

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

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

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

Это почти наверняка неверно. Специалисты-технологи должны разбираться в продуктах, о которых они заботятся.

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

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

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

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

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

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

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

Я думаю, что он на самом деле имеет в виду, что тот факт, что разработчик имеет 2-летний опыт работы с C #, не означает, что лучший инженер-программист с Java-опытом, который никогда раньше не занимался C #, не мог прийти, изучить C # и быстро стать лучшим разработчиком C #, чем первый парень.

Другими словами, вы не обязательно должны сбрасывать со счетов парня из Java за работу, просто потому, что он «сделал время» в C #.

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

Я работаю в вертолетной компании, и авиационные инженеры здесь специализируются на типах самолетов, с которыми они могут работать. Они должны быть «оценены по типу». Технически они могли работать на чем угодно, от Robinson R22 до Jumbo Jet, но не без подготовки к переоборудованию.

Я думаю, что это очень похоже на разработку программного обеспечения, за исключением того, что «обучение конверсии» более неформально для разработчиков программного обеспечения.

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

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

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

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

Резюме и примеры:

«Искусство» включает в себя скульптуры, романы, комиксы и картины. Навыки перекрытия включают в себя:

• Форма тела и теория цвета: скульптуры, комиксы и картины
• Текстовое общение: романы и комиксы

... И так далее. Но, как упоминалось выше, комический художник вряд ли преуспеет в своем первом романе. Они должны думать по-другому.

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

• Алгоритмы: ОС / интегрированные системы, игры и другие места, которые вам часто нужно оптимизировать для скорости или памяти. Редко большое дело в веб-разработке
• Дизайн: везде в веб-разработке, но не очень важно в интегрированных системах без пользовательского интерфейса.
• Клиент-серверное программное обеспечение: менталитет «не доверяй клиенту», который не обязательно существует в некоторых доменах (игры для одного игрока и другое автономное программное обеспечение для настольных компьютеров, которое, как я признаю, в наши дни встречается реже).

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

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

Такого рода вещи часто случаются там, где я работаю.

Мне нравится сравнивать с профессией дяди моей жены - автомехаником.

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

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

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

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