[有關軟體設計] UI上應該要盡量避免User誤用的情況

主題 : 

最近在處理一個bug，我在UI上的設計讓User誤以為是把 ip 寫到他指定的 gateway 相對應的 network interface上。

但實際上我的UI是要讓User指定的ip寫到default gateway上。

這種UI上讓User誤解的情況應該要盡量避免才對。

[有關軟體設計] 什麼是架構 ?

主題: 什麼是架構 ? 

應該問說，怎樣的東西在設計上應該被列為架構而非細節 ?

會問這個問題，是因為我認為在軟體設計中辨識架構是一件非常重要的事情。
 如果架構錯了，那麼可能要全部砍掉重來。
因此，如果能夠辨識架構和之微末節之間的差異，
那們我們就能在一個project kick 之初就能略過那些之微末節，並且花更多的時間反覆思考這樣的設計是否符合需求。 

我個人對於架構的理解如下: 

這個'個別'部份的設計和規劃對於整體的其他部分的影響,

1. Hard to inverse
     不可逆(或是很難reverse，也就是必須某個flow從來，某個部分必須先取消然後從新做)

2. Design dependency
     必須先決定這個設計，才能決定其它設計

3. Implement dependency
        如果這個設計改變了，其它很多的設計也全需要改變
       舉一個簡單的例子，要決定買了幾個衣櫥，要釘在牆壁上，衣櫥裡面的空間也需要規劃。        而你家的空間，放衣櫥的位置是固定的。

那以這個例子來說什麼是架構 ? 
           我個人認為是
                 1. 衣櫥的長寬高(放起來必須視覺上一致)
                 2. 衣櫥的顏色和外觀 (很少買了還可以退貨)
                 3. 衣櫥要釘的位置 (可能衣櫥深度和高度要一樣，才不會突兀)
                 4. 衣櫥的整體容量

 而什麼是枝微末節
                 1. 衣櫥內部每一層的高度規劃
                        因為目前大部分的內部都是可微調的，並且這部分幾乎不會影響到其他部分)

結論:

如果我們真的能夠更理解什麼是架構而什麼是枝微末節，
那麼我們可以花更多一點時間在架構上而少花一些時間在之微末節上，也許就可以做出更良好的軟體。

[有關軟體設計] - build a new project的心得

寫一個新的project和舊的project不同的地方，就是一個全新的project必須 1. 盡量發現可能的問題 有可能是spec上的，架構上的... 2. 做很多架構上的決定 3. 要能給出很多好的solution讓系統效率好/彈性/好debug&maintain 4. 寫很多code 因此，個人心得如下： 1. 做每個架構上的決定時，一定要有邏輯。也就是能夠說明每一個決定的原因。 如果是因為決定不出來而隨便選一個自己喜歡的，最好也記錄下來。 而做決定的方式如下, a. 目前發現方法 x, y, z(要盡可能的發現可能的方法) b. 分析x, y, z方法的因為做了什麼事情，在架構上是如何，所以會有怎樣的優缺點。 c. 因此在分析完後會有一個比較好的方法, 而方法必須由此決定出來。 d. 如果分析不出來，倉皇做出的決定，也最好記錄下來，自己是隨便選一個。因為怎樣所以決定不出來。 2. 請別人幫你Design Review(最好要跟你差不多有經驗的，或者比你更有經驗的) 這時候就會用到上面那個步驟記錄下來的東西。所以你的同伴會知道且了解你做的決定是為了解決或是避開哪些問題。 3. 因為實作時你會需要寫非常多code，為了讓自己更有產能，最好把自己的環境tune到能最有效率的狀態。 (如果是maintain別人的project通常不會有這個需求) 4. 寫完一段code就自己做code review。寫完一大段請同事和你一起code review。 5. 只要是Review就是吃經驗值。所以如果經驗不夠也review不出什麼東西。所以可能盡量獲取更多的design&implement的經驗。 7. 這是一段循環，做了一個大方向的決定之後，就會往那個方向前進，接下來就會需要解決這個決定所帶來的問題。 心得大概是這樣，有想到再補上。