2015年2月27日 星期五

人月神話

這本書其實有點老舊了,舉的例子都老到不行,不過讀起來還是覺得相當中肯。

我覺得凡是在開發軟體的開發者,管軟體開發的管理者,開軟體公司的老闆,都可以從這本書裡獲益;總括來說,開發軟體跟開發軟體系統,是完全不同的問題,前者是技術,關係的是個人工程師的熟練度;後者卻是管理,關係的是一群工程師如何溝通。

簡單的軟體大部分的軟體工程師都能寫出來,但,軟體系統需要在不同平台上測試過、需要完整的文件說明、需要讓內藏的錯誤儘可能的被找出來,這當中的工夫是以倍數在算的;如果算上每個工程師間的溝通成本,缺乏管理能讓大型團隊一事無成,這也是本書名的來由:「人月」並不是衡量軟體系統開發難度的好指標,我們都知道一個工程師寫一個月和三十個工程師寫一天,所能得到的東西是完全不一樣的。

每一章,作者都針對一個軟體系統開發的管理要訣進行說明:如何組成有效率的團隊、架構設計師的重要、團隊要如何溝通、文件怎麼管理……。可以算是作者在大型系統開發打滾多年之後總結出來的武功祕籍,一步步讀來,除了吸取作者字字珠璣的告誡,也讚嘆作者在那電腦還是珍貴資源的年代,就能完成如此大型的系統開發,網路上也有不少人整理出書中的重點,可見Heresy blog,有第一到十二章的整理(我也很好奇為啥十二章之後就沒整理了lol):
https://kheresy.wordpress.com/2011/03/22/the_mathical_man_month_p1/
https://kheresy.wordpress.com/2011/03/25/the_mathical_man_month_p2/
https://kheresy.wordpress.com/2011/04/01/the_mathical_man_month_p3/

本書的第十六章是一個頗具話題性的章節:沒有銀彈

這裡的銀彈不是指金錢,而是指在對付可怕的狼人(軟體系統專案)時,大家總希望可以出現神奇的銀彈可以讓狼人一槍斃命,但作者認為:沒有,這世界上就是沒有銀彈,沒有任何突破能讓軟體系統的生產力大幅提升一個數量級;想要弄好一個軟體系統,好好規劃、實行才是正途,就像想要對付狼人,好好改造、把它萌化才是正途

作者的論點是,因為軟體就是如此複雜的工作,現在的進步例如引入高階語言、物件導向、分時(time-sharing)、人工智慧等等,都只是處理軟體附屬上的困難,沒有直指本質的複雜核心,當附屬的困難被解決了,本質的困難仍未解決,人們在創作、溝通、理解軟體上,仍然有著無法解決的本質困難,而附屬困難並佔不到軟體開發的9/10以上。

詳細內容可見:
http://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9

我個人的看法是沒這麼悲觀,以十年來看,軟體開發也許沒有十倍進步,但長久看下來,我們的軟體生產力仍然進步神速。

現今的高階語言,也許可以用C++的standard library 為濫觴,為常用的複雜架構定下一個標準,現在要寫出複雜結構的程式碼遠比過去容易,也更不容易出錯;安全、多執行緒方面,新一代的高階語言如AZ大神推薦的Golang,最近在研究的Rust等,都針對這方面進行了補強。直譯式語言讓原型(prototype)建立更容易,展示程式概念也更加輕鬆寫意,在各種平台上也能有同樣的表現。

對測試、自動化產生code 都有更好的支援,servo用python 去剖析規格文件,自動產生出幾萬行的程式碼;網路提供的服務,例如issue tracker, git, CI測試、文件控管,林林總總的服務,程式碼的生產、測試、管控遠比過去強大得多。

十年也許太短,把「沒有銀彈」的尺度拉開,軟體本質的複雜性問題仍然被解決中,隨著軟體解決問題的能力不斷上升,我個人樂觀的覺得,我們生產軟體系統的生產力,仍然有超過一個數量級的提升。

--

