對開發準則的一些心得

2018-7-4 10:08:24 星期三

有些感悟, 一些東西如果設定一些準則, 他可能規定了你至少要做哪些事情 / 你最好這樣去做

根據準則去執行, 就會減少不必要的遺漏; 對莫能兩可的事情快速做出決定, 不再糾結

如果心裡沒有乙個標準, 每次開發都會覺得這樣寫也可以那樣寫也可以, 左右為難, 最後感覺只要能實現當時的需求, 完事就可以了, 不管那麼多了, 最後**就比較亂, 沒有規律, 隔一段時間後自己都看不懂了.

用例圖, 流程圖

他們規定了我們至少考慮的幾個方面: 1. 使用者是誰, 2.使用者怎樣使用, 3.操作物件是誰, 有了這樣乙個"準則", 我們做方案設計的時候, 就少了些不確定性, 因為這些是必須考慮的

比如: 要先確定這個功能是誰在使用, 這就涉及到使用者的角色, 和其所擁有的許可權控制, 相關操作介面怎麼顯示等等, 這樣你就不會遺漏對使用者許可權控制的功能開發

情景: 我最近做任務單分配的功能, 一開始沉浸在裡邊一直想, 這個型別任務單怎麼分配給誰, 那個型別的任務單怎麼分配給誰, 等想好了這些,

確被提醒說, 沒有考慮人工干預分配的情況, 我這才回過頭來從頭考慮, 誰在使用這個功能, 在什麼場景下使用這個功能:

使用**自動分配 -> 部門內分配,

有許可權的上級部門的同事 -> 跨部門分配 -> 分配給部門負責人 -> 再由**分配

再比如乙個方法究竟定義幾個引數合適的問題,

1. 有人覺得語言本身又沒有那麼嚴格的限制, 我想怎樣都可以

(相反的觀點: 如果太多引數, 一是呼叫時必須按照引數順序傳輸, 即使有些不用傳也得傳空, 二是引數越多邏輯就很有可能越複雜, 改都不敢改, 三是一些時候其實只需要其中一段邏輯但是仍然要走很多無用的判斷, 甚至取出很多無用的值 )

2. 有人覺得最好只定義1個, 乙個引數乙個結果, 很純粹的方法, 一看就知道需要啥

(相反的觀點是: 1個引數的話方法過於簡單, 能處理的邏輯有限, 必須通過多個方法去實現乙個目的 )

3.我個人覺得最好不超過兩個, 引數不多記著也方便, 大概也能猜出方法是幹啥的, 可以控制稍微多一些的邏輯, 但也不會太多, 閱讀也方便

上邊說的是單個的方法, 那麼對於類的構造方法呢?

問題: 構造方法是乙個類的入口, 比較特殊, 它要做一些初始化的操作, 因此很多構造方法要寫很多引數

現實: 但是經常遇到的情況是, 之所以要寫乙個單獨類, 很可能是為了把一些方法整合在一起:

1. 可能這些方法是處理同乙個資料庫表的, 這些方法被其他功能模組使用, 並不依賴構造方法的引數

2. 也可能是為了實現乙個共同功能模組的方法的集合, 這時, 很多方法也並不依賴於構造方法的引數, 有些甚至不需要引數, 獨立的可以單拎出去

構造方法的作用一般是根據傳遞來的乙個或幾個引數, 再獲取出一大堆相關的資料作為成員變數,

但不是每個成員方法都需要全部的成員變數, 如果都放在建構函式中去初始化, 難免會浪費資源

我的方案: 構造方法盡量少的定義引數, 每個成員方法也要有必要的引數, 以便讓其他呼叫者知道該傳什麼引數