Ответ 1
Мне еще предстоит найти хороший курс CompSci, который надлежащим образом готовит инженеров-программистов для работы. Если вы найдете тот, у которого есть следующие [хотя его можно назвать CompSci, я сомневаюсь, он больше похож на Real-World Software Design, который является совсем другим зверем].
Информатика - это более теоретический предмет, который имеет очень реальные последствия для мира, но более полезен в академическом свете. Дизайн алгоритма, к примеру, фантастически полезен для инженеров-программистов, но на самом деле он не очень полезен для потребителя. Например, знание того, как построить алгоритм быстрой сортировки или понимание обхода связанного списка, на самом деле не так полезно в сегодняшней среде разработки программного обеспечения - конечно, понимание теории полезно для выбора правильных инструментов для работы, не поймите меня неправильно, Как разработчики, многие из нас полагаются на выход в мир компьютерных наук, чтобы продвигать наши инструменты разработки, на самом деле, без них многие разработчики оставались бы барахтающимися, но выставляли выпускников компьютерных наук перед пользователем и заставляли их разрабатывать значащее программное обеспечение для них и академический интеллект будут падать на куски, потому что они говорят на разных языках.
Гораздо более полезный курс для инженеров-программистов будет включать в себя как можно больше [и, возможно, больше] из следующих компонентов, которые я могу представить себе с головы:
- Язык программирования - базовый поток программы, парадигмы, синтаксис и т.д. Это в основном преподается довольно хорошо, поэтому я не буду слишком сильно зацикливаться на этом. Хотя было бы полезно, если бы преподавали несколько совершенно разных классов языков программирования - например, я изучил C, Pascal и VB 3 ( "Я не помню точной версии" ). Было бы более полезно, если бы программисты изучили по крайней мере один функциональный язык, один императивный язык, один декларативный язык.
- Отладка. При написании приложений nTier [которые используются в большинстве/большинстве реальных приложений мира] было бы полезно узнать, где что-то идет не так, вплоть до уровня протокола, если необходимо. Для этого полезны инструменты анализа, такие как WireShark.
- Коммуникационные устройства - XML, XQuery, XPath, XSL, XSD [поскольку они, кажется, используются так широко).
- Реляционная конструкция базы данных. Об этом достаточно хорошо сказано.
- Настройка производительности реляционной базы данных. Простое проектирование таблиц недостаточно, зная, когда нужно индексировать определенные поля, а когда это не так важно и, похоже, не покрывается много курсов.
- Нормализация данных. Во многих случаях это также хорошо объясняется. Хотя большинство студентов, похоже, выходят в реальный мир, извергая теории, которые им преподавали, - "всегда будьте привычны к нормальной форме Boyce-Codd" и т.д., Не задумываясь о последствиях этих теорий. Иногда в реальном мире у нас очень хорошие причины нарушают правила.
- Оптимизация запросов. Написание базовых запросов часто, по-видимому, находится на внешних границах зон комфорта выпускников, оптимизация должна преподаваться. Кроме того, инструменты, такие как профилировщики запросов, должны преподаваться, чтобы помочь студентам отладить проблемы производительности с приложениями.
- Хранимые процедуры/триггеры. Я еще не встречал ученика, который мог бы написать хранимую процедуру или триггер или использовать один из них эффективно. Выбор/Объединение/Вложенные выборки, по-видимому, являются предел того, чему учат, когда дело доходит до дизайна запроса.
- Основные алгоритмы. Это хорошо сказано в моем опыте, но многие студенты, похоже, не имеют представления о том, как решить, какие алгоритмы применяются к ситуациям, не говорящим "используя такие и такой алгоритм, решить эту проблему". Было бы полезно, если бы вы могли сказать "решите эту проблему", и они вроде бы, ладно, у меня есть алгоритм, который был бы полезен в этой ситуации, это лучше всего из-за x, y или z и вот как это можно применить для обеспечения решения.
- Рекурсия. Мне еще предстоит найти подход, который может научить рекурсии, кажется, что либо вы его получите, либо нет. На днях я найду хорошую метафору, которая позволит понять это даже самым базовым программистом.
- Абстрактные- Это похоже на то, что многие курсы затушевывают, несмотря на то, что они являются одним из основных принципов ООП.
- Рефакторинг кода. Знать, когда рефакторировать и почти так же важно, когда не нужно.
- Повторное использование кода. Похоже, что много курсов выплевывают обезьяны с вырезами/вставкой - это не значит, что нужно использовать повторное использование кода!
- Контроль источника. Я не узнал об источнике управления до моего третьего или четвертого задания на программирование, и я не знаю ни одного специалиста по программному обеспечению, который изучил управление источниками как часть своего курса... почему это?
- Резервное копирование и восстановление. Я не слышал о каких-либо курсах, которые преподают это. Сколько начинающих программистов потеряли всю свою работу, потому что они просто не думали о ее поддержке? Я знаю, что у меня было в прошлом - совсем недавно. Это не то, что я не знал о поддержке, но, как говорится, "со мной это никогда не случится". Это случится с вами, и вы гарантируете, что это будет прямо перед тем, как вы сможете демонстрацию всего, что вы только что потеряли.
- Обслуживание файловой системы. Ладно, некоторые из этих курсов немного затушевывают, но многие этого не делают.
- Написание спецификаций хорошего качества. Это всегда представляется как краткое из курсовой работы, но ученика редко просят самим спроектировать. Написание рабочей области и понимание шаблонов документов, по-видимому, далеко за пределами большинства программных курсов.
- Документация пользователя. Пользователи не думают, как вы, передавая им программное обеспечение, которое "самоочевидно" или "так просто, что идиот может его использовать" взорвется вам в лицо. Там известная поговорка о том, что "Программирование сегодня - это гонка между инженерами-программистами, которые стремятся построить больше и лучше идиот-защищенных программ, а Вселенная пытается создать больше и лучше идиотов. Пока вселенная побеждает". Напишите пользовательскую документацию, которой может следовать 8-летний возраст - может показаться болезненным ее написать, но как только это будет сделано, и еще больше, вы будете благодарить себя.
- Техническая документация - то есть было бы полезно, если бы студенты могли использовать Sandcastle, nDoc или любые инструменты документации.
- Планирование тестирования - разработка тестов и программного обеспечения, которое позволяет тестировать. nUnit или подобное было бы отличным инструментом для обучения на курсах по разработке программного обеспечения. На самом деле, преподавание любой структуры тестирования было бы лучше, чем не преподавание каких-либо... как будто это так.
- Тестирование FAT/SAT/UAT. Было бы полезно понять различные сценарии тестирования в реальном мире, такие как проверки работоспособности, приемочные тесты factory и тестирование приёма пользователей. Выйти для вашего программного обеспечения так же важно, как и его разработка. Если вы не доставляете то, что, по мнению клиента, они получают, вам не платят - как бы блестящим ни было ваше решение на техническом фронте.
- Архитектура программного обеспечения - понимание различных компонентов приложений n-уровня реального мира, преимуществ и недостатков их использования.
- Взаимодействие с пользователями. Возможно, это не компьютерная наука, а научиться разговаривать с людьми, которые не часто бывают на вашей длине волны и не думают так же, как вы, идет с коммуникацией, но на самом деле что-то нужно знать разработчикам.
- Common Sense - Дин, динг, динг, динг - там много программистов без унции! Курсы предназначены для того, чтобы доказать, что вы можете думать сами за себя, я не понимаю, почему так много выпускников приходят в реальный мир, думая, что все, что им нужно сделать, это применять правила, которые они преподавали вслепую, не задумываясь о причинах и последствиях. Я повторю то, что я сказал ранее - в реальном мире мы иногда находим очень веские причины для нарушения правил. Мы не следим за ними слепо, и мы тоже не сломаем их. Разработка программного обеспечения - это искусство, и, как и все искусства, мы должны знать, когда можем и не можем и так же важно, когда мы должны и не должны нарушать правила. Как выпускник, вы узнали правила, вы это доказали. Теперь вам нужно сделать то, что курс действительно пытался вас научить, - примените то, что вы научились думать самим.
- Прослушивание- Вы были бы удивлены, сколько раз я вижу код, написанный, потому что разработчик "думал, что они знают, чего хочет клиент", вместо того, чтобы фактически слушать то, что говорит пользователь, и понимать их реальные потребности.
- Понимание - идет рука об руку с прослушиванием.
- Коммуникационные навыки
- Разговор с технически неумелым - то есть значительная часть вашей пользовательской базы
- Продвижение проекта - продажа ваших идей тем, кто пишет проверки.
- Приоритезация - как решить, какие функции важнее других.
- Бюджетирование - оценка времени
- Управление временем - как это сделать вовремя, когда все вокруг вас мешают вашему времени и не заботятся о ваших крайних сроках. Так же, как когда все ваши друзья хотят, чтобы вы отправились в паб на пинту или десять, когда у вас есть кусочек работы, вы еще не начали работу до конца дня завтра.
- Ползучесть области - когда сказать, что нет, это не в спецификации/бюджете.
И даже если вам удалось узнать все это в своем курсе, я полагаю, что вы все равно узнаете больше через три-четыре месяца о стажировке в консалтинговой компании по разработке программного обеспечения достойного callibre, чем на всем курсе. Я узнал больше в первые шесть месяцев после моего бакалавра, чем в течение всего трехлетнего курса. По общему признанию, я бы упал на свое лицо без многих вещей, которые я узнал на этом курсе, но было так много, что было обучено без необходимости, которое могло быть заменено гораздо более полезным контентом.