Re: [問題] 何謂寫得漂亮?

看板C_and_CPP (C/C++)作者 ( )時間16年前 (2010/01/17 05:11), 編輯推噓10(10070)
留言80則, 14人參與, 最新討論串5/9 (看更多)
※ 引述《Savate (二郎不是餓狼更不是惡狼)》之銘言: : 我記得我在修數值方法時 : 老師第堂課就說 : 程式要寫出來沒什麼 : 要寫得好就是要多看人家的程式 : 要寫得漂亮就要靠天份了 : 天份? 什麼天份啊? : 何謂寫得漂亮呢? 你的老師顯然還活在舊時代, 在過去 programming 的技術是曾經被視為一種藝術沒錯, 但後來已經被視為是一種工程, 根據特定的工程方法就可以實作出易讀易懂易維護的軟體系統, 把 programming 視為 art 的舊時代早就結束很久了, 現在都單純是 engineering 而已, 根本沒有什麼天分問題, 學過相關的工程方法論就算是阿貓阿狗也寫得出人模人樣的程式來, 差別就在於你有沒有學過和願不願意學。 現在的軟體架構也早就膨脹到不是光看別人寫的程式就能學到東西的, 除非他們有附上完整的技術文件跟工程圖給你, 而且運氣不好還會學到一堆錯誤的知識和觀念, 早期是因為 C 語言本身的機制太簡單卻又什麼都能做, 導致各種奇奇怪怪的旁門左道技術被不同人發明出來寫 code, 當時想學遍或看懂這些 code 是真的要多看別人的程式沒錯, 把一個想法以最奇怪最難懂的 coding 方法寫出來的人成被供奉為神, 但隨著支援抽象概念的更高階語言普及, 實現那些概念的方式都有了語言機制的支援, 能夠以更簡單明瞭的方式去實現, 那些艱澀難懂的舊時代程式碼早就變成垃圾和毒瘤了, 常見概念的實現方法也漸漸的被收集成一些 pattern 並記載在書上, 實在沒有必要去 trace 人家寫好的程式來重新發現這些 pattern, 這裡講的 pattern 可不僅侷限於廣為人知的 design pattern, 架構分析甚至商業邏輯事實上都有 pattern 存在, 國內知道 GoF 那些 pattern 的人已經不在少數了, 但見過 PEAA 甚至加以運用的人卻不是那麼的多: Patterns of Enterprise Application Architecture http://martinfowler.com/eaaCatalog/ 把 pattern 跟 GoF Design Patterns 劃上等號並認為它根本沒用其實也是很大的誤解; 總而言之 trace 別人寫的 code 才會把程式寫得漂亮的時代已經過去了, 因為現在對「漂亮」的定義不再是「奇怪」。 事實上那些「奇怪」的程式早在 10 年前就開始陸陸續續受到報應, C99 的 strict aliasing 幾乎讓那些程式全部爆光光了, 要不是 gcc 還有提供什麼 -fno-strict-aliasing 的選項, 我看世界上大概沒幾個 C 寫的軟體還活得下來, 就算活下來了效能也是被跑在 server mode 的 Java 程式打得趴在地上; 不過 strict aliaing 又是另一個故事了 (它跟 restrict pointer 這兩項機制可以建構出真正高速的 C 程式), 在這邊提出來只是要說在過去很多「奇怪到被認為很優美」的程式, 在現代看來不但醜陋骯髒, 甚至執行的效率還有可能比較差, 現在 open source 的程式碼幾乎都還大量殘留這些糟糕的遺跡, 多看了反而也只會學壞而已, 時代早就不一樣了。 : 事實上我也在科技業板看過這類推文 : "寫程式需要天份" 只要努力就可以了, 要天分的說法是把 programming 視為 art 的舊時代才在講的。 : 我個人自己的解讀是 : "如何把一個構想用程式實現出來"的思考過程 可以去學一些搭 UML 的軟體開發流程來用用, 譬如學術界常見的 UP 跟現在「軟體工業界」很愛用的 EssUP (我強調軟體工業界的意思...應該不用說了), 哪個步驟該用哪些圖都會告訴你, 包括如何分析畫出來的圖決定要撰寫哪些類別跟方法, 哪些類別應該合併或分解等等, 最後按圖施工自然就會從架構上看起來都很漂亮, 即使是分工交給一些只懂 coding 的人去寫末端的東西, 整個大格局也不會很輕易的就被他們搞得亂七八糟。 最後要說的是, 如果你有心成為新舊時代之間的橋樑, 打算把舊時代的程式慢慢做苦工把它們翻新的話, 我倒是不反對你把去多看舊時代裡被稱為寫得很好的程式, 但是並不是現在就去看, 要做這種工作的必須是同時熟稔過去年代裡各種奇門異術和現代工程方法的人, 先習慣了現代的工程方法並深知舊時代藝術的缺點後才有辦法翻修, 不然只會做得亂七八糟看起來不三不四而已, 抗壓性等等的能力可能也需要具備, 因為在學術界和工業界都幾乎沒有人會支持你做這件事, 可稱得上是非常寂寞又苦悶的工作, 而且這種事情一般也不適合太張揚所以很難激發成就感, 畢竟去公司面試的時候讓人知道你重寫過一堆東西, 人家還怕你什麼都要重寫一遍拖慢整個 project 的進度。 -- Ling-hua Tseng (uranus@tinlans.org) Department of Computer Science, National Tsing-Hua University Interesting: C++, Compiler, PL/PD, OS, VM, Large-scale software design Researching: Software pipelining for VLIW architectures Homepage: http://www.tinlans.org -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.133.199.45 ※ 編輯: tinlans 來自: 220.133.199.45 (01/17 05:40)

