半步踏入專業的大門（逃

半步踏入專業的大門（逃

這兩週看了《代碼整潔之道》（其實這本書並非具體教你怎麼寫代碼的，而是教你怎麼成爲一個專業的開發），感受不少東西確實說的頗有道理，我也正在逐漸去落實。下面我就挑選了一些我認爲咱們團隊的開發所欠缺的一些素養，融合我本身的一些觀點、經從來提取一些建議。

態度

不要忽略任何一個問題的（bug, 缺陷，設計不合理......）地方

印象很深入的就是，你們老是說：

• 「我知道個人代碼寫的很爛」

• 「這裏只能怎麼怎麼樣，不能怎麼怎麼樣」。

• 「當這裏怎麼樣的時候，可能會出問題」

• ...

一我的是很基本不可能寫出完美的程序的。可是，一個基本的素養就在於，一旦知道這個地方是有問題的，就立刻去改。這個時候多花的時間要遠遠比你出問題來再來修復要來的快（同時也有價值）。舉個例子，當時我在開發亮燈的時候，項目推動的比較急，同時對工具不熟悉。我選擇了徹底過程式的寫死了全部的接口。當時我也知道這樣作不對，可是就放過了這個問題。然而，問題就像滾雪球同樣，越滾越大，以致於後來，我本身的不能很好的理解本身的程序，每加一個功能都舉步維艱。那個時候真的是很是黑暗的一段日子。所以，只要你知道你的程序在哪一個地方不合理，就應該儘快的去修正他。

瞭解本身的領域（工做領域，業務領域）

在團隊，可能作技術的（我一直認爲，產品，設計，運營也算是技術，只是技術點，技術形式不同）大多有一個誤區：衡量一個作技術的人是否專業，就在於他的專業知識學習的量。不是這樣的。技術是多個維度的。作東西是，他既須要瞭解本身的工做領域（就是從事方向的知識，好比開發就包括算法，設計模式等），也須要了解本身的業務領域。若是是編寫招新的篩選系統，你就應該對整個招新的流程，面試官須要什麼，報名的人須要什麼進行了解；若是是編寫寫做的程序，你就應該去了解每一個做家的習慣，行業的標準。最不專業的作法就是對着原型，原型說明文檔寫程序，卻對裏面爲何是這樣不求甚解。相反，你應該能辨別，質疑規格說明書。瞭解業務領域還有一個好處就是，你對將來會有必定的預見性，你可能會有意識的往某些方面留個後手，用於擴展。

說 「不」 與 「是」

咱們在團隊作東西的時候常常會面臨說「不」和說「是」的狀況。

• 「你能不能在這周完成某個功能」

• 「這個項目能不能在何時上線上線」

• 「你能不能在某個時間點以前把圖出完」

• 「你能不能在何時把粉絲數增到多少」

• ....

基本上在作項目的時候咱們無時無刻的都會面臨這個問題

本身是否真的盡全力了

每當我被人問及，「你爲何不能再某個時間點完成這個任務」的時候，我真的都會去思考，我究竟是不是盡全力了，仍是我真的花費了不少時間來墮落。我我的人爲，若是沒有進全力去作一件事，是沒有資格去說「不」的。不然，至少你的心裏要生出一絲愧疚感，這纔是正常的。

能不能 與 試一試

你們都是人，人性都是有弱點的：咱們你們老是會趨向於護住面子，避免承擔責任或是避免衝突。當你說出試試的時候，意思你以前的想法並無盡本身的全力，你還有額外的精力去作；抑或有新的方案。若是你沒有額外的經歷，又沒有新的方案，那說試一試的時候你是否是就是爲了本身能作完也是對的，不能作完也是對的？這本質上也是不誠實的表現。同時回憶，本身有沒有說過「我是該作什麼事情了」，「我但願作什麼事情了」這樣的話。而後最終結果是怎麼樣的？

當你說是的時候，必須是

