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

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

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

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

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

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

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

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

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

Давайте возьмем, к примеру, очень простую ошибку, которую я исправил в некотором графическом коде, связанном с 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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