每晚10點，捕獲技術(shù)思考和創(chuàng)業(yè)資源洞察

表妹之前報的是數(shù)學(xué)專業(yè),，想轉(zhuǎn)專業(yè)學(xué)軟件開發(fā)，想聽聽我的看法,，原因是我在IT行業(yè)里混了有一些時間了,，這些年來，每天如同勤勞的螞蟻搬默默地搬磚,。回想起自己剛開始從事編程的情形,，感慨萬千。我只是一名普普通通的碼農(nóng),，和優(yōu)秀的程序員相比,，真的是自慚形穢。

該不該支持她,？先談?wù)勎覍Τ蔀橐幻细癯绦騿T的一點看法,。

一、定位問題,、解決問題

bug對程序員來說并不陌生,，開發(fā)中我們遇到的bug，有的其他人也遇到過了,，并且修復(fù)了分享出來了,，這時候我們通過Stackoverflow論壇，或是Google等搜索引擎找到答案,。

但是我們在工作中也可能會遇到一些疑難bug,，這些bug我們在搜素引擎上找不到解決方案,，特別是一些bug無法重現(xiàn)，可能好幾天都不得其解,。

做移動開發(fā)時,，有次我就遇到了一個客戶反饋的bug，因bug重現(xiàn)不了,，定位不到問題,，遲遲沒有解決而搞得人焦頭爛額。

簡單描述這個bug：

同一款類型手機,，系統(tǒng)版本高點的手機正常,，其他機型沒有問題。單獨客戶的那款類型的手機出現(xiàn)問題

剛開始懷疑是該類型手機的自身的應(yīng)用鎖功能導(dǎo)致的,，后來客戶反饋,，他的手機只有我們這個應(yīng)用會出現(xiàn)這樣的問題，其他的應(yīng)用程序正常,。

最后重現(xiàn)問題的方法,。因為之前給過客戶兩個不同安裝包，雖然是兩個不同安裝包,，但兩個包改動并不大,。

于是乎，試著卸載手頭的手機的最新應(yīng)用程序,，先安裝舊的安裝包,，再安裝新的安裝包，bug重現(xiàn)了,。

通過解決這個bug,讓我明白了,，對于用戶反饋的bug，我們開發(fā)者要盡量從自身找問題,，冷靜分析問題,。

實在不知如何下手，請求隊友們幫忙,，別人的一句無意的話,，可能能幫助你解決問題，盡可能少的否認問題的存在,。

解決問題是我們的義務(wù),。公司請我們來目的只有一個，解決問題,。工作中要是遇到困難,，這很正常，我們需要做的是主動尋找答案和辦法,，哪怕辦法不妥,，也要想法設(shè)法去嘗試解決,，別輕易跟領(lǐng)導(dǎo)說，我不會,。

有次聽見市場部的領(lǐng)導(dǎo)安排一位同事定一個大會議室,，客戶下午要來討論需求。雖然是大公司,，但要定個大的會議室是很難訂到的,，弄不好還需托關(guān)系。這個同事問了樓層前臺,，前臺說沒有大會議時,，被其他部門定了,，于是他跟領(lǐng)導(dǎo)說“前臺說沒有大會議室了,，我訂不到了”，領(lǐng)導(dǎo)當(dāng)時就急了,，“那怎么辦?讓我來定嗎,？還是叫客戶不要開會了？”

這位同事在發(fā)現(xiàn)自己訂不到會議室后,，應(yīng)該做的是自己想辦法解決問題,，向前臺說明此處會議的重要性，看看能否和其他部門協(xié)商一下,。解決問題的能力是員工最關(guān)鍵的能力,。在工作中遇到困難特別正常，在這時,，我們有一項義務(wù),，就是找到解決問題的辦法，而不是制造問題,，讓領(lǐng)導(dǎo)來抉擇,。

二、心理承受能力強,，承受起壓力,，承受得起委屈

 現(xiàn)在招聘平臺對于招聘程序員崗位一般都會附上這么一項：

抗壓能力強，承受能力好一項,。

 剛畢業(yè)的時候,，到一家軟件創(chuàng)業(yè)公司上班，公司規(guī)模不大,，加上領(lǐng)導(dǎo)只有6個人,。

由于自身基礎(chǔ)不扎實，幾乎每次挨訓(xùn)的都是我,，在團隊中我是屬于打雜的角色,。

