三十天系列文至此即將告一個段落，雖然筆者到目前為止並沒有分享非常多的實戰，但 ng generate 、 ng add 、 ng update 這三個面向的 Schematic 其實也都已經介紹過且實戰練習過了，未來在實務應用上，也就只是範本種類再多一些、程式碼或是檔案再多一些、複雜度更高而已，屆時要考驗的就是大家有沒有辦法舉一反三了。
最後，筆者幫大家總結一下這個系列文的重點：
在使用 Schematic 的時候， Angular CLI 或者是 Schematics CLI 都需要先讀取 Schematics 專案裡的 collection.json 來解析該專案是否有該 Schematic 的設置並執行。
同樣地， Schematics 專案裡所有的 Schematic 都會在 collection.json 裡設置好相關設定與檔案路徑。
支援
ng update的 Schematics 除外，通常支援ng update的 Schematics 會新增另外一個migration.json來配置。
JSON Schema 是一組用來描述另一組 JSON 數據結構的 JSON ，目前已經廣泛應用在非常多的地方。
而替你的 Schematic 加上 JSON Schema 除了可以用來規範及驗證使用者所輸入的參數外，還能夠讓你的 Schematic 擁有提示訊息的功能。
至 Day05 看更多
撰寫測試程式碼可以保護你的程式、快速驗證結果，且寫測試的同時也是在寫規格，正因為如此，想要讓自已的程式碼品質變得更高，以減少未來花費在 Debug 上的時間的話，學會撰寫測試是必然且必須的。
另外，筆者覺得當我們在寫測試的時候，以下幾個心法需要銘記在心：
Arrange - 初始化目標物件、相依物件、方法參數、預期結果，或是預期與相依物件的互動方式等等。Act - 呼叫目標物件的方法。Assert - 驗證結果是否符合預期。
筆者在今年 1月時，曾經在 Angular Taiwan 線上讀書會 分享過測試的主題，有興趣的邦友可以看看當時的錄影與簡報。
使用範本時，範本檔名是用兩個底線區隔參數與固定文字，如：
hello-__name__.component.ts
要使用函式，則是直接在參數名稱後面加上 @ 與函式名稱，如：
hello-__name@dasherize__.component.ts
而在範本檔案內，則是用 <%= 參數名稱 %> 來將參數的值綁定到範本中；在範本裡使用判斷式時，是用 <% %> 來將判斷式的區域包起來。
如：
import { Component, OnInit<% if(!!viewEncapsulation) { %>, ViewEncapsulation<% }%><% if(changeDetection !== 'Default') { %>, ChangeDetectionStrategy<% }%> } from '@angular/core';
@Component({<% if(!skipSelector) {%>
selector: '<%= selector %>',<%}%><% if(inlineTemplate) { %>
template: `
<p>
<%= dasherize(name) %> works!
</p>
`,<% } else { %>
templateUrl: './<%= dasherize(name) %>.<%= dasherize(type) %>.html',<% } if(inlineStyle) { %>
styles: []<% } else { %>
styleUrls: ['./<%= dasherize(name) %>.<%= dasherize(type) %>.<%= style %>']<% } %><% if(!!viewEncapsulation) { %>,
encapsulation: ViewEncapsulation.<%= viewEncapsulation %><% } if (changeDetection !== 'Default') { %>,
changeDetection: ChangeDetectionStrategy.<%= changeDetection %><% } %>
})
export class <%= classify(name) %><%= classify(type) %> implements OnInit {
constructor() { }
ngOnInit() {
}
}
其實筆者在 Day29 的文章裡有分享到另一個範本語法的類型：
TemplateAstEscape，它是被<%-與%>包起來的區段，不過筆者目前沒有在原始碼裡發現它的存在。
TypeScript API 在 Schematics 專案中大多是用於解析程式碼，取得程式碼欲插入的位置後的實際變更依舊交由 Tree 來處理。
而筆者在 Day20 與 Day21 所分享的 TypeScript AST Viewer 和 TSQuery Playground 都是可以讓你在使用 TypeScript Compiler API 變得更輕鬆愉快的超好用工具，請多善加利用。
Angular 團隊針對 Angular 專案本身做了很多非常好用的 API ，擅用這些 API 可以讓你寫 Schematics 時更加輕鬆、愉快。
雖然筆者還有不少是在引入路徑為 @angular-devkit/schematics 底下與 @angular-devkit/core 底下的 API 還沒有介紹完，但在鐵人賽這邊實在是不好搜尋與翻閱，所以筆者想未來等筆者比較有空時，找個比較好的方式來將它們介紹給大家，屆時可能會將其發佈在我個人的部落格上，並且分享到 Angular Taiwan 的 FB 社團裡。
有興趣的邦友們，可以再多加留意！
雖然筆者的確只針對 Angular 、 React 與 Vue 來分享，但其實「一法通，萬法通。」，其運作方式與原理都一樣，只要該專案有使用 npm 系統，基本上是都可以使用的。
目前在非 Angular 的專案中，的確無法像在 Angular 專案裡可以直接使用 ng add 、 ng generate 與 ng update 這些指令來使用 Schematics ，一定要透過 Schematics CLI 來使用。
但雖然不能直接透過上述指令啟動 Schematics ，Schematics 本身可以做到的事情可是一樣都沒少，頂多只是需要換個方式或者是繞個彎處理而已，實際上都能夠達到該有的效果。
筆者相信以 Angular 團隊的技術能力，一定可以在不久遠的將來就能在其他專案做到這件事，敬請期待囉！
雖然範例跟練習都很粗淺，但這系列寫到現在，大致上已經把 Schematics 的可以做到的事情都差不多介紹過一遍，也把目前所知道的 Schematics 相關工具都分享給大家，剩下的就只是應用層面及程式複雜度的問題而已。
此外，雖然筆者還是有不少事情沒有分享到，但俗話說：「授人以魚不如授人以漁」，筆者已經將這個這麼好用的工具分享給大家了，其他的就留給大家去探索與研究囉！
非常期待大家能夠使用它開發出更多、更好用的 Schematics 。
或許有邦友覺得筆者這六篇文章根本就是濫竽充數，但筆者在一開始就有解釋過：因官方並沒有這方面的 API 文件，所以將其提列出來也是希望未來大家在找的時候能夠更方便。
而另一部分是，筆者並不是單純的複製貼上而已，每一個 API 筆者都有仔細看過原始碼與其測試，並且自己寫範例去測試該 API 是否正如自己所想的方式運作，而筆者也因為這六篇文章也讓筆者自己對於 Angular Schematics 的了解又更上了一層樓。
所以不管別人怎麼說，至少筆者覺得這六篇文章對自己而言是非常重要且非常有價值的，希望你也能這麼覺得。
關於 ng new 的部分，雖然 Angular 本身也是使用 Schematics 來處理，但很遺憾的是，目前並沒有開放給開發者們來客製，或許在未來的某一天會有機會也說不定，敬請期待囉！
Angular Taiwan 今年的大型會議 ng-tw 2019 將在 11/2 、 11/3 宜蘭礁溪老爺飯店舉行，兩天一夜與大神們近距離研討的機會非常難得，走過路過千萬別錯過！！
此外，以下是臺灣 Angular 社群的相關連結，非常歡迎大家加入 Angular 的行列：
本系列文至此結束，非常感謝大家的 Like 、收藏、訂閱以及分享，希望本系列文能夠幫到大家，讓人人都變成高效率的開發者，謝謝！
iThome鐵人賽
看影片追技術