|
|
|
2007-01-04, 05:33 PM
|
#1 |
|
註冊會員
 
|
討論 - 你們認為程式的藝術是什麼
如題
你們認為程式的藝術是什麼 除了把功能做出來之外 我認為是導入設計架構 設計樣式 讓程式變得容易擴充 修改 除錯 讓修改數萬甚至數十萬行的程式碼也可以變的很優雅 應該算是吧 ================== 現今程式碼的 size 動輒幾百萬甚千萬行程碼 如果沒有遵循軟體開發流程 軟體設計架構 要維護 擴充 除錯都 是難上加難 試想你要如何再幾百萬行程式裡面撈出你想改的那一行 並且改了之後不影響其他的程式碼 這時軟體工程就變的相當重要 ================== 各位認為呢 此帖於 2007-01-04 05:46 PM 被 snoopy 編輯. |
|
送花文章: 623,
|
|
向 snoopy 送花的會員:
|
|
2007-01-04, 06:28 PM
|
#2 (permalink) | |
|
長老會員
|
引用:
才是王道啊!!! 不然日子一久，要改都要花很大的力氣，還常常會顧東不顧西！ 把其它相關的程式碼改錯了 |
|
|
__________________ 一切有為法 如夢幻泡影 如露亦如電 應作如是觀 |
||
|
|
送花文章: 150,
|
|
向 劍痞憶秋年 送花的會員:
|
|
2007-01-04, 09:26 PM
|
#3 (permalink) |
|
管理版主
|
八個字
簡化 と 組合、效能 と 拆解 說到寫的讓人看的懂，其實這不是這麼重要 因為一般只要寫好詳細的註解即可 且很少人會去看您的原始碼 簡化 : 事後可以簡化的程式碼，比事後不能再簡化的程式碼還好 因為 表示程式擴充性高 比如 可以在更多的地方插入新的代碼 組合 : 組合是模組的實現，不止提高區段程式碼的利用 更渴提高自己對程式寫作的興致 效能 : 雖然現在的 PC能力越來越快 但這始終是一項不可不重視的要求 這也是進步的原動力之一 拆解 : 拆解 -(成就)> 組合 組合 -(造就)> 模組 模組 -(使之)> 簡化 簡化 -(形成)> 效能 效能 -> 拆解 |
|
|
送花文章: 2053,
|
|
2007-02-06, 02:43 AM
|
#6 (permalink) |
|
長老會員
 |
許多人認為，程式本身的易讀性不是很重要，反正在重要的地方會詳加注解。
但事實上，這造成了「大型專案 - 拆解 - 重組」的「不可行性」。 到了專案升級的時候，之前的程式幾乎成為「雞肋」。 是該「全部重寫」；還是「拆解 - 重組」？ 這種事情；去問問灑銀子的老板；馬上就有答案了。 那就是為何不少大型專案要求編程師在「定義涵數」時； 必須直接使用「統一的原始英文名稱」的原因。 下一次專案系統升級時，可能已經過了好幾年了， 人事早就異動到不知道誰幹了什麼好事的境地了。 如果一目不能瞭然...  很多堪用的東東就祗好放棄了。 如果您是業主，您會有什麼感覺~？   ........................................................... |
|
|
送花文章: 52967,
|
|
2007-02-02, 11:37 PM
|
#9 (permalink) |
|
長老會員
|
我不懂程式...
不過我覺得 相同的功能若是能做到 最佳效能~佔用最少的資源,這是很厲害的! |
|
__________________ 大千海水尚可量 十方虛空猶可涉 諸眾生心尚可同 世尊功德不可盡 諸佛世尊有 百四十 不共佛法。 以彼彼諸名 詮彼彼諸法 此中無有彼 是諸法法性 odysee | Buddha-img | 如何得觀音菩薩感應 |
|
|
|
送花文章: 1537,
|
|
2007-02-03, 06:12 PM
|
#13 (permalink) | |
|
管理員
|
引用:
|
|
|
__________________ 在「專業主討論區」中的問題解決後，要記得按一下  按鈕喔，這是一種禮貌動作。  一樣是在「專業主討論區」中發問，不管問題解決與否，都要回應別人的回答文喔。 不然搞 [斷頭文]，只看不回應，下次被別人列入黑名單就不要怪人喔。 天線寶寶說再見啦~ ... 天線寶寶說再見啦~ 迪西：「再見~ 再見~」 『 Otaku Culture Party 』 關心您 ... 
|
||
|
|
送花文章: 37855,
|
|
2007-02-04, 08:29 PM
|
#14 (permalink) | |
|
長老會員
|
引用:
剛開始，他常會以專案團隊的救星的姿態出現，達成；甚或超前編程進度，而成為開發團隊的英雄； 但是；通常到了最後，他就是開發團隊、廠商與業主的困擾。 通常在專案中；我寧可找到能夠依尋專案規範行事的編程師。 要辨視出醬子的人很簡單，您祗要請問他是否能夠遵循「CMMI LX」行事； 然後看到他漸漸地顯露出不屑的表情，您就知道了。  |
|
|
|
送花文章: 52967,
|
|
2007-02-06, 04:37 AM
|
#15 (permalink) | |
|
長老會員
|
「這可真是一篇好文~~~ 我真是臭屁的該打屁股~~~！^^;」
引用:
硬體的效能... 本來就是拿來用的... 何況是給「軟體」用？ 除了「密集運算」才有使用低階語言搶時間的訴求外； 而這種具有「特異功能」的「專業程式」；許多時候是直接購買專業現貨而達成的。 根本無法交給專案團隊編寫；看看「Excel 97」「增益集」中的「規劃求解」就明白了； 那種專解「單形法」的「線性規劃」軟體，全世界知名的祗有三、五家... 微軟~ 省省吧！ 即使是「微軟」的 Office；也祗是一堆市場上買來的C語言/甚或組合語言模組。 比較誇張的說法是：微軟祗是「規劃」並「編寫」出了一個「龐大而嚴謹的使用者介面」... 大多數「微軟」自編的程式都是以「維護管理」為出發點而成局的，所以慢得要死~！ 可是這種玩法卻保障了程式維護的「便利性」、「升級性」或「延展性」、「回收再生性」； 但它就絕對不是「最佳效能」；甚或「佔用最少資源」；完全辦不到~！祗會越來越肥大！ 但是呢... 基於這種理由的肥大；在另一方面卻能有效的配合「微軟」的市場行銷策略， 使「微軟」的軟體無往不利~~~！ 同時... 加惠全球硬體廠商，使得硬體天王的台商有利可圖；也因此促進了 PC 產業的升級... 各位看官；文走至此... 我們還有什麼話好說的~？ 我們的外匯就正是靠著「日益肥大且遲緩」的「微軟 - 作業系統」、「微軟 - Office」 以及「日益粗壯的應用軟體」在支撐的...  那我們還在抱怨啥呀~~~ 快去勸敗；請全球的胞胞換 OS 和 AP 吧~~~ 呵~ 呵~ 呵~ (好啦~ 一口氣唬爛七篇了；該可以去切腹謝罪啦~~~  )(唬爛的感覺真好~~~ 已經很久沒這樣... 啦~ 啦~ 啦~ 就是這樣~~~  ) |
|
|
|
送花文章: 52967,
|
混合模式