一會用PS切圖,，一會兒用css寫樣式，一會兒用jQuery寫個簡單的Tab切換效果,，那時候jQuery還是正火,，這些活倒是沒話說。只是遇到問題時,，壓力接踵而至,，感到一陣陣的無助。

最讓我印象最深的是做會員模塊時,，要實現(xiàn)在線支付功能,，得與支付寶、財付通第三方支付sdk對接,，在此之前,，我對這些一點都不了解。

不怕你笑話,，當(dāng)時心里那個怕啊,，雖說專業(yè)是計算機軟件的，可同學(xué)中從事專業(yè)對口的的,，寥寥無幾啊,，指望同學(xué)指點幾乎不太可能。

找同事幫忙也就更不太可能了,，他們都很忙,，負責(zé)的模塊也多，當(dāng)時心里就慌了,，要是沒能完成任務(wù),，豈不是得丟了飯碗。好不容易應(yīng)聘到的崗位,，如果因此就沒有了,，心不甘啊。

在做程序員前,，早就聽老師說過,，程序員最關(guān)鍵的是解決問題，甭管你之前學(xué)沒學(xué)過,，只要在你職責(zé)范圍內(nèi)有需求,，你都得想法設(shè)法把問題處理。

想到這,，心靜了下來,，逐個訪問官網(wǎng)，按照官網(wǎng)提供的文檔以及官網(wǎng)提供的demo,，逐個對接到項目中來,，領(lǐng)導(dǎo)安排我做這個模塊前,， 還特意給我的賬號各打了10元，方便調(diào)試,。

對接這兩個,，我用了4天的時間，雖然中間遇到一些坑,，但還是算完成了任務(wù),。

通過查看官方論壇查看別人碰到相似問題的，實在沒法就加入官網(wǎng)技術(shù)群,，找技術(shù)支持幫忙,。

記得周五那天演示給領(lǐng)導(dǎo)看時，領(lǐng)導(dǎo)輕輕拍了我一下肩膀,，說,，“不錯，流程走通了”,。心里甭提有多開心,，這次任務(wù)給予了我足夠的信心，讓我繼續(xù)走程序員這條路,。

特別喜歡這樣一句話：噴泉之所以漂亮是因為她有了壓力；瀑布之所以壯觀是因為她沒有了退路,；水之所以能穿石是因為永遠在堅持,。

三、養(yǎng)成一種好的編碼習(xí)慣,，該注釋要注釋

曾有網(wǎng)友調(diào)侃：程序員喜歡兩件事：

1. 喜歡說別人程序不寫注釋,；

2. 喜歡自己在程序中不加注釋。

注釋的目的不是為了解釋代碼做什么——可以讀取代碼!注釋目的是為了解釋當(dāng)你寫代碼的時候是如何思考的,。

在寫完代碼的后面兩三個月,，可能我們已經(jīng)不記得上述任何問題的答案，所以,，要寫下來,，為我們后面解決bug提供了重要的線索。

項目維護工作不僅讀懂源碼,，而且還需要在原有源碼基礎(chǔ)上作出修改,。如果沒有統(tǒng)一代碼規(guī)范，很可能會出現(xiàn)這種現(xiàn)象：

張三完成開發(fā)以后,，李四進行維護加一段代碼,，過一段時間王五又加一段代碼。原本一個很普通的需求,，經(jīng)歷了N次迭代和修改,，已經(jīng)形成了巨大的功能,。直到有一天，張三,、李四,、王五都辭職了，新來的員工看到那一大堆沒有統(tǒng)一規(guī)范的代碼,。想死的心都有了,。

不知你有沒有類似這樣的經(jīng)歷：

• 很多的時候閱讀自己的代碼，需要花費很多時間,？

• 尤其是出現(xiàn)bug的時候需要逐行的debug,？

• 自己編寫的代碼過了一段時間后再來看自己都亂了頭緒。甚至懷疑這代碼是我自己寫的嗎,？

隨著不斷迭代版的維護成本越來越高,，從而形成惡性循環(huán)。程序背后的架構(gòu)設(shè)計或模式固然重要,，但良好的命名也不容忽視,。不規(guī)范的命名不僅讓我們對代碼難以理解，更糟糕的是,，會誤導(dǎo)我們的思維,，導(dǎo)致對代碼的理解有偏差。

