Re: [閒聊] 你在開發程式時，是重視績效還是品質
: 這些現有的程式碼...
: 其實還蠻爛的
: 結果公司同事在寫程式時就分成兩種類型
: 一種是只針對功能的功能面上做修改
: 對整個功能的程式有很多地方其實不瞭解
: 另一種是會把整個功能的程式都做個了解
: 不只做功能面上的修改
: 原本程式可能會有一些沒被發現的問題
: 也會一起修改
: 另外還會增加程式的可讀性與維護性
: 兩種花的時間...當然會差很多
: 不過對於日後維護的人而言
: 維護的容易程度也會差很多
: 發這問題...是好奇大家會傾向於哪種類型
: 看來第一種居多啊
不一定耶, 要看真實的狀況, 假如這一版已經經過 QA 驗證了
又很接近 release 給客戶的時間,
通常我們會盡量用第一種方法 workaround.
雖然 code 也許看起來很囧.
可是大規模的改 code 改架構, 會怕衍生出新的問題.
所以又得在安排 QA 驗證, 而且你在舊的架構中已經解過的 issue
說不定還得在上新架構候重新驗證一次, 會拖一點時間.
所以這種事情最好一開始就趕快做, 但是...不說你也知道...:p
其實就算是要用第一種方法, 也是要考慮會不會影響其他部分.
也是要很清楚來龍去脈才能動的.
就算真的要大規模的更改, 也建議在 branch 上面修改.
QA 測試後再 merge 回 trunk.
可能還是要看公司的性質,
如果是 ODM 廠, schedule 通常都是出錢的老大說了算. 囧
: To xxtuoo:
: 我覺得程式難懂 不算品質好=.=+
: 補充一下:
: 我指的是...至少"適當"的加些註解吧
: 就算程式邏輯真的很複雜
: 如果能進行些說明...要是還是很難懂
: 也不能怪寫的人了
: 我之前看一個要離職的人的程式
: 程式邏輯其實很簡單
: 但沒註解...要維護會比較花時間
註解也是一種方式啦, 但是註解寫到 7~8 行,
還得看 function 裡面得 page down 兩三次的 code 也是很累人的.
(例子有點極端 :p)
我也不算是會一開始就規劃的好好的人 :p
但是只要發現自己寫的 function 需要 page down 太多次,
就會開始拆解局部, 盡量用 sub function 肢解那一堆 code.
其實只要在配合良好的命名規則,
只要看 main function 呼叫的那些 sub function 名稱,
大概就會知道他要做哪些事情.
一點小小心得.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.169.191.77
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 10 之 11 篇)：