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

16

Я имею в виду, что есть действительно полезные библиотеки, которые могут решать проблемы, когда вы застряли и не знаете, как решить то или иное с вашим знанием языка программирования, который вы используете ... Например, Boost для C ++ или JQuery для JavaScript или Spring для Ява ... Они решают проблемы за считанные секунды, и вам все равно, как они это сделали (несмотря на то, что они написаны на том же языке, на котором вы программируете) ... Так что мне интересно, я один использую библиотеки, хотя и не являюсь способен написать решение своих проблем с нуля или это стандартная практика?

Kabumbus
источник
Они не решают проблемы людей, они - просто решение общих проблем в смежных областях.
Абимаран Кугатасан
так нормально ли не знать, как решать типичные проблемы в смежной области и сказать «просто используйте *** (ваша любимая библиотека здесь)», это исправит это, не вдаваясь в то, как они на самом деле это сделали?
Кабумбус
1
Вы когда-нибудь программировали масштабируемые программы? Честно говоря, ни одна библиотека не является идеальной в 100% случаев, и ошибки неизбежны. Теперь, если эта ошибка находится в одной из многих внешних библиотек, которые вы используете, и через 2 года после цикла разработки вы столкнетесь с проблемами, и что вы знаете? Это одна из тех библиотек, которые вы используете! Так что, честно говоря: нет смысла использовать библиотеки как быстрое решение (по крайней мере, не для программного обеспечения корпоративного уровня и т. Д.), Потому что они становятся чем-то вроде ограничения по мере продвижения вперед.
Йерлук
5
@jerluc: стандартные библиотеки часто гораздо лучше разработаны и поддерживаются, чем код какой-либо организации. Например, Boost's shared_ptr считается «обязательным» для всех в отрасли, с которой я сталкивался, а различные другие фрагменты кода, предоставляемые boost, позволили проекту, над которым я работаю, сосредоточиться на деталях проблемы, а не на потратить время на работу над некоторыми менее важными вещами, которые уже были сделаны. Вы можете столкнуться с проблемами в дальнейшем, поэтому вам следует выбирать библиотеки, которые вы выбираете, но в целом они хороши. Синдром «не развит здесь» - это плохо.
TZHX
@ TZHX Полагаю, я должен быть более определенным в том, чтобы сказать, что то, что я сказал, относится в основном к библиотекам, которые могут выполнять такие вещи, как обертывание того, что можно было бы считать «кодовым элементом». Имеет смысл доверять «изобретенному колесу», не написав обертки ввода-вывода (когда библиотеки доступны для таких оберток), но не имеет смысла доверять «несколько круглому колесу», или, другими словами, библиотеке, которая делает какая-то магия черного ящика и работает для того, что вам нужно в данный момент.
Джерлук,

Ответы:

22

Можно ли не понимать, как решить проблемы самостоятельно, и использовать вместо этого библиотеки?

В общем, нет, это не так.

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

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

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

blueberryfields
источник
13

После того, как computerworld.com.au спросил Бьярна Страуструпа: «Есть ли у вас какие-либо советы для начинающих программистов?» И он ответилПравда программатора и тем, что необходимое для тех , кто будет один.
«Знать основы информатики: алгоритмы, архитектуры машин, структуры данных и т. Д. Не просто слепо копировать методы из приложения в приложение. Знайте, что вы делаете, что это работает, и почему это работает. Не думайте, что вы знайте, какой будет отрасль через пять лет или чем вы будете заниматься тогда, так что соберите портфель общих и полезных навыков. Постарайтесь написать лучший, более принципиальный код. Работайте над тем, чтобы «программирование» стало профессиональной деятельностью и меньше «хакерской» деятельности низкого уровня (программирование - это тоже ремесло, а не просто ремесло). Учитесь у классиков в этой области и у более продвинутых учебников, не будьте довольны легко усваиваемым «как» руководства и онлайн-документация - это мелко ".
Надеюсь, это прояснит ваши сомнения о том, что требуется для

