※ 本文為 MindOcean 轉寄自 ptt.cc 更新時間: 2017-04-06 16:57:03
看板 Gossiping
作者 標題 [問卦] 程式寫得快和寫的精簡哪個比較強?
時間 Thu Apr 6 11:38:50 2017
本人文組 程式設計只有修了3年
但都只是皮毛 每次交作業都草草了事
後來聽強者說他拿到案子都只要別人1/3的時間就能完成
另外一位說別人用5000行的程式他只要2000行就完成
到底這兩種 哪一種較強?
--
因為離心臟最近 制服可是伴隨整個高中時代的唷，
所以呢，第二顆鈕釦凝聚了那個人的所有感情。
『兩個人的距離越親密，第二顆鈕扣的距離就越遙遠。』
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 114.26.219.47
※ 文章代碼(AID): #1OvRXDok (Gossiping)
※ 文章網址: https://www.ptt.cc/bbs/Gossiping/M.1491449933.A.CAE.html
※ 編輯: yoyodiy (114.26.219.47), 04/06/2017 11:39:14
--
推 : 在yo叔面前都是渣1F 04/06 11:39
→ : 文組繞過理組只要三年2F 04/06 11:39
推 : 交的到女友比較強3F 04/06 11:39
→ : 林北都出嘴叫人寫最強4F 04/06 11:40
推 : 以專案來講，如果都能符合規格，我選快的 ^^"5F 04/06 11:40
推 : 越短越強 但是可讀性越差 除非比賽你這樣寫會被打6F 04/06 11:40
推 : 精簡7F 04/06 11:40
→ : 別寫錯才是強8F 04/06 11:40
推 : 說認真，寫得精簡才是強者9F 04/06 11:40
推 : 寫的出來就強了10F 04/06 11:40
→ : 寫的讓別的工程師也看的懂才叫強11F 04/06 11:40
→ : comment寫的好 讓別人看的懂才叫強12F 04/06 11:40
→ : 自high的 就寫爽就好 多人開發的 要寫人懂的 多少不是重點13F 04/06 11:41
推 : 寫的精簡 而且bug少的才強14F 04/06 11:41
推 : 執行快、用的資源少。比較強15F 04/06 11:41
推 : 用嘴巴寫程式最強16F 04/06 11:42
→ : 精簡>>>>>>>>>>>>快17F 04/06 11:42
推 : 精簡>快>出來18F 04/06 11:42
→ : 看得懂最強19F 04/06 11:42
推 : 寫得精簡卻不好維護的跟屎沒兩樣20F 04/06 11:42
→ : 當然要寫得讓人看無而且精簡有用才是真強者尼21F 04/06 11:42
推 : 寫的別人看的懂 好維護才厲害 真的22F 04/06 11:42
→ : 不要寫得別人看不懂就好。23F 04/06 11:43
推 : 不如寫的繞24F 04/06 11:43
推 : 老實說寫的精簡只是在自嗨 越精簡可讀性越差25F 04/06 11:43
推 : 當然是精簡的強，執行速度會快些26F 04/06 11:43
推 : 精簡 還要能讓人懂才是真的強27F 04/06 11:43
推 : 我全部寫在同一行就完成28F 04/06 11:43
→ : 繞過最強29F 04/06 11:44
→ : 精簡無所謂，但是comment要解釋一下怎麼來的。30F 04/06 11:44
推 : 何不繞過31F 04/06 11:44
→ : 最好程式裡還帶有程式碼可以保護智財權尼32F 04/06 11:44
→ : 需求變動過十次，每次都能改得又快又穩的強33F 04/06 11:44
推 : 精簡比較強34F 04/06 11:44
推 : 除非不想讓其他人看懂 不然可維護性也要兼顧吧35F 04/06 11:44
→ : 莫明其妙除一個數，鬼才知道是要幹嘛。36F 04/06 11:44
→ : 能夠讓三個月後的自己還看得懂比較重要37F 04/06 11:44
→ : 程式跑的效率跟程式碼的可讀性較重要38F 04/06 11:45
→ : 要寫得別人看不懂除非是要離職，不然通常是自己維護39F 04/06 11:45
推 : 繞過最強40F 04/06 11:45
推 : 誰管你code怎麼寫 重點是執行速度要快 用到的資源要少41F 04/06 11:45
噓 : 當然是繞過去最強42F 04/06 11:45
→ : 過兩週自己就看不懂啦43F 04/06 11:45
→ : coding44F 04/06 11:45
推 : 現在都看系統吧 好維護+穩才是王道45F 04/06 11:45
→ : 超精簡 結果不能改46F 04/06 11:45
→ : 不管如何 在yo叔面前都是渣47F 04/06 11:45
→ : 沒歷經變動考驗的，快和精簡都沒意義48F 04/06 11:45
推 : deadline前如期上線 誰管你寫多久49F 04/06 11:46
推 : 繞過最強50F 04/06 11:46
→ KangSuat …
→ : 很少會碰到 超小ROM 或是 需要copy到RAM跑的超小RAM情況52F 04/06 11:46
推 : 精簡53F 04/06 11:46
→ : 為了deadline，很多寫法是急就章的...54F 04/06 11:46
→ : 不然需求一來 舊的精簡也是渣55F 04/06 11:47
→ : 等等 竟然是yo叔 那程式碼什麼的全繞過就好了啊 (?56F 04/06 11:47
→ : auto auto(auto){auto;}57F 04/06 11:49
推 : 執行快、占用最少資源達到目的的最強58F 04/06 11:49
推 : 能寫別人一眼就能看懂&接手的最強!59F 04/06 11:49
推 : 想太多 賣得掉再說60F 04/06 11:49
推 : 註解寫的好 後續好維護才是好程式 tune效能是之後的事61F 04/06 11:50
推 : bug少62F 04/06 11:50
→ : 有些自以為聰明的 寫出"最佳解" 結果沒人能接 有屁用!?63F 04/06 11:50
推 : 寫到別人看不懂還不是沒用 有問題都找你64F 04/06 11:50
推 : a=sin(x*180/pi)>cos(y*180/pi)?b+100:(c-d)/265F 04/06 11:52
→ : 繞過去比較強66F 04/06 11:53
→ : 後續好維護的碼才是好程式，寫得太精簡沒人看得懂67F 04/06 11:53
→ : 後續接手的人很頭大好嗎?
→ : 後續接手的人很頭大好嗎?
→ : 沒有bug最強拉69F 04/06 11:53
→ : 這還好啦....70F 04/06 11:53
推 : 能寫出執行得快跟佔用資源少最強71F 04/06 11:53
→ : 剛剛有人講，擴充性也很重要。72F 04/06 11:54
→ : 精簡才是境界73F 04/06 11:54
推 : 都不寫 但是看得懂別人code的人最強74F 04/06 11:55
推 : 先快再求精簡75F 04/06 11:56
→ : 看得懂最重要76F 04/06 11:56
推 : 三個月後你還看得懂自己的code算你過關77F 04/06 11:56
推 : 更正 能賣最強78F 04/06 11:56
→ : 能讓別人看得懂最重要......79F 04/06 11:57
推 : 原PO不要再自謙了80F 04/06 11:58
推 : 精簡比較強 但是商業面要好維護 速度更重要81F 04/06 11:59
推 : 複製貼上最強82F 04/06 12:00
推 : 簡單 易懂 執行輕量快速 無後顧之憂才是好的現代魔法83F 04/06 12:00
推 : 好讀好改比較強84F 04/06 12:01
推 : 寫的短用comment補充啊 有差嗎85F 04/06 12:01
推 : 寫的沒人看得懂才有價值86F 04/06 12:03
推 : 鼻要精簡 精簡=難改 為後面的菜比8想想好嗎87F 04/06 12:03
推 : 任何一個傻瓜都能寫出計算機可以理解的程式碼88F 04/06 12:03
→ : 唯有寫出人類容易理解的程式碼，才是優秀的程式人
→ : 唯有寫出人類容易理解的程式碼，才是優秀的程式人
推 : 推維護性跟擴充性90F 04/06 12:04
噓 : 繞過去最強91F 04/06 12:05
推 : 繞過92F 04/06 12:05
推 : 可讀性 跟 可程式性93F 04/06 12:09
推 : 精簡沒屁用 執行效率 易讀可維護性高的coding style才好94F 04/06 12:12
→ : 最佳解寫了沒人能接，是怪寫出來的人喔 XD95F 04/06 12:13
推 : 遠古時代有這樣的習俗，但在現在已經不適用了96F 04/06 12:13
推 : 最強的是不要寫程式，程式寫得好，要飯要到老97F 04/06 12:14
推 : 好笑的是最佳解是你自己定義的 哪天你接到人家天書再哭98F 04/06 12:15
推 : 能讓別人接手的最強99F 04/06 12:16
推 : 接得到案結得了案收得到款比較強100F 04/06 12:17
推 : 精簡強啊！最好是只有自己才看的懂更好，讓自己無法被取101F 04/06 12:19
→ : 代。
→ : 代。
推 : 精簡103F 04/06 12:20
→ : 後面的人無法接手更好104F 04/06 12:20
推 : 都不強 沒有Bug 才是強 管你多精簡多麼快 錯了就是遜105F 04/06 12:20
推 : 都不強 沒有Bug 才是強 管你多精簡多麼快 錯了就是遜
推 : 有些人寫的快 但是這邊改好了 那邊又出包了 根本搞笑
推 : 都不強 沒有Bug 才是強 管你多精簡多麼快 錯了就是遜
推 : 有些人寫的快 但是這邊改好了 那邊又出包了 根本搞笑
推 : 寫得看不懂才能保住工作權好嗎108F 04/06 12:23
推 : yo叔不要釣魚109F 04/06 12:23
推 : 寫看得懂=失業110F 04/06 12:23
推 : 有些人寫的很精簡 但是錯誤就是錯誤 還不知道怎麼改111F 04/06 12:23
推 : 笑死 一堆鍵盤軟體工程師 沒半點軟體工程概念112F 04/06 12:23
→ : 繞113F 04/06 12:24
噓 : 有寫文件的比較強114F 04/06 12:25
→ : 寫了10幾年 還是感覺精簡比較難 真的是經驗的累積115F 04/06 12:25
推 : 看架構跟之後的維護116F 04/06 12:25
推 : 有沒有了解要寫的程式內容原理 至於快或精簡已不重要117F 04/06 12:26
推 : 5000行...大學生作業膩？知道android codebse幾行嗎？6118F 04/06 12:28
推 : 0G以上...已經沒在算行數了.
推 : 0G以上...已經沒在算行數了.
推 : 可以繞過rar最強120F 04/06 12:28
推 : 為什麼有Bug就是前人寫不完善有疏忽你看不懂就無法改121F 04/06 12:29
推 : 強不強不知道 但是應徵筆試教你畫出奇形怪狀*星星金字122F 04/06 12:30
→ : 塔圖案 你每一行都用print畫出來大概很不妙
→ : 塔圖案 你每一行都用print畫出來大概很不妙
推 : 當然是全部打在一行的強124F 04/06 12:30
推 : 註解也要維護，有人改了code沒改註解會造成反效果125F 04/06 12:32
噓 : 看老闆給多少錢126F 04/06 12:33
推 : 絕對是擴充性127F 04/06 12:33
→ : 多寫幾行註解不如把程式直接寫得明瞭，除非效能差很大128F 04/06 12:33
→ : 兩個都不好 看得懂比較重要 不過這樣就失業了129F 04/06 12:35
推 : 寫程式行數和速度不是重點，軟工才是重點，上面大家都130F 04/06 12:38
推 : 說完惹～
推 : 說完惹～
推 : 寫程式就是結果論 寫的快或精簡 只要有bug 就是無用132F 04/06 12:38
推 : 資工同學程式都用複製貼上的133F 04/06 12:39
→ : 有人也太理想化了吧 大一點的程式怎麼可能完全無bug XDD134F 04/06 12:41
→ : 修bug當然是第一優先 但可讀性再怎麼算也應該是第二或第三
→ : 那種故意寫垃圾為了不讓人取代先不談
→ : 修bug當然是第一優先 但可讀性再怎麼算也應該是第二或第三
→ : 那種故意寫垃圾為了不讓人取代先不談
推 : 說真的，只用嘴巴寫出來的才是最強137F 04/06 12:43
推 : 寫出沒bug不用維護的最強138F 04/06 12:45
推 : 大一點的程式都有模組化程式的新功能,但如果沒有對139F 04/06 12:46
推 : 整個系統掌控了解,很多軟體問題往往都在於沒了解底層
推 : 造成的問題也往往找不出原因,要寫軟體,要懂系統內部
推 : 整個系統掌控了解,很多軟體問題往往都在於沒了解底層
推 : 造成的問題也往往找不出原因,要寫軟體,要懂系統內部
推 : 看的懂的142F 04/06 12:47
推 : 有差嗎 還不是看專案143F 04/06 12:47
推 : 快短無bug144F 04/06 12:51
推 : 繞過去的最猛145F 04/06 12:51
推 : 跑的快才重要......146F 04/06 12:52
推 : 個人是不用註解也看得懂的越好。可擴充性也是重點。147F 04/06 12:54
→ : 寫重要的，hello world 寫的再精簡再快也是hello world.148F 04/06 12:56
推 : 還有程式分Kernel層,Liberary層,UI層,看你是寫哪一層149F 04/06 12:57
推 : 除了以上三層還有app層
推 : 除了以上三層還有app層
推 : 小專案前者 大專案後者 如果是要持續維護的專案151F 04/06 12:58
→ : 為了趕時間亂寫 後期付出的代價會很龐大
→ : 為了趕時間亂寫 後期付出的代價會很龐大
推 : 你是認真的嗎？你出來問問題哪會有解答，只有繞過去而已153F 04/06 13:01
→ : 精簡的強154F 04/06 13:01
推 : 客戶通常看不懂程式碼只要能運作就好155F 04/06 13:13
推 : 現在寫扣還要有防護的觀念 這樣寫法是不是有漏洞給人家156F 04/06 13:15
推 : 攻擊 如果人家逆向容不容易被分析 當然如果只是拉ㄐ小
推 : 程式就短吧
推 : 攻擊 如果人家逆向容不容易被分析 當然如果只是拉ㄐ小
推 : 程式就短吧
推 : 我覺得可讀性比較好，此外還要考慮相容性跟唯讀159F 04/06 13:22
推 : 好籠統的問題 對寫程式的人而言160F 04/06 13:22
推 : 懶覺比雞腿.....161F 04/06 13:23
推 : 把程式物件化模組化不寫重複code162F 04/06 13:25
推 : 精簡最好 可以減短寫一堆廢話幹嘛163F 04/06 13:26
→ : 跟企劃 報告一樣啊 簡單明瞭不是比較好? 結果全都寫一
→ : 堆廢話增加頁數感覺很強- -
→ : 跟企劃 報告一樣啊 簡單明瞭不是比較好? 結果全都寫一
→ : 堆廢話增加頁數感覺很強- -
推 : 可維護性高的166F 04/06 13:31
推 : 寫得可以讓人看懂最強167F 04/06 13:36
→ : 不過這只是對寫程式的而言，對客戶而言，聽話的最強
→ : 不過這只是對寫程式的而言，對客戶而言，聽話的最強
推 : 日後修改不必牽一髮動全身，架構設計強才是神人169F 04/06 13:38
推 : 精簡到底有啥用 別人看不懂也沒用170F 04/06 13:38
推 : 覺得可讀寫比較重要171F 04/06 13:39
推 : 程式還分Full version跟Customer version就不多講了172F 04/06 13:42
→ : 有興趣自己跳進來摸一摸就知道寫程式很簡單又好玩
→ : 有興趣自己跳進來摸一摸就知道寫程式很簡單又好玩
推 : 精簡有啥用 要別人看得懂才是重點174F 04/06 13:43
推 : 不是有些都考什麼 如何寫更精簡 坦白說 懂歸懂 但真實做
推 : 專案時 還是要以合作為優先吧 別人看得懂才是重點
推 : 當然要能寫得精簡 代表本身實力到一定程度以上了
推 : 不是有些都考什麼 如何寫更精簡 坦白說 懂歸懂 但真實做
推 : 專案時 還是要以合作為優先吧 別人看得懂才是重點
推 : 當然要能寫得精簡 代表本身實力到一定程度以上了
→ : 讓人看的懂最好178F 04/06 13:47
推 : 趁這篇熱門問一下 小弟想學好C 那個Dev-C++適不適合179F 04/06 13:55
推 : 寫得沒人看得懂不好維護的code就是垃圾180F 04/06 13:56
推 : 當然是簡化的強啊181F 04/06 14:01
推 : 通常別奢望你遇到的code有註解,倒不如要求自己要看懂182F 04/06 14:01
→ : 而且遇到沒註解的code三天兩頭都遇到,沒註解就停擺了
→ : 而且遇到沒註解的code三天兩頭都遇到,沒註解就停擺了
推 : 當你接過別人的爛攤子，你就知道長短快慢都是屁184F 04/06 14:03
推 : 有邏輯、看得懂才是重點
推 : 有邏輯、看得懂才是重點
→ : 嗎? 那老闆請你來幹嘛?186F 04/06 14:03
推 : 要看你在什麼樣的生態裡面啊啊，台灣很多只要有這個功187F 04/06 14:05
推 : 能跟便宜就好了，當然是寫的快，甚至一套可以動的就放他
推 : 跑也沒在做維護跟安全性更新。
推 : 能跟便宜就好了，當然是寫的快，甚至一套可以動的就放他
推 : 跑也沒在做維護跟安全性更新。
推 : 能有效率除bug的才是人才190F 04/06 14:05
→ : 這兩個指標都不是很可靠啊191F 04/06 14:06
噓 : 花一次小錢爽一輩子？192F 04/06 14:08
推 : 精簡無BUG>>>>>>快!193F 04/06 14:08
→ : 寫程式的人有爽到嗎？194F 04/06 14:08
推 : 可讀性最高的最強195F 04/06 14:14
推 : 讀得懂才是重點，再快再精簡沒辦法改有屁用196F 04/06 14:18
→ : 這ID會問這問題太怪了，不是都寫出rar解密程式？197F 04/06 14:30
推 : 選胸部大的198F 04/06 14:33
噓 : yo叔我也住苗栗，可以約炮嗎199F 04/06 14:46
推 : 能讓別人看懂比較重要 ...200F 04/06 15:00
推 : 精簡可讀性低gg201F 04/06 15:05
推 : 有的精簡都嘛是用系統資源換的 不然就亂設flag跟global202F 04/06 15:15
推 : 說真的數學運算寫的精簡邏輯沒錯是強
推 : 但是大案子很多都嘛類似的架構去延伸
推 : 這時候維持架構跟可再用性就很重要
推 : 簡單來說還是要看你案子給多少系統資源去改你的程式做法
推 : 說真的數學運算寫的精簡邏輯沒錯是強
推 : 但是大案子很多都嘛類似的架構去延伸
推 : 這時候維持架構跟可再用性就很重要
推 : 簡單來說還是要看你案子給多少系統資源去改你的程式做法
推 : yo叔是yo家族之光 都能繞過去207F 04/06 15:23
推 : 精簡，程式寫太多容易導致執行上的拖時間208F 04/06 15:26
推 : 寫的別人一眼看懂比較好，除非你什麼都要自己來209F 04/06 15:26
推 : 快的 而且可讀性>短210F 04/06 15:36
推 : 以目前的經驗來說 重點是註解 註解 註解 很重要所以說三遍211F 04/06 15:48
推 : 精簡，但要讓人看得懂好維護212F 04/06 15:48
推 : 可讀>精簡>快 有些人寫得跟天書一樣 不知道在銃啥小213F 04/06 15:52
推 : 寫的能用能賣214F 04/06 16:16
→ : Code 精簡不代表編譯出來精簡，況且現在編譯器功能都很強215F 04/06 16:46
→ : 大專案裡 Code 的重點主要在於可閱讀性以及修改彈性
→ : 最好能搭配文件解釋一些單看 Code 不易理解的部分
→ : 以上幾點評估方向都是為了提升正確性、彈性與工作效率
→ : 大專案裡 Code 的重點主要在於可閱讀性以及修改彈性
→ : 最好能搭配文件解釋一些單看 Code 不易理解的部分
→ : 以上幾點評估方向都是為了提升正確性、彈性與工作效率
--
(￣︶￣)ｂ et79210 說讚！
4樓 時間: 2017-04-06 13:10:17 (澳門)
→
04-06 13:10 MO
寫得快的才比較強，因為快代表可以接更多的工作或有更多的時間。即使有BUG就修，沒人敢保證自己程式沒BUG。現實大多數都追求一個快字，加上慢長的修BUG來賺維護費。加上簡短的程式是小，但並不代表精，而且失去了短時間工作。程式上快而精是上好的，若加上小便完美了
5樓 時間: 2017-04-06 13:23:41 (台灣)
→
04-06 13:23 TW
對自己要求精簡，但希望別人的程式好讀 尤其是變數跟函數的命名，最討厭那種不知所云的奇怪命名，沒有寫註解的話還要猜一下
6樓 時間: 2017-04-06 13:36:43 (台灣)
→
04-06 13:36 TW
不一定,不管是寫的快還是精簡,一堆BUG或耗資源=沒用,不過如果是以結果都相同的情況,是好讓其他人維護的強...而精簡也不一定是不好維護的....
10樓 時間: 2017-04-06 14:26:34 (台灣)
→
04-06 14:26 TW
程式完全符合需求及正確性 > 容易維護擴展 > 速度快占用資源少 客戶才不管你的程式有多精簡.按期交件最重要
12樓 時間: 2017-04-06 16:32:11 (台灣)
→
(編輯過) TW
寫完能一次到位又沒有BUG的最強 上面寫甚麼能賺錢寫得快的那些通通都是菜逼八 寫程式最花時間的明明就是DEBUG寫得快有甚麼屁用，功能/需求東漏西漏搞出一堆BUG也可以寫很快啊 你只要人家的1/3就能寫完，但是你花在DEBUG的時間要人家的三倍以上意義何在寫得精簡有甚麼屁用，自己要DEBUG的時候你就知道有多痛苦 你只要別人行數的1/4，但是有BUG的時候你就會發現架構要全部打掉重寫，看過不少白癡這樣幹過，連測試都還沒過就在精簡程式，渾身菜味所以我最佩服的是寫完後測試能一次過關的神人，代表這類人思緒非常清晰，邏輯思考能力超乎常人 最重要的是，這類人寫出來的程式非常的好閱讀，光這點就屌打一堆人了
回列表(←)
分享