“老大”是我很要好的一個朋友，也是一個對於我的職業發展產生過很大影響的一個朋友。上個週末去了千島湖，順便給“老大”帶了一些枇杷，在送枇杷過去時和他好好地聊了聊。
 
我們倆在軟體行業做了都有近十年的時間，分別在全球知名的兩個通訊公司工作。在這之前，我倆是UTStarcom的同事，工作在同一個專案組。“老大”現在是公司的一名Manager（“老大”更喜歡Leadership這個詞與“老大”一起談軟體行業），而我是公司的一名Architect。
 
我倆的談話總是以“最近怎麼樣”開始的，而我這次與他談到了對於現在所在公司的前景的擔憂。一方面公司在WiMAX上面並沒有達到期望的結果，另一方面，覺得通訊公司在軟體的開發方面並沒有很深的積累，不少開發方法還是“作坊式”的。當然，這裡說到的深是相對的，是相對於那種以軟體開發為本的公司，如Microsoft，等。對於“通訊公司在軟體的開發方面並沒有很深的積累”這一點，“老大”與我有相同的看法。比如，現在的通訊公司大量採用的都是C，除了據我所知Nortel在採用C++和OO開發接入網這一塊很有經驗。OOP毫無疑問是一個能使應用問題得到更好解決的一種開發方法，當然，要真正的駕馭OO，對於開發人員的要求的確是更加的高。在Cockburn的《OO專案求生法則》中對關於OO開發的風險有很好的闡述，但我想歸根到底還是人的問題。
 
我們談到了專案的管理。“老大”提到他現在所做的專案當中有一部分的程式碼質量非常的差，只有通過重寫才能解決問題，但“老大”的老大的老大似乎並不知道應當讓大家這樣去做，而是一味的強調“測試！測試！再測試！”。對於這一點，我談了我的看法“說到底是相關人員其實並不瞭解軟體”。雖然，這些人也在軟體行業有八年仍至於十年以上了，但他（她）並沒有真正的掌握軟體行業的特點，主要存在以下幾方面的問題：
 
1）很多Manager在做Management以前都是技術出身，由於做技術期間沒有在軟體技術上有很深的積累，在做management時，當別人提出一種的確行之有效的方法時，就沒有能力去判斷是否從長遠來看有利於自己的團隊和產品，只相信那些能產生一定的資料的方法（比如，程式碼覆蓋率）。在與“老大”談時，我們打了一個比方：比如，我們建了一座樓，如果這座樓的根基是好的，那麼我們可以通過Refactor來“每次裝修一個房間”，從而達到最後的“量變產生質變”的效果，在這種情況下，我們可以採用加強測試（如UT – Unit Test）來配合我們的Refactor；反之，如果這座樓的根基有問題，那“每次裝修一個房間”能解決問題嗎？此時，我想Restructure是更好的一個選擇。當然，由於這些人並不明白這些道理，於是使勁的去做UT，那結果一定是：苦了工程師（沒錢沒生活）又害了產品（失去了重生的機會和使用者）。針對這種情況，Manager是應當鼓勵restructure呢？還是小的Refactor？Manager真的需要知道嗎？還是可以通過向相關的人問一問，怎樣做更好。問誰？專家？不。一線工程師會告訴你答案。當然，我們談話中也持同一觀點：如果一個功能模組很爛，但並不經常出問題，或說是不佔用大量的資源，在這種情況下即使是根基有問題，我們也不應當馬上去Restructure它。“老大”將根基不好的軟體比喻成“軟體黑哃”，很有新意！
 
2）不相信團隊。不相信團隊能通過採用新的方法從而改變現狀。我想很多的Manager在嘴上說“我相信我的團隊”，而內心裡其實是不相信團隊。為什麼呢？其中，有一部分原因是他（她）自己從來就沒有通過技術的變化而成功的改變現狀的成功經歷，因此，對於他（她）來說同意採用新方法就是一次“大冒險”。
 
3）不願意承擔責任和風險。這些人往往Offer都不錯，他（她）沒有必要讓自己去take risk，從而影響自己的“前（錢）途”。這其實是1）和2）所帶來的行為結果。
 
4）只關心自己。有些Manager只關心自己，並不關心自己的團隊以及自己所負責的產品。至於，團隊是否有太多的Overtime，或是士氣低下等等，一概視而不見，更不用說產品的未來了。
 
後來，我們也談到了開發方法，如Agile，SCRUM等等。我的觀點是：開發方法的出發點是好的，而且，很多方法的確是行之有效的，但關鍵在於我們在運用這些開發方法時，有時會“走火入魔”。在很多情況下，如果我們不能很好的把握運用這些方法的時機和分寸，那隻能出現以下結果。
 
1）採用了方法論後，發現團隊更忙了，但是產出卻是更低了，質量也沒有得到改善。進而
 
2）宣告這種方法無效。
 
其實，軟體行業一直以來就有很多行之有效的方法（但不是終級方法，別忘了No silver bullet!），只是，我們不能很好的去實踐和把握運用它們的時機和分寸。比如，現在很多軟體開發方法都鼓勵UT，但是UT這一概念是在30年前提出的。我們的從業人員對於UT真的有足夠的認識和切身的體會嗎？除了UT，自動化測試也是很好的一種方法，但我們的測試人員真的覺得它重要嗎？
 
在很多的軟體書籍中都提到了人的重要性，但軟體行業真的是這麼認為的嗎？從現在狀況來看，我相信這一觀念還沒有深入到從業人員的骨髓中。甚至，不少人還用管理生產的方式來管理軟體產品。在《從優秀到卓越》這一書中，作者指出其研究結果顯示：先人後事！即先找到合適的人然後再想要做什麼。雖然，這書不是針對軟體行業的，但我想無論什麼行業，其有些共性是相同的。我想“先人後事”在所有行業都通用。