比起寫業務程式碼更不幸的是，主要工作是修 Bug，bug，buG, bUg。

在一家大的公司裡，不同的人總會有不同的運氣：

• 運氣好的人遇上一個好的專案，升職加薪，從此就走上了人生的巔峰。
• 運氣差的人攤上一個差的專案，升不了職，少加了薪，並且還獲得不了技術成長。

我剛畢業那會兒，所在團隊的主要工作是，維護一個『又老又舊』的系統。比起寫業務程式碼更不幸的是，我們的主要工作是修 Bug，bug，buG, bUg。

那一年多裡，儘管都是維護舊系統和少量的新需求，我們還是在飛速的成長~~。而來源主要是：

• 組內技術活動。
• 花時間投入練習。
• 假想專案的重構。

當你在有限的條件下，還能做出一定的成績，到底還是相當有成就感的。

只修 Bug 是怎樣的一種體驗

在這樣的專案裡：

• 工作一個月時，你開啟 Backlog，看看需求卡，發現那張需要三個人天的卡，好像會更有挑戰一些。
• 工作兩個月時：你開啟 Backlog，看看需求卡，發現完成這卡只是時間問題。
• 工作三個月時：你開啟 Backlog，看看需求卡，發現清清楚楚地知道修改哪一行。

有一天，業務人員來了一個新的需求。雖然只是加上一個新的導航，但是你總會小開心一會兒。

可你來到這樣的專案時，你總會想著離開，向自己的 Buddy、PM 、Sponsor 訴說。可惜，你只是一個畢業生，太年輕了。對於你來說有挑戰性的專案，不會考慮要你的。在你的感覺裡，那種『自己是大公司的輪子』的感覺就特別強烈。多你一個不多，少你一個不少。你走了也不會影響這個專案，畢竟招一個人來修 bug，還是蠻輕鬆的。因此，這個專案走了一個又一個技術好的人，卻也來不了一個技術好的人。

時間一久，每個人都充滿了危機感。我們總是擔心：當你換到另外一個專案的時候，別的專案 PM 會考慮你麼——因為你是來自這個沒有挑戰性的專案。這個時候，你已經無路可走了，你必須去提高你自己。

當別人救不了你的時候，你只能自救。當別人救不了你們的時候，你們也只能自救。幸運的是，我們當時還有足夠的時間，可以提高專案組的水平。於是，我們對組織了各種的組內技術分享、workshop、培訓等等。

當你有強烈的改變意識的時候，那麼事件就會變得很簡單。真正可怕的是溫水煮青蛙式的，而當你面對的是溫水，你總會不斷嘗試去離開。

組內技術活動

當你們專案無聊的時候，總會空餘一些時間。上進一點，就會創造一些學習的條件。有了條件，那麼剩下的就是靠人為了。

於是乎，我們在每週挑取了兩個時間，做一些技術的事情。包含了下面的一些內容：

• 技術分享。
• workshop。
• kata。

不同的活動都有不同的目的，有的可以提高演講者的技術能力，有的則是可以一起提升能力。下面就讓我們詳細瞭解一下不同的活動。

技術分享

想必大家都已經知道這個是什麼了~~。當時的情況，大概是我們七個人裡，每週會有兩次技術分享。分享的主題會比較廣泛：

你最近在玩的技術棧。當你們所用的專案技術棧，比較老舊的時候，就想不斷地去嘗試新的技術。在工作之外，便會去玩一些『新鮮』的技術棧（坑）。它就像是一股清流，即使不能幫你清除舊的汙水，也能讓人們看到一絲希望。而且除了能提升團隊的視野，還可以將之視為替換現有架構的探索。

專案相關的技術及業務。在沒有結對程式設計的專案裡，共享知識對於團隊來說是一個頭疼的問題，而技術分享就是最簡單的方式。不過，對於新人來說，讓他們做相關的技術分享才是最好的方式。這也視作為我們對新人的考察：

• 對於專案的瞭解程度
• 找到缺少的相關知識
• 培養新人的表達能力

在專案上，這幾乎是每個新人都會經歷的一個分享~~。

特定主題的技術分享。即，我們限定好一個大的主題，每個人挑選一個特定的主題來分享，它可以人為地提高整個組在某一領域的水平。當時我們做過 SOLID、設計模式、前端相關等特定主題的分享——每個人挑選設計模式中的一個模式，然後做相關的技術分享。當你做分享的時候，你對這模式就比較瞭解；而別人做分享的時候，也能引發你的思考。由於這些主題之間的相關性比較強，它可以加深對這一領域的印象。

其他雜七雜八的內容。過多的技術分享，可能會導致大家精疲力盡，因此就會有一些技術之外的分享。比如，你喜歡的各種動漫啊、知乎上流行的程式設計師女裝啊等等。

而就效果來說，技術分享對於分享者的能力提升比較大，聽眾則是知道有這個東西，啟發性一般都會比較少。如果是針對於提升能力來說，應該採用 workshop 等方式。

workshop

