Part 1 是一個開發人員要知道的基本知識。chap3 他提到了12點應該要作到的事情，作到了才會得到一個高品質的軟體。我們並不是完全都符合這些條件，但也不是全部都沒作到，例如規格這個部份，我們的產品並沒有一份正式的完整的規格文件，但是在每一次要修改的時候，我們都會確認一次修改的內容，至於規格就是討論出來，比較明確的是UI上要長出來的東西，至於後端的改進，就只能用文字來描述。
我們有用 BugZilla+SVN，搭配著Eclipse的MyLyn使用，整合起來很方便，當產品或專案在發展的過程中，有著BugZilla搭配著問題跟解決狀況，對專案管理來說可以很輕鬆地掌握目前開發的進度跟狀況，也知道每一個PG的生產力與進度，但在產品發展到比較穩定的狀態，沒有很多項目要修改的時候，我們就比較少用到這個東西了。
我們沒有固定的測試人員，通常會讓新進人員充當測試者，既可以讓他熟悉整個產品的功能，也可以因為他還不是開發人員的身份，而更客觀地以使用者的角度來使用跟測試這個軟體。不過當這個開發人員進入專案作為一個開發者的時候，就不能把他當測試者了。這時候，我們會讓公司裡面的美工或其他非此專案的開發人員來充當測試者。總和來說，我們沒有固定的測試人員，但我們在某些特定的時刻，會配置臨時的測試人員。
每日編譯沒有做，但我會每天checkout大家commit進去的東西，並確認隨時都可以編譯，出 Error時就會去問問看，是不是有什麼檔案忘了commit，人總是會掉芝麻粒的。
其他幾個項目，我們沒有作到完美，但都是有的，例如一個步驟建構專案，用SVN，修正問題後再繼續新的程式，安靜的工作環境，但這一點講得有點心虛，因為常常會因為我講電話太大聲，而破壞這個寧靜，不過開發人員通常會用耳機+音樂這種白噪音來解決這個問題。
邊開火邊射擊，這是一個小公司所能擁有的特色，因為小，所以反應要快，轉換要快，內部溝通要順利，人都已經這麼少了，還在內耗，這樣的公司最好盡早離開。軟體技術有一定的更迭週期，隨著大環境的變動，我們就是得要一邊轉換跑道，一邊跟著市場的腳步轉變方向，還得要配合客戶的需求變動，每天都有新的挑戰要做。
因為 Joel 是做套裝軟體的，因此他們必須面對各種使用者的 Windows 環境，也可能會遇到很多當機的狀況，他們就必須要自動化收集當機狀況。我還蠻羨慕可以這樣的，我們的產品都是網頁的App，我不曉得有什麼方法，可以直接收集在使用者的瀏覽器中crash的狀況，通常我們都是到server裡面去看錯誤log，至於網頁上出現的錯誤訊息，都是讓回報人員剪貼畫面，並詢問使用的狀況，來判斷發生錯誤的問題點。
這樣的錯誤收集方法，在有限客戶的狀況還可以處理，但未來如果客戶變多了，或是做了網頁服務，可能就得考慮要有個錯誤收集器，並自動將錯誤回報給Server，但這個方法還是沒有辦法知道，客戶的錯誤畫面出現了什麼東西，應該找個時間研究一下這個問題（Can you take a 「screenshot」 of the page using Canvas?、Take a screenshot of a webpage with javascript?，看來做得到，但for IE only）。
Part 2 提到如何管理開發人員。就一個軟體公司來說，硬體成本非常地低，公司資本額也不需要太多，唯一最需要耗費的，就是人力成本，而且人力是最難被估計跟測量的一個工具，當然也是最難被管理的一項工具。
從 chap 20 提到怎麼面試一個開發人員，對尋找熱情這一點我非常同意，壞人選在面試時跟本部會在意什麼事情，也沒有什麼情緒起伏，因為他們只是要找一份工作而已，沒有其他更深層的想法。至於在面試時直接要求他寫一個function，我曾經想過要套用這個作法，讓面試者可以用電腦查資料，然後利用一段時間寫一隻程式，但目前還沒有這樣試過。
尋找一個有熱情的人，這一點，我們是思考一種方法，要求應徵者做一個15分鐘的短簡報，藉此來判斷這個人有沒有辦法清楚地整理自己的資料，並透過簡報的方式講出來，而不是簡單地用一問一答的方式來處理，其實問答的互動方式，常常會遇到一個狀況，就是應徵者只講了幾句話就講不下去了，短短地回答讓人不知道該如何是好，話越少當然就越難分辨與判斷這個人的優缺點。
關於測試人員的狀況，似乎是個無解的問題，因為軟體開發人員不一定會是一個好的測試人員，測試人員得不厭其煩重複測試的內容與動作，也必須像是雞蛋挑骨頭一樣，找很多特殊的使用狀況來測試一個軟體，而好的測試人員也不一定會一直甘心做QA的工作，公司還得替他們規劃如何轉進到開發單位，要不然這樣一個人才，可能會在一段時間後，滿腔熱血就被消磨殆盡。
而軟體又不是一個可以完全被自動化測試的產品，總會有很多地方，需要用非常原始的人工方法，去做測試，甚至要當一個天真的使用者，去使用這個軟體，才會發現很多問題。軟體的品質對產品來說又是個非常重要的議題，這個無解的難題，相信還會一直困擾著我，揮之不去。
chap 25提到了身為一個軟體開發人員或是公司的生存法則，當展示使用者介面給非開發人員看時，如果畫面不好看，就算內部設計再好也都等於是白做的，因為User一看到這樣的介面就不想用了，怎麼會知道你的產品好或壞。但相反地，如果展示的時候，畫面很好看，他會認為你已經把所有功能都完成了，在這些畫面裡面填上程式碼是非常簡單的工作。
產品demo的時候一定要炫，就Steve Jobs最了這件事情，這樣才能吸引大家的目光。如果畫面還沒完成，就讓他這樣，不要一開始就全部做完，但每一個功能都有缺陷。由非技術人員啟動的專案，在提報資料的時候，必須要提供幾種美術設計讓他選，原因有兩個，第一要讓他們有參與的感覺，並做出決策，第二是不要讓他們深入到設計的細節，甚至更動軟體的內部邏輯，因為這樣的更動可能會變成大災難。
作者的軟體公司以販賣Windows軟體維生，在chap30這個國家的狗做些什麼工作？這一章裡面，他提到一件非常重要的事情，就是要吃自己的狗食，換句話說，就是要使用自己開發的
軟體。當公司裡面的人真正去使用軟體時，才會發現很多使用上設計不良的問題。自己生產的東西，如果連自己用起來都不順利，那麼怎麼能說服客戶花錢去買一個這樣的軟體！
開發人員必須也要是這個軟體的使用者，用了之後，才知道好不好用，才能針對軟體提出更好的設計。用了之後，如果用得很高興，也會對自己的工作更有認同感，做起事情才會更起勁。
在 chap36 Ben and Jerry 模式與 Amazon 模式，Joel 提到了兩種截然不同的商業模式，兩種都有可能會成功，也有可能會失敗，但他提醒大家，要認清自己的定位，而且要堅持下去從一而終，搖擺不定的作法只會虛耗資源。
在 chap 40 開放源碼的經濟學中，他提到為甚麼一些商業公司要支援開放源碼，甚至大力推銷這樣的軟體開發策略，不管如何，開發一個軟體需要耗費成本，一個能讓很多開發者注意甚至無嘗貢獻自己的資源的軟體專案是非常幸運的，多數的開放源碼產品背後都有個商業公司協助支撐整個專案的開發。
這樣的策略就像是一家讓客戶喝啤酒免費的餐廳一樣，客人會因為免費的啤酒，上門消費，因為喝酒而點很多菜，而餐廳就可以靠這些菜餚賺錢。因此，撇開開放源碼藉以推動軟體世界的良性循環來說，單就商業利益的角度來看，在開放源碼的同時，除非有著連帶的附加價值，要不然就沒有必要耗費自己的資源做這些事情。
作者 Joel 的公司是採用 MS 的技術，雖然在 Part4 裡面，對 MS .NET 有著深深地怨念，但似乎也只能摸摸鼻子，就這樣接受 MS 打破過去一直以來的往下相容的策略，而是採用全新的軟體架構。這似乎是一個無解的問題，因為往下相容，導致公司要一直為了舊的錯誤設計多寫很多程式，多做很多例外處理。但是身為作業系統的平台，當 MS 無法以嶄新功能吸引使用者付費升級的同時，只好大破大立地將舊的系統破壞掉，期待以新的架構，吸引使用者的目光，進而付費升級。
雖然 Joel 認為 MS 現在的 .NET 策略錯了，但他也設下伏筆，告訴讀者，因為 MS 本身的現金足夠，可以花好幾年的時間大破大立，就算策略錯誤，因為公司龐大，還是有可能會再將策略轉彎，換句話說，Joel 希望 MS 注意到他對 .NET 所下的註解，而重新檢視公司的發展策略。
《約耳談軟體(Joel on Software)》翻譯計畫
約耳趣談軟體：來自專案管理的現場實錄
約耳趣談軟體 讀後心得
[約耳趣談軟體] 心得筆記：如何決定是否要雇用某人？
沒有留言:
張貼留言