相反,，良好的命名規(guī)范,，則可以讓我們的代碼更加容易讀懂，也能向讀者正確表達事物以及邏輯的本質(zhì),，閱讀命名規(guī)范的源碼理解沒有那么費勁,，會有一種享受的感覺。

有的人喜歡對變量str1,，str2,，str3、,，str4類似這樣的命名,，甚至還對其添加注釋。

有的人可能認為注釋越多,，其他人看到的就會越好,。其實不然，注釋過多,，或是一些冗余注釋,，反而會影響源碼的可讀性。如果我們良好的命名規(guī)范，結(jié)合了需要和命名,。它可以省去許多不必要的注釋,。

對于方法命名，首字母一會兒大寫,，一會兒小寫,；一會兒全稱一會兒簡寫；一會兒用駝峰命名法一會兒用匈牙利命名法,。

當(dāng)然,，起一個好的名字確實不是件容易的事情。首先,，既要有盡量多的提供變量信息,，又要盡可能的保證名字短小精悍，還不能為了短小而隨意采用縮寫而導(dǎo)致閱讀障礙,，另外還要盡量保證以后程序更新后名稱仍然能很好的描述其內(nèi)容,。

在編寫代碼中，要盡可能的遵守一個良好的命名規(guī)范,，并且不停地的調(diào)整學(xué)習(xí)命名,，從而逐漸掌握起一個良好名字的能力。

我們應(yīng)該做的就是規(guī)范開發(fā),，減少自己出現(xiàn)的錯誤,。很多時候項目的壓力一部分也是由于前期開發(fā)中遺留的眾多的問題。

那些看似無用的東西要經(jīng)過我們慢慢地累積由量變達到質(zhì)變的時候,，相信你能體會到其價值所在,。

程序是寫給自己看懂，更是寫給別人看的,，平時要多注意代碼規(guī)范，養(yǎng)成一種好習(xí)慣,，起初好習(xí)慣是人培養(yǎng)出來的,，后來好習(xí)慣卻能成就一個人。

養(yǎng)成良好的代碼規(guī)范不是為了別人,，也不是為了公司,，而是為了提高自己的編程修養(yǎng)，提高自己認識事物的能力,。讓自己編寫的代碼可維護性更好,、可重用性和可擴展性更強。

四,、養(yǎng)重視溝通

編碼只是程序員工作的一部分,，團隊之間的溝通也不容忽視。

職場里，有的程序員在任務(wù)進展過程中不注意溝通,，認為我只要最后把領(lǐng)導(dǎo)安排的任務(wù)完成了就算完事了,，結(jié)果往往需要項目負責(zé)人或上級主管問起來時才想起來匯報進展；更糟糕的情況是即使在開發(fā)過程中出現(xiàn)了問題,，也不敢主動溝通,，而要等到別人問起來了才提出目前碰到的困難。這樣會給別人造成極大的困擾和擔(dān)心：如果我沒有問,，那么這個問題是不是就卡在這里,？項目進度是不是就延期了。

職場上對你的職場形象造成負面影響的其實并不是事情沒有按期達成,，因為有時候確實有一些因素會導(dǎo)致事情無法正常完成,，而危害最大的是你沒有及時溝通問題，造成問題的擱淺和發(fā)酵,，最終造成的結(jié)果與預(yù)期不符,；這會給團隊帶來不必要的麻煩：出現(xiàn)問題為什么不及早反饋溝通？

你遇到的問題,，或者團隊中已經(jīng)有人解決了,。因此，我們需要意識到定期溝通的機制對于跟進效果是一個重要的指標(biāo),；那么如何搭建一個好的溝通機制呢,？在這里給大家推薦一個SMART模型。

• S代表的是Specific:溝通內(nèi)容要具體

• M代表的是Measurable：衡量指標(biāo)要量化

• A代表的是Achievable：目標(biāo)制定要實際

• R代表的是Relevant：個人的目標(biāo)要與團隊目標(biāo)一致,；團隊的目標(biāo)要與公司戰(zhàn)略一致,。

• T代表的是Time：完成工作需要的時間，預(yù)計達成結(jié)果的時間

以上觀點只是個人看法,，有不足之處,，歡迎指正，一起進步,。要不要支持表妹學(xué)軟件開發(fā)呢,？

你可能還喜歡