在我所認知的程序世界里面,除了學習新的技術和知識外,還存在著五大基礎屬性,它們分別是:看、聽、讀、寫、說。在日常的工作和學習中這些屬性占據著重要位置,就好像RPG游戲一樣,人物的屬性值越高,能力就越強,學習到的技能就越多越高級。所以,在日常生活中不能忽略了這些能力的提升,打怪升級靠的就是它們。
看
這里說的“看”不是指看代碼的能力,是指觀察事物并對其進行分析和轉化成代碼語言描述的能力。它是屬于一種觀察能力,與平常用眼睛看東西還是有很大的區別的,前者需要加入分析和思考的步驟。
舉個例子,比如觀察一塊積木,首先我們能夠感知的是它的形狀、位置、大小和顏色。但是如果這塊積木要搬到程序的世界里面,明顯上面的所感知的信息是無法直接運用的,所以,我們需要把他作進一步的抽象轉化:
class Block
{
property shape:String;
property x:int;
property y:int;
property z:int;
property width:int;
property length:int;
property height:int;
Property color:int;
}
我們通過一次觀察,在腦海中完成了如上面的代碼所示。但是這是每個學程序的同學都應該所具備的分析和認知能力。如果觀察再深層次一點,就是應該通過現象來看透本質,找出其隱含屬性,還要分析其與其他事物的關聯關系。
那么,下面我們再繼續“看”。就上面例子,可以看出模型的屬性都采用了比較簡單的屬性描述,在程序中是不太容易還原其在現實中的實際形態的(假設我們在實現一款3D建模工具)。所以,需要進一步的優化,可以得到下面的代碼:
class Size
{
property width:int;
property height:int;
property length:int;
}
class Pointer
{
property x:int;
property y:int;
property z:int;
}
class TriangleShape
{
property vetexes:Array:
}
class Block
{
property shape:TriangleShape;
property position:Pointer;
property size:Size;
Property color:int;
}
上面代碼的演變過程可以看出來,經過仔細的分析很多對象的屬性都被進一步被抽象化,更加符合程序的描述和設定。如果再進一步的深入分析和理解的話,可能還可以將分析發散做到與其他事物的關聯上,如不同形狀的積木抽象,以及由積木組成的物體聯想(例如使用積木堆積的城堡)。這里就不一一列舉代碼了,代碼在這里只是輔助我們去細化所看到的東西的轉化結果,也是對事物的認知過程,不同的人對不同的事物認知不同,產生的轉化結果也不大相同。但是有一個方向可以確定的,就是事物的轉化結果是一定要具備可逆性的,即根據代碼可以還原原本的事物或場景,如果還原度越高還原的物體的種類越多,那么“看”的能力就越強。
所以平時可以多留意周邊的事物然后多運用上面說的辦法來進行分析。如果你不喜歡分析實際物體,那也可以分析嘗試分析別人程序,像做客戶端的同學很多時候都需要仿照別人的App來設計,那就可以經常看看別人App的效果和功能,然后實際分析一下,還可以著手驗證自己的“看”法。
聽
要了解一個人的想法最直接的方法就是聽他講述。而作為程序員的我們很多場合都需要自己用心聆聽仔細分析,例如你跟別人討論問題、去參加技術大牛的分享會、又或者你邊看教學視頻中的講師講解等等。那么,聽的能力就決定了你對所講內容的接收程度。
一般來說如果自己對話題沒有什么概念的情況下,別人說的內容是很難被吸收進去的。所以,在聽之前都需要自己先了解一些與話題相關的東西,這樣才能有利于在別人講的過程里面去做分析,然后形成自己的結論和問題,然后再拋出你的問題,得到回答后修正你之前的結論,最后得出最終結論并進行確認;通過這樣一個反復的“聽和反饋”的過程,你對別人說的內容才能得到最大程度的接收,甚至引出更有價值的東西。
筆者不太建議大家在聽完別人分享自己的想法和心得后毫無反饋。這樣一來別人并不知道你了解到什么程度,二來他自身對于這件事情的認知也沒法得到進一步的了解,因為認知過程本來就包含了相互探討這一重要環節,缺少互動的溝通可以視為一種無效的溝通。
所以,我們要注意不要成為上面所說的那樣,平時要有意識地進行聽的能力培養。總的來說。在聽前要做好了解主題內容的準備并帶上自己的疑問;聽的過程要圍繞主題來分析總結問題,盡量做到每一次的聽都能夠有所反饋。
讀
從一開始接觸編程就開始被要求讀別人寫的例子代碼,了解別人的編碼思想,然后將其轉化成屬于自己的東西;讀成為了程序員首要的能力。所以,這方面的能力強弱決定著編程能力提升的速度。
不管是一開始學習程序時讀別人代碼,還是學習架構是讀別人寫的文檔,甚至是開始應用時讀需求文檔等等,這些都屬于讀的能力范疇。所以,不要以為閱讀代碼能力很強就是讀的能力強,其實這只是一小部分,更加強大的能力應該是體現在“讀懂”一些使用自然語言描述的文檔,并將其通過程序方式展現出來。
對于讀的方式因人而異,每個人都會有屬于Ta自己的閱讀方式。筆者一般采用的方式為圈重點,然后再深耕細作。主要考慮的是個人時間精力有限,不可能每個點都讀透。所以會從需求出發,先找出與需求相關的重點部分,然后再細細地讀,深入里面的每個細節,并且進行一些總結和通盤考慮。如果是代碼的話甚至還會加上工具來輔助了解(如斷點調試)。
我們要經常保持定量地讀別人的代碼(通過書籍或者開源社區),分析別人的代碼最終形成自己的積累。通過這樣不斷的累積經驗,才能使我們在讀的速度和質量方面達到進一步的提升。
寫
一提到寫,大家都會聯想到寫代碼,這是我們平常最工作。我們對寫的興趣是非常濃厚的,可以寫出滿滿的成就感。但是一提到要撰寫設計、架構等文檔,相信很多人都會覺得懵逼,根本就無從下手,也不知道需要寫些什么,原本寫代碼的時候很順溜,一換到寫這些文檔就變得很吃力。但是我想說的是,這些也是寫能力的一部分重要體現。
我們都知道如果一個需求還沒想好怎么實現,那么千萬不要急著開始實現編碼的工作。尤其對于負責整個產品的主程來說,應該要訂好編碼前的架構,約定和注意事項等,并寫下文檔方便在多個人之間協作開發。譬如,我在某個項目中考慮到了通訊部分功能可以單獨抽取出來作為公共模塊,那么在這個東西就應該體現在你設計文檔里面,還要加以規范說明,讓大家知道并且去使用它來完成工作。
如果你對寫這類專業文檔還有些迷茫,不知寫什么,如何編排內容等。那么,筆者覺得你應該先去搜集一些資料來了解大概要寫什么內容,然后理清自己的思路,給文檔制定提綱,然后把要說的內容寫出來就好。不一定要拘泥于格式和字數,能夠表達出思想和思路的文檔才是好文檔。
還是那一句要想提高自己的寫能力,一定要先克制自己不要一下來就先寫代碼,而是先學會寫前的思考分析,把一些重點和可預見問題提出來,遇到不理解或無解的問題,不要想當然地去做,而是先搜集資料然后咨詢經驗豐富的前輩來輔助你進行分析。剛開始這個過程可能會很不習慣,花費的時間也可能會比較長,但是不要急躁,一旦你熟悉后這個過程就變得很輕松,你的思考層面也會得到拓展。這樣做法對于往后的代碼才會寫得更加順暢,翻工的幾率才會更少。
說
對于一個整天與計算機打交道的人來說表達能力確實會退化,而且不太會與人打交道。但是不代表我們可以只要負責敲代碼就好,必要的表達能力還是需要培養的。因為在一個團隊里面跟其他人的溝通都是必不可少的;如果你編碼能力很厲害,但是沒有辦法表達清楚你的想法和做法,團隊的其他成員都將不知道怎么與你配合,導致整個團隊的工作效率低下。因此還是要適當地培養和鍛煉自己的表達能力。
為了要表達清楚事情,其實我們可以在這之前做出一些準備,盡量將要講的內容包括一些細節做好研究和說明,形成文檔或者PPT,在講述的時候才能有條不紊地進行。至于為什么要準備到關鍵點和細節,原因就是在緊張的時候可以起到輔助功能(沒錯!程序員很容易緊張,特別看到一大群人在聽你說話的時候...)。
然后就是多在一些公開場合表達自己的想法。要重視每一次參加公司的內部分享會或者討論會,很多同學在公司內部開會的時候都不愿意發表意見,其實我覺得這是一個不錯的鍛煉機會,你可以借助這樣的機會來把你對某件事情的觀點和想法表達出來,哪怕說得不是特別好也無所謂,重點是你要關心別人有沒有聽懂你的想法,然后每次會議后再來思考自己需要調整和改進的地方。有人也許會問,那如果參加一些技術沙龍或者論壇是不是更能鍛煉這方面能力。我個人覺得如果你能克服緊張的心理那時極好的,但是我更建議從公司或者團隊內部開始,因為都是熟悉的人精神會放松一點,然后再逐漸面向陌生人。
最后就是有意識地將專業內容通俗化。一個團隊由很多不同專業領域的人組成,那么,在表達的時候就要注意使用比較通俗的字眼來說明相關的專業知識,讓別人更加容易接受你說說的內容。如:“與服務器通訊”就比“請求服務器”要來得通俗。
結語
也許有人會說,這些能力隨著工作經驗的增加自然就會增長,沒必要刻意去提升。但我想說這正好相反,這五項基礎屬性的最終目的是幫助自己分析、總結經驗和知識;是它們決定了你的經驗累積的多少,而不是你的工作年限。
由于平時寫作的時間太少了,加上文筆確實不好,結果一篇文章反復修改,寫了好幾個月才完成(如果我是作家,估計是要失業了)。所寫的觀點并不一定正確,但這確實是我在成長過程中的體會,如果覺得對你有用那么請你動動手指給我點贊;沒有幫助到你也不要緊,點贊了就可以(偷笑)。