假如我是一行代碼（程序員必備）

這次我想問大家：有沒有想過如果你是一行代碼，沒有想過，讓阿福帶著大家進入一行代碼的神奇世界！希望大家多多參與討論！

前言

一直以來很想寫這樣的一篇文章，奈何對這個論題的理解一直停滯不前，理解的也不夠透徹。今天偶然的一個想法，綜合自己的工作經歷和項目經驗，突然找到了靈感，現在，為大家帶來這篇文章。

緒論

故事應該從麥肯錫公司的金字塔原則談起，我們都知道，麥肯錫公司的金字塔原則教給我們的是重點突出、邏輯清晰、主次分明的邏輯思路，也就是告訴我們一種從金字塔塔尖逐漸向下推演的過程，至於，金字塔原理的詳細內容，在此就不做贅述了。其實大家可以發現，金字塔原理是很符合我們的思維習慣的，這裡面又涉及到一種重要的思維方式，那就是推演。而大部分人的這項能力其實和一般人別無二致。但是，反向的思維，比如說歸納又有多少人能夠熟練掌握呢？大多數人程序設計，往往從架構基本概念入手，不斷向下挖掘，不斷的推演，當然有時候會輔以頭腦風暴，效果更佳。但我們今天，就從一行小小的代碼談起，刷新一下我們的認知！

假如我是一行代碼

為何這樣想？

我們不止一次在生活中聽到」假如我怎樣怎樣，我會怎樣怎樣「的句式，而這樣的句式說出來的一般意義無非就是讓我們站在另一個角度去思考問題，比如說曾經一個物理學家假設自己是一個電子，他借著這樣的假設進入了另外一個神奇的天地，那是一片從來沒有人到達的樂土，那是一個就算兩個電子相撞、抑或相互泯滅都顯得舉足輕重的一個世界，在那裡，電子是主宰，而不再是人類。電子遵循著生存的法則，相安無事。而我們，今天的主題，將帶著大家以一種全新的思維去看待程序設計，假如我是一行代碼！

站在一個軟體工程師的角度，我們往往覺得一行代碼對於我們的影響是微乎其微的，可以忽略不記，而今天，當我們假想自己是一個代碼塊的時候，我們可能會發現另一個世界。但是有人提出質疑了，那你為何不假想自己是一個關鍵字，是一個字母，是一個位元組或者一個比特位呢，莫急，且聽我慢慢道來，我們今天討論的程序設計，我認為實用的有討論意義的單位最小就是一行代碼了，再小的話，將失去我們討論的價值所在。當然，換個角度來講，如果你想探究cpu內部的加、減、乘、除的機理，你選一行代碼作為參考自然是不夠的，那個時候，位元組等量級的參考才是我們真正所需。

對於web前端的學習有不懂的，或者不知道學習路線，不知道學習方法，不知道該如何紮實能找到工作的朋友，我還是要推薦下我自己建的前端學習群：477149581，首先你要是前端黨，其次不管你是小白還是大牛，我都挺歡迎，小白嘛，主動點多問問題也就學好了，群里每天分享乾貨，包括我自己最近花了一星期整理的一份適合2017年自學的最新web前端資料，送給大家，歡迎初學和進階中的小夥伴。

那麼，讓我們開始思考，假如我們是一行代碼，我們會怎麼思考呢？文字有時候還是顯得太枯燥了，我們來張腦圖天馬行空一下。

可以清楚的看到，作為一行代碼真的還是不錯的，有這麽多的事情可以干，哈哈。當然，我著重標出來的1和2大家一看都知道這兩個老梗，不懂的自行谷歌之。

當然了，我們並介意那些天馬行空的想法，但是在想這些事之前還是先把我們最主要的事情先做好吧，那當然就是我們的程序設計啦！現在，我們就確立一下我這行代碼現在想的問題，那就是如何寫出一段好的程序，下面的話，讓我們進入今天的主題，主題，主題。

我要怎麼做？

上面我們已經談到了我們為何要這樣去思考問題，我們爭取站在一行代碼的角度去理解軟體設計這門藝術，那麼，作為一行代碼的我們，現在已經確立了這樣的一個宏偉的目標。我們現在站在這樣一個難題面前，想著如何去攻克它，證明我們自己的實力，似乎現在已經到了一種劍拔弩張的狀態，空氣里到處都充斥著火藥的味道。

但是作為一行聰明的代碼，我不能蠻幹啊，我一定得先在心裡有一個想法，然後去擴充它，由於我所處的層次是比較低的，我只能就一點點的思考了，大家可不要笑話我這行代碼啦！思考的結果我該以什麼樣的形式呈現給大家呢？苦思冥想之下突然發現作為一行優秀的代碼，todoList一定是要有的，於是就有了我下面的思考。於是就有了下面的列表：

• 首先當然是拉攏幾大程序設計結構，if-while-for他們了，這樣一來，我軍士氣大漲。

2.拉來測試大神「junit」為我們代碼質量保駕護航。

3：找一些敵軍的優秀精神領袖，觀察其處事風格，正所謂知己知彼，百戰不殆！（當然具體的尋找思路就是GitHub嘍！）

4：鏈接一些api大哥，為我們的一些底層操作實現無縫接入。

5：請教演算法大師，為我等思維模式的提高錦上添花。

6：拜訪設計模式，了解高可用軟體開發之道。