рейнджер
источник
4
+1 - я думаю, что важно отметить, что - хотя я на 100% согласен со Страуструпом - ОП не должен понимать, что это означает, что он должен изобретать велосипед на каждой вещи, которую он делает. Основная причина, по которой образование в области компьютерных наук включает в себя реализацию класса String, MergeSort и других алгоритмов, заключается в том, что, когда мы используем библиотеки, доступные на выбранном нами языке, мы понимаем, что происходит под капотом. Разобраться с достаточным количеством библиотек с хорошим пониманием основ, и можно в значительной степени предсказать, что
скрывается
Формируется человек, которому нужно несколько десятков параграфов, чтобы тщательно проанализировать, обосновать и объяснить, почему особая марка и аромат чая пробудили его интерес, при этом полностью отказавшись от сути первоначального вопроса. НО я все еще люблю его!
Филипп Дупанович
1
Честно говоря, я знаю много об алгоритмах, архитектурах машин, структурах данных и многом другом. Это не значит, что я понимаю, что именно делает каждая из наших сторонних библиотек, или даже вся теория, лежащая в ее основе. Я думаю, что это хороший совет, но он не означает, что нужно знать все о вашем приложении.
Дэвид Торнли
12

Да, и мы все делаем это!

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

  1. Во-первых, метод Objective C выделяет буфер пикселей с помощью malloc () и присоединяет его к своему объекту Objective C.
  2. Позже что-то происходит, и подпрограмма C отправляет сообщение в объект Objective C и получает буфер пикселей.
  3. Подпрограмма C сжимает содержимое пиксельного буфера с помощью jpeglib и отправляет его через соединение TCP / IP.

Там очень много всего происходит! Вот несколько вещей:

  • Динамический распределитель памяти для реализации malloc (), который предполагает, что память является физически смежной и линейно адресуемой.
  • Базовая система виртуальной памяти ядра Дарвина для отображения как фрагментированной физической ОЗУ, так и дискового пространства (которое отличается от физического ОЗУ) в нечто, что представляется динамическому распределителю памяти, как физически непрерывная и линейно адресуемая ОЗУ.
  • Объектная система объективного C
  • Система обмена сообщениями во время выполнения Mac OS и способ ее взаимодействия с объектами Objective C
  • Реализация в библиотеке jpeglib стандарта сжатия растровых изображений JPEG с потерями, в котором используется алгоритм дискретного косинусного преобразования
  • Сетевая подпрограмма пользовательского пространства для отправки данных, которая вызывает различные реализации протоколов TCP и IP, которые, в свою очередь, обращаются к ядру ОС. Затем, в зависимости от того, что вы включили для своей сети, он может вызвать драйвер для порта Ethernet, чип Wi-Fi или, что более необычно, драйвер USB или Firewire.

Вы понимаете все детали того, как все эти вещи на самом деле реализованы? Я уверен, что нет! Я сомневаюсь, что есть очень много людей на планете, которые делают - возможно, даже ни один. Так что я просто не беспокоюсь об этом.

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

Боб Мерфи
источник
1
Если бы мне нужно было понять весь код, который я использую регулярно, мне нужно было бы понять сжатие данных, включая JPEG, геометрическое представление данных, включая все в <i> Книге Nurbs </ i>, тонкости форматов PDF и U3D и гораздо больше. У меня есть ссылки на все, но я никогда не буду иметь все это в упадке.
Дэвид Торнли
Я должен признать, что я не всегда понимаю в деталях все строительные блоки, которые я использую для написания рабочего кода, но я чувствую себя несчастным, когда это происходит. Понимание или, по крайней мере, знание того, что при необходимости я могу понять базовые компоненты, значительно облегчает жизнь. Я рад, что знаю, как работает распределитель, какие принципы используются для сжатия изображения JPEG, как работает TCP / IP, как может быть реализована виртуальная память, как работает ЦП и т. Д. С удалением всех этих низкоуровневых деталей это хорошо, но не имея доступа к деталям, чувствует себя очень плохо ...
Пьер Арно
5

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

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

Также мы обычно решаем проблемы, абстрагируя сложные части, так почему же это не так?

Spoike
источник
5

Библиотеки существуют для решения общих проблем. Вам нужно решить, решат ли они конкретную проблему, которую вы решаете. Они НЕ заменяют незнание того, как решить проблему. Например, предположим, что вашему приложению требуется хеш-таблица, у вас должно быть достаточно знаний, чтобы понять, какую проблему решает хеш-таблица. Вы должны быть в состоянии оценить производительность библиотеки, которую вы используете, чтобы решить, будет ли она работать в вашем приложении. Я считаю, что использование библиотеки для покрытия неадекватных технических знаний не является правильным вариантом использования. Решение об использовании библиотеки должно зависеть от того, ускорит ли использование библиотеки разработку и предоставит ли она проверенное и надежное решение. Решение об использовании библиотеки не должно зависеть от неспособности программистов решить данную проблему.

