Неужели обилие фреймворков сбивает с толку программистов? [закрыто]

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

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

Согласовано. В настоящее время я работаю над программным пакетом, который настолько обременен фреймворками, что делает практически невозможным понимание бизнеса. Как только фреймворки лишают вас реального решения бизнес-задач, а не просто решения MVC , это заходит слишком далеко. Как вы утверждаете, многие программисты IMO пытаются создать архитектуру / программу для решения ORM и MVC, и они редко спрашивают, действительно ли это как-то помогает решить проблему, для которой в первую очередь существует программное обеспечение.

Да, я знаю, что видеть какой-то необработанный SQL на странице JSP - это «нет-нет», но если вы полевой консультант, где это подходит для конкретного решения? И нет, это не означает, что структура не правильная, не у всех клиентов есть 20 тысяч долларов на каждом шагу, чтобы гарантировать, что незначительная точка данных проецируется на страницу.

Это аргумент, который всплывает регулярно, во многих областях и во многих формах.

Общая форма этого аргумента:

Делает ли [x: tool / technology] людей хуже в [y: функция, на которую влияет x]?

Например:

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

По памяти, вездесущий ответ почти всегда: не совсем. У вас всегда будут люди, у которых хорошо и плохо получается [у], но теперь они просто плохи в другом аспекте навыка.

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

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

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

Однако я также чувствую, что фреймворки, такие как веб-формы ASP.NET, абстрагируют всю природу сети без состояния до такой степени, что многие новые веб-разработчики не имеют ни малейшего представления о том, что на самом деле происходит под капотом. Это приводит к неэффективному, раздутому коду, который работает плохо, потому что разработчик соединяет компоненты вместе, используя методологию «drag'n'drop», не понимая, что происходит на уровне HTTP.

Итак, я считаю, что фреймворки необходимы для разработки программного обеспечения высокого уровня, но они не освобождают разработчиков от некоторого понимания того, что абстрагируется. Да, фреймворки могут сделать вас глупыми, но только если вы их не поймете.

Автоматическая коробка передач или чувствительные к дождю дворники делают нас хуже водителей?

Я не думаю, что кодирование без каркасов обязательно подразумевает лучшее понимание базовых систем. Это подтверждается тем, что работодатели вынуждены задавать простые вопросы кодирования на собеседованиях, просто чтобы убедиться, что кандидат может использовать согласованный метод.

В конечном счете, это зависит от разработчика. Хорошие делают, плохие нет.

И в том же духе выбор фреймворка только потому, что он существует без фактического анализа его возможностей и плюсов / минусов, также является признаком плохой практики разработки.

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

Я здесь каждый раз качаю головой, когда явно новый программист спрашивает что-то о, скажем, хранении некоторых данных, и каждый сразу же говорит им использовать инструмент ORM . Нет, нет, нет, нет ... им нужно сначала научиться делать это самостоятельно.

Возможно, распределение «тупости» на самом деле не изменилось, и вместо этого мы просто раздаем разработчикам более масштабные и сложные способы выстрелить себе в ногу?

Это не рамки, которые тупят программистов. Глупые программисты будут глупы, используют ли они фреймворки или нет.

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

Например, я учился в колледже по проектированию компиляторов, где мы кодировали LR-парсер с нуля на C, прежде чем научиться использовать генераторы парсеров, такие как lex и yacc. Это было очень познавательно, и с тех пор я стал лучше понимать и ценить все языки программирования, которые использовал.

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

Это интеллектуальная работа, где ум против тупости еще важнее.

Цитата из превосходного «Дивиденд траты Мура» Джеймса Ларуса (выделение добавлено):

Тридцать лет назад Билл Гейтс изменил приглашение в Altair Basic с «READY» на «OK», чтобы сохранить 5 байт памяти. Сегодня немыслимо, чтобы разработчики знали об этом уровне детализации своей программы, не говоря уже о том, чтобы беспокоиться об этом, и это правильно, поскольку изменение такого масштаба сегодня незаметно ... Мы не могли бы производить сегодняшние системы используя ремесленные методы ручной работы, которые были возможны (необходимы) на машинах с 4К памяти.

Я думаю, что, вероятно, вводить в заблуждение то, что фреймворки позволяют вам избегать навыков, необходимых для решения сложных проблем, или позволяют избежать глубокого понимания. Вместо этого, единственная причина , по которой мы можем создавать современные сложные системы (сложность которых может порождать сложные проблемы и не поддаваться глубокому пониманию), заключается в том, что у нас есть платформы (и высокоуровневые ОО-языки для сбора мусора, и интегрированные среды разработки с контекстно-зависимой помощью и проверка синтаксиса «на лету» и все другие достижения в области разработки программного обеспечения, которые иногда подвергаются критике как обескураживающие программистов).

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

Несколько устаревшим примером является MFC : программист мог бы сэкономить много времени, используя MFC вместо Windows API, но без знания API (что означает наличие опыта реальной работы с необработанным API), они часто зависали , Это почти никогда не происходило, потому что типичный программист MFC обладал знаниями Windows API.

Тем не менее, благодаря Windows Forms в .NET , благодаря лучшей инкапсуляции и лучшей объектной модели, программист может почти игнорировать то, что он использует просто еще одну оболочку Windows API. Так что меньше шансов застрять, но когда это случится, это может повредить.

К сожалению, время выхода на рынок всегда короче, а проекты становятся все сложнее, поэтому у программистов нет времени углубляться. Это печальное состояние индустрии программного обеспечения ...

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

Те, кто нуждается или хочет знать «материал», стоящий за рамками, будут учиться и исследовать всеми правдами и неправдами.

Нет, абсолютно нет. По своей сути фреймворки представляют собой комбинацию библиотеки подпрограмм и шаблона, двух проверенных и надежных инструментов программирования. «Это бедный работник обвиняет свои инструменты ...

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

При создании программного обеспечения фреймворки экономят время. При обучении созданию программного обеспечения фреймворки мешают пониманию.

Я думаю, что проблема в основном в том, что компьютеры стали слишком мощными. Для большинства программистов больше нет разумной причины «приступать к основам». Просто требуется больше времени, чтобы сделать то же самое, и во время выполнения нет никакой значимой разницы. Единственный способ решить эту проблему - ввести искусственные ограничения, как это делают соревнования, такие как js1k.

Может быть, в школах должен быть специальный предмет «Оптимизированный дизайн», где вы должны создавать программы в условиях ограниченного пространства и времени?

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

Большинство Frameworks будут иметь функции, которые программисты будут использовать снова и снова.

По-видимому, чтобы сыграть здесь адвоката дьявола, я думаю, что фреймворки (во всяком случае, «хорошие») могут в значительной степени способствовать развитию образования программиста. Хорошо спроектированный фреймворк решит множество проблем, и, используя фреймворк, программист сможет понять, какие проблемы решаются и как. По моему мнению, структура - это (/ должна быть) кристаллизация лучших практик программирования, и она может научить программиста на примере.