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

[tinlans ( )]

※ 引述《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 ([e-mail])
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)
→ hilorrk:不是說軟體的工程方法還不成熟嗎O.O?
→ tinlans:可以透過約定強化它，往藝術跟講求天分走一定是開倒車。
推 yauhh:本篇概念是所謂漂亮是可以學到的,不一定是天份或信仰
→ in09:那怎麼我這麼常看到阿貓阿狗都不如的科班生
→ COLDTURNIP:師父引進門，修性在個人。
→ yauhh:阿貓阿狗都不如?那你要先看一下你所評估的環境是局限的或開
→ yauhh:放的. 可能在局限範圍內,他不是你要的人,所以被你狠批.
→ yauhh:但你可要再想想你的評估範圍是不是太狹小.
推 revivalworld:看到發文時間... 你沒睡嗎... = =
推 ledia:我覺得有必要把 design 跟 implementation 分開來
推 damody:軟工不成熟只有在台灣，請多互動，不要只被限在台灣。
推 damody:我覺得原po先去把code complete背下來再說。
→ ksmrt0123:把the art of programming 的art譯成藝術是誤解了
→ ksmrt0123:想想看有那個學校把CS dept放在art school?
推 sunneo:淚推 Q_O  我現在想辦法把前人的爛code改寫
→ sunneo:但還是得瞞著老闆 得跟他說我不作這樣的事
→ sunneo:因為對他而言能動就好 知道表面就夠了 他不管維護性的
推 wa120:大部分的大學教授都活在舊時代...
推 yauhh:我對本篇的舊時代論點還有點懷疑,不過若要這樣講也沒關係啦
→ yauhh:art跟sciense,philosophy一樣是範圍很大的詞,並不是不在art
→ yauhh:部門的就不可稱為art.
→ erotic:老師有沒有教你寫文章要分段、縮進、使用句號啊? = =
推 Savate:推這篇  你的講解套用在我老師的說法和背景真的很符合
→ tinlans:樓樓上的疑問我可以解答。如果是傳統的「方塊文」我倒是會
→ tinlans:好好的選句號。但因為方塊文通常不易閱讀，所以網路上產生
→ tinlans:了一個標點換一行的文體格式。這種狀況可不是胡適當年想得
→ tinlans:到的。而這種斷行方式輕易打上句號，很容易讓人引起一種「
→ tinlans:然後呢？」的疑惑。
→ in09:"講"方法論的人,不見得就不會是爛code的作者..,show個作品吧?
→ ksmrt0123:the art of ... 的art的解釋如下:
→ ksmrt0123:if you describe something as as art, you mean that
→ ksmrt0123:it requires skill and that people learn to do it by
→ tinlans:樓上那句話害我 google 了「NDA 失效」翻了半小時...XD
→ tinlans:嗯，是樓樓上才對。
→ ksmrt0123:instinct or experience, rather than by learning
→ ksmrt0123:facts or rules.
→ ksmrt0123:programming是art, 但不應被解釋成藝術
→ ksmrt0123:然後污名化 "舊時代" 的 the art of programming
→ ksmrt0123:什麼時候對「漂亮」的定再是「奇怪」了?
→ ksmrt0123:                     定義
→ ksmrt0123:亂講一通
→ tinlans:其實我講的是透過大量 casting 和操弄 pointer 出現的特技
→ tinlans:跟它的附加效果，跟你想的那個不一樣。
→ tinlans:看過很多純 C 的 source code 就會知道我在說什麼了，很多
→ tinlans:過去 trace 那些 code 的人，看到「程式居然還能這樣寫」
→ tinlans:，然後衍生出「這種寫法很神」等等的觀感，演變出一些莫名
→ tinlans:的崇拜和濫用，並被擴大解釋為藝術，跟你講的完全不相干。
→ ksmrt0123:你把某些人的行為解釋成一般普遍現像
→ ksmrt0123:要寫易讀易懂易維護的code在"舊世代"已是基本原則
→ tinlans:可是呢，某些「概念」在當代的語言機制並不支援，在這時候
→ ksmrt0123:用strict aliasing跟restrict pointer來說明
→ tinlans:人們就會想出各式各樣的「解決方案」。而這些解決方案就是
→ tinlans:問題的來源。
→ ksmrt0123:「奇怪到被認為很優美」更是不妥... 這兩個東西是隨個
→ ksmrt0123:architecture/optimizing compiler演進才有比較顯著的好
→ ksmrt0123:處... 用現在的環境去挑剔過去不需要的東西不是正確的
→ ksmrt0123:態度...
→ tinlans:你似乎搞錯了因果關係。起因及前提在於到了「現在」還有人
→ tinlans:在提倡將「過去」的遺跡拿到現在來用，所以我當然可以用現
→ tinlans:在的角度去重新審視它。
→ tinlans:strict aliasing 被標準化的背景不光是最佳化考量，當年
→ tinlans:放棄允許用 incompatible pointer 之間的 casting 建立
→ tinlans:aliasing relation，其中一個考量就是那種 code 本身就不
→ tinlans:易閱讀，否則其實只要加入 restrict pointer 這個新要素
→ tinlans:就相當充足了。
→ tinlans:再來，「易讀易懂」的定義在當代會因「主流寫法」而改變，
→ tinlans:如果一個「大師」用了相當難懂的寫法去實現一項功能，接著
→ tinlans:大家認為他是大師所以一定是好方法而學著用，那麼這種複雜
→ tinlans:難懂的寫法，瞬間就變成「老手」認知裡「本來就該會」的東
→ tinlans:西，但是對新手或是該圈子之外的人來說卻完全不是這回事。
→ tinlans:而所謂「要寫得好就是要多看人家的程式」就是這麼回事了。
→ tinlans:這句話在 15 年前我也說過，但在現代我絕不這麼說。
→ tinlans:而我在現在聽到了這句話，結果就是回了這麼的一篇。
→ tinlans:要說抱持著「大師都用這種寫法，你看不懂就是孤陋寡聞、看
→ tinlans:得太少、經驗淺、程度差」這種想法的人在當代是少數，那我
→ tinlans:可是完全不同意。
→ tinlans:回的順序雖然是倒過來的，不過應該每個點都有回到了，之前
→ tinlans:有過漏看幾句就被說避重就輕挑想回的回這種經驗，不得不謹
→ tinlans:慎一點。
推 abovelight:推這篇 以前的我看不懂 現在多少了解了