Чому вони не навчають цього в школі? [зачинено]


118

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

  • одиничне тестування
  • контроль версій
  • спритний розвиток

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

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


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

14
Я не впевнений, що справедливо називати контроль версій "останнім трендом". SCCS був розроблений у 1972 році - en.wikipedia.org/wiki/Source_Code_Control_System
JeffH

2
Вони вчать цим речам в RIT.
geowa4

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

1
Я думаю, що це значною мірою залежить від університету, в який ви зараховані. Принаймні для університету, який я відвідую, я можу вам сказати, що тестування підрозділу є вимогою до всіх наших домашніх завдань CS з самого початку (навіть якщо вони не дотримуються кращих практик, але це старт), а також контролю версій. Крім цього, я згоден з думкою, що університет повинен навчити вас універсальних, абстрактних понять. Щоб правильно зрозуміти тестування, контроль над версіями, а також гнучка розробка вимагає багато досвіду з перших рук, який ви навряд чи зможете вписати в повний навчальний план, який у вас все одно є.
Йоханнес Рудольф

Відповіді:


188

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

Наприклад, незважаючи на останні досягнення в галузі матеріалознавства, будівельні інженери вже близько 2000 років знають, як побудувати арку, яка не перевалиться, і це те, чого можна навчити і вивчити в університеті з відносно невеликим суперечкою. Хоча я повністю згоден з вами щодо методик, яких повинні засвоїти розробники програмного забезпечення, ця угода заснована на особистому досвіді та неформальних міркуваннях. Для того, щоб бути «найкращою практикою» у суспільстві, нам потрібні кількісні дані, які можна зібрати дуже дорого: наскільки допомагає контроль версій? Як це допомагає? Одиничне тестування? Ми можемо міркувати про ефективність різних методик, але насправді доводити, що ефективність безумовно була б дуже дорогою. Нам потрібно запустити повний, реалістичний програмний проект від початку до кінця, неодноразово, з групами програмістів, які мають рівнозначний досвід, використовуючи різні методи. Принаймні, нам знадобиться безліч даних про існуючі проекти, які ці проекти не бажають випускати.

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

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

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

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


44

Тому що наші вчителі:

  1. Ніколи не пробував тестування,
  2. Не знаєте, як користуватися контролем версій і
  3. Навіть не чув про "спритний розвиток".

Студенти повинні взяти справи в свої руки. Ми це зробили, і вийшло просто чудово, чи не так?


3
"Ми це зробили, і вийшло просто чудово, чи не так?" - Деякі з нас ... деякі були загублені по дорозі, тому що вчителі не зробили все, що могли.
Андрій Ронеа

12
Ну що б не робили вчителі, люди все одно скаржаться. Гостре завжди прагне знань і буде вийде просто відмінно.
Джеффрі Хосе

Наші викладачі не були розробниками програмного забезпечення, і ми не збиралися здобувати ступінь з розробки програмного забезпечення; ми - значною мірою - пішли на інформатику, яка є іншим звіром, зосереджена більше на теорії, ніж на практиці.
Дін J

1
@mislav: Хто були вашими вчителями?
CesarGon

43

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

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

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


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

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

У мене був такий клас під назвою «Командний програмний проект». Він не охоплював контроль версій, але охоплював UML, методології розробки програмного забезпечення, збір вимог, тестування одиниць тощо.
Адам Яскевич

@Alan, про які школи ти говориш?
життєвий баланс

40

Інформатика завжди була дещо суперечливою; Частина, що стосується комп’ютерів, не є наукою, а частина, яка є наукою, не про комп'ютери.

Університети, як правило, більше спираються на «науковий» кінець (алгоритми, структури даних, компілятори тощо), оскільки ці речі набагато «позачасові», ніж сучасні найкращі практики в галузі, які мають тенденцію розвиватися і змінюватися з року в рік. Наприклад, контроль версій зазнав дивовижних змін за останні 5 або 10 років, але big-O все ще є big-O, а хеширование, btrees та рекурсія все ще такі ж корисні, як і 40 років тому. Їх ідея полягає в тому, щоб дати вам достатню основу, щоб потім можна було підібрати такі інструменти, як git, і зрозуміти, що це означає, коли вам кажуть, що основна структура даних - це ациклічний графік хешів SHA-1, і що розробники наполегливо працювали оптимізувати кількість системних дзвінків, щоб він був пов'язаний з іо.

