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

22

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

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

Gratzy
источник
Вот хорошая статья, которую я вспомнил несколько лет назад и которая касается вашего вопроса. В частности, автор ссылается на проблему, связанную с отсутствием чего-то похожего на BASIC как на платформу для обучения. salon.com/technology/feature/2006/09/14/basic
GrandmasterB
Мы обучаем навыкам решения проблем, необходимым для выбора правильной структуры из множества «еще одной» структуры.
systempuntoout
1
Что значит заглушить группу людей?
Рэндалл Шульц

Ответы:

18

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


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

Jé Queue
источник
4
+1...just solving MVC, it has gone too far.
Талви Ватиа
2
Мне смешно, что Гратзи принял этот ответ, а сообщество не проголосовало за лучший ответ на его субъективный вопрос (который говорит об обратном). Похоже, он пытался найти ответ, а не задавать вопрос.
Крейг,
1
@Craige - вы подразумеваете, что правильный ответ всегда самый популярный ответ?
Jé Queue
1
@Xepoch - Совсем нет. Как субъективный вопрос, я чувствую, что у этого вопроса нет реального ответа с самого начала. Мне просто интересно, что он выбрал ответ, который говорит противоположность большинству других ответов на этой странице. Я думаю, что он нашел единственный ответ, который отражал то, что он предложил в своем вопросе, и решил, что он был правильным, потому что он соответствовал его убеждениям.
Крейг,
31

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

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

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

Например:

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

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

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

Стивен Эверс
источник
Большие ракетки требуют меньшего мастерства от теннисистов хуже?
Системович
22

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

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

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

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

Дэн Диплом
источник
Не могу согласиться с «веб-формами ASP.NET, абстрагирующими всю безлимитную природу сети», я очень часто встречался с разработчиками, которые не понимают, что происходит под ними и вызывает глупые проблемы сIsPostBack
billy.bob
14

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

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

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

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

Адам Лир
источник
11
Автоматический транссексуал делает водителя хуже :)
Jé Queue
3
Я не согласен только с вопросом, позволяют ли фреймворки создавать больше плохих разработчиков?
Gratzy
2
@Gratzy: я так не думаю. Я думаю, что те же самые плохие разработчики будут процветать без фреймворков, просто по-разному.
Адам Лир
3
Я не согласен с Анной. Без фреймворков даже ленивым программистам приходилось расширять свои знания. Фреймворки на самом деле увеличивают (возможно, немного) число плохих программистов.
Волшебник
1
Чтобы противостоять аргументу автоматической трансляции: многие профессиональные водители не водят машины с ручным управлением, а многие другие переходят к плавному переключению весла, которое обычно управляется компьютером.
Стивен Эверс
10

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

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

GrandmasterB
источник
4
Где останавливается менталитет «ты должен сделать это сам»? Каждый программист должен написать свой собственный компилятор перед его использованием?
Мипади
2
Это не останавливает. Программисты всегда должны учиться. Не всем программистам нужно писать компилятор. Но я сомневаюсь, что есть много замечательных программистов, которые проходят всю свою карьеру настолько безрассудно в своем ремесле, что в какой-то момент даже не пытаются ее сделать.
GrandmasterB
6
В соответствии с логикой отказа от использования инструмента ORM до тех пор, пока вы сначала не «сделаете это самостоятельно», я, вероятно, также не должен использовать уровень абстракции базы данных, пока не напишу обращения к базе данных напрямую? Или, на самом деле, я не должен использовать базу данных, пока не напишу систему хранения с использованием файловой системы? Ну, файловая система тоже абстракция ... С чего начать? Для каждого поколения они собираются начать с более высокого уровня абстракции или, чтобы сделать более интересные вещи за меньшее время.
RationalGeek
2
Я думаю, что если программист остается на более высоких уровнях абстракции, он может быть совершенно компетентным программистом и создавать совершенно функциональные бизнес-приложения из своих совершенно функциональных кабин. Но я сомневаюсь, что они будут теми, кто создаст следующий обязательный язык программирования, или тот, который создаст следующее новшество в базах данных, или напишет следующую инновационную игру, которая выдвигает графические технологии на грань.
GrandmasterB
2
@jkohlhepp: В каждом значительном проекте, который я когда-либо пытался, предоставленная абстракция всегда просачивалась. Если бы у меня не было стремления понять глубокие вещи происходящего, я был бы потерян и непродуктивен. Если вы когда-нибудь хотите делать интересные вещи, вы должны знать все.
Пол Натан
4

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

Родни Гицель
источник
4

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

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

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

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

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

Билл Карвин
источник
4

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

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

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

Джош Келли
источник
2

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

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

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

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

колдун
источник
1

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

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

Джесси С. Слайсер
источник
1

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

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

Shog9
источник
Я думаю, что вы, возможно, упускаете суть вопроса, я не предполагаю, что фреймворки не являются хорошими инструментами, потому что существует очень много инструментов, обеспечивающих настолько много абстракций, что это позволяет большему количеству людей обвинять их инструмент.
Gratzy
3
@Gratzy: ну конечно. Чем больше людей используют инструмент, тем больше сука об этом. Когда компьютеры были огромными, дорогими и редкими, только горстка людей в мире могла жаловаться на то, как тяжело им пользоваться - теперь это делают все . Точно так же фреймворки не должны делать программистов еще тупее - они просто привлекают множество и немых программистов.
Shog9
1

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

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

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

Джори Себрехтс
источник
-1

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

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

Панду
источник
1
Оу, ты не мог быть более неправильным с твоим ответом.
NB
-1

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

Крис Аллен Лейн
источник
Почему отрицательный голос? Просто потому что ты не согласен? Бу.
Крис Аллен Лейн