Чи варто продовжувати практику кодування самоучки або навчитися робити кодування професійно? [зачинено]

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

Це суміш кількох речей, які я роблю. Я схильний поєднувати кілька парадигм програмування разом. Як функціональні та OO. Я схиляюся до функціональної сторони більше, ніж ОО, але бачу використання ОО, коли щось має більше сенсу як абстрактна сутність. Як ігровий об’єкт. Далі я також проходжу простий маршрут, коли щось роблю. На противагу цьому, здається, що іноді код, який я бачу від професійних програмістів, заради нього складний! Я використовую багато закриттів. І нарешті, я не найкращий коментатор. Мені легше просто читати свій код, ніж читати коментар. І в більшості випадків я просто закінчую читання коду, навіть якщо є коментарі. Плюс мені сказали, що через те, як просто я пишу свій код, прочитати його дуже просто.

Я чую, як професійно підготовлені програмісти продовжують працювати над такими речами, як тести для одиниць. Щось я ніколи раніше не використовував, тому я навіть не маю уявлення про те, що вони є, або як вони працюють. Багато і багато підкреслень "_", які насправді не до смаку. Більшість методик, які я використовую, прямо від мене, або кілька книг, які я прочитав. Не знаю нічого про MVC, я багато чув про це, хоча з такими речами, як backbone.js. Я думаю, що це спосіб організувати заявку. Це мене просто бентежить, тому що до цього часу я створив власні організаційні структури.

Це трохи болить. Я взагалі не можу використовувати шаблонні програми, коли швидко щось вивчаю, як, наприклад, з Ubuntu. У мене проблеми з розумінням коду, який я можу сказати, від когось пройшов навчання. Повне програмування OO справді залишає неприємний смак у моїх устах, але це, здається, те, що КОЖНЕ інше суворо використовує.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мистецька складова - це весело: ти це робиш, тому що тобі подобається. Природно, це та частина, яку ви навчите самі спочатку.

Компонент дисципліни викликає більше неприємностей: ви робите це з необхідності. Хоча це життєво важливий компонент роботи в команді: ви не можете піти від цього, хоча б певною мірою. Після того, як ваш код буде інтегрований з вашим товаришем по команді, ваша гнучкість "змінити речі за бажанням" сприймає нос. Однак вам потрібна можливість змінити код з упевненістю у відповідь на зміни вимог або вирішити помилки. Тут проводяться різні "нудні" тести: з безліччю тестів, можна легко перевірити, чи порушує ваша остання зміна чи ні.

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

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

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

@ assfallows: "Чесно кажучи, програміст - це не те, чим ти є. Програміст - це те, чого ти постійно вчишся бути". насправді бути всім і закінчити все кодування.

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

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

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

Вам не потрібно бути більшим коментатором. Але ви повинні бути хорошим комітетом (так, почніть використовувати якусь VCS - рекомендую Git).

Стиль - це річ, яка ЗАВЖДИ розвивається. Не хвилюйся з цього приводу. Ви дізнаєтесь, що таке код багаторазового використання, а що ні. Але ви повинні попрактикуватися і отримати для цього допомогу.

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

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

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

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

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

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

І найкращим рецептом для цього є практика. Ви завжди повинні мати проект; якщо ви між платними концертами, візьміть особисту іграшку. Запасний час один вихідний? Працюйте через "привіт світ" для мови чи платформи, якими ви ніколи не користувалися. Шукайте способів навчитися багато чому одразу. Наприклад, побудуйте щось у Google App Engine, і ви дізнаєтесь одразу про бази даних Python, BigTable та колонки. Ви отримаєте хорошу дозу "професійного" стилю Google.

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

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

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

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

• Правильно?
• Зрозуміло?
• Підтримується?
• Ефективний?

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

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

Будь вірною собі !! Продовжуйте вчитися і насолоджуватися тим, чим займаєтесь.

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

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

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

Для тестування підрозділів шукайте розробку тестових програм.

Для коментування придумайте код, який ви написали після відсутності. І час, коли інші витратять зворотну інженерію.

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

Удачі: D

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

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

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

Я схиляюся до функціональної сторони більше, ніж ОО, але бачу використання ОО, коли щось має більше сенсу як абстрактна сутність.

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

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

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

Я використовую багато закриттів. Добре. Тому вони там. Вони лякають деяких людей, які застрягли в 1990-х і застарілу модель Java-квазі-OOP, але насправді це їхня проблема.

І нарешті, я не найкращий коментатор.

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

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

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

Багато і багато підкреслень "_", які насправді не до смаку.

Як і в коментарях, це суб'єктивно і залежить від мови. У C і C ++ lowercase_with_underscoresє досить поширеною умовою іменування. У багатьох інших мовах ви практично ніколи не бачите підкреслення. Але наприкінці дня це справді не важливо. Будь-яка функція викликана write_to_logчи WriteToLogнасправді не зміниться. Комусь доведеться просто висмоктати його і відповідати тому, що там домовилися команди.

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

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

Повне програмування OO справді залишає неприємний смак у мене в роті

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

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

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

Це не повна відповідь, у вас вже є кілька хороших. Однак є кілька моментів, які на мене виглядають трохи заплутаними і не зверталися до них.

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

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

Сучасні мови програмування часто підтримують декларативну модель програмування. Наприклад, у C # використання Linq призводить до декларативного стилю, оскільки ви не говорите, як отримати те, що ви хочете; ви говорите лише те, що хочете.

Повне програмування OO справді залишає неприємний смак у моїх устах, але це, здається, те, що КОЖНЕ інше суворо використовує.

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

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

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

Коротка відповідь: так.

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

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

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

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

Знаючі? Можливо.
Якщо ви ненавидите школу, ви не отримаєте більше, ніж поставите.

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

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

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

Якщо ви йдете, вибирайте розумні профі та бутони.

Друге питання - Чи можу я використовувати власний стиль?

У вас є два питання.

Перший - у вашій назві. Будь ласка, дивіться мою попередню відповідь.

Другий детально викладений приблизно в п’яти параграфах, де ви характеризуєте, як ваш стиль відрізняється від професійного стилю, перелічені нижче:

• 100% самоучка.
• Різні за технікою та організацією.
• Суміш функціональної та об'єктно-орієнтованої.
• Менш складний.
• Багато закриттів.
• Кілька коментарів.
• Немає одиничних тестів.
• Мало підкреслює.
• Ні MVC.
• Немає backbone.js.
• Немає шаблонових додатків.

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

http://en.wikipedia.org/wiki/Coding_conventions

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

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

Причини існування єдиного коду (і рівномірного навчання) полягають у збільшенні швидкості та продуктивності розвитку та певним чином інституціоналізації вивчення передового досвіду. Такі питання, як camelCase або use_underbars, можуть здатися тривіальними і дрібними, але послідовність є корисною.

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

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

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

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

Я вважав ідеали "Agile Manifesto" корисними у своїй кар'єрі (www.agilemanifesto.org)

• Індивіди та взаємодія над процесами та інструментами
• Працює програмне забезпечення над всеосяжною документацією
• Співпраця з клієнтами щодо укладання договорів
• Відповідаючи на зміни протягом наступного плану

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

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

Звичайно, я вивчив синтаксис та поняття в моєму навчальному процесі, але саме в комерційному світі я почав вчитися програмувати.