01/17 06:33, , 1F
不是說軟體的工程方法還不成熟嗎O.O?
01/17 06:33, 1F

01/17 06:51, , 2F
可以透過約定強化它,往藝術跟講求天分走一定是開倒車。
01/17 06:51, 2F

01/17 08:26, , 3F
本篇概念是所謂漂亮是可以學到的,不一定是天份或信仰
01/17 08:26, 3F

01/17 09:02, , 4F
那怎麼我這麼常看到阿貓阿狗都不如的科班生
01/17 09:02, 4F

01/17 09:46, , 5F
師父引進門,修性在個人。
01/17 09:46, 5F

01/17 10:03, , 6F
阿貓阿狗都不如?那你要先看一下你所評估的環境是局限的或開
01/17 10:03, 6F

01/17 10:03, , 7F
放的. 可能在局限範圍內,他不是你要的人,所以被你狠批.
01/17 10:03, 7F

01/17 10:04, , 8F
但你可要再想想你的評估範圍是不是太狹小.
01/17 10:04, 8F

01/17 11:08, , 9F
看到發文時間... 你沒睡嗎... = =
01/17 11:08, 9F

01/17 11:26, , 10F
我覺得有必要把 design 跟 implementation 分開來
01/17 11:26, 10F

01/17 11:28, , 11F
軟工不成熟只有在台灣,請多互動,不要只被限在台灣。
01/17 11:28, 11F

01/17 11:30, , 12F
我覺得原po先去把code complete背下來再說。
01/17 11:30, 12F

01/17 11:59, , 13F
把the art of programming 的art譯成藝術是誤解了
01/17 11:59, 13F

01/17 12:00, , 14F
想想看有那個學校把CS dept放在art school?
01/17 12:00, 14F

01/17 13:05, , 15F
淚推 Q_O 我現在想辦法把前人的爛code改寫
01/17 13:05, 15F

01/17 13:06, , 16F
但還是得瞞著老闆 得跟他說我不作這樣的事
01/17 13:06, 16F

01/17 13:07, , 17F
因為對他而言能動就好 知道表面就夠了 他不管維護性的
01/17 13:07, 17F