列完了這些，我苦思冥想，接下來該幹什麼呢？作為一行有著完美主義血統的代碼，我忍受不了自己的todolist不完善，然而我卻忘記了，完美不存在，我們只是能盡量做得完美而已。下面的事情，還用我多說嗎？那當然就是個」做「；當然，我們開始的話就要分析一下我們的todolist中計劃可行性。

首先，我們大致將其分為兩類，受外部影響的和內部可消化的。

大家覺得是哪一項更加重要呢？當然，是受外部影響的重要啦！在這裡的話，以計劃4說明下：

幾個月前，一名NPM（NodejsPackageManager）社區的貢獻者AzerKoçulu出於對NPM管理層的怨憤，不聲不響刪除了自己在NPM上面的全部代碼，其中就包含只有11行代碼的「Left-pad」，沒想到從北京 到美國矽谷，從大學宿舍學習Nodejs的新手到Facebook的資深工程師，整個互聯網界都炸開了鍋，他們手中的許多Nodejs模塊，全罷工了。

據NPM官方博客，「left-pad」刪除后， 受到影響的模塊達到數千個。

這可真是我代碼界的前輩啊，但是這是一個典型的反面教材，有人就質疑了，為什麼不設計一個官方標準庫，把那些引用次數很多的api都放進去呢，（這一點上，jdk就做的比較好）還有一個更典型的例子，真有一個一行代碼的模塊，叫做isArray，下載量達到88萬次，萬一有一天，代碼擁有者的賬號被黑客盜走了，黑客一時興起，刪了這個小模塊，到時候真可就是嗚呼哀哉了！

這說明了一個道理，外部模塊有風險，且用且謹慎。在舉個例子，你要開發一個項目，請了好幾個大神，大神也答應你好的，結果真到交付的時候，大神說最近沒時間，還沒開始干，這時候，有著一顆玻璃心的我，豈不是要抓狂，在加上我們代碼界又都是一些耿直boy，有啥事會發生還真別說不來，就像上面node社區的那位小哥！so，首先確認外部的風險點，保證項目進度可控。

做完了todolist，也確認了外部的風險點，接下來該幹嘛呢？哼，讓我好好想想，該幹嘛呢？突然靈機一動的我都被自己機智到了，當然是確認驗收標準，什麼才算的上是一段好的代碼呢？我們在開發的過程中也一定是在有著明確的驗收標準后才會開始的，要不你怎麼知道什麼時候該停下來！如果不知道什麼時候停下來，就像遞歸沒有終止條件，到最後你只會因為資源耗盡而亡，就像遇見了程序裡面的棧溢出。那麼，我們就來定義下，當然，我希望我們友誼的小船能升級為巨輪，會盡量寫好的，列舉如下：

當然，不同的項目有著自己不同的項目標準，而我們這裡僅僅是一點好代碼的驗收標準，當然，若有不妥之處，還望指正。有了這些，我們就要開始動手了，想想也激動。

於是我們進入了正式的開發編碼，能一直編碼的話那也真是人生一件樂事啊，正當我們激情滿滿的時候，產品小姑娘跑過來，這有幾個需求需要改一下，頓時有莫有覺得心好累啊！但是不怕，我們設計的巧妙的結構還是足以容納這一點的改動的。看吧，前期規劃的重要性，於是乎，一切好像都向著美好的方向在發展著，我們的小心臟也可以放下來了。似乎馬上就要成功的到達彼岸了。終於開發完了，自己完成簡單的自測之後，覺得這樣的小模塊提測不會有問題的啦，然而，我們還是想多了，還是有著這樣那樣的問題，最終，我們的小模塊終於上線了，而我們學到了什麼呢？從一行代碼的角度思考，我們又能學到什麼？

我們得到的啟示

為了更直觀的看到我們得到的啟示，我們來試著將我們的思考過程以圖表的形式呈現出來。

看到上面的圖表，我們的思路是不是更加清晰了一點呢？我們把這幅圖倒著來看，儼然就是一張倒著的金字塔，而不同的是，我們這次是從塔底向塔的最上方爬，也就是採取歸納的方法，一步步的向我們的目標靠近，這是一種逆向的思維，同時也是對我們思維方式的一種鍛煉和提升，我們常規的編碼就是站在一個比較高的角度上去思考，去進行腦暴，把我們需要考慮到的點歸納進來，從而實現我們todolist的完整性。最終為我們的這一段可驗收的代碼貢獻自己的力量。從這裡我們還可以聯繫一點，那就是當你站在一個比較高的層次的時候，也要去考慮底層運行的機理，比如說在項目管理的過程中，身為項目經理，一般都是從技術崗位一步步的幹上來的，所以在思考問題的時候，會站在底層開發人員的角度去思考，而如果這個經理非技術出身，那麼他在進行項目管理的時候就會想當然的站在自己的角度去進行思考，忽略一些細節，往往這樣的項目，開發人員累死累活，卻沒有什麼成果！我們不該想想背後的原因嗎？

在本文我們可以看到，推演和歸納的思想在我們項目進行的過程中，構建一段普適性高的代碼的時候，扮演著非常重要的作用，當你站在一個較低的層面的時候，你可能會看到不一樣的世界，一句列印的代碼在那個世界里也可能舉足輕重，而你，收穫的不僅是歸納的思維，在現實生活中，還可能收穫的是理解和尊重。