今年將迎來我編程的第十七個年頭。我的編程之旅始于九十年代末,上大學的時候,主要涉足基于表格的網頁設計,傳統的ASP,和Microsoft Access數據庫。原來只是當作業余愛好的編程現在已經成為了我的事業和激情。我一生一半的時間都在學習、蹣跚、成功、失敗,并且經常情不自禁地為代碼美麗和復雜的天性而折腰。
我在代碼上淫浸了足夠長的時間,因此看到了很多語言和平臺的興盛和消亡,看到了很多模式被普及,被苛責,然后再次被推廣。在某些時候,我常常分不清這是大勢所趨還是明日黃花。
編程的流行趨勢是短暫的,但我堅守的規則,往往在生活中的其他地方也能發揮作用。事實上,生活就像代碼(我已經買了這個域名來證明這一點?。R韵率俏铱偨Y的3個偉大的經驗教訓,歷經一次又一次編程和生活的大浪淘沙。
1.可商榷的決定往往是一種權衡。
偉大的辯論總是發生在開發社區中。無論它是最近關于TDD作為web開發的一種可行方法的辯論,還是什么水平的開發人員應該使用ORM(或micro-ORMs)。無論是.NET MVC應該優于WebForms還是以JavaScript為中心的app應該比基于頁面的app更受青睞,對我來說,答案都一樣:看你權衡之后的取舍?
在任何比較兩種流行方法的辯論中,我們總是會從自己的立場出發,兩利相權取其重,兩害相權取其輕。在我的職業生涯早期,我曾執著于追求所謂的正確答案。感覺過程是線性的:擺脫做事的老辦法,轉而投向新的并且更好的方法的懷抱。曾經有一段時間我深信,編寫自己的SQL查詢是一種過時的練習,并且ORMs是最后贏家。
但是,我了解到,更好的辦法應該由內容決定的。例如,今天完全成熟的ORMs在隔離映射相關數據網格到對象的冗長管道提供了偉大服務,但隔離也使得某種非標準查詢變得困難并且有潛在的效率低下問題。n+1 select problem就是經典的在少寫代碼和寫更多高效代碼之間做權衡。我使用ORM的程度完全受我期待應用程序使用的數據量,我所受到的潛在的時間限制,app長期可擴展性需求這三者的影響。(順便說一句,我目前是micro-ORMs,比如說Dapper的忠實粉絲,它能讓我編寫我自己的SQL和一些精巧的對象-關系映射)。
我已經將這個經驗應用到了我生活的其他方面。我是應該買一套公寓還是長租房子?我是應該啟動自己的生意還是工作于已經成立的公司?沒有絕對正確的選擇。當你權衡利弊了之后,你便可以更好地應對生活中的各種難題。
2.清晰并不總和簡潔相關。
和大多數工程師一樣,我對持續重構一直到代碼盡可能地少和簡潔的機會垂涎三尺。如果可以選擇更少又更簡潔的代碼來完成同樣的任務,那么我為什么要選擇要個更多代碼的方案呢?通常情況下,更簡潔的語言會導致更好的交流。畫蛇添足只會阻礙核心信息的提取。但是,最終的目標不應該是簡潔——而應該是可交流。于我而言,下面這段直截了當的代碼,在它更長的時候……
if (HasFarm() && HasBoat()) { Broadcast("You are wealthy!"); } else if (HasFarm() && !HasBoat()) { Broadcast("You are OK!"); } else if (!HasFarm() && HasBoat()) { Broadcast("You are OK!"); } else if (!HasFarm() && !HasBoat()) { Broadcast("You are poor!"); }
……反而比這個簡潔版本更明確。
(HasFarm() && HasBoat()) ? Broadcast("You are wealthy!") : (HasFarm() || HasBoat()) ? Broadcast("You are OK!") : Broadcast("You are poor!");
雖然這是一個品味問題(有些人可能會覺得后者看上去更加一目了然),但是我在這里要表述的觀點是,有時候解釋的最偉大方法并不是簡化。這個經驗也適用于日常生活,我花了大量時間來思考怎么樣才能更好地傳達消息以便于對方接收——有時更詳細的講解并非沒有價值,而是更明確傳達信息的必須。
舉例來說,我想要更明確和更詳細地告訴我爸爸應該如何關閉iPad(“按住右側的按鈕一段時間……”)?;蛘撸铱此贫啻艘慌e地鍵入了一些我已經提交到本地分支的內容給我的同事(“剛剛犯的錯誤已被修復”),然后當它涉及到部署更新到產品中時,我就能很明確地知道哪些具體的提交被合并和出現(“檢查4812-4822行,其中包括在6/15發行版本中的DoneDone問題,將在今晚的產品發布中提出來?!保?。
3.累計良性債務,并且要持續償還。
我在一個特別害怕欠債的家庭中長大。八十年代中期,我的父母傾其所有又東拼西湊,付了他們第一套房子75%的首付,然后在七年內付清了剩余款項。用現金支付是常態。信用支付在他們看來幾乎是一種罪過。作為一個孩子,我的看法是,債務完全是壞的。我從不認為欠債是一種優勢。
直到我看到其他人是如何對待債務的——在我20出頭的時候——我終于知道了債務也可以是有益的。如果你能夠合理地承擔債務,那么之后你也能獲得成功。如果借助現在更好的上升空間可以加速你之后的成長,那么債務可以成為一筆巨大的財富。
代碼也是如此。有時它值得你現在承擔一點債務——錯過抽象或者有一些未優化的SQL代碼——如果這樣做可以讓你更快地發布內容給不斷增長的觀眾的話。關鍵是要了解你必須償還它,以及你可以在適當的時間段之后償還。
這就是債務在生活和編程中的竅門。償還債務需要持續進行。將一周10%的時間用于重構,相當于你是在按時支付編碼的信用卡賬單。如果你保持一種持續、可支撐的還債狀態,那么累積債務實際上對你是有好處的。
-
編程
+關注
關注
88文章
3619瀏覽量
93785
原文標題:17年編程生涯的三大經驗總結
文章出處:【微信號:edn-china,微信公眾號:EDN電子技術設計】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論