• 口頭上說會作

• 內心認真對待作出的承諾

• 真正行動

我以爲一個專業的人，他會說」我將在何時完成什麼事「。當你說出一句肯定的許諾的時候，就會認真的對待本身要作的事情。

堅守原則

當你進了全力的時候，若是是不能完成的，這個時候就應該堅決的說」不「。同時，對於ddl的問題，我我的認爲，若是真的是爲了整個team好，是不該該爲了ddl而放棄一些原則的。好比說，你不該該由於趕時間就不作測試；你不該該由於趕時間就選擇放棄良好的設計，而去堆代碼。

尋找編程的狀態

規律的工做時間

有一些很差的現象就在於，炫耀本身熬了多少夜，把本身的晚睡做爲一種榮耀，這是一種畸形的行爲。要想爲何會讓本身熬夜，是否是由於本身在精神狀態好的時候時間沒充分利用（這個時候去熬夜還算態度端正....）。事實上，你真的相信本身半夜精神狀態不佳的狀況下寫出來的程序嗎？也許，你這個時候搞出來的東西，會成爲你往後的夢魘。

避免心流和阻塞

不知道你們有沒有過這種感受：有時候你會進入一種很是玄妙的狀態，感受本身寫程序效率超高，沉迷於編程不能自拔。你會不會感受這很爽？其實事實上這並不必定是一件好事。由於大多數狀況下，你在這種狀態是的目光是很是狹窄的，你並不能站在一個很是全局的角度其思考，去設計。我就有過這樣的經歷，在寫尋她這個項目的時候，寫了一大堆以後發現和我原來的設計是衝突的....

和心流相對應的一種狀態就是堵塞。有時候會有這麼一種感受，你怎麼也不想寫程序了，或者說怎麼樣都寫不出程序了。

感受解決心流和堵塞的方式就是：找我的和你一塊兒結對編程。大家一塊兒寫程序的時候，可能時不時的會交流一下，遇到問題相互解決一下。這實際上就是一箇中斷的過程，中斷了進入心流。同時，不知道你們有沒有這種體驗，和別人一塊兒幹活的時候，本身也會想着去作事情。若是結對不能解決你的問題，不妨暫時離開，出去走走。

壓力，焦慮

以前程序組有位新人和我說：我最近又要考試，又要作任務，感受真的什麼都作很差，以爲十分焦慮。對於這種狀況，我以爲比較好的就是，能夠找我的溝通，尋求一些支援；同時要把有限的時間真正規劃好，在作事情的時候就不要想別的了，畢竟焦慮也沒用是吧。同時就是，即便時間緊，也要堅持本身的原則，危機中也要有紀律。由於紀律之因此爲紀律，就是幫助你度過難關的。

思考的習慣，時機

你們在寫程序的時候，有時候會遇到一些問題不能解決。這個時候你會怎麼辦？一直盯着你的顯示器硬槓？我以爲，平時要適度的知道何時本身應該離開一下。同時，本身平時也要養成思考的習慣。我本身就曾經在自行車上，在洗澡的時候解決過很多問題。平時能夠培養出一種節奏。

互助

當你遇到一個問題死槓槓不出來的時候，感受是時候去詢問一下別人的見解。我知道程序員都比較悶騷，都喜歡本身獨立去解決問題。這是咱們的優勢，也是咱們的弱點，沒有絕對正確的事情，把握好平衡，該和別人交流時候就交流。評判一個東西是否學通，再也不與你本身是否是以爲本身懂了，在於能不能用本身的話，邏輯清楚的把他講明白，同時聽的人也能聽明白。因此，諮詢的時候，不管是對己，仍是對人，都是有好處的。

Kata

