Создавайте небольшие специализированные модули для повторного использования и для создания более крупных и сложных вещей, о которых будет легче думать.
Изначально это был ответ на мою AMA (Ask Me Anything) о том, почему я делаю небольшие модули Node.js. Мой ответ относится к Node.js и может быть неприменим к вашей платформе. Причина, по которой это так хорошо работает на Node.js, заключается в том, что у вас могут быть вложенные зависимости, поэтому они никогда не конфликтуют.
Люди слишком легко попадают в ловушку LOC (строк кода). LOC практически не имеет значения. Неважно, состоит ли модуль из одной строки или из сотен. Все дело в сдерживании сложности. Думайте о модулях узлов как о блоках Lego. Вам не обязательно заботиться о деталях того, как это сделано. Все, что вам нужно знать, это как использовать блоки Lego, чтобы построить свой замок Lego. Создавая небольшие специализированные модули, вы можете легко создавать большие сложные системы, не зная каждую деталь того, как все работает. Наша кратковременная память ограничена. Вдобавок, имея эти модули как повторно используемые пакеты, другие люди могут повторно использовать их, и когда модуль улучшается или исправлена ошибка, выигрывает каждый потребитель.
Представьте себе, если бы все производители ПК сделали свои собственные процессоры. Большинство сделало бы это плохо. Компьютер был бы дороже, и у нас были бы более медленные инновации. Вместо этого большинство используют Intel, ARM и т. Д.
Это было бы невозможно, если бы не принцип работы npm. Красота возможности использовать вложенные зависимости означает, что мне не нужно заботиться о том, какие зависимости есть у используемой мной зависимости. Это мощно.
Несколько лет назад. До Node.js и npm. У меня была большая база данных фрагментов кода, которые я использовал для копирования и вставки в проекты, когда мне это было нужно. Это были небольшие утилиты, которые иногда пригодились. npm теперь моя база данных сниппетов. Зачем копировать-вставить, если это можно require и с преимуществом ясного намерения. Исправление ошибки во фрагменте означает обновление одного модуля вместо ручного исправления всех экземпляров, в которых используется фрагмент.
Например, Chalk - один из самых популярных модулей на npm. Вы можете не осознавать, что на самом деле это набор модулей. Это зависит от модуля для определения, поддерживает ли терминал цвет, для получения escape-кодов ansi и т. Д. Все это могло быть просто встроено в основной модуль, и, вероятно, есть во многих случаях. Но это означало бы, что любому, кто хочет создать альтернативный модуль стилей терминальной строки, придется изобретать колесо во всем. Имея эти вспомогательные модули, люди могут легко извлечь выгоду из нашей работы в Chalk и, возможно, даже помочь улучшить Chalk косвенно, улучшив одну из зависимостей.
Еще один пример. У меня есть модуль user-home, который получает домашний каталог пользователя. Вы могли подумать, что проще просто сделать process.platform === 'win32' ? process.env.USERPROFILE : process.env.HOME. И большинство из них так и поступают. Но сначала зачем требовать, чтобы все знали, как получить домашний каталог? Почему бы не использовать Лего-блок? Вы также можете не осознавать, что эта проверка не завершена. В Windows вы также должны проверить process.env.HOMEDRIVE + process.env.HOMEPATH, и вы также можете выполнить дополнительные проверки. Блоки Лего. (Сейчас в Node.js для этого есть API, именно по причинам, указанным выше)
Вы сами делаете обувь? Нет, вы покупаете их в магазине. Большинство не заботится о том, как сделана обувь. Насколько хорошо он подходит.
Я хочу, чтобы программирование было проще. Упрощает создание надежных систем. И путь вперед, с моей точки зрения, определенно не состоит в том, чтобы изобретать все заново, и каждый снова и снова совершает одни и те же глупые ошибки.
