很多工程師，會希望自己的程式有人看過，有人可以提供Feedback。但相反的，很多人懶得幫別人看Code，覺得開發以外還要做額外的事情，真的是很麻煩。
我個人覺得Code Review是值得的，畢竟人再怎麼精明總是會有盲點，多一個人幫忙看一下會比較心安。
不過Code Reivew不只是看看Code而已，要懂得怎麼看才有意義。
做一件事情之前，要先確認這件事的目的，才不會迷失方向，我認為Code Reivew的目標有這些：
可以發現這些目標其實都是為了：提高團隊效率。
給予：華頓商學院最啟發人心的一堂課：Give and Take。
當初跟某位長輩聊到，在職場上，應該要用怎麼樣的態度面對其他人？應該要完成其他人的期待嗎？還是要以自己的利益主？或是有其他的思考方式。
他給我的建議是：當個給予者(giver)。
剛開始工作的時候，總覺得寫文件很麻煩，程式寫完，會動、執行結果正確不就沒事了嗎，為什麼要寫一堆惱人的文件或註解，麻煩死了，自己寫的東西怎麼可能會忘記？
結果過了一陣子回來看自己半年前寫的東西，有些還真的不知道發生什麼事了，完全沒印象當初怎麼會這樣寫，或者是有些操作流程忘記了，導致沒辦法正常執行某些程序。
這個時候才後悔當初自己為什麼沒有留下一些文件可以參考。
總之，要寫文件，還要有一些方向，這篇主要就是想要聊一下兩件事，一、寫文件的目的跟好處，二、怎樣的內容需要文件化。
適度的分層可以幫助我們整理、歸類程式，維持程式庫的整潔性，除了方便我們管理程式，日後團隊協作時，也可以以依照層級劃分工作，促進團隊開發效率，也能降低溝通成本。
相信大家沒聽過Laravel也聽過別人吹捧Laravel XD
總之使用Laravel到現在大概過了一年，想說來記錄一下這一年來的想法和心得。
試著從另一個角度來看「單一職責原則(Single Responsibility Principle, SRP)」，我覺得它想討論的其實是一種如何整理程式的思維。
想像一下，一個亂七八糟的書櫃，隨意擺放不同類型的書，數量少的時候，也許我們可以記得每本書的位置，但是當數量變多，可能幾百本，想要快速地從書堆中找到想要的書，幾乎變得不可能。
但如果我們有事先將書籍依照類型整理，比如，小說、科普、散文、漫畫等類型，我會知道我現在要找的書，是哪一種類型，這樣立刻就縮小了搜尋範圍，讓我們可以快速地的找到想要的書籍。
在討論程式之前，先想像一下，如果一塊沒有良好都市計畫的土地，最後會發展成什麼樣子？
由於沒有良善的規劃，隨著人口增加，越來越壅擠的住宅空間，越來越雜亂的市容，原有道路交通設施的供給不足，天天都在塞車。即便要進行都市更新或是新建重大交通設施，要面臨的將是巨大的成本與溝通。
最近在某些機緣下，有機會可以將自動化單元測試導入我們團隊，
由於我們團隊對於單元測試較無經驗，
在引入的過程中，應該會遭遇一些問題，
所以我想將這段引入的過程跟我的想法記錄下來，以供日後檢討與反思。
不曉得大家有沒有聽過這個法則？應該或多或少有聽過，那我自己對80-20法則有這樣的解釋方式：
80%的產出，來自於20%的時間／心力。
更進一步說80、20對我來說只是虛數，其實可以翻譯成：
大部分的產出，來自於少部分的時間／心力。
或是反過來說：
大部分的時間，花在無產出的事情上。
每個人大學快畢業的時候，都會面臨選擇，是繼續念研究所，還是離開學校就業、或是趁年輕還有精力時圓夢？大四時，我跟隨同學的腳步，送出了推甄的申請，後來也幸運錄取了，那是還不錯的系所，所以我當時相當開心。
只是這樣的開心並沒有持續太久，在愉悅的心情沉澱下來後，我開始進行仔細地的自我評估，考慮了各種面向，包含自己的個性和能力、念研究所的目的與收穫、以及未來職涯等等，終於在經歷一段掙扎後，決心放棄錄取資格。
文章開始前稍微補充一下個人背景，給大家一個參考依據，簡單來說，我大學就讀的是資訊相關科系，算是前段的大學，並且成績維持在中上。
在反思的過程中，我透過不斷詢問自己的方式，來評估自己是否要唸研究所，像是：是因為比較好找工作嗎？是因為起薪比較高？或是我對研究有熱誠？還是只是大家都在唸我也去唸一下好了？