我們的產品底層是乙個平台，提供基礎業務，以及擴充套件api。在平台之上，通過個性化配置，和定製開發，得到最終的產品
本文不談配置的事，只說說定製
平台發布到不同的專案之後，各專案自行定製。由於不同的專案需求差異較大，有時候平台提供的擴充套件api無法滿足，專案就直接修改或增加平台的**。但是這樣就有個問題，平台就不能隨意公升級了，因為專案對平台**的修改不可控，平台公升級之後，很可能與定製的**衝突
延伸一下，我想到其實用到的各種開源框架也有這個情況
以struts2為例，把struts2也看做乙個平台。初級的開發者，只會用到平台預設的功能。高階的開發者，會對平台進行擴充套件，比如自定義interceptor、validator等
這種擴充套件，都是基於平台事先設計開放的api來進行的，是「合理的擴充套件」，或者說是「預期的擴充套件」。在struts2公升級的時候，只要有意識地保持這些api的穩定，那麼使用者自定義的擴充套件就不會受到影響
另一種擴充套件，則是在struts2沒有「預料」到的地方，直接修改了平台的源**，那麼這種擴充套件，就跟本文前面提到的現象一樣，是一種「意外的擴充套件」，實際上不叫擴充套件，而是"hack"，或者說「侵入」，是不鼓勵的，因為框架公升級以後，這些擴充套件很可能就衝突了。有時使用者被逼無奈，必須做出這種選擇。如果這種情況很多的話，那麼可以認為框架的「擴充套件性」是比較差的
所以乙個框架，應該在設計時，事先識別出擴充套件點，開放相應的api，以達到較好的擴充套件性。在公升級時，也要注意向下相容，盡量不要修改現有的介面
順便也想通了乙個問題，為什麼很多開源框架都提供user guide和developer reference：
user指的是普通使用者，不做擴充套件
developer指的是高階使用者，會對現有框架做擴充套件，甚至修改，有時就是框架的作者
當然，這2類人群，實際上都是程式設計師
框架和平台的擴充套件性
我們的產品底層是乙個平台，提供基礎業務，以及擴充套件api。在平台之上，通過個性化配置，和定製開發，得到最終的產品 本文不談配置的事，只說說定製 平台發布到不同的專案之後，各專案自行定製。由於不同的專案需求差異較大，有時候平台提供的擴充套件api無法滿足，專案就直接修改或增加平台的 但是這樣就有個問...
架構 擴充套件性
擴充套件選和伸縮性 擴充套件性 指對現有系統影響最小的情況下，系統功能可持續擴充套件或提公升的能力。表現在系統基礎設施穩定不需要經常變更，應用之間較少依賴和耦合，對需求變更可以敏捷響應。它是系統架構設計層面的開閉原則 對擴充套件開放，對修改關閉 架構設計考慮未來功能擴充套件，當系統增加新功能時，不需...
CSS可擴充套件性
今日在寫pc官網的時候，一直對於html css的結構編寫完全按照自己的思維方式，今天把 交給老大的時候，被他指出很多編寫 的錯誤性，比如 結構，標籤的使用，語義化，css的可擴充套件性，由於 主要還是需要做seo優化，所以在標籤使用上也有些不合理之處，給了我一些建議，自己記錄以下 1 在html標...