Відмінність програмування в школі від програмування в галузі? [зачинено]

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

Які існують відмінності між програмуванням в академічній обстановці та програмуванням у "реальному світі"?

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

• Зберіть та проаналізуйте вимоги, коли вони вам безпосередньо не даються
• Дизайн та аналіз архітектури з майже нескінченними можливостями
• Створіть плани тестів та дійте на них, щоб оцінити та покращити якість системи
• Працюйте спільно над командою людей з різним походженням та рівнем досвіду
• Оцініть і сплануйте роботу, навіть якщо ви не знаєте, що саме будувати
• Ефективно спілкуватися із зацікавленими сторонами, які мають різні потреби, які не обов'язково узгоджуються
• Розмовляйте графік, бюджет, якість та функції, не розчаровуючи зацікавлених сторін

О так, і ви також повинні мати можливість писати код, хоча це в середньому займає лише 40 - 60% часу інженера-програміста.

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

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

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

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

У "Реальному світі" ...

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

Висновок

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

Вони стикаються з різним аспектом проблеми:

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

Ця різниця у «фокусі» - це те, що робить академічний магістр C практично не в змозі написати програму Windows (оскільки ми API API не входить у стандарт C99!), Таким чином відчуваючи, що він «не в змозі програмувати». Але насправді він має всі можливості, щоб дізнатись самого, чого йому не вистачає. Щось - без належних академічних досліджень (не обов'язково зроблених в Академії) - знайти досить важко.

Гарні відповіді. Дозвольте лише додати, академічне програмування, як правило, майже як іграшкове за масштабом. Це добре для викладання. Як вчитель, ви намагаєтесь передати ідеї найефективніше. Мінус реалістичного програмування настільки якісно інший, що важко подолати розрив.

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

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

Ці речі не вчать, і вони роблять величезну різницю в продуктивності.

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

Оновлення: Наче хтось читав мою думку: очікування випускників проти реальності ...

Моя думка, два інші фактори:

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

Читання VS Writing : Ще одним побічним ефектом розміру проблеми є те, що часто в "реальному світі" ми піддаємось роботі, яку написали інші, або для цілей технічного обслуговування (я ніде не займався технічним обслуговуванням в академічних колах), розширення або просто розподіл праці. Тому читання коду стає набагато важливішим, ніж його написання.

Пропозиція щодо вдосконаленої програми програмування : Академія повинна більше піддавати нас ситуаціям у реальному світі, не звертаючись до професійної підготовки. Лікарям доводиться стикатися з трупом в якийсь момент, щоб побачити, чи вони "зроблені для цього" (я чув, як люди після цього досвіду скидають курс). Якби я на початку двадцятих років бачив проект LOC розміром 20 тис., Який складався з різних стилів програмування, які я повинен був зрозуміти за один день і виправити помилку в три, я, можливо, розглядав би інші варіанти кар’єри - хоча, мабуть, ні.

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

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

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

У мене немає нульового особистого досвіду навчання з програмування в школі - я був англійським майором. Запитайте мене про Кітса та Байрона! - але я отримав декілька нових дипломів і виховував їх та наставляв у світі професійної розробки програмного забезпечення. Тож я можу говорити з цієї точки зору.

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

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

У наукових колах

КРЕСЛЕННЯ

• У нас є терміни, які в основному набирають бали.
• Помилки не викликають проблем, оскільки більшість проектів ніколи не використовуються в реальних програмах.

ПЛЮСИ

• Ми отримуємо достатньо часу для досліджень.
• Відхилення від початкових цілей не викликає особливих проблем.

У галузі

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

Перевір це:

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

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

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

Насправді,

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

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

Залежно від того, в якому секторі ви працюєте, ви повинні відповідати його законам.

Майкл торкнувся лише кінчика айсберга, вказавши завдання, пов’язані з програмуванням, які я б класифікував як прості речі (якщо ти коштуєш тісто, за яке ти платиш).

Загалом ви зіштовхнетесь як мінімум з кількома проблемами на кожну галузь у галузі:

• Діючі закони (колишня конфіденційність клієнта для медичних)
• Предметні ноу-хау (наприклад, система оподаткування податків, інвентар, управління ресурсами, медичні схеми, галузеві стандарти)
• Клієнтські вимоги, які відсутні або відсутні, або не відрізняються від галузевих стандартів / законів

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

Єдина реальна відмінність тоді полягає в тому, що проект реального світу

• має клієнта
• має бюджети (час, гроші, людські ресурси)

Це інша гра з м'ячем, коли хтось інший робить правила :)

Якщо ви подивитесь на теми, що вивчаються в ІТ в академічних колах, ви знайдете приблизно половину часу, витраченого на математику, науку, факультативи тощо, а іншу половину - на такі навчальні предмети, як: Дизайн компілятора, Теорія алгоритмів, Комп'ютерна архітектура, Оптимізація, операційні системи, цифрова електроніка та кілька інших курсів, пов'язаних з галуззю, такими як програмування на C та веб-програмування.

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

Візьміть вимоги Microsoft Web Programming (тобто сфери, необхідні комусь, щоб бути продуктивним членом команди в організації):

1- C # .NET або VB.NET

2- ASP.NET

3- HTML та CSS

4- SQL Server (або інша база даних)

5- програмування та дизайн додатків OO

6- сценарій Java

7- рамки MVC

8- Деякий вплив засобів контролю джерел

9- Деякий вплив на автоматизовані інструменти тестування

10-помилковий інструмент відстеження

Концепції 11-електронної комерції (необов’язково)

12-ОРМ

13-Деякі навички бізнес-аналізу

14-Деякі навички спілкування

15 - Мабуть, деякі основи хмарних обчислень

Як ви бачите, що більшість вимог, зазначених вище, рідко зосереджені (ви можете отримати один курс в деяких максимум) під час коледжу / університету.

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

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

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

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

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

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

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

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

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

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