我們的開發哲學：合作和測試
有大量的書籍討論編程語言和框架，但很少有資源討論像「測試和合作」這樣的話題。然而在大型工程中，這些話題能夠輕易地使你的團隊取得成功或失敗。
我們從無數的實踐經驗中認識到這些軟技能非常地重要：很多時候項目出錯的原因都是因為缺乏測試和合作。下面是在Tower用戶數目增長至100,000的過程中我們所學習到的一些經驗。
請確保你已經閱讀了這個系列的第一章節：結構、設計模式和編程規約
有的代碼都屬於團隊
代碼是團隊所有，並不是任何一個開發人員的私有物。這也意味著你所寫的任何代碼都不屬於你，而屬於你所在的團隊。用這樣的方式來看待你所寫的代碼是非常有益的，有以下幾點原因：
1、不一定非要按照你的方式進行編碼。在了解代碼始終屬於團隊後，理所當然地我們需要遵守一定的編碼標準和規則。既然它不屬於你，你不能肆意地按照你喜歡地方式去進行編寫。你所寫的代碼是通用的代碼庫，所以必須遵守一些通用的規則。這也能夠讓你在看同事的代碼時更加寬容，你可能本能地想到你會以不同的方式完成他們的工作。 但是，請記住所有代碼的編寫需要遵守的是團隊的方式而不是你自己的方式，這可以幫助你更加開放地理解其他解決方案和方法。
2、一切都是你的問題。當你在代碼中發現問題時，是不是你的錯誤一點都不重要。因為項目的所有代碼都屬於團隊，並且你是團隊的一員，任何來源的有缺陷的代碼都成為你的問題。如果團隊中的每個人都秉持著「這不是我的問題」的態度，那麼這個團隊永遠也不會開發出優秀的產品。
3、你，你，你。我從opbeat公司的Ron Cohen在一次會議上的演講中了解到這一點。這簡單地提醒了我們作為軟體開發者的責任：你有責任編寫代碼。同時，你還負責使其運用於生產中。當然，你有責任解決它的任何問題。在我們自己的團隊中，我們沒有專門的質量保證團隊，這提醒我們開發人員不僅要負責編寫代碼，還要負責編寫出的代碼的質量。這個責任不是你可以逃脫或交給其他人的。
分享關於代碼審查的知識
代碼審查有助於提升團隊的代碼質量。首先，多個人在相同的代碼上進行檢查，能夠提供更多更好的解決方案，將有機會產出更高質量的代碼。其次，代碼審查有助於團隊的人對所有代碼進行了解。例如，當只有一名開發人員指導某段代碼時，就會存在一定的風險。每當這位開發人員休假、生病甚至離開公司時，團隊都將遇到麻煩。即使沒有這些情況發生，這也說明你的團隊沒有真正的實現共享代碼庫。此外，代碼審查有助於促進團隊內部的知識交流，提升團隊的整體開發水平，因為初級開發人員可以從交流中向高級開發人員學習。高級開發人員也應該意識到在指導初級開發人員時他們也能夠學習到新的事物。
並不是所有的都需要改善
你可以認為程序中的所有一切都可以改進，但重點不是什麼可以改進而是什麼值得改進。我們知道自己的產品存在弱點，如果時間是無限的，我們可能會改進每一點。但隨著時間成為任何團隊的稀缺資源，我們不得不設定優先順序。如果你不這樣做，你的產品將不會朝向你想要的方向發展，甚至可能根本就沒有任何方向。
能夠負責任地思考是否真的去改善某件事情是一門藝術，這需要多年的經驗，而且最好的情況是，經過有意識的培訓。對許多事情說不，是獲得任何有價值的先決條件，這個道理同樣適用於軟體開發。
進行提問
在閱讀其他人的代碼時，很容有就在頭腦中假設你會做得更好。在第一次閱讀時，你可能認為這行或那行代碼似乎不需要如此複雜，甚至是多餘的。你也許是對的，但很難說，因為你實際上並沒有編寫代碼。
根據我們自己的經驗，我們知道即使是最簡單的問題也可能包含令人驚訝且無限的複雜性。 只有在實際解決問題的時候（考慮可能的解決方案，副作用等）才能充分地理解它。
因此，當遇到一段讓你懷疑的代碼時，假設大量隱藏的複雜性是一個很好的基本規則。從這個角度來看，你可以深入了解代碼並嘗試理解它以及潛在的問題——或者您只需與隊友進行對話並詢問一些簡單的問題。
只有經過測試的軟體才完整
單元測試有時被認為是錦上添花。然而，我們的確需要在開發過程中進行單元測試。在較小的項目中，您可能不用編寫單元測試。然而，在任何甚至只有少量複雜性的項目中，你都應該進行單元測試。很多工程，起初看似非常簡單，但後面將發展的越來越複雜。
單元測試對我們至關重要的確有許多原因：
1、測試使我們能夠安全並快速地完成大的代碼改變。在每一個大型的項目中，你不得不在一些時候完成一些重構。但是在重構的過程中，如果沒有一定數量的單元測試將會帶來非常糟糕的體驗：在修復一些問題的時候常常不可避免地會破壞另一些地方的代碼，如果擁有足夠多的單元測試那麼你就能夠容易地知道哪裡出現了問題。
2、我們可以很自信地向外部發布項目。如果你的應用需要提供給付費用戶使用，如果你沒有足夠多的單元測試，那麼在每次將代碼提供給用戶使用時你總是會充滿擔心。
3、測試使我們可以獲得更優秀的代碼。進行良好的測試是最終獲得優秀項目代碼的最好的前置條件，因為測試能夠幫助你更好地理解你所解決的問題，並幫助你創造簡單的、模塊化的代碼
4、測試能幫助我們及時更新文獻。在一個理想的世界中，應用中的每一個部分都應該記錄在文檔中。我們希望擁有一份簡潔、格式漂亮、易於閱讀的文檔，並且最為重要的是當我們每次更改代碼的時候我們都希望文檔能夠及時的更新，當然這是非常理想化的。但是使用單元測試可以到達這個目的，雖然形成的文檔不像專門的文檔那麼專業化，但是至少保證了文檔能夠反映當前的項目狀況。單元測試能夠成為一個非常有價值和可靠的文檔來源。
對於大型項目來說，對重要部分代碼進行充分的測試是非常重要的。它使我們在發布應用程序的時候能夠非常自信，並且我們總是能夠安全、快速地對代碼進行更改。
測試能夠加快開發的速度
起初，你可能會認為測試驅動的開發似乎非常消耗時間，會降低你的開發進程，並且編寫單元測試的確需要花費一定的時間。但是隨著時間的推進，你會發現編寫單元測試能夠加快你的開發！你可能會花費更少的時間來編寫實現代碼，因為在你寫單元測試的時候你應經完成了大量的工作。另一個好處是：當代碼需要發生改變時能夠降低破壞現有代碼的可能性。你將能夠節省無數原本會花在查找和修復bug的時間，然後你就能夠用這些時間做更多有用的事情。
通過測試修復問題
修復bug和編寫測試應該是密不可分，當然你可以僅跟蹤bug並簡單地修復代碼。然而，我想你應該對「回歸」這個詞很熟悉：你確定已經修復的bug再次出現在你面前。如果你想要確保bug的確被修復了，那最好的辦法就是編寫測試代碼來確保。
測試低層次的組件
當開發一個每天都有超過100,000人使用的軟體產品時，我們總能夠從中學到很多經驗教訓。一方面，我們明白錯誤是無法避免的，尤其是像Tower這樣的產品，需要處理複雜的系統初始化過程，你不能夠控制所有的事情。但另一方面，我們知道哪裡發生的錯誤最多。 在Tower（很可能在許多其他較大的應用程序中），大多數錯誤往往發生在低級別組件中。但比較好的是，這種組件非常適合單元測試。在這個領域，測試驅動的方法提供了一個巨大的機會——通過合理地測試低級組件，以合理的投資來提高應用程序的整體穩定性和質量。
有效測試
通常，儘可能使單元測試覆蓋你的代碼是非常可取的做法。然而，當你聽到一個軟體開發人員吹噓他的「100%測試覆蓋率」，你應該小心。聽起來我們似乎應該測試程序的每一行代碼，但是實際上並不是這樣。
一方面，我們需要花費無限的時間來確保100%的測試覆蓋率。然而，更重要的是我們不必要編寫太多的單元測試，尤其當你進行重構時，你不僅要維護你的代碼，還要維護測試代碼。當你的代碼改變時，你也必須要更改你的測試 關鍵的標準是——測試能給你帶來價值嗎？通常，如果只是測試很簡單的邏輯那麼測試所能夠提供的價值就非常小。在這些情況下，測試所帶來的價值就遠小於維護它所花費的精力。編寫有效的測試也即意味著盡量編寫少的但價值高的測試，而不是編寫一堆價值較低的測試代碼。
僅測試，不要運行！
在你的應用程序中手動地進行測試需要花費大量的時間：你必須啟動應用，跳轉到特定的頁面，然後執行相應的操作來進行測試。然而編寫單元測試只在最初的時候需要花費一些時間，之後的多次測試將會非常容易。僅運行單元測試將比啟動整個應用進行手工測試要快的多。除了速度快之外，測試也能夠提供高質量和穩定的測試結果，在大多數情況下，前期所投入的時間是完全值得的。
來源於網路
TAG:大開科技 |