Як би ви пояснили, що інженерія програмного забезпечення є більш спеціалізованою, ніж інші галузі інженерних досліджень? [зачинено]

Я працюю з тим, хто наполягає на тому, що будь-який хороший інженер-програміст може розвиватися в будь-якій технології програмного забезпечення, а досвід певної технології не має значення для створення хорошого програмного забезпечення. Його аналогія полягала в тому, що вам не потрібно мати знання про продукт, який будується, щоб знати, як побудувати конвеєр, який виробляє згаданий продукт.

У чомусь це комплімент, щоб його дивилися оком, таким чином, що "якщо ти хороший, ти добрий у всьому", але певним чином це також досягає професії, як у "Codemonkey, іди прашком". Без досвіду роботи з певними рамками програмного забезпечення ви можете швидко потрапити в проблеми, і це важливо.

Я спробував пояснити це, але він цього не купив. Будь-які різні погляди чи думки з цього приводу допоможуть пояснити, що мій досвід в одній речі не стосується всіх речей?

але певним чином це також реалізує професію, як у "Codemonkey, go sling code".

Я б стверджував зовсім протилежне. Хороший інженер-програміст мав би можливість концептуалізувати, архітектувати та проектувати якісну програмну програму з агностиком технології. Протилежним кінцем цього спектра є лише ". Codemonkey" .NET або Java або PHP, які добре дають напрямки або технічні характеристики та використовують інструмент для реалізації програмного забезпечення.

Інженеру програмного забезпечення не потрібно бути майстром усіх інструментів, але він повинен мати досить гарне розуміння того, що більшість з них є, що вони подають до столу та що, ймовірно, буде найбільш відповідним для даного проекту . Я б очікував, що кодова мавпа буде лише майстром їх проголошеної експертизи в певному інструменті.

Я б не повірив інженеру Ford, який не знає, як робити роботу Механіка.

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

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

Це не досягає простоти, з якою ви можете підібрати нові мови та рамки. Завжди з ними пов'язана крива навчання, але справа в тому, що це крива, а не вертикальна стінка для хорошого інженера-програміста.

Хороший інженер програмного забезпечення має широкий спектр досвіду в багатьох різних інструментах та технологіях. Якщо він цього не робить, як він може вибрати найкращий інструмент для роботи? Щоб вибити стару кліше, людині, яка вміє користуватися молотком, кожна проблема виглядає як цвях. Навіть якщо ви не фахівець з викруткою, вам варто зрозуміти їх, щоб ви могли розпізнати гвинт як не просто кумедний цвях.

Версія TLDR: Інші інженерні дисципліни потребують знання матеріалів, які вони використовують (наприклад, архітектори повинні знати, скільки навантажень можуть перенести матеріали, які вони використовують у своєму дизайні ). Мови та рамки, які ми використовуємо для інженерії програмного забезпечення, мають певні обмеження, і нам потрібно ознайомитись з ними, щоб їх розробляти та ефективно розвивати.

Існує дві чіткі фази того, що ми робимо. Перший - це концептуальна конструкція. Це дизайн системи високого та низького рівня (наприклад, використання UML). Дизайни високого рівня теоретично можуть бути агностичними (хоча іноді дизайн високого рівня повинен враховувати такі особливості, як платформа бази даних, поза проміжним програмним забезпеченням на полицях тощо). Низькорівневі конструкції трохи складніше. Ви можете спроектувати специфіку бізнес-логіки, не вкладаючи в них деталей інфраструктури, і знову це теоретично може бути агностиком платформи.

Другий етап - власне програмування. Хоча одні розглядають програмування як побудову, інші (включаючи мене) стверджують, що кодування все ще є дисципліною дизайну (в ППП Боб Мартін посилається на статтю, де автор висуває дуже хороший аргумент до цього ефекту, я не маю цього мене зараз, але я оновлю цю відповідь посиланням на цю статтю). Фактична конструкція відбувається, коли ви натискаєте компіляцію і фактично є безкоштовною.

Так само, як архітектор повинен враховувати такі речі, як міцність на розрив та стиснення будівельних матеріалів, якими він користується, так і інженер-програміст повинен знати можливості платформи, на якій розробляють, коли пише код. Я заперечую, що дизайн системи низького рівня не дуже ефективний, якщо він також не враховує вибір платформи.

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

Однак, аналогія вашого колеги є помилковою. Розуміння проблем із доменом є важливим для будь-якої інженерної дисципліни. Якщо ви не повністю розумієте проблему, яку ви намагаєтеся вирішити, і людей, яких ви намагаєтеся задовольнити, стає нескінченно складніше побудувати найкраще можливе рішення їхніх проблем.