А тепер подумайте, де ви дізналися все, що вам потрібно було знати, щоб зрозуміти це останнє речення - якщо відповідь "університет", вони виконують нормальну роботу.


13

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

Коледж надає вам коробку інструментів, повну інструментів. Це викрутка, тобто півмісяць. Ви МОЖЕТЕ використовувати кожен інструмент один раз у коледжі. Це коли ви входите в реальний світ - це коли ви дійсно дізнаєтесь, що у вас є. Ви розбираєте корисні з решти, які ви хочете залишити вдома на верстаку, про всяк випадок, і ті, які ви тримаєте в кишені щодня.

Tqm, Iso, Cmm, Agile і т. Д. Це все примхи, які вони прийдуть, і вони підуть, жоден із успішних - це не просто здоровий глузд. Усі успішні інженери та компанії використовують якийсь аромат здорового глузду, саме тому вони робили їх успішними, мало кому потрібно ім’я для цього. Проблема полягає в тому, що ви не можете продати здоровий глузд, менеджер не може довести свою цінність компанії, навчаючи та купуючи здоровий глузд без прискіпливого імені. Вкажіть назву, яку їх начальство прочитало в якійсь статті новин чи журналів, і менеджер зберігає свою роботу, а ви зберігаєте своє. Дуже мало хто з компаній, які заявляють, що дотримуються цієї практики, насправді так і є. Більшість пишуть чек консультанту і отримують щорічний та / або життєвий сертифікат в якомусь клубі, щоб вони могли розмістити графіку на своєму веб-сайті або етикетку на коробці, в якій надходить їх товар. Багато хто буде стверджувати, що це рідко ... бував там, бачив, буває. Це все, що стосується бізнесу, вам доводиться іноді вирізати кути, щоб залишатися вигідними, і тримати двері відчиненими та увімкненими. Жорсткі послідовники всіх цих практик всі стверджували, що останній був пристрастю, а цей - хіба що останній, дійсно, був занадто дорогим для наслідування, це не так. Останнє було підробленим, що ви тільки найняли консультанта, це справжнє. Як і мови програмування, вони теж будуть розвиватися. Останнє було підробленим, що ви тільки найняли консультанта, це справжнє. Як і мови програмування, вони теж будуть розвиватися. Останнє було підробленим, що ви тільки найняли консультанта, це справжнє. Як і мови програмування, вони теж будуть розвиватися.

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

Чому люди думають, що cmm чи спритний або хтось із інших - це привид? Чому вони думають, що їх немає? Чому професор навчив вас програмувати саме так? Щоб уникнути готів чи уникати констант чи уникати цього і того? Це тому, що він створює більш надійний код? Краще виконувати код? Зменшує помилки людини? Або це тому, що праці / програми легше оцінювати, надаючи їм більше часу на дослідження? Це тому, що вони не знають, як програмувати, і вони просто слідкують за тим, щоб хтось залишився на цій темі? Вони вчили вас, що ви не можете мати надійний, надійний, високоефективний код? Ви навіть не можете "обрати жодних двох" ретельних перешкод як надійних, так і високих показників? Іноді ви жертвуєте надійністю для виконання. Іноді ви не дбаєте про надійність чи продуктивність, просто хочете отримати версію 117.34. 2 ще однієї програми бухгалтерського програмного забезпечення версії 118.0.0. Ваша бізнес-модель полягає в продажі оновлень версій та технічній підтримці, і, наскільки розробники програмного забезпечення будуть робити будь-який старий робот, який зможе записати той же код таким же чином. Замініть згорілого на свіжий з коледжу та продовжуйте продавати оновлення.

Універсальних відповідей на ці запитання немає, ви повинні з’ясувати, яка ваша думка, жити з нею і відстоювати її. Змініть свою думку, живіть з нею і захищайте її.

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

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

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

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