Pemdas
источник
Это означало бы, что для моего текущего проекта мне нужно знать детали спецификаций PDF и U3D. Для определенного проекта аспирантуры мне пришлось бы много знать об определенных алгоритмах линейного программирования (симплекс был бы безнадежным для моего случая). Если бы было необходимо точно понять, что делает библиотека, чтобы использовать ее, я бы никогда ничего не сделал.
Дэвид Торнли
Я не утверждаю, что вам нужно понять все детали реализации. Но стоит знать, чего ожидать от результата. Возьмите пример хеш-таблицы снова. Если вы видите низкую производительность, то как начать оценивать причину. Первая вещь, о которой я бы начал думать, это частота столкновений между моими ключами. Если вы не представляете, как что-то работает, то как вы можете начать выдвигать гипотезу о причинах, по которым что-то не работает или не работает так, как вы ожидаете?
Пемдас
5

На самом деле, до вас .

Чем лучше вы понимаете инструменты, с которыми работаете, тем лучше вы можете ими воспользоваться.

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

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

dukeofgaming
источник
5

Важно знать свое царство и свою часть процесса.

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

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

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

GrandmasterB
источник
2

По моему опыту: поскольку вы не можете устранить библиотечную зависимость, вы и ваша команда должны знать достаточно, чтобы решить проблему.

Как программисты, у нас мало времени, поэтому мы должны выбрать тот, который имеет наивысший приоритет. Проблема должна быть решена как можно быстрее и деликатнее. Только эта причина делает «изучение всего, что работает» несколько излишним.

Здесь я хочу добавить «зависимость». Как сообщество, мы все зависимы от других. Мы стоим на Giants для создания нашего приложения: Java, .NET, API ... И мы доверяем Giants в их работе; потому что это работает для очень многих людей. Если у вас есть проблема с фреймворком или API, есть хороший шанс, что другие где-то сталкивались с этим, и есть решение / обходной путь.

Единственная проблема здесь: может быть, где-то, по ограниченным критериям, гиганты рухнули. Например, flash не поддерживается в некоторых ОС, и есть много вещей, которые мы не могли бы сделать без нее. Эта возможность больше нуля, но в этом случае у нас есть небольшие вещи, которые мы можем сделать. Только в этих случаях знание о том, «что скрывается за капотами», оказывается полезным, поскольку оно указывает на то, где проблема действительно и может создать большой обходной путь; но я не уверен, что время, которое мы инвестируем, действительно того стоит.

Чтобы справиться с этой возможностью, я думаю, что есть решение: потому что большинство программистов могут легко уловить «поверхностную работу» библиотеки, и только иногда нам действительно нужен кто-то, кто очень хорошо понимает: давайте разделим команду, чтобы сделать это. Попытка объединить команду, в которой каждый испытал около 1,2 полезных библиотек / инструментов / «наборов навыков», которые включали : у кого-то хороший опыт работы с jQuery, у кого-то специализация на базе данных, ... Это очень поможет в минимизации рисков.

Хонг Лонг
источник
2

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

При вызове быстрой сортировки вы должны знать о худшем поведении. В противном случае злоумышленник может ввести данные для наихудшего случая и выполнить DoS.

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

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

Безопасный
источник
1
Выделение буферов фиксированного размера для чего-либо является переполнением буфера, ожидающим, чтобы случиться. Гораздо лучше использовать язык, который поддерживает динамические массивы и позволяет вызываемому пользователю управлять своими собственными буферами.
Мейсон Уилер
1

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

Одной из трудностей в программировании является преодоление соблазна решить все проблемы самостоятельно.

Камил Шот
источник
1

Это нормально, но это опасно. Как общая практика, человек должен знать, что он разработал.

Рейчел
источник
1

Своего рода...

Это нормально, если вы получаете общее представление о том, что пытается сделать библиотека или фреймворк. Что касается внутренних частей, а что нет то нет. Прагматичный подход. Это работает, он сделал то, что я хочу, хорошо.

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

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

Но не пытайтесь все выяснить, если у вас нет много свободного времени ... Посмотрите на это так. Причиной для языков программирования является то, что мы защищаем от выполнения ассемблерного кода, причина для того, чтобы ассемблерный код защищал нас от выполнения 1 и 0. Я не думаю, что вам нужно знать все мелкие детали механизма, стоящего за ним, но просто знать общую суть этого. Как сборщик мусора, я знаю, что он будет иметь дело с моими указателями / памятью, мне все равно, какой магически аккуратный алгоритм он использует, я просто знаю, что он работает (для того, что мне нужно) и больше ничего не делает. Может быть, минус этого, но Мех. Если, конечно, вы не в той области, где вам приходится иметь дело с этим. Тогда ты бы не стал задавать этот вопрос, потому что это часть твоей работы, ха-ха.

mythicalprogrammer
источник