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

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

Если вы спрашиваете себя, откуда взялось название: то, как работал сокурсник в университете, немного напомнил мне о создании Lego. Я не хотел иметь проблем с компанией по производству игрушек и изменил название на Bricks. Также LBD уже расшифровывается как «Learning by Design», а BBD было свободным сокращением 🤓.

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

В этой статье я хочу вернуться к этой теме и поделиться с ней своим последним опытом и мнениями людей вокруг меня.

Это не всегда так плохо

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

Код, который вам нужен для определенного домена, вероятно, уже был реализован другими специалистами в этой области.
Некоторые другие преимущества:

  • Библиотека, вероятно, уже используется и одобрена многими разработчиками заранее - например. JUnit, широко используемая среда тестирования приложений Java.
  • Большинство ошибок и крайних случаев уже рассортированы
  • Хорошие библиотеки поддерживаются и улучшаются
  • Необязательно быть экспертом во всех областях, чтобы создать приложение - например, NumPy - пакет для фундаментальных научных вычислений с Python, включая математические типы данных и функции.

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

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

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

Однако…

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

Риск 1 - вы слишком зависимы (это обязательство)

В 2016 году пакет NPM из 17 строк был удален из-за юридической проблемы. Этот пакет использовался для выравнивания текста по правому краю, и от него зависели некоторые популярные фреймворки. В результате были сломаны тысячи приложений. Ну… вы поняли!

Всю историю можно найти здесь: https://arstechnica.com/information-technology/2016/03/rage-quit-coder-unpublished-17-lines-of-javascript-and-broke-the-internet/

Риск 2 - безопасность

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

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

Изобретайте велосипед!

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

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

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

Есть и другой способ - мышление первого принципа.

Сведите все к самой фундаментальной истине. То, что мы уверены, правда, а затем рассуждать оттуда - Илон Маск

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

Например:
Илон Маск, один из самых новаторских людей нашего времени, использует такое мышление для решения проблем.
https://medium.com/the- миссия / Илон-Маск-3-ступенчатых-первых-принципов-мышление-как-думать-и-решать-сложные-проблемы-подобные-a-ba1e73a9f6c0

В SpaceX он разрабатывал ракеты, основываясь только на законах физики, а не на улучшении современных технологий. Он не хотел верить, что полет в космос обходится так дорого. С его новаторской идеей повторно использовать ракеты и ускорители, ему удалось сократить расходы на полет в космос более чем в сотню раз. Https://jamesclear.com/first-principles

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

Вот несколько примеров, которые показывают, что иногда необходимо «изобретать колесо», чтобы эффективно решать некоторые проблемы и оказывать более сильное влияние. (Также вряд ли кто-то вспомнит «человека», работавшего над 42 итерацией библиотеки Node-JS 🤓)

Совершенно другой (но важный) момент - это накладные расходы, которые библиотека может привнести в программный проект. Скорее всего, вы не стали бы использовать каждую строку библиотеки или ее функциональные возможности, увеличивая размер приложения. Например, когда вы устанавливаете или обновляете приложение на своем мобильном устройстве, вы всегда загружаете все приложение со всеми его скомпилированными библиотеками. У вас, вероятно, нет неограниченного объема сотовых данных, и вы не хотите тратить их все таким образом. Кроме того, у Apple даже есть ограничение для AppStore. Если размер приложения превышает 150 МБ, его можно загрузить только при подключении к Wi-Fi.

Заключение

Как видите, нет однозначного правильного или неправильного. Использование библиотек дает много преимуществ, но в то же время создает риски и другие компромиссы. Я надеюсь, что эта статья проясняет обе стороны медали.
В настоящее время создание программного обеспечения без существующих компонентов для компании среднего размера неосуществимо. Уже есть хорошие решения общих проблем, которые можно использовать. Имейте в виду, что очень важно думать о поддерживаемости и компонентах, которые зависят от используемых библиотек. Также имейте в виду, что ошибки могут не быть исправлены в ближайшем будущем (или вообще не будут исправлены). И последнее, но не менее важное: каждая библиотека потенциально может включать в себя вредоносный код и накладывать на него накладные расходы.

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