以下內容摘抄收錄自網路
dry是 don't repeat yourself 的縮寫，意思是"不要重複自己"。
軟體工程名著《the pragmatic programmer》首先提出了這個原則。它的涵義是，系統的每乙個功能都應該有唯一的實現。也就是說，如果多次遇到同樣的問題，就應該抽象出乙個共同的解決方法，不要重複開發同樣的功能。
這個原則有時也稱為"一次且僅一次"原則（once and only once）。
它背後的指導思想，就是盡可能快、盡可能簡單地讓軟體執行起來（do the ******st thing that could possibly work）。
但是，這裡出現了乙個問題。仔細推敲的話，你會發現dry原則和yagni原則並非完全相容。前者追求"抽象化"，要求找到通用的解決方法；後者追求"快和省"，意味著不要把精力放在抽象化上面，因為很可能"你不會需要它"。所以，就有了第三個原則。
rule of three 稱為"三次原則"，指的是當某個功能第三次出現時，才進行"抽象化"。
這是軟體開發大家martin fowler在《refactoring》一書中提出的。
它的涵義是，第一次用到某個功能時，你寫乙個特定的解決方法；第二次又用到的時候，你拷貝上一次的**；第三次出現的時候，你才著手"抽象化"，寫出通用的解決方法。
出處：[**的抽象三原則](
寫**時時刻設想你就是將來要來維護這坨**的人。
先弄清你的問題是什麼！
越懶越好。
過早優化是一切罪惡的根源。
不要重新發明輪子。
測試通過前說什麼「它可以工作」都是純扯淡。
了解你的工具。
一切以使用者需求為導向。
利用分治、抽象，解開子問題之間的耦合。
出處：[程式設計的首要原則(s)是什麼？](
如何對使用者更加友好，是一兩句話說不清楚的事情。所以這裡只粗略說一下我想到過的要點：
統一：隨時注意，人是乙個統一的系統的一部分，而不是什麼古怪的神物。基本上可以把人想象成乙個程式模組。
抽象：最大限度的掩蓋程式內部的實現，盡量不讓人知道他不必要知道的東西。不願意暴露給其它程式模組的細節，也不要暴露給人。「機所不欲，勿施於人」。
充要：提供給人充分而必要（不多於）的機制來完**想完成的任務。
正交：機制之間應該儘量減少冗餘和重疊，保持正交(orthogonal)。
組合：機制之間應該可以組合(compose)，盡量使得幹同一件事情只有一種組合。
理性：並不是所有人想要的功能都是應該有的，他們經常欺騙自己，要搞清楚那些是他們真正需要的功能。
通道：人的輸入輸出包括5種感官，雖然通常電腦只與人通過視覺和聽覺互動。
直覺：人是靠直覺和模型(model)思考的，給人的資訊不管是符號還是圖形，應該容易在人腦中建立起直觀的模型，這樣人才能高效的操作它們。
上下文：人腦的「快取記憶體」的容量是很小的。試試你能同時想起7個人的名字嗎？所以在任一特定時刻，應該只提供與當前被關注物件相關的操作，而不是提供所有情況下的所有操作供人選擇。上下文選單和依據上下文的鍵盤操作提示，貌似不錯的主意。
出處：[什麼是「對使用者友好」](
構建數倉的一些基本原則
乙個邏輯或者物理模型由哪些記錄和字段組成，應該遵循最基本的軟體設計方法的高內聚和低耦合原則。主要從資料業務特性和訪問特性兩個角度來考慮 將業務相近或者相關 粒度相同的資料設計為乙個邏輯或者物理模型 將高概率同時訪問的資料放一起，將低概率同時訪問的資料分開儲存 建立核心模型與擴充套件模型體系，核心模型...
CSS 一些原則
優化你的css 所謂高效的css就是讓瀏覽器在查詢style匹配的元素的時候盡量進行少的查詢，下面列出一些我們常見的寫css犯一些低效錯誤 1 不要在id選擇器前使用標籤名 一般寫法 div divbox 更好寫法 divbox 解釋 因為id選擇器是唯一的，加上div反而增加不必要的css匹配。2...
系統設計的一些原則
系統設計的好壞在根本上決定了軟體系統的優劣。可以說 差的系統設計必定產生差的軟體系統 但是不能保證 好的系統設計必定產生好的軟體系統 因為在設計之前有需求開發工作，在設計之後還有編碼，測試和維護工作，無論哪個環節出了差錯，都會把好事搞砸了。據說上帝把所有的女士都設計成天使，可是天使們在下凡的時候，有...