Maison >interface Web >js tutoriel >Concevez et construisez votre propre base de code JavaScript : trucs et astuces
Codebase : Nous les utilisons tout le temps. Les bibliothèques de code sont l'endroit où les développeurs regroupent le code qu'ils utiliseront dans leurs projets, ce qui permet toujours de gagner du temps et d'éviter de réinventer la roue. Il est préférable d'avoir un package réutilisable, qu'il soit open source ou fermé, plutôt que de créer encore et encore des packages avec les mêmes fonctionnalités ou de copier et coller manuellement à partir de projets antérieurs.
Arrêtez de mutiler les corps : les périls de la taille de police des pixels
ES2016 : l'avenir de JavaScript doit-il être axé sur les développeurs ?
En plus du code packagé, la base de code peut-elle être décrite plus précisément ? À quelques exceptions près, une base de code est généralement constituée d'un seul fichier ou de plusieurs fichiers dans le même dossier. Son code doit pouvoir être enregistré séparément et utilisé normalement dans votre projet. Les fichiers de bibliothèque vous permettent d'ajuster la structure ou le comportement en fonction du projet. Imaginez un périphérique USB qui communique uniquement via l'interface USB. Certains appareils, tels que les souris et les claviers, peuvent être configurés via les interfaces fournies par l'appareil.
Dans cet article, je vais vous expliquer comment construire le fichier bibliothèque. Bien que la plupart des méthodes puissent être appliquées à d’autres langages, cet article se concentre sur la création de bibliothèques JavaScript.
Avant tout, les bibliothèques permettent de réutiliser facilement le code existant. Vous n'avez pas besoin de déterrer un ancien projet pour copier les fichiers, il suffit d'introduire les fichiers de la bibliothèque. Cela vous permet également de diviser votre application en composants, ce qui rend la base de code de votre application plus petite et plus facile à maintenir.
Bibliothèque Christ Church (source)
Tout code abstrait qui facilite la mise en œuvre d'une fonction spécifique ou peut être réutilisé peut être empaqueté dans une bibliothèque déposer. jQuery est un exemple intéressant. Bien que l'API de jQuery dispose d'un grand nombre d'API DOM simplifiées, elle revêtait une importance considérable dans le passé lorsque les opérations DOM entre navigateurs étaient difficiles.
Si un projet open source devient populaire et que de nombreux développeurs l'utilisent, il y a de fortes chances que des personnes participent à son développement en posant des questions ou en contribuant au code. Quoi qu’il en soit, cela aide la bibliothèque et les projets qui en dépendent.
Une bibliothèque open source populaire apportera également de grandes opportunités. L'entreprise peut reconnaître la qualité de votre travail et vous faire une offre. Peut-être que l'entreprise vous demandera d'intégrer votre projet dans son application. Après tout, personne ne connaît mieux votre projet que vous.
Bien sûr, cela pourrait être juste une habitude : aimer taper, aider les autres et apprendre et grandir dans le processus. Vous pouvez repousser vos limites et essayer de nouvelles choses.
Avant d'écrire la première ligne de code, vous devez déterminer ce que fait votre bibliothèque - vous devez définir une cible. Avec cet objectif, vous pouvez vous concentrer sur le problème que vous souhaitez résoudre avec cette bibliothèque. Gardez à l’esprit que la forme originale de votre base de code sera plus facile à utiliser et à mémoriser lors de la résolution de problèmes. Plus l’API est simple, plus il est facile pour les utilisateurs d’apprendre votre base de code. Présentez une philosophie de conception Unix :
Faites une chose et faites-la bien
Demandez-vous : quel problème votre base de code résout-elle ? Comment allez-vous le résoudre ? Allez-vous tout faire vous-même ou utiliserez-vous la base de code de quelqu'un d'autre ?
Peu importe la taille de votre base de code, essayez de créer une feuille de route. Répertoriez toutes les fonctionnalités que vous souhaitez et divisez-les en autant de morceaux que possible jusqu'à ce que vous disposiez d'une base de code petite mais résolvant les problèmes qui ressemble à un produit minimum viable. Cela deviendra votre première version. À partir de là, vous pouvez établir des jalons pour chaque nouvelle fonctionnalité. Essentiellement, vous transformez votre projet en morceaux de code au niveau du bit, ce qui rend chaque fonctionnalité plus efficace et plus intéressante. Croyez-moi, cela vous gardera en forme.
À mon avis, je souhaite développer ma base de code du point de vue de l'utilisateur. On pourrait appeler cela une conception centrée sur l’utilisateur. Essentiellement, vous créez un aperçu de votre base de code, en y réfléchissant davantage et en la rendant plus facile à utiliser pour ceux qui la choisissent. Dans le même temps, vous devez réfléchir aux domaines dans lesquels vous avez besoin de personnalisation, ce qui sera abordé plus loin dans cet article.
Le test ultime de l'API consiste à essayer vos propres techniques et à utiliser votre base de code dans votre projet. Essayez de remplacer le code précédent par le vôtre et voyez s'il répond aux fonctionnalités souhaitées. Essayez de rendre votre base de code aussi intuitive que possible, en lui permettant d'être utilisée de manière plus flexible dans des conditions limites et personnalisable (plus d'informations à ce sujet dans un article ultérieur).
Voici un aperçu de ce à quoi pourrait ressembler une base de code pour les chaînes d'agent utilisateur :
// Start with empty UserAgent string var userAgent = new UserAgent; // Create and add first product: EvilCorpBrowser/1.2 (X11; Linux; en-us) var application = new UserAgent.Product('EvilCorpBrowser', '1.2'); application.setComment('X11', 'Linux', 'en-us'); userAgent.addProduct(application); // Create and add second product: Blink/20420101 var engine = new UserAgent.Product('Blink', '20420101'); userAgent.addProduct(engine); // EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101 userAgent.toString(); // Make some more changes to engine product engine.setComment('Hello World'); // EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101 (Hello World) userAgent.toString();
En fonction de la complexité de votre code, vous pourriez consacrer beaucoup de temps à la structure organisationnelle . L'utilisation de modèles de conception est un excellent moyen d'organiser votre base de code et peut même résoudre certains problèmes techniques. Cela évite également une refactorisation approfondie pour ajouter de nouvelles fonctionnalités.
La flexibilité est ce qui rend une base de code puissante, mais il est difficile de déterminer les limites entre ce qui peut et ce qui ne peut pas être personnalisé. chart.js et D3.js sont de bons exemples. Les deux bibliothèques de codes sont utilisées pour la visualisation des données. Chart.js facilite la création de graphiques intégrés sous différentes formes. Mais si vous souhaitez plus de contrôle sur les images, D3.js est ce dont vous avez besoin.
Il existe plusieurs manières de donner le contrôle à l'utilisateur : configuration, exposition de méthodes publiques, via des rappels et des événements.
La configuration de la base de code se fait généralement avant l'initialisation. Mais certaines bibliothèques de code vous permettent de modifier les configurations au moment de l'exécution. Les configurations sont généralement limitées à de petites pièces et seule la modification de leurs valeurs pour une utilisation ultérieure est autorisée.
// Configure at initialization var userAgent = new UserAgent({ commentSeparator: ';' }); // Run-time configuration using a public method userAgent.setOption('commentSeparator', '-'); // Run-time configuration using a public property userAgent.commentSeparator = '-';
方法通常是暴露给实例使用的,比如说从实例中获取数据,或者设置实例的数据和执行操作。
var userAgent = new UserAgent; // A getter to retrieve comments from all products userAgent.getComments(); // An action to shuffle the order of all products userAgent.shuffleProducts();
回调通常是在公共的方法中被传递的,通常在异步操作后执行用户的代码。
var userAgent = new UserAgent; userAgent.doAsyncThing(function asyncThingDone() { // Run code after async thing is done });
事件有很多种可能。有点像回调,除了增加事件句柄是不应该触发操作的。事件通常用于监听,你可能会猜到,这可是事件!更像回调的是,你可以提供更多的信息和返回一个数值给代码库去进行操作。
var userAgent = new UserAgent; // Validate a product on addition userAgent.on('product.add', function onProductAdd(e, product) { var shouldAddProduct = product.toString().length < 5; // Tell the library to add the product or not return shouldAddProduct; });
在一些例子中,你可能允许用户对你的代码库进行扩展。因此,你需要暴露一些公共方法或者属性来让用户填充,像Angular的模块 (angular.module('myModule'))和Jquery的 fn(jQuery.fn.myPlugin)或者什么都不做,只是简单的让用户获取你的代码库的命名空间:
// AngryUserAgent module // Has access to UserAgent namespace (function AngryUserAgent(UserAgent) { // Create new method .toAngryString() UserAgent.prototype.toAngryString = function() { return this.toString().toUpperCase(); }; })(UserAgent); // Application code var userAgent = new UserAgent; // ... // EVILCORPBROWSER/1.2 (X11; LINUX; EN-US) BLINK/20420101 userAgent.toAngryString();
类似的,这允许你重写方法。
// AngryUserAgent module (function AngryUserAgent(UserAgent) { // Store old .toString() method for later use var _toString = UserAgent.prototype.toString; // Overwrite .toString() UserAgent.prototype.toString = function() { return _toString.call(this).toUpperCase(); }; })(UserAgent); var userAgent = new UserAgent; // ... // EVILCORPBROWSER/1.2 (X11; LINUX; EN-US) BLINK/20420101 userAgent.toString();
在后面的例子中,允许你的用户获取代码库的命名空间,让你在对扩展和插件的定义方面上的控制变小了。为了让插件遵循一些约定,你可以(或者是应该)写下文档。
对测试驱动开发(test-driven development)来 说,写下大纲是良好的开始。简单来说,指的是在你写实际的代码库之前,在你写下测试准则的时候。如果测试检查的是你的代码特性是否跟期待的一样,以及你在 写代码库之前写测试,这就是行为驱动开发。不管怎样,如果你的测试覆盖了你的代码库的每一个特性,而且你的代码通过了所有的测试。你可以确定你的代码是可 以正常工作的。
Jani Hartikainen讲述了如何利用Mocha来进行单元测试 Unit Test Your JavaScript Using Mocha and Chai。在使用Jsmine,Travis,Karma测试JavaScript (Testing JavaScript with Jasmine, Travis, and Karma)这篇文章中,Tim Evko展示了怎么通过另一个叫做Jasmine的框架来设置良好的测试流程。这两个测试框架都是非常流行的,但还有适应别的需求的其他框架。
我在这篇文章前面撰写的大纲,已经讲述了它期待怎样的输出。这是一切测试的开始:从期望出发。关于我的代码库的一个Jasmine测试像是这样:
describe('Basic usage', function () { it('should generate a single product', function () { // Create a single product var product = new UserAgent.Product('EvilCorpBrowser', '1.2'); product.setComment('X11', 'Linux', 'en-us'); expect(product.toString()) .toBe('EvilCorpBrowser/1.2 (X11; Linux; en-us)'); }); it('should combine several products', function () { var userAgent = new UserAgent; // Create and add first product var application = new UserAgent.Product('EvilCorpBrowser', '1.2'); application.setComment('X11', 'Linux', 'en-us'); userAgent.addProduct(application); // Create and add second product var engine = new UserAgent.Product('Blink', '20420101'); userAgent.addProduct(engine); expect(userAgent.toString()) .toBe('EvilCorpBrowser/1.2 (X11; Linux; en-us) Blink/20420101'); }); it('should update products correctly', function () { var userAgent = new UserAgent; // Create and add first product var application = new UserAgent.Product('EvilCorpBrowser', '1.2'); application.setComment('X11', 'Linux', 'en-us'); userAgent.addProduct(application); // Update first product application.setComment('X11', 'Linux', 'nl-nl'); expect(userAgent.toString()) .toBe('EvilCorpBrowser/1.2 (X11; Linux; nl-nl)'); }); });
一旦你对你的API设计的第一个版本完全满意,是时候开始思考结构和你的代码库应该如何被使用。
你或许使用过模块加载器。使用你的代码库的开发者有可能使用加载器,所以你会希望自己的代码库与模块加载器是兼容的。但兼容哪一个呢?应该怎么从CommonJS,RequireJS,AMD和其他加载器中挑选呢?
En fait, vous n’êtes pas obligé de choisir ! Universal Module Definition (UMD) est une règle dont le but est de prendre en charge plusieurs chargeurs. Vous pouvez trouver des extraits de différents styles en ligne ou apprendre du référentiel UMD GitHub et le rendre compatible avec votre base de code. Commencez avec l'un de ces modèles ou ajoutez UMD avec votre outil de construction préféré et vous n'aurez plus à vous soucier du chargeur de module.
Si vous souhaitez utiliser la syntaxe d'import/export d'ES2015, je vous recommande d'utiliser Babel et le plugin UMD de Babel pour convertir votre code en ES5. De cette façon, vous pouvez utiliser ES2015 dans votre projet tout en générant une base de code compatible.
Je suis tout à fait favorable à l'utilisation de la documentation sur chaque projet. Mais cela implique souvent beaucoup de travail, ce qui fait que la documentation est reportée, voire oubliée.
La rédaction du document doit commencer par des informations de base telles que le nom et la description du projet. Cela aidera les autres à comprendre ce que fait votre base de code et si elle leur est utile.
Vous pouvez fournir des informations telles que la portée et les objectifs pour mieux informer les utilisateurs, et fournir une feuille de route pour leur permettre de comprendre quels nouveaux changements pourraient être à l'avenir et quelle aide ils peuvent apporter.
Bien sûr, vous devez vous assurer que les utilisateurs savent comment utiliser votre base de code. Cela commence par la documentation de l'API. Les didacticiels et les exemples sont d'excellents ajouts, mais les écrire peut être un travail énorme. Cependant, ce n'est pas le cas de la documentation Inline. Voici quelques commentaires qui peuvent être analysés et convertis en pages de documentation à l'aide de JSDoc
Certains utilisateurs souhaitent apporter des améliorations à votre base de code. Dans la plupart des cas, il s'agira de code contribué, mais certains créeront une version personnalisée pour un usage privé. Pour ces utilisateurs, il est utile de fournir une documentation pour les méta-tâches telles que la création de la base de code, l'exécution de tests, la génération, la transformation et le téléchargement de données.
Lorsque vous ouvrez votre base de code, il est utile d'obtenir des contributions de code. Pour guider les contributeurs, vous pouvez ajouter de la documentation sur les étapes à suivre pour contribuer au code et les critères à remplir. Cela vous aidera à examiner et à accepter le code contribué et son code de contribution correct.
Dernier point, utiliser une licence. Techniquement, même si vous ne choisissez aucune licence technologique, votre base de code est toujours protégée par le droit d'auteur, mais tout le monde ne le sait pas.
J'ai découvert que ChooseALicense.com est un site internet qui permet de choisir une licence sans être un expert juridique. Après avoir sélectionné la licence, ajoutez simplement le fichier LICENSE.txt au répertoire racine du projet.
对一个好的代码库来说,版本是很重要的。如果你想要加入重大的变化,用户可能需要保留他们现在正在使用的版本。
Semantic Versioning是流行的版本命名标准,或者叫它SemVer。SemVer版本包括三个数字,每一个代表不同程度的改变:重大改变,微小的改变和补丁
如果你有一个git仓库,你可以在你的仓库添加版本数字。你可以把它想象成你的仓库的快照。我们也叫它标签 Tags。可以通过开启终端和输入下面的文字来创造标签:
# git tag -a [version] -m [version message] git tag -a v1.2.0 -m "Awesome Library v1.2.0"
很多类似GitHub的服务会提供关于所有版本的概览和提供它们的下载链接。
npm
许多编程语言自带有包管理器,或者是第三方包管理器。这可以允许我们下载关于这些语言的特定代码库。比如PHP的Composer 和Ruby的RubyGems
Node.js,一种独立的JavaScript引擎,拥有 npm,如果你对npm不熟悉,我们有一个很好的教程beginner’s guide。
默认情况下,你的npm包会发布为公共包。不要害怕,你也可以发布私有包 private packages, 设置一个私有的注册private registry, 或者根本不发布avoid publishing.
为了发布你的包,你的项目需要有一个 package.json 文件。你可以手动或者交互问答的方式来创建。通过输入下面的代码来开始问答:
`npm init`
这个版本属性需要跟你的git标签吻合。另外,请确定有README.md 文件。像是GitHub,npm在你的包的展示页使用它。
之后,你可以通过输入下面的代码来发布你的包:
`npm publish`
就是这样!你已经成功发布了你的npm包。
Bower
几年前,有另一个叫做Bower的包管理器。这个包管理器,实际上不是为了特定的语言准备的,而是为了互联网准备的。你可以发现大部分是前端资源。在Bower发布你的包的关键一点是你的代码库是否跟它兼容。
如果你对Bower不熟悉,我们也有一个教程beginner’s guide 。
跟npm一样,你也可以设置一个私有仓库private repository。你可以通过问答的方式避免发布。
有趣的是,在最近的一两年,很多人转为使用npm管理前端资源。近段npm包主要是跟JavaScript相关,大部分的前端资源也发布在了npm上。不管怎样,Bower仍然流行。我明确的推荐你在Bower上发布你的包。
我有提到Bower实际上是npm的一种模块,并最初是得到它的启发吗?它们的命令是很相似的,通过输入下面的代码产生bower.json文件:
`bower init`
跟npm init类似,指令是很直白的,最后,发布你的包:
`bower register awesomelib http://www.php.cn/`
像是把你的代码库放到了野外,任何人可以在他们的Node项目或者网络上使用它!
核心的产品是库文件。确定它解决了问题,容易和适合使用,你会使得你的团队或者许多开发者变得高兴。
我提到的很多任务都是自动化的,比如:运行测试,创建标签,在package.json升级版本或者在npm或者bower重发布你的包。 这是你像Travis CI 或 Jenkins一样踏入持续集成和使用工具的开始。我之前提到的文章 article by Tim Evko 也讲述到了这点。
你构建和发布代码库了吗?请在下面的评论区分享!
以上就是设计和构建你自己的JavaScript代码库:提示与技巧的内容,更多相关内容请关注PHP中文网(www.php.cn)!