當專案上要採用一個新的技術棧時，僅僅中是一個技術分享是不能解決問題的，你還需要有 workshop 這樣的東西。比如你們將在新的專案裡引入 Next.js，那麼這個時候就需要有一個 Next.js Workshop。由組織者來規劃每一步的內容，第一步做什麼，第二步做什麼，等等。參與者則是單獨或者結對的形式，按照組織者的步驟一步步往下來做相關的技術練習。比如在 workshop 開始前，先 clone 並搭建好基礎程式碼（hello, world）。開始的時候，便是先實現一個簡單的 header，然後是新增樣式等等。

也因此在這樣的 workshop 裡，我們不僅可以聽過相關技術棧的知識，也能掌握一些相關技術棧的具體實踐。

kata

一種程式設計練習方式，針對某個題目反覆進行操練，達到熟能生巧的目的。簡單的來說，就是你一直練習某一個特別的東西，直到你習慣了。比如，對於 TDD（測試驅動開發，先寫測試，並由測試驅動出功能） 的練習。

在平時工作的時候，我們不會總是習慣於 TDD 的流程：測試 -> 實現 -> 重構。特別是，當你的卡就要被打包到新的 Release 包時，先實現總是會保證交付的。又或者是，當你對程式碼庫特別熟悉的時候，你可能兩三分鐘就改完程式碼，然後去喝咖啡，再回來花個十幾分鍾寫一個測試。而當你不熟悉 TDD 的時候，你更不會採用這種方式，你會的可能就是 Test First。為了將 TDD 的思維融入你的想法裡， 你就需要大量的這種練習~~。

在這個時候，我們就需要嚴格的按照步驟，一步步往下執行。以便於在將來，我們可以嚴格的按照這些步驟來執行。

除此，還有一種方式可以做，只是我們沒有在這個專案裡實施。

dojo

dojo，（日語：道場）。在西方世界，dōjō 一詞主要指的是一個專門針對日本武術的訓練場所。在敏捷團隊裡，Dojo 的進行方式比較『詭異』，也比較有意思。

如果你瞭解過結對程式設計的話，可能就會對兩個人的結對過程比較感興趣。按我的理解，結對程式設計存在著三種不同的階段：teaching（引入門），driver-navigator（有經驗與新手），結對（有經驗與有經驗）。即在實現功能的時候，兩個人會輪流寫測試和實現功能——你先寫測試，我實現功能，然後換角色。而 Dojo 就是一堆人在輪流寫程式碼：

即在有限的時間裡，每個人上去實現同一功能的程式碼。

如，A 實現了測試，B 上去實現業務，C 上來重構。D 上來看了看，你們寫的程式碼都是 xx，於是 Revert 之前寫的程式碼。可惜 D 的時間也只有七分鐘，所以 E 上來 Revert Revert。。。

笑~~

花時間投入練習

限於之前已經有相當多的文章，介紹練習相關的技巧，如：

假想專案的重構

哈哈，如果你覺得你的專案技術棧老舊，那麼你一定在腦子裡使用了 N 種技術棧，對他們進行重構了。並且當你有一些時間可以分配到上面，如下班前的一個小時時間，又或者黑客馬拉松等等。那麼，你一定會開始去做這樣的事。

與上面的技術活動相比，這是一個對於業務（我的意思是，對於公司來說）更有價值，並且更容易說服別人的方式。

1. 學習別的專案的技術棧，然後將之應用到現有的系統上。
2. 使用一個新的技術棧練習， 以此作為技術支撐，在未來替換現有的系統。

由於我們與其他專案大組的業務是相似的，並且他們的團隊規模差不多是我們的 10 倍。當某個新的應用完成後，我們要做的便是：fork from xx，將改吧改吧，應用到我們現有的模式上。這個時候就有問題了，一般這些新的專案都會採用最新的技術棧。在正式引入專案之前，我們都是要學習這些技能，並配合業務做一些修改。也因此，我習慣性的將這種專案視為修改 bug、bUg、Bug。

後來，我們突然有機會彎道超車了，我們可以先重構某一部分系統。『因為已經做好相關的技術積累，並沒有遇上一些太大的問題』。只是我們實施一半的時候，就發生了一些意外。後來的後來，這個專案“到期結束”了

現在是 2017 年，當你的專案還在使用舊的 jQuery + Backbone，又或者是 Angular 1.x。並且你們覺得他們有一些問題，這些問題採用一些新的框架，如 Angular 2，又或者是 React 能解決這個問題的話。這個時候，我們就可以嘗試去學習新的技術棧，並驗證它的可行性。當有一天，你們需要去重構現有系統的時候，你拿出的直接是一個可行性的 Demo，而不僅僅是一個理論上的東西。

當時我們的專案想替換掉舊的搜尋引擎，我們先是用 Solr 實現了一遍 DEMO，又用 ElasticSearch 做了一遍 DEMO。同時，我們也在計劃替換應用部分的功能，我們先用 React 實現了一遍 DEMO，又嘗試用生態純靜態的方式玩了一遍。。。生命可貴，可以多玩就多玩一些吧。

小結

所以，你是因為加班呢，還是因為加班，才沒有時間學習？？？