Яка різниця між рівнем коледжу та корпоративним програмуванням? [зачинено]

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

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

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

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

Однак є ще деякі поширені проблеми.

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

• дизайн / вимоги, як правило, набагато нечіткіші в реальному світі, ніж в колегіальній атмосфері. Коли ви пишете професійний код, хтось повинен визначити мету коду, і вам просто не даються проблеми з іграшками або навіть добре відомі проблеми. Цілком ймовірно, що рано чи пізно саме ви будете займатися проектуванням! Клієнти зазвичай не знають, чого хочуть (і навіть коли вони знають, чого хочуть, це може бути не те, що їм потрібно), а менеджери зазвичай просто описують велику картину, залишаючи програмістам багато деталей та варіантів. Залежно від застосовуваних методів ("спритний" -vs- "V цикл" тощо), вибір і детальне визначення проблеми можуть відбутися рано чи пізно, але вам потрібно принаймні тримати відкриту думку і цікавитись, чи дійсно ви робите те, що необхідно. Ви також можете розглянути зміни вимог, якщо поточне завдання занадто важко кодувати або є неефективним. Ви можете все-таки написати щось марне або надмірно складне, оскільки клієнт або ваш менеджер не зрозуміли вашу думку або вони не погоджуються з вами. Тим не менш, ви завжди повинні ставити під сумнів вимоги (це навичка виживання). Також пам’ятайте, що вимоги можуть змінитися в середині завдання, і ви повинні бути готові до цього.

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

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

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

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

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

Це питання засноване на недійсному припущенні:

"Як ти насправді переходить від учня до професіонала в галузі програмування?"

Ви стаєте професіоналом, отримуючи за це плату. Ви ніколи не перестаєте бути студентом. Якщо ви так зробите, ваша кар’єра закінчена.

Вийди у світ і влаштуйся на роботу. Ваше захоплення навчанням - це користь.

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

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

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

Я отримав би користь, досягнувши попереднього рівня C #?

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

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

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

Як ти насправді переходить від учня до професіонала в галузі програмування?

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

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

Влаштуйся на роботу, не чекай. Звично нервувати, але будьте чесними щодо своїх навичок і не приховуйте ентузіазму, щоб дізнатися більше. Як правило, перемикайте компанії кілька разів, особливо на початку вашої кар’єри.

Вітаю вас із закінченням ступеня та удачі у дорозі до професійного програмування.

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

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

Але до вашого питання

Як ти насправді переходить від учня до професіонала в галузі програмування?

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

Відповідь Карла про масштаб - це місце. У вас не виходить сортувати масив з 15 чисел, вам доведеться сортувати набір даних на мільйон, скажімо, номерів рахунків.

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

Щодо підготовки до корпоративного світу, я б запропонував два способи: a) Отримати стажування навіть низькооплачувана або не оплачувана допоможе вам спостерігати за роботою інших. b) У всіх магазинах додатків ви можете спробувати написати та опублікувати додаток у магазинах Apple / Google / MS. Це допоможе вам краще зрозуміти робочі процеси, значення тестування, необхідність налаштування правильного середовища та інструментів тощо.

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

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

Що б ви зробили, якщо ваш професор змінить вимоги домашнього завдання з програмування за два дні до того, як вам доведеться його виконати?

У промисловості це досить поширене явище.