1. 程式人生 > >不要讓你的習慣禁錮了你的思維

不要讓你的習慣禁錮了你的思維

以下文章轉載自(我師父部落格):http://www.hifreud.com/2015/03/11/let-it-go/

感覺寫的真棒,推薦給說有跟我處境一樣的程式猿們!

關於工作

以前一直以為自己精力旺盛,可以同時做好幾件事情,而後來才發現,完全不是自己想的那樣,每件事情都想著,就會每件事情都做不好,我不是Windows,不會巨集觀並行微觀序列,所以我的態度就是,同一時間只做一件事情,並且專心做這一件事情,一件一件解決。

關於技術

工作中遇到不懂的問題是一個很常見的場景,而解決辦法是什麼,卻五花八門,有人會直接張口問同事,有人會Baidu或者Google,有人會直接去查API,還有人會去看自己總結過的部落格。每種方法基本上都是可以解決問題,而問題的關鍵是什麼樣的習慣會導致什麼樣的結果。

  • 直接問同事的:或許你覺得太簡單了,問一下沒什麼大不了,但是絕大多數情況下的結果是,這個問題輕鬆解決了,但是下一次又遇到這個問題,又忘了,再問那個同事。周而復始。自己一直沒什麼沉澱。甚至假如哪一天那個同事離職了,這個問題就永遠的變成了問題。

  • Baidu或者Google:這個已經上升了一個等級,明白了問題要靠自己解決,相信大多數程式猿都是比較高傲的,不喜歡問別人問題,習慣性的自己去解決的。但是Baidu和Google也是講究技巧的。有的人可以找到,有的人找不到。在這裡又把程式猿劃分出了等級。而通常能解決問題的是一些大的技術社群,所以,沒事還是多去StackOverflow,CSDN之類的地方逛逛,對自己還是比較有好處的。

  • 查API: 前端時間做EasyUI的東西,直接開啟官網,看API的使用。這時候有個同事過來看到,聊起來說到底在網上怎麼解決問題算是比較效率的。而在這個問題上我倆意見是統一的,查API。因為雖然Baidu或者Google解決了問題,但是隻是解決了一個點的問題,而如果查API,獲得的將是面的效應。在搜尋問題和答案的過程中花了稍多的時間,得到的結果確是天壤之別。

  • 查自己的Blog: 程式設計看起來是動動手指頭就可以搞定的工作,但歸根結底還是腦力勞動。隨著工作時間的增長,年齡的增長,記憶力會變差,並且技術這種東西,兩個月不看,基本就跟你形同陌路了,所以平時養成隨時記錄學習到的知識點和遇到的問題及解決方案的好習慣是很有必要的。不需要太多時間,每次遇到,隨手記錄下,按照Agile的思維,每個月總結下前段時間的問題。可能短時間看不出會有什麼成長。但是就在這潛移默化間,幾年之後,差距是顯而易見的。並且就我現在遇到的幾個大牛而言, 幾乎都有隨時記錄筆記寫寫技術心得的好習慣。向大牛們看齊。

關於習慣

結果驅動,不要因為過程多麼完美沾沾自喜,結果才是衡量一件事情成功與否的唯一標準。而習慣,是慢慢培養的。前段時間做一個Maven遷移的工作。花了接近2天的時間,本地測試完全沒有任何問題,可是提交上去之後,在別人那根本就跑起來。最後發現問題在於我測試的時候,沒有清除本地快取,導致本地一直是好用的,其他人那不可用。老徐說我是習慣不好,確實,有時候有點急功近利,而做技術,急不得,只能一步一個腳印的往前走。 
最近一直熬夜,加班。導致記憶力完全不行,前腳說的話,後腳就忘了,以前一直想做一個EasyAgile的東西,個人任務管理工具,後來發現worktile.com跟我想的需求完全一模一樣,只不過是個B/S架構,不過B/S就B/S把。堅持使用,每件事都記下來,劃分優先順序,一件一件解決。

關於思維

學習技術的思維是一根筋,不要總想著把什麼東西做出來了就可以了,大家都是學技術的,隨便找個差不多的人,給定足夠的時間,大家都可以實現功能,而問題是誰實現的更好,在出了問題的時候誰能更快的定位和解決問題。做技術,多問問為什麼這麼做,這麼做有什麼好處,技術細節是怎麼實現的,效能有沒有問題,採用這種方案會導致什麼問題,能不能符合業務需求,出現問題的解決方案或者替代方案是什麼。比如Java中的匿名內部類,為什麼會出現,是為了回撥,在java中不允許像javascript那樣在引數裡傳遞方法,所以java的解決方案就是匿名內部類,表象上傳入的是一個類,實際需要的只是那個重寫方法,並且在JDK1.8中已經引入了C#中早就存在的Lambda表示式,看起來就更像是傳入了一個方法。漫漫技術路,思維是既定的,但是這種思維的習慣需要時間來慢慢養成的。

關於專案

最近在做一個私活,後臺的介面+維護系統。每當客戶跟你聊的時候,你會發現,他口中,所有東西都是很簡單的。比如維護系統,在客戶嘴裡就是一堆增刪改查,當然,不可否認的是,維護系統大多數的操作確實是增刪改查,但是也有很多的邏輯是很複雜的,並且這些很複雜的邏輯會佔到30%甚至更多,會佔用開發時間的60%。而當你把這些困難,或者換個詞叫做成本告訴客戶的時候,客戶不會思考自己的需求,而是會直接懷疑你的能力,在他眼裡,這種小事情都辦不到,或者需要這麼長時間,這麼多錢,你是在騙錢麼。而這時候,你就需要斟酌一下自己的詞彙,用更多的口舌來說服對方,這個就是需要這麼高的成本。最後結果只有一個就是你做,但前提有兩種,第一種是客戶妥協,第二種是自己妥協。這個時候,溝通其實比專案更累, 
前段時間還跟一個要做商城網站的人聊需求,而對方是完全不懂技術的型別。他的想法是,如果你有一套系統,我可以買過來。即使這個是以前給別人做的。在這個地方,先撇開別人的老路再走還有沒有意思的問題不談,單從版權問題上來聊,就有很大的隱患。國內大部分人的想法是想要免費的,或者最少成本的拿到一套軟體,因為在客戶眼裡,軟體就是一個光碟,或者一個U盤,裡面存了點程式碼,甚至,就是一個地址,讓他下載了一堆他根本看不懂的檔案。這東西怎麼就能值幾十甚至上百萬。這是一個很可怕的想法。就像現在的大學生畢業設計一樣,網上下載個Demo,Copy一下,隨便改改,署上自己名字,搞定。沒有人去關心,背後究竟是誰做的,怎麼做的。沒有人關心原作者的心血。這是個惡性迴圈。