Почему этому не учат в школе? [закрыто]

За лето мне посчастливилось попасть в Google Summer of Code. Я многому научился (возможно, больше, чем я узнал в сумме всех моих университетских курсовых работ). Мне действительно интересно, почему они не учат некоторым вещам, которым я научился раньше в школе. Назвать несколько:

• модульное тестирование
• контроль версий
• гибкое развитие

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

Не поймите меня неправильно, я не думаю, что для университетов желательно всегда преподавать самые модные прихоти программирования, но разве мои профессора не должны учить меня чему-то другому, кроме «рисовать диаграмму, прежде чем начинать писать код»?

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

Например, несмотря на недавние достижения в области материаловедения, инженеры-строители около 2000 лет знали, как построить арку, которая не упадет, и это то, чему можно научить и чему научиться в университете с относительно небольшими спорами. Хотя я полностью согласен с вами в отношении методов, которым должны овладеть разработчики программного обеспечения, это соглашение основано на личном опыте и неформальных рассуждениях. Чтобы быть общепризнанной «лучшей практикой», нам нужны количественные данные, сбор которых может быть очень дорогим: насколько помогает контроль версий? Как это помогает? Модульное тестирование? Мы можем рассуждать об эффективности различных техник, но на самом деле убедительное доказательство этой эффективности будет очень дорогостоящим. Нам нужно будет запустить полный реалистичный программный проект от начала до конца, много раз, с группами программистов, которые имеют одинаковый опыт и используют разные методы. По крайней мере, нам понадобится много данных о существующих проектах, которые эти проекты не захотят выпускать.

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

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

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

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

Потому что наши учителя:

1. Никогда не пробовал модульное тестирование,
2. Не знаю, как использовать контроль версий и
3. Даже не слышал об «гибкой разработке».

Студенты должны взять дело в свои руки. Мы сделали это, и все получилось хорошо, не так ли?

Леонардо да Винчи писал:

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

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

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

Университеты склонны больше полагаться на «науку» (алгоритмы, структуры данных, компиляторы и т. Д.), Потому что эти вещи гораздо более «вневременные», чем текущие передовые практики отрасли, которые, как правило, развиваются и изменяются из года в год. Например, система управления версиями претерпела поразительные изменения за последние 5 или 10 лет, но big-O по-прежнему остается большим, а хеширование, b-деревья и рекурсия по-прежнему так же полезны, как и 40 лет назад. Их идея, как правило, состоит в том, чтобы дать вам достаточно основы, чтобы вы могли затем подобрать такие инструменты, как git, и понять, что это значит, когда вам говорят, что основная структура данных представляет собой ациклический направленный граф хэшей SHA-1, и что разработчики много работали. чтобы оптимизировать количество системных вызовов, чтобы он был привязан к io.

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

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

Колледж предоставляет вам набор инструментов, полный инструментов. Это отвертка, то есть гаечный ключ в форме полумесяца. Вы МОЖЕТЕ использовать каждый инструмент один раз в колледже. Когда вы входите в реальный мир, вы действительно узнаете, что у вас есть. Вы отсортировываете полезные от остального, какие хотите оставить дома на верстаке на всякий случай, а те, которые держите в кармане каждый день.

Tqm, Iso, Cmm, Agile и т. Д. Это все причуды, они приходят и уходят, ни один из успешных из них не является чем-то большим, чем просто здравым смыслом. Все успешные инженеры и компании руководствуются здравым смыслом, и это то, что сделало их успешными, мало кто нуждался в названии. Проблема в том, что нельзя продавать здравый смысл, менеджер не может доказать свою ценность для компании, обучая и покупая здравый смысл без запоминающегося имени. Назовите его так, чтобы его начальство прочитало в какой-нибудь новостной статье или журнале, и менеджер останется на своей работе, а вы - на своей. Очень немногие из компаний, которые заявляют, что следуют этой практике, на самом деле это делают. Большинство выписывают чек консультанту и получают свой годовой или пожизненный сертификат в какой-либо клуб, чтобы они могли разместить изображение на своем веб-сайте или этикетку на коробке, в которой поставляется их продукт. Многие будут утверждать, что это редко ... был там, видел, такое бывает. Все это часть бизнеса, иногда приходится срезать углы, чтобы оставаться прибыльным, держать двери открытыми и свет включенным. Хардкорные последователи всех этих практик все утверждали, что последний был увлечением, а этот - нет, последний действительно был слишком дорогим, чтобы следовать, а этот - нет. Последний был фальшивым, вы только что наняли консультанта, этот настоящий. Как и языки программирования, они тоже будут развиваться. Последний был фальшивым, вы только что наняли консультанта, этот настоящий. Как и языки программирования, они тоже будут развиваться. Последний был фальшивым, вы только что наняли консультанта, этот настоящий. Как и языки программирования, они тоже будут развиваться.

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