Те, що я дійсно хотів сказати тут, саме зараз ми опиняємось у рідкісній ситуації, коли ми можемо спостерігати еволюцію паралельного Всесвіту (і, можливо, впливати на це). Так, інформатика - це молода наука порівняно з фізикою. Але в той же час вона розвивалася багато разів. Залежно від місця роботи та з ким ви працюєте, ви можете спостерігати за інженерами обладнання. Мови програмування в світі апаратних засобів, безумовно, не нові, але вони розвивалися не так швидко, як світ програмного забезпечення. Програмне забезпечення мало кілька десятиліть. Апаратні засоби завжди вважали інженерів програмного забезпечення, як громадян другого класу. Наша робота проста, їхня робота важка. (Зауважте, що насправді я і апаратний, і програмний інженер). Цікавим є те, що зараз вони все ще мають справу з тим, що ми б вважали елементарними чи інфантильними проблемами. Чому мені потрібно використовувати управління версіями, я єдиний, хто працює над цим чіпом. Ваш досвід роботи з gcc або іншими дешевими компіляторами або безкоштовними IDE, можливо, не можна порівняти з дорогими інструментами, якими я користуюсь, якщо компанія вважає, що ви досить варті її використання, або навіть знаєте, як ним користуватися, вони купують вам копію. І довгий перелік інших виправдань. Мені було приємно навчитися як vhdl, так і verilog та стати продуктивними протягом двох тижнів з того, що майже не зважився на таке інженер-апаратник (незважаючи на мій диплом, зазначаючи, що інженер-електрик, моя посада є інженером програмного забезпечення). Я хотів вивчити ці мови, коли мені були доступні інструменти, я залишався в офісі до ночі і навчав себе. З цього моменту інженер, зокрема, зрозумів, що те, що я говорив, є правдою, що мова - це лише синтаксис, Основи програмування однакові, всі інструменти роблять те саме. Її яблука та яблука, а не яблука та апельсини.

Загалом, хоча все ще важко надіслати повідомлення про те, що одна з цих двох паралельних галузей має набагато більше досвіду в галузі мов, звичок програмування, контролю джерел, тестування, інструментів, середовищ програмування тощо, ніж інша. Проблема, яку я намагаюся вирішити, - це прийняття конструкцій обладнання, коли вони розробляються, створити доступні функціональні тренажери, які ми можемо зв’язати за допомогою моделювання (віртуальної машини) процесора, щоб ми могли розпочати тестування обладнання та розробити тест і програмне забезпечення, що доставляється задовго до того, як ми перейдемо до кремнію. Ні, в цьому немає нічого "нового", але у нас немає механізму отримати останній код, відстежувати зміни в коді, щоб побачити, куди нам потрібно зосередити свій час. Немає механізму відстеження документації, яка визначала б інтерфейс користувача (програмування) до апаратного забезпечення. Один золотий примірник знаходиться у чиїй-небудь вхідній пошті електронної пошти у двійковій формі і змінюється лише тоді, коли це не означає, що вам доведеться читати контрольний запис, щоб дізнатися, що відбувається. Зачекайте, що цей verilog - скільки років? Та помилка, яку я провів цілий тиждень на тобі, з'ясувала три тижні тому і виправила? Тож ми просто летимо на якесь місце відпустки та вечірки протягом півроку, чекаючи, як апаратники закінчать своє завдання та перекинуть його нам на стіну, чи ми скористаємось цією можливістю, щоб спробувати бути терплячими та оптимістичними та навчити їх, що вони є методи здорового глузду, які не такі нав'язливі, що дозволяють їм і виконувати свою роботу, створювати резервну копію своєї роботи, а також ділитися своїми речами для експертного огляду ... що verilog - скільки років? Та помилка, яку я провів цілий тиждень на тобі, з'ясувала три тижні тому і виправила? Тож ми просто летимо на якесь місце відпустки та вечірки протягом півроку, чекаючи, як апаратники закінчать своє завдання та перекинуть його нам на стіну, чи ми скористаємось цією можливістю, щоб спробувати бути терплячими та оптимістичними та навчити їх, що вони є методи здорового глузду, які не такі нав'язливі, що дозволяють їм і виконувати свою роботу, створювати резервну копію своєї роботи, а також ділитися своїми речами для експертного огляду ... що verilog - скільки років? Та помилка, яку я провів цілий тиждень на тобі, з'ясувала три тижні тому і виправила? Тож ми просто летимо на якесь місце відпустки та вечірки протягом півроку, чекаючи, як апаратники закінчать своє завдання та перекинуть його нам на стіну, чи ми скористаємось цією можливістю, щоб спробувати бути терплячими та оптимістичними та навчити їх, що вони є методи здорового глузду, які не такі нав'язливі, що дозволяють їм і виконувати свою роботу, створювати резервну копію своєї роботи, а також ділитися своїми речами для експертного огляду ...

