Про учебу. Не знаю, как раньше, но сейчас как таковым языкам нас не учат...ну сишку борландовскую преподают год (и то скорее не сишку, а ООП посредством сишки), паскаль год, а всё остальное или по ходу обучения на практиках или самостоятельно, НО ведь никто и не говорил и не обещал, что мы должны быть программистами.
Какой толк от менеджера, который знает процесс только по бумажке, а о каких-то ньюансах даже и не догадывается? Почитайте как работает Макдональдс (я его хоть и не перевариваю, но кое-чему у них можно поучиться) - там в руководители выбивается только тот, кто знает ВЕСЬ процесс. Объясню дальше...
Основной упор идет на предметы системного анализа (ЮМЛ, вся фигня), мат.обучение прикладного характера, т.е. в названии Информационные Технологии Проектирования наиболее важное слово последнее. По крайней мере, нам так говорят. И не соглашусь по поводу Паскаля. Он нужен, т.к. он наиболее прост в обучении, а представьте людей, у кого в школе или не было информатики, или на такую информатику без слез не взглянешь? Таким вот и нужен паскаль на первых порах обучения..
UML не фигня, если он используется к месту. Да Паскаль хорош как вантуз, но один год - это слишком. Мое мнение: пол-года - Паскаль (чистка), 2 года - С++ (воспитание) с постоянной практикой до конца жизни.
Далее - С#, Жаба или что кому нравится на выбор (развитие).
А теперь объясняю. Вы, как системотехник, должны спроектировать систему так, что бы при реализации возникло как можно меньше проблем. Так же Вы должны уметь спланировать процесс разработки, учесть все трудозатраты, время на тестирование, багфиксинг, оптимизацию и пр. Т.е. Вы должны не просто знать как выглядит инструмент, но Вы должны сами уметь им пользоваться.
Не зная ньюансов языка вы можете упустить что-то при проектировании, или наоборот - спроектировать систему, слишком кривую для имплементации на требуемом языке/платформе.
В некоторых случаях высокоуровневое проектирование может так и остаться высокоуровневым, т.к. в целях повешения производительности часть кода нужно будет реализовать низкоуровневыми средствами.
Или пример из планирования - как Вы думаете, сколько времени займет написание кросс-платформенной библиотеки для работы с файлами? Можете задавать вопросы - посмотрим сколько Вы насчитаете.
И еще...по поводу качества обучения, могу твердо сказать по своим одногруппникам. Кто хочет учиться - тот будет учиться и у преподавателей хватит квалификации им в этом помочь.
Не хватит. Вас научили рисовать схемы и мыслить системно? Сейчас этого мало. В данный момент работодателя интересует, например, опыт работаты в большой команде. В чем из нижеперечисленного у Вас есть опыт? Слава Богу это не must have, но... Итак:
1. хороший стиль
2. отсутствие предвзятостей в стилях и в программировании вообще
3. поддержка чужого кода
4. умение разбираться с документацией на англ.
5. работа с системами контроля версий
6. микропланирование
7. умение вести базовую документацию
8. создание и поддержка Test Case'ов
Думаю этого начала хватит. Это вещи, которые сейчас реально нужны, ведь эпоха Коболизма уже миновала, но в наших ВУЗах этому не учат.
О QA-фишках, теориях программирования, и прочем вообще помолчим.
Так вот если эти знания пока не так насущны для программиста (кодера), но с каждой ступенькой вверх они становятся MUST HAVE.
Господа, а давайте пригласим сюда представителей ДГМА (завкафедрами и преподавателей) и спросим у них - ДОКОЛЕ?!