Почему люди думают, что cmm, agile или что-то еще - причуда? Почему они думают, что это не так? Почему профессор так учил вас программе? Чтобы избежать gotos или избежать констант или избежать того и этого? Это потому, что он производит более надежный код? Более эффективный код? Уменьшает человеческий фактор? Или это потому, что работы / программы легче оценивать, давая им больше времени на исследования? Это потому, что они не знают, как программировать, и просто следят за чьей-то книгой по этому поводу? Они учили вас, что у вас не может быть обслуживаемого, надежного и высокопроизводительного кода? Невозможно даже "выбрать два" ремонтопригодных, мешает и надежная, и высокая производительность? Иногда вы жертвуете надежностью ради производительности. Иногда вы не заботитесь о надежности или производительности, вы просто хотите получить версию 117.34. 2 еще одной бухгалтерской программы до версии 118.0.0. Ваша бизнес-модель основана на продаже обновлений версий и технической поддержке, и что касается разработчиков программного обеспечения, любой старый робот может писать тот же код таким же образом. Замени сгоревший на новый, окончивший колледж, и продолжай продавать обновления.

На эти вопросы нет универсальных ответов, нужно узнать свое мнение, смириться с ним и отстаивать его. Измените свое мнение, живите с этим и защищайте его.

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

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

Мир внутри и за пределами университета примет эти формулы (cmm, agile и т. Д.) Для решения проблем, и когда выйдет следующая, они так же быстро откажутся от них. Вам не обязательно использовать контроль версий, чтобы добиться успеха, есть столько же успехов, как и без него (ну, на самом деле, из-за возраста отрасли до сих пор гораздо больше успехов без контроля версий). Точно так же вы можете добиться успеха с минимальным тестированием (посмотрите на действительно громкие имена в компьютерной индустрии в качестве примеров). Вы можете добиться успеха, тестируя свой собственный код, а также добиться успеха, следуя правилу, согласно которому вы никогда не должны тестировать свой собственный код. Вы можете добиться успеха, используя emacs, и вы можете добиться успеха, используя vi. Вы должны решить, какой микс вам подходит, и, если вам повезет, найти подходящее вам место для работы.

Когда вы заканчиваете колледж и попадаете в реальный мир, слушайте, работайте и спорьте с «старожилами». У них десятилетия или столетия совместного опыта, ловушки, в которые они попадались, которые вы можете избежать или протестировать самостоятельно (возможно, вы понимаете, что не нужно прикасаться к горячему горшку, чтобы узнать, что он вас обожжет). Многие увидят, по крайней мере, одна или две из этих причуд, которые приходят и уходят, и в частности, как сильно они были сожжены и что они сделали, чтобы оправиться от этого. Они знают много разных способов тестирования, а также названия стилей тестирования, которые пришли и ушли. Что работает, а что нет. Где есть риск и как не тратить время на пустяки. Когда вы повзрослеете и станете старожилом, продвигайте его вперед. Платите за то, что вы узнали, пытаясь научить тех, кто следует за вами. Не забудьте научить их, КАК ловить рыбу, не давайте им рыбу. И иногда вы должны позволить им потерпеть неудачу, прежде чем они добьются успеха, чтобы они не обгорели слишком сильно.

