程式碼通常可以採用兩種粗俗的形式：庫或框架。

庫是一組構建塊，它們可以共享一個共同的主題或可以很好地協同工作，但是在很大程度上是獨立的。

框架是包含編寫程式碼的上下文。可以是採取控制反轉，特定於領域的語言的形式，也可以只是一種很自以為是且內部耦合的庫。

兩者之間沒有界限。判斷是否為框架或庫的一種方法是問自己：“我可以將其與其他類似框架結合使用嗎？或者它是否建立了與其他方式可以互斥的方式？”

框架的主要特徵是它們對程式設計師施加了限制。他們沒有提供程式設計師可以做的一系列新事情，而是在程式設計師可以做的事情上建立了界限。為了換取靈活性，他們通常消除樣板，為在其之上構建新庫建立試金石，並允許程式設計師的技能成為更具可移植性的專案。實際上，有時限制本身是可取的！畢竟，型別系統不過是對程式碼施加限制的一種方式。侷限性並不是本質上的壞處。

然而。當您編寫一個期望其他人用來構建真實專案的框架（即，它不僅僅是一個玩具）時，您承擔的責任要比庫更大。

通常，框架必須提前預測其使用者可能需要在其內部進行的各種操作。它必須承擔起相應的責任。它需要提供一個正常完成各種操作的方式，否則，為什麼要使用它？

這也轉化為開發人員的經驗。您的框架是否引入了超出基本語言的基於約定的行為？您最好徹底記錄下來，否則使用者將無可救藥地迷路。您是否引入特定領域的語言？您現在負責構建鏈的一部分，並負責編輯器整合。

現在，如果有一個主要組織來支援該框架，那麼計算就可能成功了。Google可以支援Angular，Pivotal可以支援Spring，Epic可以支援Unreal Engine。在這些情況下，可以採用框架方法，因為存在著資源和意願，可以真正覆蓋所有需要覆蓋的基礎。

因此，我的觀點：框架並不總是壞的，但是與庫相比，對於建立者和使用者而言，框架帶來的風險要大得多。如果您的框架可以是一個庫而又不會損失很多，那就作為庫。如果您不在大型科技公司工作，那麼您可能沒有時間或精力來提供框架所需的全部精力。庫不是萬能的，但它們應該是首選。