先求有，再求好

作者: mgtsai () 看板: Soft_Job
標題: Re: [閒聊] 你在開發程式時，是重視績效還是品質
時間: Sat Sep 17 23:58:08 2011

※ 引述《thinkniht (不下棋=.=)》之銘言：
: 不好意思...我想我內容寫得不太好
: 所以整篇文章砍掉
: 該問說各位在寫程式時
: 是想只要讓程式可以跑就好呢?
: 不想花太多時間在上面
: 還是會想多花點時間追求讓自己開發的程式更有品質呢?
: (讓程式更好維護、或者讓程式運作上可以更穩定之類的)

一個經驗談吧

套句部隊參一二三四為了要應付明天軍團的督導
正在中山室爆肝熬夜做(假)資料時，嘴巴常常吐出的一句名言：

    "先求有，再求好"

以完成任務導向的前題下，以在時限內結案為最高指導原則
無法結案的後果，我想大家都是行內人，應該滿清楚的

------

如果案件給的時間少到連時限內結案都可能出問題的情況下
就不要多想吧，短視一點，埋頭做就對了

------

不過在有多出來時間的狀況下，這就是自己可以善加運用之處
看多出多少時間，把自己之前為了趕工胡亂湊的 code，再好好順過一次
(這時剛好就是使用 refactoring 技巧的時機點)
有多少空餘時間就改多少，不要多耗時間
若用了太多時間而影響到原本案件的進度，那就有點不太好囉

當然某些時機，要動到比較大塊的時間做架構面的調整
比如說需要兩星期時間，只改架構而不做新功能
這時就要等待發動的時間點，先不要想到要調整，就一鼓腦兒動手開刀下去
若刀開了一半，到了要給上頭東西的時間點，進也不是退也不是，那就真的尷尬了

當然，若公司有 revision control system，自己有開 branch 的權限
(或者自己已經架設一個私人版的 revision control system)
這時，要做較大規模的架構調整時，可以開一個 branch 專門處理這件事
就不太受當架構改到一半，要交出一個版本時，進退兩難的窘境

當然，在自己發現需要很多時間順理程式或改架構時
這時就要多想一些理由向上頭爭取時間來處理

或者講明需要多少時間，若現實狀況下明講不太允許時
試試當分配每個 task 需要多少時間時，多爭取一些
原本三天可以做完的 task 爭取五天時間，五天可以做完的 task 爭取八天時間
重點就是多爭取到多少時間，才做多少調整
能爭取多少，就看當時的案件的實際進展情況與自己的爭取的技巧而定

------

當然，調整架構的大前題是，為了往後的維護順利與增加開發效率
若達不到這兩項目標，要不要調整這個架構就要好好考慮
千萬不要只為了所謂的漂亮結構，耗許多時間 over design 堆砌往後用不到的積木

------

其實，程式的品質要做到什麼程度
裡頭有很多的臨場判斷與折衝權衡，很難一概而論

如果有無限多的時間與預算，這時當然可以寫出高品質的程式
但通常這個前題是不成立的，任何案件的時間與預算都是有限的

在有限的預算內，以結案的前題下
可以換到多少品質，就看過程中使出什麼樣的法門

大家加油吧！

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.32.58.129
推 andymai:推...不能再同意你更多...                                09/18 00:06
推 robler:我只要有一個能交的版本就一定會備份一個才動手再改XD       09/18 09:42
→ robler:再好的東西交不出去也是沒用                               09/18 09:42