Я действительно хотел сказать, что прямо сейчас мы находимся в редкой ситуации, когда мы можем стать свидетелями эволюции параллельной вселенной (и, возможно, повлиять на нее). Да, информатика - молодая наука по сравнению с физикой. Но в то же время он многократно эволюционировал. В зависимости от того, где вы работаете и с кем работаете, вы можете наблюдать за инженерами по аппаратному обеспечению. Языки программирования в мире аппаратного обеспечения, конечно, не новы, но они не развивались так быстро, как мир программного обеспечения. У программного обеспечения было преимущество в несколько десятилетий. Аппаратное обеспечение всегда считало программистов людьми второго сорта. Наша работа легкая, их работа тяжелая. (Обратите внимание, что я на самом деле инженер по аппаратному и программному обеспечению). Интересно то, что прямо сейчас они все еще имеют дело с тем, что мы считаем элементарными или инфантильными проблемами. Зачем мне использовать контроль версий, я единственный, кто работает на этом чипе. Ваш опыт работы с gcc или другими дешевыми компиляторами или бесплатными IDE вряд ли может сравниться с дорогими инструментами, которые я использую, если бы компания считала, что вы достаточно достойны, чтобы использовать их, или даже знала, как их использовать, они бы купили вам копию. И длинный список других отговорок. Я имел удовольствие изучить и vhdl, и verilog, и стал продуктивным в обоих в течение недели после того, что было почти вызовом такого инженера по оборудованию (несмотря на то, что в моем дипломе говорилось, что инженер-электрик, моя должность - инженер-программист). Я хотел изучать эти языки, когда инструменты были доступны для меня, я оставался в офисе до ночи и учился сам. С этого момента этот инженер, в частности, понял, что то, что я говорю, было правдой, языки - это просто синтаксис, основы программирования одинаковы, все инструменты делают одно и то же. Это яблоки и яблоки, а не яблоки и апельсины.

В целом, хотя по-прежнему трудно сказать, что одна из этих двух параллельных отраслей имеет гораздо больший опыт в языках, программировании, управлении версиями, тестировании, инструментах, средах программирования и т. Д., Чем другая. Проблема, которую я пытаюсь решить, состоит в том, чтобы взять проектирование оборудования по мере их разработки, создать доступные функциональные симуляторы, которые мы можем связать с симуляцией (виртуальной машиной) процессора, чтобы мы могли начать тестирование оборудования и разработку теста и поставляемое программное обеспечение задолго до того, как мы перейдем к кремнию. Нет, в этом нет ничего «нового», но у нас нет механизма, чтобы получить последний код, отслеживать изменения в коде, чтобы увидеть, на чем нам нужно сосредоточить свое время. Нет механизма отслеживания документации, определяющей пользовательский (программный) интерфейс к оборудованию. Одна золотая копия находится в чьем-то почтовом ящике в двоичной форме и изменяется только тогда, когда, ну, вам не нужно читать verilog, чтобы узнать, что происходит. Подожди, сколько лет этому верилогу? Вы выяснили и исправили ту ошибку, на которую я потратил всю неделю? Так что, если мы просто полетим в какое-то место для отпуска и повеселимся на шесть месяцев, ожидая, пока специалисты по аппаратному обеспечению закончат свою задачу и бросят ее нам, или мы воспользуемся этой возможностью, чтобы проявить терпение и оптимизм и научить их тому, что они есть методы здравого смысла, которые не настолько навязчивы, что позволяют им как выполнять свою работу, так и делать резервную копию своей работы, а также делиться своими материалами для экспертной оценки ... этому верилогу сколько лет? Вы выяснили и исправили ту ошибку, на которую я потратил всю неделю? Так что, если мы просто полетим в какое-то место для отпуска и повеселимся на шесть месяцев, ожидая, пока специалисты по аппаратному обеспечению закончат свою задачу и бросят ее нам, или мы воспользуемся этой возможностью, чтобы проявить терпение и оптимизм и научить их тому, что они есть методы здравого смысла, которые не настолько навязчивы, что позволяют им как выполнять свою работу, так и делать резервную копию своей работы, а также делиться своими материалами для экспертной оценки ... этому верилогу сколько лет? Вы выяснили и исправили ту ошибку, на которую я потратил всю неделю? Так что, если мы просто полетим в какое-то место для отпуска и повеселимся на шесть месяцев, ожидая, пока специалисты по аппаратному обеспечению закончат свою задачу и бросят ее нам, или мы воспользуемся этой возможностью, чтобы проявить терпение и оптимизм и научить их тому, что они есть методы здравого смысла, которые не настолько навязчивы, что позволяют им как выполнять свою работу, так и делать резервную копию своей работы, а также делиться своими материалами для экспертной оценки ...

