最近這段時間，工作稍顯繁忙，沒有太多的時間，進行系統性的總結，僅以最近的一些code review和ci, 寫一點小體會。
codereview, **審查，即在將自己的**merge到主分支之前，程式設計師將自己的分支，與伺服器上的**主分支，建立乙個merge request，指定給有相應許可權的同事。該同事在收到merge request的請求後，對提交者的**進行審查，對**規範，邏輯問題，以及其他**問題，提出修改建議。提交者在收到意見後，針對意見修改後，再次提交merge request. 直至所有的**問題都解決後，將本次merge request的分支合併到主分支。
另一種codereview, 是我所在的工作組內的乙個傳統活動，主要是全組的同事，每週選取乙個特定的時間，然後針對某個同事在某個專案中的**，進行全體的review。一方面是讓大家彼此都能了解各自在做哪方面的工作，另一方面，構建乙個相互之間，切磋編碼水平，相互學習，相互提高的平台。
我依然記得，在我剛參加工作的那一年，公司就有code review的機制。我將自己參加工作後，第一次寫的專案**，提交code review後，收到的上級給我的**評審意見。**量可能也就是100行左右，提的審查意見就有10多條，涉及到了編碼的方方面面的問題。當時，在收到**評審的內容後，真的是有點無地自容，也暗暗的鼓勵自己，以後在提交**時，一定要注意自己的**質量，多多測試，對自己交出去的**負責任。隨著工作的深入，在專案的後期，當我再次提交**審查的時候，已經很少再有需要修改的地方了，很多都可以直接通過審查，合併到主分支。現在想到自己的**，已經在很多的醫院的伺服器上，每天在穩定執行著，心裡面還是有很多成就感的。
組內的code review, 一般則是負責分享的同事，對著**，先講一遍邏輯。然後接下來一周，其他同事進行線下的code review, 然後第二週再集體進行分享，對之前同事的**提出修改建議。
對於自己了解邏輯的**，review起來，更多地是看一些語法方面的問題。
ci的字面意思就是持續整合，主要用於敏捷開發中。由於敏捷的專案是在持續地進行迭代，因此隨著專案不斷地深入，功能特性會越來越多，相應的測試用例也會成倍地增加。
如何能夠保證專案在不斷地迭代開發中，不會因為增加某乙個新的特性而影響原來的功能點；或者是在修復乙個**的bug時，不至於時間太緊迫或別的原因，而導致引入新的bug。
因此，引入持續整合的概念。這樣，每當有新的**提交後，就會觸發**倉庫，對當前的**進行整合，執行過去撰寫的測試用例。這樣，如果某一條測試用例，在前乙個版本的**中可以順利通過；而執行新版本的**後，就無法通過時，就很容易地定位到問題點——到底是，由於測試用例沒有根據新的需求進行更新；還是由於增加新的特性，而影響了原來的邏輯。
ci到底有多麼有用呢？這個或許只有真正體驗到它給自己的工作帶來多少便捷，才有話語權。
就我們專案組而言，自從在某乙個迭代中，專門增加了ci的機制後，大概乙個多月的時間內，已經至少幫我們預防了四五個重要的bug。試想，如果不是ci幫我們測出了問題，一旦專案**部署到生產環境後，造成的損失和修復的成本都會成倍增加。因此，花費一定的時間，在自己的專案中，引入持續整合，將會是乙個事半功倍的選擇！
當然，ci也不是萬能的，也不能把全部的希望都寄託在ci上。因為畢竟ci的**，也是開發撰寫的。ci到底能夠在多大程度上覆蓋所有的測試case，決定了ci的可信度。因此，並不是ci通過了，專案**就一定沒有問題了。因此，我們需要辯證地看待這個問題。
Code Review 之後的總結
1.對於isset和empty的區別 值isset empty a f t a 1tt a nullft array ff 2.intval變數轉成整數型別。在你確認一定是整數的時候，可以加上這個，而且在裡面可以加上號trim 例 intval trim post 3.對於錯誤值，要先判斷是否存在，...
Code Review的最佳實踐
code review是開發者之間討論修改 來解決問題的過程。很多文章談論了code review的諸多好處，包括知識共享，的質量，開發者的成長，卻很少討論審查什麼 如何審查。體系結構和 設計 風格 測試審查 在提交 之前，我經常用git新增改變的檔案 資料夾,然後通過git diff 來檢視做了哪...
CodeReview的幾點思路
這週在公司一直給同事做codereview，感覺還是比較痛苦的，因為一些機制並不是很人性化，至少說，流程上有一些不成熟的環節。和大家一起分享，希望有經驗的朋友給我一下批評建議。方案1 review meeting，即online review。基本不可行。很大程度上依賴於主持者的素質，而且如果主持者...