卡塔就是當你天天開始編程的時候，都花個10分鐘左右，用你但願熟悉的語言，寫一個你已經知道怎麼解決了得問題。這個稱之爲變成柔道場。這不是爲了真正解決問題，而是在於練習你須要解決這個問題所須要的動做和決策。叫編程柔道場的緣由就在於，柔道就是爲了訓練你能在真正須要的時候不須要思考就能出招。我最近的一個星期就以快排做爲個人卡塔，目前能在2分鐘內寫出一個正確的快排。

下面是一些收集了各類卡塔的網站，裏面都是你們喜歡用的卡塔

http://codingdojo.org/

http://katas.softwarecraftsma...

http://codekata.pragprog.com/

測試驅動開發

這個我推薦老人去試試，不推薦新人去試（由於可能你再也寫不出程序了....）。

相信你們已經很久沒經歷過之前那種，寫幾行程序，而後就能編譯，鏈接，運行看到結果那種欣喜的感受了。目前的狀態時你可能會寫出好大一坨代碼。而後最後去試試他能不能跑通。這樣一個很差的點在於你的測試數據並不嫩敢保證測試到全部的模塊。

我就有這種感受：一個項目寫完，程序跑通。可是，我仍是很是擔憂我寫的不夠完整，邏輯不夠嚴密，可能隨時會掛。

測試驅動開發就是你在每寫一段小程序以前，先寫他的測試程序，而後寫好以後立刻測試。這樣的一個週期在十幾分鍾。測試驅動開發的好處在於：

• 可以讓你的程序設計更良好。由於，你要作到一個小東西他是可測試的，你就會想着讓他的耦合度下降，可以拿出來單獨測試

• 中斷心流。實際上一次測試就是一箇中斷，若是沒經過，就要回去修，直到經過了測試

• 總體上縮短期。自動化測試的好處在於，你加入了一個新模塊後，若是不肯定會不會破壞掉之前的模塊，就跑下測試就行了。由於原來的測試程序都在

• 反饋及時而細緻。經過單元測試，你能立刻定位到，程序是那個模塊出了問題。

• 文檔。事實上，你的測試就是你的文檔。

學習

時間拆分（番茄工做法）

比較理想的狀態是，手頭上有一個項目。這樣就能很好的平衡項目和學習的時間。一個好的作法是把任務都按時間拆分紅多個時間段吧。能夠參考番茄工做法

避免鑽死

這個已經在上面提到過了

多樣性

一我的只有一個技術是比較難活下去的，能夠多嘗試不一樣的東西。好比你原來是寫Java這樣的靜態語言，你就能夠試試Python這樣的動態語言；若是原來是用IDE的，不妨試試用文本編輯器，而後本身編譯，運行，調試；若是平時習慣用圖形界面，不妨去體驗一下命令行的威力.....

多給別人看本身的程序，多看別人的程序

不要由於以爲本身的程序寫的搓就很差意思給別別人看。想一想都知道這樣不是一件好事情。想要進步，仍是要不斷的突破自我吧。多看別人的程序，能看到別人是怎麼考慮問題，怎麼去設計的，吸取別人的一些長處。我基本上...每看一我的的代碼.....寫程序套路都會變一下....

預估

產品通常是沒有這個能力來準確預估一個開發、設計須要多長時間的。當被問及完成一個東西須要多久的時候，你是否是會憑感受立刻說一個數呢？是，預估不少時候是憑感受的。可是，我以爲比較好的作法是，你和他說等一下。而後你就來算一算本身要多久。顯然，一個任務越小，咱們的預估是越準的。因此一個可行的方案就是，你先儘量的把本身的任務拆分紅不少不少的小分，而後每一個都給本身留一個，樂觀時間，標準實際，悲觀時間。而後累加。而後告訴你的產品經理。當你遇到意外超過了你的標準時間，立刻和team裏面的人反饋。來作計劃修正。

結語

以上都是《代碼整潔之道》的一些挑選和思考。由於有我的因素，也不必定是正確的吧。同時不少很比較虛，若是對具體的感興趣，能夠翻翻這本書，挺不錯的。