Зрештою, інженерія програмного забезпечення (і будь-яка інженерна дисципліна) полягає у застосуванні низки концепцій для вирішення проблеми. Якщо ви часто використовуєте одні і ті ж інструменти, ви отримаєте більше знання з цими інструментами. Вам буде простіше визначити проблеми, які ці інструменти можуть вирішити, ризики або помилки з використанням цих інструментів, а потім використовувати ці інструменти для побудови рішення.

Його аналогія полягала в тому, що вам не потрібно мати знання про продукт, який будується, щоб знати, як побудувати конвеєр, який виробляє згаданий продукт.

Це майже напевно невірно. Спеціалістам із виробничого виробництва потрібно дуже багато зрозуміти про продукти, що перебувають під їх доглядом.

У будь-якому випадку, краща аналогія з випускниками курсів машинобудування: хоча всі починають (і в механічному, і в програмному забезпеченні) з майже однаковими навичками, ніхто не залишається "інженером-механіком", а натомість спеціалізується на типах речі, які вони будують. Так само розробка програмного забезпечення також має дуже чіткі підполі.

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

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

Хтось, хто є фахівцем одного типу програмування, може не змогти перейти на інший відразу через різні вимоги. Звичайно, інженер програмного забезпечення має основи для цього, але потрібен час, щоб щось спеціалізуватися.

Я згоден з умовою, яку пропонує ваш колега, хоча я б додав застереження.

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

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

Я думаю, що він насправді має на увазі те, що лише тому, що розробник має надійний досвід C # за два роки, це не означає, що кращий програмний інженер з Явою, який ніколи не робив C # раніше, не міг прийти разом, вивчити C # і швидко стати кращим розробником C #, ніж перший хлопець.

Іншими словами, вам не обов’язково знижувати хлопця Java на роботу, ДАЛЕ, оскільки він "провів час" у C #.

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

Я працюю в вертолітній компанії, а авіаційні інженери тут спеціалізуються на типах літаків, з якими вони можуть працювати. Вони повинні бути "типними". Технічно вони могли працювати над чим завгодно: від Robinson R22 до Jumbo Jet, але не без підготовки до перетворення.

Я думаю, що це дуже схоже на інженерію програмного забезпечення, за винятком того, що "навчання конверсії" є більш неформальним для інженерів програмного забезпечення.

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

Вивчення нової мови або специфіки для нового домену схоже на художника, який передусім займається олівцем та чорнилом, навчившись малювати (або навпаки). Це те, про що говорить більшість інших відповідей, як ваш друг частково правильний - застосовується багато одних і тих же понять.

Але навчити художника як ліпити 3D-об’єкт чи написати роман (Обидві форми художньої виразності) - це зовсім інший звір. Ось така точка зору, звідки ви виходите.

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

Короткий зміст та приклади:

"Мистецтво" включає скульптури, романи, комікси та картини. Перекриття навичок включають:

• Тела форми і кольору тіла: скульптури, комікси та картини
• Текстове спілкування: романи та комікси

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

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

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

Чи всі працівники дорожнього будівництва можуть користуватися кожним обладнанням та технікою на робочому місці? Відповідь - ні. Є машини, які вони знають і, ймовірно, знайомі з іншими. Це саме стосується інженерів програмного забезпечення, там x кількість мов та фреймворків, яких ви знаєте, оскільки ви працюєте з ними щодня, але не слід очікувати, що вони знають точні операції інших без певної підготовки. Це як взяти робітника з відбійним молотком і призначити йому завдання водіння цементного змішувача.

Мови програмування та рамки - це лише інструменти в поясі інструментів інженерів програмного забезпечення. Є кілька інструментів, які ви будете знати краще за інших через досвід. Зрештою, найкращим інструментом є розуміння основних понять та принципів обчислень. Вибір мов та рамок - це лише вибір того, який викрутка використовувати на якому гвинті.

Такі речі трапляються багато, де я працюю.

Мені подобається порівнювати з професією дядька моєї дружини - автомеханіком.

Він спеціалізується на Mercedes, він може застосувати свої знання до інших марок автомобілів, і він це робить - деякі з них досить рідкісні, але це не означає, що він може негайно відремонтувати зробити X, оскільки ти кажеш, що це робить шум.

Я програмую на декілька мов, але це не означає, що я знаю, чому Safari на вашому MacBook перезавантажує сторінки щоразу, коли ви змінюєте вкладку (сьогодні дивний дзвінок). Я спробую розібратися, чому, але я не збираюся знати це вгорі голови, оскільки обчислювальне поле ВЕЛИЧЕЗНО .

В обох випадках, витративши деякий час на перегляд наших відповідних полів, ми, мабуть, могли б розробити відповідь, але не за десять секунд, про які думають люди, бо "але ти працюєш з автомобілями" або "але ти працюєш з комп'ютерами".

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