01/17 13:17, , 18F
大部分的大學教授都活在舊時代...
01/17 13:17, 18F

01/17 14:05, , 19F
我對本篇的舊時代論點還有點懷疑,不過若要這樣講也沒關係啦
01/17 14:05, 19F

01/17 14:09, , 20F
art跟sciense,philosophy一樣是範圍很大的詞,並不是不在art
01/17 14:09, 20F

01/17 14:10, , 21F
部門的就不可稱為art.
01/17 14:10, 21F

01/17 17:41, , 22F
老師有沒有教你寫文章要分段、縮進、使用句號啊? = =
01/17 17:41, 22F

01/17 19:41, , 23F
推這篇 你的講解套用在我老師的說法和背景真的很符合
01/17 19:41, 23F

01/17 19:52, , 24F
樓樓上的疑問我可以解答。如果是傳統的「方塊文」我倒是會
01/17 19:52, 24F

01/17 19:52, , 25F
好好的選句號。但因為方塊文通常不易閱讀,所以網路上產生
01/17 19:52, 25F

01/17 19:53, , 26F
了一個標點換一行的文體格式。這種狀況可不是胡適當年想得
01/17 19:53, 26F

01/17 19:53, , 27F
到的。而這種斷行方式輕易打上句號,很容易讓人引起一種「
01/17 19:53, 27F

01/17 19:54, , 28F
然後呢?」的疑惑。
01/17 19:54, 28F

01/17 21:27, , 29F
"講"方法論的人,不見得就不會是爛code的作者..,show個作品吧?
01/17 21:27, 29F

01/17 22:08, , 30F
the art of ... 的art的解釋如下:
01/17 22:08, 30F

01/17 22:08, , 31F
if you describe something as as art, you mean that
01/17 22:08, 31F

01/17 22:09, , 32F
it requires skill and that people learn to do it by
01/17 22:09, 32F

01/17 22:09, , 33F
樓上那句話害我 google 了「NDA 失效」翻了半小時...XD
01/17 22:09, 33F

01/17 22:09, , 34F
嗯,是樓樓上才對。
01/17 22:09, 34F

01/17 22:09, , 35F
instinct or experience, rather than by learning
01/17 22:09, 35F

01/17 22:10, , 36F
facts or rules.
01/17 22:10, 36F

01/17 22:13, , 37F
programming是art, 但不應被解釋成藝術
01/17 22:13, 37F

01/17 22:14, , 38F
然後污名化 "舊時代" 的 the art of programming
01/17 22:14, 38F

01/17 22:17, , 39F
什麼時候對「漂亮」的定再是「奇怪」了?
01/17 22:17, 39F

01/17 22:17, , 40F
定義
01/17 22:17, 40F

01/17 22:18, , 41F
亂講一通
01/17 22:18, 41F

01/17 22:18, , 42F
其實我講的是透過大量 casting 和操弄 pointer 出現的特技
01/17 22:18, 42F

01/17 22:19, , 43F
跟它的附加效果,跟你想的那個不一樣。
01/17 22:19, 43F

01/17 22:20, , 44F
看過很多純 C 的 source code 就會知道我在說什麼了,很多
01/17 22:20, 44F

01/17 22:20, , 45F
過去 trace 那些 code 的人,看到「程式居然還能這樣寫」
01/17 22:20, 45F

01/17 22:21, , 46F
,然後衍生出「這種寫法很神」等等的觀感,演變出一些莫名
01/17 22:21, 46F

01/17 22:21, , 47F
的崇拜和濫用,並被擴大解釋為藝術,跟你講的完全不相干。
01/17 22:21, 47F

01/17 22:24, , 48F
你把某些人的行為解釋成一般普遍現像
01/17 22:24, 48F

01/17 22:25, , 49F
要寫易讀易懂易維護的code在"舊世代"已是基本原則
01/17 22:25, 49F

01/17 22:27, , 50F
可是呢,某些「概念」在當代的語言機制並不支援,在這時候
01/17 22:27, 50F

