打卡譜

2017年7月7日13:47　　　　開始。

  2017年7月7日20:55　　　 結束了。

---

 

2017年7月9日13:37　　　　開始。（看了知乎上關於前端的一些問答，還有大神的簡歷。目前走的最大的彎路就是先學了jquery而沒有先看高級程序設計。）

 

2017年7月9日19:59　　　　結束。

---

 2017年7月10日13:22　　　　開始。

2017年7月10日18:52:　　　　結束。準備研究一下留言欄。

---

 2017年7月12日13:50　　　　開始。

昨天沒有打卡，研究了一下留言板怎麼寫，尚有兩個關鍵功能沒有實現（也不知道昨天干啥了）。若是有興趣能夠去看看，指出錯誤更好咯。

地址：github 。啃書了（第七章：函數表達式，比較少，若是看的比較容易會再看一遍第二三章）

---

 

昨天直接關機了，忘記打卡。

剛開機，稍後開始看書。

2017年7月13日18:14　　　　看不下去了，頭有點疼。今天就到這了。

---

   忘記打卡，昨天晚上半夜睡不着，而後反知乎，看見網易雲課堂發表的關於前端的文章，這裏是連接：知乎連接 內容大概是關於工做時間和能力成長的關係，（良好的代碼習慣可讓你的工做經驗翻倍）下面會貼出主編具體說了什麼。

 

做者：網易雲課堂
連接：https://www.zhihu.com/question/19589966/answer/197597062
來源：知乎
著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。

每一年的三月到六月，都是招聘高峯，除了大量的應屆畢業生涌入社會以外，還有一些工做了一兩年還沒有找到穩定歸屬感的人，也會開始投遞簡歷（沒錯，基本都是在拿了年終獎以後）。

這時候，前端技術的主管須要在這些投遞過來簡歷的人中，耗費大量精力來篩選符合公司要求、團隊發展、技術基礎三方面條件的人選。常見的招聘要求中，基本都有「工做經驗」的要求，並且都是以年做爲單位。可是實際狀況卻告訴咱們，工做經驗每每不是以年衡量的，甚至有些時候跟時間沒有關係。

因此，爲何你的前端工做經驗不值錢？這裏從一個小小的面試題目入手：

 

編寫一個javscript函數 fn，該函數有一個參數 n（數字類型），其返回值是一個數組，該數組內是 n 個隨機且不重複的整數，且整數取值範圍是 [2, 32]。

 

若是願意，請先暫停閱讀文章，本身動手寫一下這個函數。是的，老簡單了。我能夠等你五分鐘。

 

~~~ 華麗的五分鐘過去了 ~~~

 

如今假設你的工做時間爲 y 年，經驗係數默認爲 1，即工做經驗是：Y = 1 * y。從如今開始，如下的錯誤，你要是遇到了，請自行調整經驗係數。

 

1. 可用

做爲一段須要知足需求的代碼來講，它最核心的、最低的要求：可用。

若是你沒有產出一個函數( fn )，或者產生了語法錯誤，那就請設置 經驗係數爲 0，而後去面壁思過；

請將代碼在控制檯運行，並執行 fn(3)，看看是否輸出一個數組，數組中包含了三個隨機且不一樣且在[2,32]的整數，若是不是，請將 經驗係數 * 0；

一個參考的半僞代碼是：

 

 

其中 getRand 、checkInArr 還另有講究，後面會提到。固然思路和方法不止一個，後面也會提到。

有至關多的面試者，包括很多工做時間爲2年之內的同窗，都會在這一步犯錯，很是遺憾。

 

2. 健壯

代碼是否老道，過了「可用」這一關後，就開始見分曉了。

所謂「健壯」，即最基本的兼容性處理、邊界處理，異常處理、用戶輸入校驗。不少時候，需求方不會明確告訴你這些邏輯怎麼處理，但並不意味着你不須要處理。

健壯的程序，必定會將這些兼容性、邊界、異常、輸入作處理，以保證核心功能的正確輸出。固然，若是你的代碼沒有任何輸入並不考慮兼容性（可能嗎？）或者僅僅是內部函數，那這一步要求能夠下降，並不意味着你能夠徹底不作。

好，回過頭看代碼：

——若是你沒有對 n 的取值範圍作校驗（n必須是 1 到 31 之間的整數），請將 經驗係數 * 0.3；

——若是你沒有對 n 是否爲數字作校驗，請將 經驗係數 * 0.5；