引用本書開頭的一段文字,大意是這樣的:雖然程式設計師很辛苦,要不斷在軟體系統的焦油坑裡掙扎,永遠解不完的bugs,被客戶刁難,被上司責怪;但軟體還是有光明的一面,把腦中想像的東西實作出來的成就,解決問題的快意。儘管走在軟體的路上有苦有樂,總的來說,樂趣還是多於苦難。

儘管前途崎嶇,崎嶇的路上,我們還是會笑著走過去。

一本讓我頗有共鳴的書,推薦給所有正在焦油坑裡掙扎的軟體開發者們(喂)。

2015年2月25日 星期三

Rust struct, impl, trait

前言:最近被強者我同學呂行大神拉去寫Servo (https://github.com/servo/servo)
用的語言是Rust(http://www.rust-lang.org/),是個非常年輕的語言(2012年出現),另外有一個老一點的Golang(2009),基本上目前中文找不到什麼資料,就算是英文的文件本身也不太完整Orz

想說文件這種東西,只要不是亂寫愈多愈好,就在這個blog 上寫一點Rust 相關的文件,等寫多了好整理起來;基本的rust 像什麼函式怎麼宣告、if 格式之類我就不寫了,那個自己翻一翻就會了。

我出身是C/C++, Python,所以解釋角度也比較偏這樣的語言。

--

這篇介紹Rust裡的集合物件: Struct, impl 跟trait

struct在rust 裡跟C++/Python的class一樣,是物件的集合跟函式的集合,不過rust 採取的方式是用 struct A / impl A的方式,把集合的物件跟函式分開。

所以在Rust 裡很常看到這樣的寫法:
struct Car
{
   Speed: int  
}  
   
impl Car {  
  fn run(&self){  
    println!(“my speed is {:d}”, self.Speed);  
  }  
}  

一個struct 比較像C裡的struct,補上impl 就變成C++裡面的Struct/Class

同時如果我們要提供一個共同的介面(interface)呢?例如我要Car跟People都實作run 這個函式,在Rust 裡這東西可以用trait 來實作,首先先實作trait,然後就可以對struct實作trait,這東西很像java 裡面的,例如:
trait movable {  
  pub fn run(&self);  
}
  
impl movable for Car{  
  fn run(&self){  
    println!(“my speed is {:d}”, self.Speed);  
  }  
 }  
之後就可以明目張膽(?)的呼叫Car.run()了

更多內容請見:
http://rustbyexample.com/trait.html
http://tomlee.co/2013/05/traits-structs-and-impls-in-rust/

2015年2月12日 星期四

用youtube開Hangout直播

最近看到watch people coding 這個網站,也真有不少人在上面開實況寫code,覺得滿有趣的,也應該自己來開個實況試試。 目前開實況知名的有Twitch ,這方面有點難搞,目前linux 沒有這方面完整的解決方案,只能用一些程式來解決,相關網址在此: https://wiki.archlinux.org/index.php/Streaming_using_twitch.tv
不過我沒有twitch 帳號,懶得申請;帳號多開一個是一個麻煩

所幸我們有另一個解決方案:用Youtube開直播。
在youtube 右上角自己大頭貼的地方,可以進到「創作者工作室」,影片管理員內就有「現場直播」可以開,不過它要跟手機連線驗證,等於是告訴google 你的手機號碼,大家連結前請多想三分鐘;打開後它會直接用google hangout 開直播,不用特別裝其他程式。

打開後大概會長這樣:

左列有一些工具可以選,例如螢幕分享,可以指定某一個視窗做為直播的內容,例如直播寫code用的終端機或者你的webcam,目前看起來沒有混成螢幕的功能,也就是不能像其他直播一樣,畫面上還會有一個webcam 的影像;也可以開右邊的訊息視窗,不過那個跟youtube 直播頁面上的訊息沒有同步。
按開始播送後就會開始直播了。

不過我覺得直播寫code 本身就有一個問題,直播遊戲的時候,遊戲是比較簡單的東西,今天打東方是躲子彈,明天打東方也是躲子彈,看直播可能可以看一些閃躲的技術;可是寫程式不是,中途插進去的話會不知道那個人是在寫什麼,直播也很難表示出設計師在背後的架構設計,設計概念,很容易變成看一個人在打字,那樣的話直播寫程式一點意義也沒有。