Чи достаток кадрів скидає програмістів? [зачинено]

Зважаючи на всі рамки, доступні в наші дні, ORM , введення залежності (DI), інверсія управління (IoC) тощо, я вважаю, що багато програмістів втрачають або не мають навичок вирішення проблем, необхідних для вирішення складних питань. Багато разів я бачив, як несподівана поведінка повзає в додатках, і розробники не в змозі реально розкопатися та знайти проблеми. Мені здається, втрачається глибоке розуміння того, що відбувається під капотом.

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

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

Так, я знаю, що побачити якийсь сирий SQL на сторінці JSP - це "ні-ні", але якщо ви польовий консультант, то де це відповідає конкретному рішенню? І ні, це не означає, що рамки невірні, не всі клієнти мають $ 20 тис. Сидіти на кожному кроці, щоб гарантувати, що на сторінці проектується незначна точка даних.

Це аргумент, який регулярно з'являється в багатьох сферах і в багатьох формах.

Загальною формою цього аргументу є:

Чи має наявність [x: інструмент / технологія] людей гірше [функція, на яку впливає x]?

Наприклад:

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

З пам’яті майже завжди є всюдисуща відповідь: не дуже. Ви завжди будете мати людей, які добре і погано роблять [y], але тепер вони просто погані в іншому аспекті майстерності.

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

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

Я пам’ятаю, що розробляв деякі перші динамічні веб-сайти ще в середині 90-х, використовуючи C та CGI (у той час, коли більшість веб-сайтів ще були статичним HTML). Насправді не існувало жодної зрілої мови скриптування на стороні сервера (наприклад, PHP чи ASP) і дуже мало бібліотек, тому вам довелося виписувати весь потік відповідей HTTP на сервер з кожної сторінки. Розбір параметрів GET та POST вимагає написання власної бібліотеки. Це було виснажливим, повільним, працьовитим і дуже схильним до помилок. Я цього не пропускаю ні одного!

Однак я також відчуваю такі рамки, як веб-форми ASP.NET абстрагують всю суть без громадянства до такої точки, коли багато нових веб-розробників мають мало поняття, що насправді відбувається під кришкою. Це призводить до неефективного, роздутого коду, який працює погано, оскільки розробник проводить водопровідні компоненти разом, використовуючи методологію "drag'n'drop", не усвідомлюючи, що відбувається на рівні HTTP.

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

Чи робить автоматична коробка передач або дощу склоочисники склоохолоджувачів нас гіршими водіями?

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

Зрештою, розробнику належить навчитися. Хороші роблять, а погані - ні.

І, таким чином, вибір рамки лише тому, що вона існує без фактичного аналізу її можливостей та плюсів / мінусів, також є ознакою поганої практики розвитку.

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

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

Можливо, розподіл "німоти" насправді не змінився, і ми натомість просто роздаємо більші та складні способи розробникам стріляти в ногу?

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

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

Наприклад, я взяв клас у програмі Compiler Design в коледжі, де ми кодували парний аналізатор LR з нуля в C, перш ніж навчитися використовувати генератори парсера, такі як lex та yacc. Це було дуже навчально, і з тих пір я краще розумів і вдячний за всі мови програмування, якими користувався.

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

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

Цитуючи чудову книгу Джеймса Ларуса "Витрата дивіденду Мура" (наголос додано):

Тридцять років тому Білл Гейтс змінив підказку в Altair Basic з "ГОТОВНО" на "ОК", щоб зберегти 5 байт пам'яті. Сьогодні немислимо, щоб розробники усвідомлювали цей рівень деталізації своєї програми, не кажучи вже про це хвилювались, і це справедливо, оскільки зміна такої величини сьогодні не помітна ... Не існує способу, як ми могли б виробляти сьогоднішні системи використовуючи майстерні, ручні роботи, які були можливі (необхідні) на машинах із 4К пам'яті.

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

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

Дещо застарілий приклад - MFC : програміст міг би заощадити багато часу, використовуючи MFC замість API Windows, але без знання API (що означає наявність справжньої роботи з сирим API), вони часто зациклюються . Це майже ніколи не траплялося, тому що типовий програміст MFC мав знання про API Windows.

Однак, за допомогою Windows Forms у .NET , завдяки кращій капсуляції та кращій об'єктній моделі, програміст може майже ігнорувати, що він використовує лише іншу обгортку API API. Так є менше шансів на застрявання, але коли це станеться, це може зашкодити.

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

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

Ті, хто потребує або хочуть знати "речі" за рамками, будуть вивчати і розслідувати гачком або шахраєм.

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

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

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

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

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

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

Більшість фреймворків матимуть функції, які програмісти використовують знову і знову.

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