Помните, что инженеры по аппаратному обеспечению, как и вы, закончили колледж с коробкой блестящих новых инструментов. Вы выучили 17 различных языков программирования, из которых вы можете использовать только один, остальные языки, которые вы в своей карьере придумаете, будут изобретены после того, как покинете колледж. По окончании колледжа они могут рассказать вам, что они знают об исчислении и теории относительности, сколько электронов находится в каждом из элементов, и вычислить заряд вокруг гауссовой поверхности. Но основная часть их карьеры - это единица, ноль и или и не (эй, у нас есть общие черты, все, что вам действительно нужно знать о компьютерах, единица, ноль и, или, а не аппаратный или программный инженер). Конечно, фундаментальные законы физики, исчисления и электронов не изменятся так быстро, как языки программирования. Но основы программирования одинаковы для всех языков и сохранятся в будущем. Вы ушли из колледжа, зная об этом, или ушли, думая, что Java отличается и лучше, чем C ++, потому что то, то и другое?

Как и в любом другом бизнесе, работа университетов - оставаться прибыльными. Они должны нанимать подходящих ученых, чтобы они приносили и нужных студентов, и нужные доллары на исследования, и нужные виды исследований, чтобы сделать университет прибыльным. Они должны предлагать подходящие классы, чтобы привлекать нужных студентов и выпускать нужных выпускников, чтобы по прошествии десятилетий работодатели как рядом с университетом, так и, надеюсь, находились далеко, осознали, что этот университет производит продуктивных и прибыльных сотрудников. (да, и иногда вам нужно привлекать подходящих спортсменов к правильному виду спорта, чтобы получить нужное количество времени на телевидении и нужное количество узнаваемости имени и дохода от спорта). Некоторые университеты будут преподавать C ++ и Java, а некоторые никогда. Кто-то изобретет CMM, кто-то будет обучать Agile, кто-то не будет делать ни того, ни другого. Если университет вообще имеет какую-то ценность, вам есть чему поучиться. Они не научат вас всему, чему можно научиться, но у них будет что-то полезное. Узнай что-нибудь, пока ты там, собери разумное количество различных инструментов в свой ящик для инструментов. Бросьте университет и устройтесь на работу. Если ваш набор инструментов - отстой, возможно, найдите другой университет и никогда не упоминайте первый. Если это подходящий ящик для инструментов, используйте эти инструменты и создайте новые в удобное для вас время. Если это неплохой набор инструментов, говорите хорошие вещи об этом университете и хороших академиках, у которых вы узнали то и это, и отплатите школе за то, что они вам дали. Даже если вы не получили все возможные инструменты в универсальном каталоге университетских инструментов, вы уйдете с определенным подмножеством. Даже если ты не закончишь школу ...

Я учил этим вещам, когда работал адъюнктом в Технологическом институте Орегона. Их учат, но очень редко.

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

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

о боже, не заводи меня

однажды у меня был декан cs в уважаемом университете, который сказал мне, что объектно-ориентированное программирование - это просто `` прихоть '', поэтому они не предлагали никаких классов для передачи таких фантазий, как C ++

Что касается того, почему они не учат этим вещам, ну, колледж существует, чтобы научить вас основам дисциплины, не обязательно лучшим практикам отрасли

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

Однако контроль версий - это то, что в наши дни непростительно. Это то, что каждый должен понимать. Это инструмент, который почти так же полезен, как компилятор, а CVS существует уже около 20 с лишним лет. По крайней мере, эти концепции должен понимать любой программист, покидающий университет. К счастью, если вы занимаетесь какой-либо групповой работой в университете, вам может посчастливиться встретиться с кем-то, кто уже знает о контроле версий и убеждает вашу группу использовать его. Я знаю, что рада, что этот человек был в моей группе.

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

