Tiny框架設計原則

tiny框架在設計時充分考慮此原則，凡是可以通過一定的約定來大大減少配置或開發量的，一般都會採用。

所以在tiny框架的擴充套件、開發、配置過程中，會經常發現一些「潛規則」，如果利用好這些「潛規則」，會起起事半功倍的效果。

tiny框架的構建者對於做重複的事情一向是深惡痛絕的，因此非常不原意開發人員在基於tiny框架進行開發時出現重複的內容。

為此tiny框架在設計上做了大量的工作，來避免程式設計師做違反dry原則的內容，所以在tiny框架中，所有的工作內容都是做一次就足夠。

減法原則是我們自己提出的，意思就是給程式設計師做減法。

一般來說越到底層的程式設計師，工作時間越短、技能越弱、經驗越少。但是實際工作當中，你會發現越到底層的程式設計師要做的事情越多，要用的技能也越多。

tiny構建者認為，這也是現在程式設計師工作效率低、質量差的重要原因。因此我們認為應該給程式設計師做減發，越到底層的程式設計師做的事情要越單

一、越簡單。

可能有人在笑了，這個也算原則？確實，它就是原則，只不過原來下級服務上級是掛在嘴上的，而tiny框架則從框架層級做了限制，使得下級必須服務上級。

這兩點主要體現在流程及頁面實現中，上級經理可以對下級完成的工作內容進行強制性要求實現，不同的是流程是採用顯式繼承的方式，而頁面是隱式繼承的方式

一般的軟體開發，整個整合過程都需要人員小心翼翼，要配這個配那個，稍不小心就會有這種那樣問題的出現

tiny框架構建者也常常知道這一點給集**員帶來的困難及給軟體開發測試帶來的巨大的工作量，因此在整個tiny框架的構建過程中，都非常注重整合過程的自動組裝，要求做到扔進去不用管，由框架自動整合。

tiny框架構建者深深知道，模組化對於軟體開發過程中開發、高度、整合、發布、維護過程中所起的作用及節省或花費的巨大成本。因此提出了業務單元()business unit)的概念，使得與模組相關的所有內容都可以放在一起。

幾乎每個熟悉tiny框架的人可能會問同乙個問題，那就是：為什麼tiny分了這麼多的工程？

tiny框架的構建者也深深的知道這樣會增加相當的整合工作，但是這樣做的好處是可以把單一原則進行強制性的約束，使得乙個模組只解決單一模組應該解決的問題，從而避免不同的問題放在一起解決所導致的鬍子眉毛縷不清的問題，同時也避免了不恰當的依賴及模板引用。

在tiny構建者多年的工作過程中，被配置的問題所常常困擾，在開發期有許多問題是由於配置不當引起，在測試在發布及公升級過程中，也有相當多的問題是由於配置不當引起的。

在tiny框架我們對配置做了大量的工作，乙個是coc方式，如果不配，則採用系統預設的值；乙個是集中原則：把需要人工需要配置的內容都集中起來統一配置；乙個是對於不需要人工干預的配置，那就整合在jar包中，作為發布者發布項的一部分。