01/17 22:28, , 51F
用strict aliasing跟restrict pointer來說明
01/17 22:28, 51F

01/17 22:28, , 52F
人們就會想出各式各樣的「解決方案」。而這些解決方案就是
01/17 22:28, 52F

01/17 22:28, , 53F
問題的來源。
01/17 22:28, 53F

01/17 22:28, , 54F
「奇怪到被認為很優美」更是不妥... 這兩個東西是隨個
01/17 22:28, 54F

01/17 22:29, , 55F
architecture/optimizing compiler演進才有比較顯著的好
01/17 22:29, 55F

01/17 22:31, , 56F
處... 用現在的環境去挑剔過去不需要的東西不是正確的
01/17 22:31, 56F

01/17 22:31, , 57F
態度...
01/17 22:31, 57F

01/17 22:32, , 58F
你似乎搞錯了因果關係。起因及前提在於到了「現在」還有人
01/17 22:32, 58F

01/17 22:33, , 59F
在提倡將「過去」的遺跡拿到現在來用,所以我當然可以用現
01/17 22:33, 59F

01/17 22:33, , 60F
在的角度去重新審視它。
01/17 22:33, 60F

01/17 22:45, , 61F
strict aliasing 被標準化的背景不光是最佳化考量,當年
01/17 22:45, 61F

01/17 22:45, , 62F
放棄允許用 incompatible pointer 之間的 casting 建立
01/17 22:45, 62F

01/17 22:46, , 63F
aliasing relation,其中一個考量就是那種 code 本身就不
01/17 22:46, 63F

01/17 22:46, , 64F
易閱讀,否則其實只要加入 restrict pointer 這個新要素
01/17 22:46, 64F

01/17 22:47, , 65F
就相當充足了。
01/17 22:47, 65F

01/17 22:55, , 66F
再來,「易讀易懂」的定義在當代會因「主流寫法」而改變,
01/17 22:55, 66F

01/17 22:56, , 67F
如果一個「大師」用了相當難懂的寫法去實現一項功能,接著
01/17 22:56, 67F

01/17 22:56, , 68F
大家認為他是大師所以一定是好方法而學著用,那麼這種複雜
01/17 22:56, 68F

01/17 22:57, , 69F
難懂的寫法,瞬間就變成「老手」認知裡「本來就該會」的東
01/17 22:57, 69F

01/17 22:57, , 70F
西,但是對新手或是該圈子之外的人來說卻完全不是這回事。
01/17 22:57, 70F

01/17 22:59, , 71F
而所謂「要寫得好就是要多看人家的程式」就是這麼回事了。
01/17 22:59, 71F

01/17 23:02, , 72F
這句話在 15 年前我也說過,但在現代我絕不這麼說。
01/17 23:02, 72F

01/17 23:02, , 73F
而我在現在聽到了這句話,結果就是回了這麼的一篇。
01/17 23:02, 73F

01/17 23:13, , 74F
要說抱持著「大師都用這種寫法,你看不懂就是孤陋寡聞、看
01/17 23:13, 74F

01/17 23:14, , 75F
得太少、經驗淺、程度差」這種想法的人在當代是少數,那我
01/17 23:14, 75F

01/17 23:14, , 76F
可是完全不同意。
01/17 23:14, 76F

01/17 23:28, , 77F
回的順序雖然是倒過來的,不過應該每個點都有回到了,之前
01/17 23:28, 77F

01/17 23:28, , 78F
有過漏看幾句就被說避重就輕挑想回的回這種經驗,不得不謹
01/17 23:28, 78F

01/17 23:29, , 79F
慎一點。
01/17 23:29, 79F

01/20 13:15, , 80F
推這篇 以前的我看不懂 現在多少了解了
01/20 13:15, 80F
文章代碼(AID): #1BKYjouA (C_and_CPP)
討論串 (同標題文章)
文章代碼(AID): #1BKYjouA (C_and_CPP)