Почему бы и нет? Мой опыт получения степени CS был почти таким же. Причина в том, что люди, которые преподают программирование, не программируют, насколько я могу судить. Необязательно преподавать этот материал для аккредитации, учителя не знакомы с этим, и студенты никогда не разрабатывают какие-либо проекты в рамках своей курсовой работы. На самом деле нет мотивации обучать программированию, в отличие от преподавания теории CS или синтаксиса Java.

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

Это зависит от вуза. Я закончил австралийский университет в 2003 году. За это время мы изучили UML, модульное тестирование, XP (и другие гибкие методологии), а также все формальные вещи, такие как Z, алгоритмы и структуры данных, операционные системы и т. Д.

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

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

Я полностью согласен с тем, что сказал Глиф. CS - настолько незрелая область, на самом деле только за последние 50 лет, что мы не знаем, что нам следует изучать, а что является лишь преходящим увлечением. Дайте ему 150 лет, и тогда все может немного успокоиться. Количество неудачных проектов в реальном мире делает очевидным, что это незрелая отрасль. Представьте, если бы 80% строительных проектов провалились!

Все это можно легко (поверхностно) осветить в одном классе по методам разработки программного обеспечения. Это не входит в большинство учебных программ по CS, потому что это не то, о чем CS, хотя я действительно думаю, что некоторое освещение этого материала полезно. В моей школе был такой класс; он не охватывал контроль версий, но он охватывал UML, сбор требований, методологии разработки (различные гибкие и каскадные), модульное тестирование, интеграционное тестирование и т. д. и требовал от нас работы в группах по 4-5 человек для разработки проекта. (довольно простая копия Clue на Java). Если вы почувствовали потребность в дальнейших курсах программной инженерии, они были доступны как факультативные.

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

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

Помните, что в колледже есть множество способов научиться чему-то вне уроков; воспользуйтесь этим. Вы много платите, чтобы посещать занятия и пользоваться оборудованием, поэтому доите его изо всех сил и ходите на собрания LUG и ACM, участвуйте в проектных группах (всегда есть ME, которые создают робота, которому нужен программист), или получите работа по администрированию сервера гуманитарного факультета. Соберите компьютер в мусорном доке здания материаловедения, загрузите ISO-образ Linux с быстрым подключением к Интернету в общежитии и поиграйте.

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

В нашем курсе нас учили Personal Software Process, который охватывал такие вещи, как запись времени, затраченного на проекты, хорошее комментирование и т. Д., Но без упоминания профессиональных основ, таких как контроль версий.

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

то же самое и с модульным тестированием - зачем выбирать модульное тестирование? Несомненно, более важным является тестирование удобства использования, системное тестирование, пользовательское и заводское приемочные испытания? Ну, если вы не считаете свою работу завершенной после того, как код будет отправлен в отдел обслуживания :)

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

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

Вышеупомянутые «мягкие навыки» не нужны для написания хорошего кода.

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

Я выучил все это в университете. Возможно, это зависит от выбранных вами курсов? Мои курсы были очень разнообразными (дизайн программного обеспечения, дизайн пользовательского интерфейса, электронная коммерция, искусственный интеллект, функциональное программирование и т. Д.). В Software Design были знакомы с шаблонами проектирования и модульным тестированием (один большой проект, который включал разные вещи). Дизайн пользовательского интерфейса ... мы были группой из трех человек, работающих над проектом. Мы ничего не могли сделать без контроля версий, так что мы получили это. Наши профессора постоянно рассказывали нам о гибкой разработке, но они предоставили каждой группе право использовать ее.

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

Чтобы ответить, почему этим вещам не учат в первую очередь: программы бакалавриата обычно обучают вас, чтобы стать студентом магистра. Только после того, как вы начнете выбирать свои собственные курсы (что обычно происходит в более поздние годы), вы можете узнать о вещах, используемых за пределами академических кругов. Вот почему они сосредоточены на алгоритмах, структурах данных, представлении вам нерешенных проблем и т. Д.

Я лично считаю, что это нормально, что они это делают. Программирование не так просто, как многие из нас думают; многие люди борются с этим. Я бы предпочел, чтобы эти люди сначала поняли, как работает цикл for, прежде чем выяснять, что такое Perforce.

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