——若是你沒有對 n 是否存在作校驗，請將 經驗係數 * 0.7；

——若是上述校驗都作了，可是沒有校驗對，請將 經驗係數 * 0.9；你須要多練習，仔細認真的。

 

3. 可靠

大多數面試者都止步於前兩關，鮮有進入第三關的：可靠。

javascript沒有強數據類型，函數的返回值也沒法強制返回的數據格式。可是做爲「可靠」的要求，儘量在任何狀況下，都返回一個可靠的結果，哪怕是異常狀況下。是的，這一步很簡單，幾乎不耗費幾個字節的代碼，可是會讓 fn 的返回值變得可靠：

 

 

若是你留意到並處理可靠返回值的問題，那請將經驗係數 * 1.2；

另外，一個牽涉的話題就是：異常狀況下，是否要拋出 Error，或 console.error ？

關於這個話題，彷佛沒有定論，須要本身衡量。個人觀點是：若是異常狀況下不會形成太大影響的話（包括定位錯誤），就不用拋錯或提示。但一樣的，這個衡量仍然是經驗性的。此處再也不展開討論。

 

4. 寬容

若是在你的平常開發中注意「可用」、「健壯」、「可靠」原則的話，你的工做經驗就會大於你的工做時間，也就會更容易受到重視，本身所挖的坑就會少。而我近期面試的人中，甚至包括五、6年工做時間的，幾乎都止步於此。

若是你要想成爲一個受歡迎的技術人員，「寬容」是第一步： 對需求寬容、對用戶寬容、對調用者寬容、對維護者寬容。

回到代碼:

——若是 n 是一個字符串數字，是否能夠容許進入處理流程？ 若是是，請將經驗係數 * 1.1；

——若是 n 是一個含有小數的數字，好比 3.000001，是否容許進入處理流程？若是是，請將經驗係數 * 1.1；

——你的代碼中，是否有足夠多且清晰的註釋？ 若是是，請將經驗係數 * 1.2；

——若是需求調整了 [2, 32] 的範圍，你的代碼是否能夠快速調整，甚至不用調整？ 若是是，請將經驗係數 * 1.2；

一個參考的半僞代碼是：

 

 

5. 精益求精

恭喜你完成了前四關！

若是你在實際開發中，時時刻刻留意這些原則，這足夠讓你的工做經驗擴大化，並給你帶來更多的承認，這些承認來自於需求方（或許是那個曾經很是蠻橫的產品狗）、用戶以及你的同事。但不該該包括你本身，你還須要更進一步。

寬容是寬以待人，精益求精是嚴以律己。內外兼修纔是高手。當你將這五個原則（可用、健壯、可靠、寬容、精益求精）變成你本身的開發習慣，你的工做經驗就跟你的工做時間沒有關係了。

 

以上。

 

本文轉載自網易實踐者社區，做者爲網易高級前端技術經理馬超，轉載已獲筆者受權。

 

 

 

今天下午就研究這個了，github上有項目代碼，有興趣的看到的能夠研究一下，知乎就能夠看見有別的大神裝逼教程。

2017年7月14日19:55　　　　今天結束。明天繼續。

 

---

沒臉打卡 2017年7月16日13:41　　　　開始。

2017年7月16日17:27 　　　　　　　　任務完成，結束。

 

---

斯哈！ 一直在看知乎上有關於前端的帖子，大多數關於面試，有人抱怨，相似於我這種，沒找到工做的、水平差的。還有牛的，說要修改本身的面試題。瞧了他出的面試題。都特麼懷疑人生了，要不我仍是作銷售去吧。 像我這種水平的挺多，比我厲害的更多。想要脫穎而出很難。

看知乎會看到窒息的趕腳。今天不打卡了。哎。看書去了，有些不堅決了。

---

 昨天下午沒打卡，複習了一下原型鏈和閉包這一塊。稍後複習一下第八章，內容不是太多（方法不少，記不下來）而後繼續看新知識。

打卡：2017年7月19日13:35　　　　開始。（肚子一直在叫……）

吐個槽：模塊模式和加強模塊模式差異在於後者var 了一個內部變量，而後返回新變量，前者須要返回具體方法。這有啥用！？？估計很快就會遺忘……

 這個客戶端檢測，能力檢測，怪癖檢測，用戶代理檢測。正則表達式之後須要增強。

2017年7月19日20:51　　結束。

---

昨天和今天表現不太好，有些懈怠了。先不打卡。