Пам'ятайте, що інженери апаратури покинули коледж із коробкою нових блискучих інструментів, як і ви. Ви засвоїли 17 різних мов програмування, з яких ви можете використовувати лише одну, решту мов, які ви використовуєте у своїй кар'єрі, винайдете після закінчення коледжу. Після виходу з коледжу вони можуть сказати вам, що вони знають про числення та теорії відносності, скільки електронів у кожному з елементів і обчислити заряд навколо поверхні Гаусса. Але основна частина їх кар’єри - це один, нульовий, і, або ні, (так, у нас є спільне, все, що вам потрібно знати про комп'ютери, один, нуль, або, а не апаратний або програмний інженер). З урахуванням основних законів фізики, числення, електрони не змінюватимуться так швидко, як це роблять мови програмування. Але основи програмування є однаковими для всіх мов і надалі залишатимуться в майбутньому. Ви покинули коледж, знаючи це, або ви залишили, думаючи, що java відрізняється і краще, ніж C ++, тому що це і те, і інше?

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


12

Я вчив цим речам, коли я був ад'юнктом в Технологічному інституті в Орегоні. Їх навчають, просто рідко.


Яким було звання класу?
Дін J

11

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

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


10

о боже, не запускай мене

колись мені декан університету в авторитетному університеті сказав мені, що об'єктно-орієнтоване програмування було просто «причудком», тому вони не пропонували ніяких занять у захоплюючих фантазіях, як C ++

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


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

І тепер все, що вони викладають (принаймні за перші пару років) у багатьох університетах, - це Java. Ах, іронія.
Меттью Шинкель

Коли він сказав вам, що ООП - привид? До появи Яви OOP був ближче до примхи, ніж потрібні знання.
Ендрю Прок

@ [drewster]: 1994, хоча я думаю, що ви даєте Яві занадто багато кредиту. OOP - це логічний прогрес еволюції мови програмування; називати це "примхами" на будь-якому етапі своєї історії (набагато менше у 1994 р.) свідчить про рівень незнання за деканом CS-рівня.
Стівен А. Лоу

2
Що з помилковою дихотомією між академічним та реальним / практичним? Майже кожна ідея, яку ви використовуєте у своїй роботі в реальному світі, надходила від академічної спільноти або вдосконалювалась. Як ви думаєте, звідки взявся брак GOTO? Об'єкти з'явилися від науковців з обчислювальної техніки в 1967 році. Багато людей з КС не зрозуміли переваги ООП, і це все ще не визначилося. Промисловість вважає, що це допомагає, але є багато невдалих проектів, які доводять інше.

9

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

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

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


Контроль версій не потрібен в університетському курсі. Вони також можуть навчити "як користуватися візуальною студією". Найкраще залишити це на роботі, коли ви знайдете роботу. Що стосується тестування - одиничне тестування не завжди є найкращим, але вони повинні навчити хоча б трохи всіх форм тестування.
gbjbaanb

@gbj погодився, я не мав уявлення, що таке контроль версій, поки я не влаштувався на роботу, і побачив переваги одразу і засвоїв це, як день. Є набагато важливіші речі, які слід викладати в шкільному ІМО.
temp2290

7

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


6

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


Тож ми повинні наймати лише інженерів-програмників, а не комп'ютерних науковців? ;-)
Ендрю Лебедь

Якщо ви вважаєте, що будь-яка з цих речей відповідає визначенню «інженерія», я переживаю. Вони відповідають визначенню сковородок, а не інженерним.
Бенджамін Р

6

Це залежить від університету. Я закінчив у 2003 році австралійський невірус. Тоді ми засвоїли UML, Unit Testing, XP (та інші Agile Methodologies), а також усі офіційні матеріали, такі як Z, Алгоритми та структури даних, Операційні системи тощо.

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

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

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


5

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

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

Університет призначений для викладання понять і теорій, адже це речі, які важко підібрати самостійно. Контроль версій - це інструмент, який можна легко підібрати. Використовуйте його трохи, прочитайте кілька навчальних посібників в Інтернеті, і все готово. Якщо вам потрібні лекції та домашні завдання, щоб з’ясувати, як перевірити щось із SVN, у вас виникнуть багато проблем з речами, які насправді є СКЛАДНІ.

Пам’ятайте, що існує багато способів дізнатися речі в коледжі поза класами; скористайтеся цим. Ви платите багато, щоб відвідувати заняття та користуватися спорудами, тому доїть його за все, що варто, і ходіть на засідання LUG та ACM, беруть участь у проектних командах (завжди є деякі МЕ, які будують робота, якому потрібен програміст) або отримують робота з адміністрування сервера відділу гуманітарних наук. Виберіть комп’ютер із завантажувальної док-станції в будівництві матеріалів, завантажте ізонекс Linux зі своїм швидким інтернетом і погуляйте.


3

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

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


3

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

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

Подумайте про інші поняття, якими я користуюсь щодня, які не принесуть користі студенту, який змириться з основами програмного забезпечення та комп'ютерних систем:

  • хороші практики коментування
  • відповідність стандартам (не лише міжнародним стандартам, але й командним стандартам кодування)
  • документація
  • контроль змін (не обов'язково такий же, як контроль версій, який стосується збереження відмінностей, це більше про те, чому і чому ви щось змінили)
  • розвиток зручності використання

Наведені вище - це "м'які навички", які вам не потрібно писати.

Однак якщо вам не вистачає "важких" навичок, таких як структури даних та алгоритми, то ваш шанс написати хороший код майже неможливий.


2

Я все це дізнався в університеті. Можливо, це залежить від обраних вами курсів? Мої курси були дуже різноманітними (Дизайн програмного забезпечення, дизайн інтерфейсу, електронна комерція, AI, функціональне програмування тощо). Дизайн програмного забезпечення піддавався моделям дизайну та тестуванню одиниць (один великий проект, який передбачав різні речі). UI Design ... ми були трьома особами, які працювали над проектом. Ми не могли нічого зробити без контролю версій, тому ми це отримали. І спритний розвиток - це те, про що постійно говорили наші професори, але вони залишали це для кожної групи, щоб використовувати його.

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


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

2

Щоб відповісти, чому такі речі не є першими, що навчаються: Бакалавратські програми, як правило, навчають вас стати студентом магістратури. Лише після того, як ви почнете обирати власні курси (що, як правило, трапляється в наступні роки), ви зможете дізнатися про речі, які використовуються за межами навчальних закладів. Ось чому вони зосереджуються на алгоритмах, структурах даних, представляють вам невирішені проблеми тощо.

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


2

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


2

Я навчився всього цього матеріалу першокурсника, за винятком спритного розвитку.

Вся справа у виборі правильної школи, ІМХО. Якщо ви підете в топ-10, ви швидко навчитесь усім цим.

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


2

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


2

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


1

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


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

1

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

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


1

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

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

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

Все найкраще в кар’єрі, сподіваюся, ви закінчили ступінь, приємно мати літери після свого імені. :)


1

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


1

Вони ґрунтуються на моєму обмеженому досвіді роботи з програмою CS перед тим, як я перейшов на спеціальності, і на моєму досвіді стажування у великій компанії з програмного забезпечення. Тестування одиниць не викладається, оскільки більшість програм, які ви повинні створити, не мають достатньо великих розмірів, щоб потребувати автоматизованого тестування, ваш гарант гарантував певний набір входів, щоб можна було протестувати все вручну. Навчання вас автоматизації тестування може також перешкоджати оцінці вашого проекту, оскільки більшість проектів класифіковані за сценаріями, які виконують автоматизовані тести, швидким поглядом на код, щоб переконатися, що у вас немає int foo1; int foo2; і ви використовуєте належний відступ.

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

Я не знаю, чому гнучкому розвитку не навчатимуться, але це, мабуть, повертається до того ж, що і з розміром програми. Незважаючи на те, що гнучка розробка є звичною для нового програмного забезпечення, яке працює на персональних комп’ютерах та невеликих серверах, воно зазвичай не використовується в таких системах, як IBM mainframes або в проблемних областях, таких як банківська чи медична, де документація є важливою. Це, мабуть, пов'язане з тим, що сприятливого розвитку не було близько 20 років тому, коли навчалося багато професорів.


> навіщо використовувати контроль версій, якщо обидва на одному комп’ютері? Я використовую управління версіями, навіть коли я єдиний за комп’ютером! В іншому випадку, як би ви керували гілками та виправленнями виправлень або навіть переглядали попередню версію файлу (назад, перш ніж остання зміна порушила її)?
Ендрю Лебедь

Дітто від Ендрю. Я широко використовую інструменти SCM, хоча вся моя робота виконується на моєму ноутбуці, і більшість з них є сольними. Резервне копіювання, контроль редагування, розгалуження та об'єднання, виправлення старого коду. Всі вони є причинами використовувати його не лише для вихідного коду, але і для будь-якого створеного контенту.
Меттью Шінккель

Немає жодних причин, чому ви не класифікуєтесь на те, чи проходить ваш код тест одиниці / прийняття

1

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

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

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


1

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

Підключення: Взявши бакалавратів в Comp Sci і MS в Soft Eng в університеті DePaul, мене в основному навчали викладачі / професори, які викладали неповний робочий день, що було мені добре, тому що я вважаю за краще, щоб вони прийшли з анекдотом попереднього дня і відносять його до класу. Крім того, що це школа, яка займається переважно тимчасовим навчанням / неповний робочий день, більшість студентів мають роботу з використання того, що вони навчаються.

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

Під час мого навчального підрозділу тестування завжди було присутнє. Незважаючи на те, що вони починають вас на Java, вони змусили нас використовувати ANT та JUnit для всіх проектів. Це було гарним початком конфігурації збірки та тестування одиниць.

І Extreme Programing був включений приблизно в 3 або 4 класи, які я проходив. Я пам’ятаю, що всі вони починалися з 12 різних аспектів, від парного програмування до одиничного тестування (див. Вище). І зараз здається, що фокус зосереджений на Agile.

Тож швидка відповідь - так, там є школи, які мають більш прагматичний підхід, ніж інші.


1

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

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

Крім того, як довго прокрутився і яку форму спритного ви мали на увазі? Існує багато різних його реалізацій від того, що я бачив.


1

Я не думаю, що спритне програмування не є придуманим, але в той же час мені важко буде думати про те, як вчитель міг би дати вам проекти, щоб дозволити вам це навчитися. Якщо тільки вони не дали вам проект A build, проект B розширити на a. Проблема - час і сфера застосування. У 4-місячному курсі було б важко.

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

Структури даних та альго - це те, над чим можна працювати в умовах класу. Чесно кажучи, вони закладають трохи більше зусиль, щоб зрозуміти тестування та версію модулів. Спробуйте запам’ятати частину університету - це навчити вас вчити себе. Колаж не зовсім такий самий мандат. Або принаймні не в тій же мірі. ІМХО.


Хм, я думав, коледж та університет означають те саме.

Залежно від того, де ти (країна мудра) у США, вони однакові, у Канаді вони різні. Я думаю, що в штатах те, що я називаю колажем, насправді називається молодшим колажем. В Австралії його називають Тафф (вибачте з правопису). Якщо не бути носієм мови, такі речі дуже "веселі"
baash05
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.