看板
[ Soft_Job ]
討論串[請益] 有公司用這種開發方式嗎?
共 19 篇文章
內容預覽:
直接回文講好了。. 所謂的規劃以「維護優先」隱含的意思是，. 代表你事先設想了一套需求，而針對這些需求去進行處理。. 很難有架構設計是可以在需求不明時就先設計都設計的，. 真的這麼做也很容易變成過度設計。. 我以為facebook 就是一個搶時效，. 並且需求大幅改變導致原本的維護性不夠用的例子耶？
(還有2789個字)
內容預覽:
個人比較相信規則. OOAD 只是協助人整理出規則的一種做法,. 例如 XX123A 這種命名好了, 沒有規則搭配的話就很難懂,. 但假如有一個規則是, XX 是功能大項縮寫, 兩層選單,. 之後的每一個數字是該層的第幾個項目, 第幾步, 哪個分支,. 那 XX123A 就能很清楚的理解為. XX
(還有292個字)
內容預覽:
最佳化是一個一開始就要規劃的東西, 事後最佳化, 效果都很差,. 不然就是改得亂七八糟. 舉個3d game例子:. DOOM原先是針對software rendering做的程式,. 在3d顯卡時代很多人想改用opengl rendering, 結果因為地圖有"洞",. 被迫在程式裡面加上一堆怪c
(還有474個字)
內容預覽:
一個 "可維護性" 高的程式，通常很容易做最佳化. 因此，當 "規劃以維護性為優先" ，之後通常很容易可以改進效能. 但是，當 "規劃以效能為優先" ，之後常常時維護成本升高如果一家公司接的專案都是 "小，而且只有一次，程式交差後就可以掉"我不否認你的作法的確可行，但通常不會是這種情形. 一、從專案
(還有1764個字)
內容預覽:
效能 與 可讀性 可維護性 可擴充性相比. 在管理的角度上我會選後者. 因為效能可以藉由測試預估出來. 但是當架構要拆掉重寫. 需要花多久 要拆到多底層. 會不會拆到一半才發現拆不乾淨反過來犧牲效能. 這些都是完全不可預知的. 在風險控管的前提下. 選擇後者長遠來看比較健康. 至少效能還是"mana
(還有43個字)