Bruce Sterling 轉貼了一篇標題為 Mea Culpa (我認錯) 的程式設計師反省文。並重新定標題為別當自作聰明的程式設計師。原作者是從 1969 年就開始進入程式設計領域，已有超過四十年程式設計經驗的 Jonathan Edwards。Bruce Sterling 認為文中的反省並不只是作為單一程式設計師的反省文，而是整個軟體產業需要一起面對的共業。
摘譯如下：
程式設計因為需要高度的分析能力，常常讓我們陷入一個誤區，為了提高程式設計能力，而不斷讓優秀的程式設計師擁有強大的優越感，自認為高人很多等，特別是相對於平庸的程式設計師，我們都希望盡情炫耀自己的聰明才智，得到同儕的仰慕眼光。但在之後的大半輩子裡，我痛苦的領悟到程式設計的重點在於態度、而非聰明才智。
現實問題的磨難最容易激發出聰明才智的創意靈感，但結果的表象雖然讓人驚喜於充滿創意的解決方案，實際上卻是後續長期維護災難的開端。一個讓人眼睛一亮的程式設計方式，但卻可能深藏著無數的深層炸彈，在日後一一引爆。
而在日後維護過程中，可能我們又會自我優越的認為，只有我才能解決其他平庸者無法解決的精密設計疏失，比如特製的資料庫系統，多線程(multi-threaded)的作業系統。
後來我把整個系統轉移到新框架上，解決掉讓人困擾了二十年的長期維護工作。這痛苦的領悟與經驗讓我瞭解，程式設計不是當最聰明的人，程式設計告訴我的是軟體是如此的複雜，讓全世界最聰明的菁英都顯得微不足道；不要想單靠一己之力解決所有複雜的問題。程式設計的重點在於簡化與慣例。把這句話倒著刺青到你的額頭上，這樣每次看到螢幕中的你都可以提醒自己這項原則。其中最重要的是態度：努力工作、負責任、專注在實際問題，而非未經驗證的猜測。
程式設計其實跟其他的工程與設計不盡相同。其中的主流文化常常陷在前面說的自我感覺良好誤區。就像是格列佛遊記般，只是多了大括號，中括號，縮排位置，要不要加小括號等議題。我們唯一同意的是其他程式設計師有多愚蠢，但我們應該自己試著 Google 一下"愚蠢的程式設計師"，就會看到自己也名列其中。
程式設計技術的提升仰賴於文化的提升，我們能做的就是在自己的工作中耐心、持續的付出、分享交流我們學習到的經驗與心得。
參考文獻：
2010年6月10日 星期四
2009年1月20日 星期二
程式設計的文藝復興
翻譯自：AppTrain: Renaissance Programming
這是一個關於採用 Ruby on Rails, PHP, MATLAB, 以及 Google
Docs 程式設計介面的故事。
文藝復興時期的程式設計師應該可以跨越平台、程式語言的限制寫
出產品所需要的程式。猶如文藝復興時期的建築師般，程式設計師
知道設計寫作程式的重點，就是在於產出程式的整齊、對稱與簡潔
。
當我們在實作 kpozsports 產品時，第一個挑戰就是原始網站是用
PHP寫的。在過去幾年來我都是在 Ruby, Rails 的程式設計開發環
境。我們團隊中的 Jim 是一位優秀的 PHP 程式設計師。我們要如
何在同一個網站中讓 PHP 跟 Ruby 共存？
1) 釐清責任區分
專案計劃中每位開發者都要達成特定的功能目標。完成這些功能性
目標的程式語言只是輔助工具。即使是一家小公司，使用多種工具
完成目標也是很常見的。比如 Rob 是 MATLAB 專家，所有運算集
中的程式碼都是使用 MATLAB 完成。架構網頁前端的程式語言則
是 PHP。這方面我們交給 Jim 完成。Ruby 在整個計劃中則是隨處
可見的，因為他的高藕合特性幾乎可以運用在任何需要系統整合的
專案中。我的主要責任是從多個來源蒐集資料，組織好資料後再傳
送到有 MATLAB 後端運算的 PHP 網站上。
2) 聚集類似的目標與工作任務(內聚)
軟體開發稱這個動作為內聚 cohesion. 本專案中的 Rake 任務是到
網頁上蒐集公開的網頁資料，所需要找的是同一款電玩遊戲的所
有相關網頁資料。剛好我最近都在研究相關的議題，這正好在工
作中派上用場。
3) 保持元件獨立
在專案中我們除了前端 PHP 及其相關的 MATLAB 模組，也架構
另一個 Rails 內部網站，兩個網站雖然互相溝通但實作上相互獨立
，我們稱為 low coupling, 如此一來我們兩邊元件開發可以同時進
行而不造成相互等待的時間浪費，也不會產生過於複雜的溝通系
統。
4) 共同設計
建構一個可用的軟體應用程式需要持續的設計。專案中所有成員
都共同參與設計的工作。我們會把重要的觀念放到線上領域知識
字典，並隨著設計過程增加到網站上。這讓我們對同樣的概念有
相同的詞彙，增加溝通效率。保有共同詞彙讓我們在開發程式的
命名上也更有共識，最後呈現給使用者的介面也會更一致。
5) 不要重造車輪
Don't Repeat Yourself, DRY 原則。The Pragmatic Programmer
裡面寫著：
在同一系統內，每個知識必須要有單一、明確、權威的表示方式。
當資料在資料庫之間傳遞時，必須由具權威代表的資料庫傳遞到備
份資料庫中。我們系統中的權威資料庫是存放在 Rails 框架構成的
網站，所有在 Rails 對資料庫做的修改都會連帶修改其他的備份資
料庫中。固定資料傳遞的方向是為了避免網站架構變得太複雜難以
維護。除了在程式碼中保持 DRY 原則外，整個系統架構上都要記
得同樣的 DRY 原則。
6) 持續的溝通
沒有位在同一辦公室的共同開發者，更是需要積極主動的溝通。在
這個專案中我們每週有兩次共同電話會議。在一星期的開始我們會
討論計劃、策略、戰術，以及任務、與遇到的問題。一星期結束時
則是每個人各自簡報的會議。如此就算有人太忙碌，或是在旅行中
，也都至少可以參與到一次的每週會議。我們私底下也是會常常溝
通，從討論複雜的程式設計議題，到補修統計學，或是共同慶祝喜
愛的橄欖球隊獲勝。
7) 開放的心胸
在 Pragmatic Thinking and Learning 中，Andy Hunt 討論到
神經生成科學 Neurogenesis。與一般坊間聽到的剛好相反，我們的
腦細胞在進入成年以後仍然不斷地產出與生長。在這個專案中我們
接觸到越多陌生的開發環境與工具，就讓我們心智成長、心靈更加
開放。
當 Rob 需要網路上的橄欖球統計資料時，我們利用 Rake 進行這項
工作，並將資料送到 Google Spreadsheet API。另一個 Rake 針對
連結到這個 Spreadsheet 的 PHP 網頁進行更新連結到新
Spreadsheet。
我們系統中已經整合許多不同系統與環境，如果要再新增其他系統
也是輕而易舉。注意我前面提到的這些工具，都是專案成員共同開
發，因此我們同時也都在不同的開發環境中一起成長精進。
在開發網站時，我也會考慮都用 Rails 或是 PHP 進行開發比較好？
結果發現將每個工具用在他最適切的使用需求上才是最好的做法。
這讓我想到文藝復興時代的藝術建築創作，一個熟練多種不同開發
環境與工具的程式設計師。就我個人來說也彷彿經歷一場文藝復興
時期的成長，除了使用的工具與開發環境外，最重要的是產出的軟
體是否符合需求？
相關文章：
C++ 之父 Bjarne Stroustrup 談軟體教育
相關連結：
Renaissance Programming
這是一個關於採用 Ruby on Rails, PHP, MATLAB, 以及 Google
Docs 程式設計介面的故事。
文藝復興時期的程式設計師應該可以跨越平台、程式語言的限制寫
出產品所需要的程式。猶如文藝復興時期的建築師般，程式設計師
知道設計寫作程式的重點，就是在於產出程式的整齊、對稱與簡潔
。
當我們在實作 kpozsports 產品時，第一個挑戰就是原始網站是用
PHP寫的。在過去幾年來我都是在 Ruby, Rails 的程式設計開發環
境。我們團隊中的 Jim 是一位優秀的 PHP 程式設計師。我們要如
何在同一個網站中讓 PHP 跟 Ruby 共存？
1) 釐清責任區分
專案計劃中每位開發者都要達成特定的功能目標。完成這些功能性
目標的程式語言只是輔助工具。即使是一家小公司，使用多種工具
完成目標也是很常見的。比如 Rob 是 MATLAB 專家，所有運算集
中的程式碼都是使用 MATLAB 完成。架構網頁前端的程式語言則
是 PHP。這方面我們交給 Jim 完成。Ruby 在整個計劃中則是隨處
可見的，因為他的高藕合特性幾乎可以運用在任何需要系統整合的
專案中。我的主要責任是從多個來源蒐集資料，組織好資料後再傳
送到有 MATLAB 後端運算的 PHP 網站上。
2) 聚集類似的目標與工作任務(內聚)
軟體開發稱這個動作為內聚 cohesion. 本專案中的 Rake 任務是到
網頁上蒐集公開的網頁資料，所需要找的是同一款電玩遊戲的所
有相關網頁資料。剛好我最近都在研究相關的議題，這正好在工
作中派上用場。
3) 保持元件獨立
在專案中我們除了前端 PHP 及其相關的 MATLAB 模組，也架構
另一個 Rails 內部網站，兩個網站雖然互相溝通但實作上相互獨立
，我們稱為 low coupling, 如此一來我們兩邊元件開發可以同時進
行而不造成相互等待的時間浪費，也不會產生過於複雜的溝通系
統。
4) 共同設計
建構一個可用的軟體應用程式需要持續的設計。專案中所有成員
都共同參與設計的工作。我們會把重要的觀念放到線上領域知識
字典，並隨著設計過程增加到網站上。這讓我們對同樣的概念有
相同的詞彙，增加溝通效率。保有共同詞彙讓我們在開發程式的
命名上也更有共識，最後呈現給使用者的介面也會更一致。
5) 不要重造車輪
Don't Repeat Yourself, DRY 原則。The Pragmatic Programmer
裡面寫著：
在同一系統內，每個知識必須要有單一、明確、權威的表示方式。
當資料在資料庫之間傳遞時，必須由具權威代表的資料庫傳遞到備
份資料庫中。我們系統中的權威資料庫是存放在 Rails 框架構成的
網站，所有在 Rails 對資料庫做的修改都會連帶修改其他的備份資
料庫中。固定資料傳遞的方向是為了避免網站架構變得太複雜難以
維護。除了在程式碼中保持 DRY 原則外，整個系統架構上都要記
得同樣的 DRY 原則。
6) 持續的溝通
沒有位在同一辦公室的共同開發者，更是需要積極主動的溝通。在
這個專案中我們每週有兩次共同電話會議。在一星期的開始我們會
討論計劃、策略、戰術，以及任務、與遇到的問題。一星期結束時
則是每個人各自簡報的會議。如此就算有人太忙碌，或是在旅行中
，也都至少可以參與到一次的每週會議。我們私底下也是會常常溝
通，從討論複雜的程式設計議題，到補修統計學，或是共同慶祝喜
愛的橄欖球隊獲勝。
7) 開放的心胸
在 Pragmatic Thinking and Learning 中，Andy Hunt 討論到
神經生成科學 Neurogenesis。與一般坊間聽到的剛好相反，我們的
腦細胞在進入成年以後仍然不斷地產出與生長。在這個專案中我們
接觸到越多陌生的開發環境與工具，就讓我們心智成長、心靈更加
開放。
當 Rob 需要網路上的橄欖球統計資料時，我們利用 Rake 進行這項
工作，並將資料送到 Google Spreadsheet API。另一個 Rake 針對
連結到這個 Spreadsheet 的 PHP 網頁進行更新連結到新
Spreadsheet。
我們系統中已經整合許多不同系統與環境，如果要再新增其他系統
也是輕而易舉。注意我前面提到的這些工具，都是專案成員共同開
發，因此我們同時也都在不同的開發環境中一起成長精進。
在開發網站時，我也會考慮都用 Rails 或是 PHP 進行開發比較好？
結果發現將每個工具用在他最適切的使用需求上才是最好的做法。
這讓我想到文藝復興時代的藝術建築創作，一個熟練多種不同開發
環境與工具的程式設計師。就我個人來說也彷彿經歷一場文藝復興
時期的成長，除了使用的工具與開發環境外，最重要的是產出的軟
體是否符合需求？
相關文章：
C++ 之父 Bjarne Stroustrup 談軟體教育
相關連結：
Renaissance Programming
訂閱：
文章 (Atom)