Я выучил все это на первом курсе, за исключением гибкой разработки.

ИМХО, все дело в выборе подходящей школы. Если вы попадете в топ-10, вы быстро научитесь всему этому.

Что касается CS Education в целом, мы просим профессоров преподавать очень много (языки любого типа, структуры данных, эффективность времени выполнения, как вещи на самом деле работают на битовом уровне). Я хотел бы задать вопрос: почему бы детям не взять на себя ответственность узнать больше о программной инженерии?

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

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

Я думаю, что хорошие программы CS должны преподавать основы, которые будут служить основой для всего будущего обучения программированию. Такие методологии разработки, как Agile, и инструменты контроля версий похожи на причуды; они приходят и уходят. Кроме того, они, как правило, используются в отраслевых, а не в академических условиях, поэтому я думаю, что университеты редко освещают такие вещи, как те, которые вы, вероятно, узнаете на работе. Я не говорю, что это правильно, но, вероятно, это академический менталитет.

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

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

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

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

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

Всего наилучшего в твоей карьере, надеюсь, ты получил диплом, приятно иметь буквы после своего имени. :)

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

Они основаны на моем ограниченном опыте участия в программе CS до того, как я сменил специальность, а также на моем опыте стажировки в крупной компании-разработчике программного обеспечения. Модульное тестирование не преподается, потому что большинство программ, которые вам нужно создать, недостаточно велики, чтобы нуждаться в автоматическом тестировании, вам гарантирован определенный набор входных данных, поэтому вы можете тестировать все вручную. Обучение тому, как автоматизировать тестирование, также может помешать оценке вашего проекта, поскольку большинство проектов оцениваются с помощью скриптов, запускающих автоматические тесты, с быстрым взглядом на код, чтобы убедиться, что у вас нет int foo1; int foo2; и вы используете правильный отступ.

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

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

Основная причина в том, что многие (большинство?) Университетов считают, что у них другая цель, чем у профессиональных школ. Таким образом, они хотят научить студентов, как учиться , и фундаментальным принципам дисциплины. Кроме того, алгоритмы и структуры данных будут применяться к любому языку программирования и не зависят от конкретных инструментов (которые могут использоваться или не использоваться до окончания обучения).

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

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

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

Плагин: Получив степень бакалавра в области компьютерных наук и магистра в области программного обеспечения в университете ДеПола, меня в основном обучали преподаватели / профессора, которые преподавали неполный рабочий день, что меня устраивало, потому что я бы предпочел, чтобы они пришли с анекдотом из предыдущего дня. и соотнесите это с классом. Кроме того, это в основном пригородная школа / школа с неполным рабочим днем, поэтому у большинства студентов есть работа, чтобы использовать то, что они изучают.

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

Во время моего обучения модульное тестирование присутствовало всегда. Несмотря на то, что они начинают вас с Java, они заставили нас использовать ANT и JUnit для всего проекта. Это было хорошим началом для настройки сборки и модульного тестирования.

Экстремальное программирование было включено примерно в 3-4 занятия, которые я посещал. Я помню, что все они начинали с 12 различных аспектов, от парного программирования до модульного тестирования (см. Выше). И теперь, похоже, в центре внимания Agile.

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

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

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

Кроме того, как давно существует Agile и какую форму гибкости вы имели в виду? Есть много разных его реализаций из того, что я видел.

Я не думаю, что гибкое программирование - это прихоть, но в то же время мне было бы трудно придумать, как учитель мог бы дать вам проекты, которые позволят вам изучить его ... Если только они не предоставят вам проект A build a, проект B развернуть на a. Проблема во времени и объеме. На 4-х месячном курсе было бы тяжело.

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

Структуры данных и алгоритмы - это то, над чем можно работать в настройках класса. Честно говоря, им требуется немного больше усилий, чтобы понять, чем модульное тестирование и управление версиями. Попытайтесь вспомнить, что часть университета - научить вас учиться самому. Коллаж не имеет такого же мандата. Или, по крайней мере, не в такой степени. ПО МОЕМУ МНЕНИЮ.