Читать книгу Мастерство Программирования - - Страница 20

"Умные программисты не пишут сложный код; они пишут код, который кажется сложным, пока вы не поймете его, а потом он кажется простым. Настоящий Мастер пишет код, который кажется простым с первого взгляда."

– Известная мудрость сообщества

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

Отсюда родился один из самых известных принципов в программировании:"Не изобретай велосипед"(Don't Reinvent the Wheel). Он призывает: если кто-то уже сделал что-то хорошо и поделился этим, не тратьте свое время на создание того же с нуля. Возьмите готовое! Казалось бы, логично и просто. Но как и во всём в жизни Мастера, здесь есть свои тонкости и парадоксы.

▍Почему обычно "не стоит изобретать велосипед"

Большую часть времени следовать принципу "не изобретай велосипед"– это очень мудрое решение. Вот почему:

1. Скорость разработки: Это самый очевидный плюс. Если вам нужно просто отправить письмо, зачем писать свой собственный почтовый протокол, когда можно вызвать одну функцию из готовой библиотеки? Вы экономите часы, дни, а то и недели работы.

2. Надежность и качество: Популярные библиотеки и фреймворки уже прошли "огонь, воду и медные трубы". Их тестировали тысячи (если не миллионы) разработчиков. Баги, скорее всего, уже найдены и исправлены. Ваши "самописные"решения почти всегда будут менее надежными на старте.

3. Богатая функциональность: Готовые решения часто предлагают гораздо больше функций, чем вам нужно прямо сейчас. Но если вдруг понадобится что-то дополнительное, скорее всего, оно уже есть "в коробке".

4. Поддержка и сообщество: У популярных библиотек есть огромные сообщества. Есть документация, примеры, форумы, где можно задать вопрос и получить помощь. Вы не останетесь один на один с проблемой.

Представьте, что вы хотите сделать бутерброд. Вы можете испечь хлеб, вырастить пшеницу, смолоть муку… или просто купить готовый батон в магазине. Для большинства задач "купить батон"– это гораздо быстрее и эффективнее.

▍Обратная сторона медали: Когда зависимость от внешних библиотек может быть проблематичной

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

1. Проблема зависимостей (Dependency Hell): Подключая одну библиотеку, вы часто подключаете "вагон и маленькую тележку"других библиотек, от которых она зависит. Эти зависимости могут конфликтовать между собой, ломать ваш код или вызывать неожиданные проблемы. Это как если бы ваш батон требовал доставки только на специальной машине, которая сама требует особого топлива и водителя.

2. "Раздувание"(Bloat): Иногда для одной небольшой функции приходится подключать огромную библиотеку, которая тащит за собой много ненужного кода. Это увеличивает размер вашего приложения, потенциально замедляет его и усложняет. Забивать гвоздь кувалдой можно, но зачем?

3. "Черный ящик": Если вы не понимаете, как работает библиотека внутри, отладка проблем или кастомизация могут превратиться в настоящий кошмар. Вы видите только внешний интерфейс, но не можете заглянуть под капот. Это как водить машину, не зная, где находится двигатель. Пока едет – хорошо, а как сломается…

4. Потеря контроля: Вы полностью зависите от команды, которая поддерживает библиотеку. Они могут изменить API, прекратить поддержку, добавить баги или не выпустить нужную вам фичу. Ваше приложение будет "заложником"чужих решений.

5. Технический долг: Иногда "быстрое"подключение библиотеки приводит к тому, что она становится частью критической логики, которую потом сложно заменить. Избавиться от неё – значит переписать огромный кусок кода, а это дорого и долго. Костыль, который притворился фундаментом.

6. Риски безопасности: Внешние библиотеки, особенно малоизвестные или плохо поддерживаемые, могут содержать уязвимости. Злоумышленники могут использовать их для взлома вашего приложения. Мастер всегда держит в уме аспекты безопасности, и это часть его ответственности. Были прецеденты, когда популярные библиотеки обнаруживались с критическими брешами или даже содержали предумышленные вредоносные закладки. Это как купить "безопасный"батон, а потом обнаружить, что в нем был яд.

7. Геополитические и экономические риски (Санкции): В современном мире это стало крайне актуально. Зависимость от иностранных библиотек может стать критической проблемой. Если доступ к репозиториям блокируют, лицензии аннулируют, или поддержка прекращается из-за санкций, ваше приложение может потерять важную функциональность, возможность сборки/обновления или даже стать полностью неработоспособным. Это учит Мастера более глубоко оценивать риски, связанные с выбором технологий и поставщиков.

▍Когда "изобретать велосипед"может быть полезно или оправдано для Мастера

Итак, когда же Мастер, взвесив все "за"и "против", решает не брать готовое, а создать своё?

1. Критически важная логика: Если речь идет об уникальной, фундаментальной или конкурентно значимой части вашего продукта, которая определяет его суть. То, что делает ваш продукт вашим. Здесь вы хотите полного контроля и уникальности.

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

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

4. Обучение и глубокое понимание: Переписывание некоторых базовых компонентов для себя (пусть даже не для "боевого"проекта, а для обучения) – отличный способ глубоко понять принципы их работы, алгоритмы и ограничения. Так вы становитесь Мастером, а не просто "пользователем"инструмента.

5. Простота: Если функционал, который вам нужен, настолько прост, что подключение целой библиотеки создает больше проблем, чем решает (например, зачем импортировать огромную библиотеку для работы с массивами, если вам нужна всего одна функция, которую можно написать в 5 строк?).

6. Отсутствие альтернативы: Когда готовых решений просто не существует, или они такого низкого качества, что ваш "велосипед"будет лучше.

Главный урок для Мастера: Принцип "не изобретай велосипед"– это мудрое правило, но не догма. Ваша задача – не слепо следовать ему, а осознанно принимать решение. Всегда задавайте себе вопросы: "Почему я использую эту библиотеку?", "Каковы риски?", "Действительно ли мне это нужно?", "Могу ли я сделать это лучше/проще/безопаснее/эффективнее?".

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

-–

Задание для мастера:Подумайте о проекте, в котором вы используете много сторонних библиотек. Выберите 2-3 из них:

1. Почему вы их используете? Соответствуют ли они причинам "не изобретать велосипед"?

2. Какие потенциальные "обратные стороны медали"могут быть у этих библиотек для вашего проекта (риски безопасности, "раздувание", потеря контроля)?

3. Есть ли в вашем проекте что-то, что вы писали с нуля, хотя могли бы использовать библиотеку? Если да, почему вы так поступили? Было ли это оправдано?

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