Различия между программированием в школе и программированием в промышленности? [закрыто]

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

Каковы некоторые из различий между программированием в академической среде и программированием в «реальном мире»?

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

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

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

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

В университете...

Ваш учитель дает вам:

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

В реальном мире"...

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

Заключение

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

Они сталкиваются с другим аспектом проблемы:

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

Это различие в «фокусе» - это то, что делает академического мастера на C практически неспособным написать приложение для Windows (так как мы Windows API не в стандарте C99!), Таким образом, чувствуя себя как «неспособное программировать». Но, на самом деле, у него есть все возможности, чтобы узнать, чего ему не хватает. Кое-что, что - без надлежащего академического обучения (не обязательно сделанного в Академии) - довольно трудно найти.

Хорошие ответы. Позвольте мне просто добавить, академическое программирование имеет тенденцию быть почти игрушечным в масштабе. Это хорошо для обучения. Как учитель, вы пытаетесь донести идеи наиболее эффективно. Недостатком является то, что реалистичное программирование настолько качественно отличается, что трудно преодолеть разрыв.

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

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

Этим вещам не учат, и они имеют огромное значение в производительности.

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

Обновление: Как будто кто-то читает мои мысли: ожидания выпускников против реальности ...

Мой дубль, два других фактора:

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

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

Предложение по улучшению обучения программированию : Академия должна больше знакомить нас с реальными ситуациями, не возвращаясь к профессиональному обучению. Врачи должны встретиться с трупом в какой-то момент, чтобы увидеть, «созданы ли они для него» (я слышал истории о том, как люди бросали курс после этого опыта). Если бы я видел в своих ранних двадцатых проект 20K LOC, состоящий из разных стилей программирования, которые я должен был понять за один день и исправить ошибку в трех, я мог бы рассмотреть другие варианты карьеры - хотя, вероятно, нет.

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

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

Изменение философии программирования таким образом, что мы делаем вещи «доказательством Стива», в целом улучшило стабильность нашего приложения.

У меня нулевой личный опыт обучения программированию в школе - я был английским по специальности. Спросите меня о Китсе и Байроне! - но я получил несколько новых оценок, воспитал их и обучил их в мире профессиональной разработки программного обеспечения. Так что я могу говорить с этой точки зрения.

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

Но вы знаете, что? Они приобрели интерес , и это большое дело. Интерес много . Я могу работать с кем-то, кто заинтересован. Я могу превратить их в разработчика, если они придут ко мне с интересом быть им. Черт, это все, с чего я начал. Это и благодарность постмодернистским американским писателям.

В научных кругах

НЕДОСТАТКИ

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

пЛЮСЫ

• У нас достаточно времени для исследований.
• Отклонение от первоначальных целей не доставляет особых хлопот.

В промышленности

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

Проверь это:

http://www.dodgycoder.net/2011/10/how-to-become-better-programmer.html

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

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

Фактически,

невозможно полностью разграничить программирование на академическом уровне и программирование в реальном мире.

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

В зависимости от того, в каком секторе вы работаете, вы должны соблюдать его законы.

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

В общем, вы столкнетесь по крайней мере с несколькими проблемами на предмет в отрасли:

• Применимые законы (например, конфиденциальность клиента для медицинских)
• Тематическое ноу-хау (например, система выставления счетов-фактур, инвентаризация, управление ресурсами, медицинские схемы, отраслевые стандарты)
• Требования клиентов, которые отсутствуют или не существуют или отличаются от отраслевых стандартов / регулирующих законов

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

Единственная реальная разница в том, что проект реального мира

• есть клиент
• имеет бюджеты (время, деньги, людские ресурсы)

Это другая игра с мячом, когда кто-то другой устанавливает правила :)

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

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

Примите требования веб-программирования Microsoft (то есть области, необходимые для того, чтобы кто-то был продуктивным членом команды в организации):

1- C # .NET или VB.NET

2- ASP.NET

3- HTML и CSS

4- SQL Server (или другая база данных)

5- OO прикладное программирование и дизайн

6- Java Script

7- MVC рамки

8- Некоторое воздействие инструментов контроля источников

9- Некоторое знакомство с инструментами автоматического тестирования

Инструмент отслеживания ошибок 10

11-концепции электронной коммерции (необязательно)

12-ОРМ

13-Некоторые навыки бизнес-анализа

14-Некоторые коммуникативные навыки

15-Вероятно, некоторые основы облачных вычислений

Как вы можете видеть, большинство требований, описанных выше, редко фокусируются (вы можете получить не более 1 курса в некоторых) во время обучения в колледже / университете.

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

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

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

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

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

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

Техническое обслуживание и ремонтопригодность

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

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

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