資訊專欄INFORMATION COLUMN
摘要：另外，圖中淡紫色的圖標(biāo)是在我目前的開(kāi)發(fā)流程中沒(méi)有或者體現(xiàn)的并不明顯的地方。五上線前多人代碼目的很簡(jiǎn)單和每一位涉及的開(kāi)發(fā)人員核對(duì)每一行代碼的變動(dòng)，防止誤提交被發(fā)布到線上。把上線的推進(jìn)權(quán)利集中到一個(gè)人的手上，梳理并核對(duì)發(fā)布順序，最終完成上線。
前言
突然想聊聊開(kāi)發(fā)流的東西，可能在一個(gè)新的環(huán)境下對(duì)之前的整個(gè)開(kāi)發(fā)流程有了些思考，思考什么？
我所理解的一個(gè)高效的開(kāi)發(fā)流程應(yīng)該是什么樣的？我所理解的開(kāi)發(fā)流
實(shí)際工作也有四年了，做互聯(lián)網(wǎng)開(kāi)發(fā)也三年了，所以自然而然對(duì)整個(gè)軟件開(kāi)發(fā)流程有了些自己的想法和理解。對(duì)于我所理解的開(kāi)發(fā)流程要有如下的特點(diǎn)：
盡可能的把問(wèn)題暴露在開(kāi)發(fā)時(shí)間周期的前期(凡事無(wú)完美，盡可能的想一些措施做好輔助即可)
養(yǎng)成好的開(kāi)發(fā)習(xí)慣去避免犯錯(cuò)
如下圖，是我整理的我所理解的一套開(kāi)發(fā)流程：
上圖中，我們?cè)陂_(kāi)發(fā)過(guò)程中隨著時(shí)間線的前移，我們犯錯(cuò)的概率盡可能的集中在前面。另外，圖中淡紫色的圖標(biāo)是在我目前的開(kāi)發(fā)流程中沒(méi)有或者體現(xiàn)的并不明顯的地方。
需要多帶帶說(shuō)說(shuō)的地方為什么需要技術(shù)評(píng)審？當(dāng)然這里需要技術(shù)評(píng)審的應(yīng)該是一些體積大或者影響面比較大的項(xiàng)目，具體的評(píng)判標(biāo)準(zhǔn)就依環(huán)境而定了。
技術(shù)評(píng)審的目的，一方面，開(kāi)發(fā)人員向負(fù)責(zé)人和相關(guān)人員同步具體的技術(shù)實(shí)施方式，是一個(gè)信息同步的過(guò)程；另一方面，負(fù)責(zé)人或相關(guān)負(fù)責(zé)人對(duì)技術(shù)方案進(jìn)行評(píng)估，畢竟負(fù)責(zé)人和相關(guān)人員是對(duì)系統(tǒng)整體了解最透徹的人，從而避免未來(lái)項(xiàng)目開(kāi)發(fā)完了或者上線了才發(fā)現(xiàn)一些比較大的問(wèn)題。
最后，技術(shù)評(píng)審?fù)ㄟ^(guò)后，相應(yīng)的開(kāi)發(fā)人員寫(xiě)代碼也可以一蹴而就，安安心心的碼代碼，是吧？
二、代碼建模建模也不是我第一次談到了，具體的實(shí)例在我之前的文章里也能找得到，我為什么這么強(qiáng)調(diào)建模？因?yàn)榻?就是抽象)之后寫(xiě)出來(lái)的代碼往往思路清晰，高可擴(kuò)展。
三、習(xí)慣性個(gè)人diff代碼①commit代碼前diff代碼?、趍erge代碼前diff代碼 ③上線前多人diff代碼
以上是我一定會(huì)去diff代碼的場(chǎng)景，目的很簡(jiǎn)單，一：是不是誤提交了代碼 二：簡(jiǎn)單的code review
四、code reviewcode review 的最佳時(shí)間我一般建議是開(kāi)發(fā)完成時(shí)或聯(lián)調(diào)階段，因?yàn)檫@段時(shí)間業(yè)務(wù)代碼基本是一個(gè)穩(wěn)定的版本了。至于這個(gè)時(shí)間之前，代碼不穩(wěn)定；至于這個(gè)時(shí)間之后，review出問(wèn)題再修改代碼的成本(浪費(fèi)測(cè)試的時(shí)間)會(huì)比較高。
五、上線前多人diff代碼目的很簡(jiǎn)單：和每一位涉及的開(kāi)發(fā)人員核對(duì)每一行代碼的變動(dòng)，防止誤提交被發(fā)布到線上。
六、上線流程這個(gè)一般出現(xiàn)在多項(xiàng)目上線的情況，涉及多項(xiàng)目的發(fā)布依賴關(guān)系，為了保證最終按正確順序的串行上線。把上線的推進(jìn)權(quán)利集中到一個(gè)人的手上，梳理并核對(duì)發(fā)布順序，最終完成上線。
七、異常監(jiān)測(cè)例如后端系統(tǒng)的話，觀察系統(tǒng)的3xx、4xx、5xx異常日志曲線在上線后是不是有突然的上升趨勢(shì)來(lái)判斷我們的上線是否正常。
掃面下方二維碼關(guān)注我的技術(shù)公眾號(hào)，及時(shí)為大家推送我的原創(chuàng)技術(shù)分享
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/28696.html
摘要：最后，我們用和適當(dāng)?shù)莫?dú)特后綴來(lái)標(biāo)注數(shù)據(jù)流。將數(shù)據(jù)流分離到兩個(gè)不同的目的地在這里，我們解析自動(dòng)定量日志，管理我們的緩沖區(qū)，查詢和區(qū)塊大小。 也許你對(duì)Fluentd的統(tǒng)一日志記錄層已經(jīng)有所耳聞?？赡苣銓?duì)日志是流不是文件這個(gè)概念也已經(jīng)很熟悉，所以現(xiàn)在就讓我們用這個(gè)方法來(lái)思考日志層。事實(shí)上，最后導(dǎo)致決定性的一點(diǎn)就是fluentd是如何被配置的。全部都是關(guān)于我們?nèi)绾翁幚韘tream的不同元素的：...
摘要：這里引出了一個(gè)概念，就是數(shù)據(jù)流這個(gè)概念，在項(xiàng)目中我將所有數(shù)據(jù)的操作都成為數(shù)據(jù)的流動(dòng)。 最近重構(gòu)了一個(gè)項(xiàng)目，一個(gè)基于redux模型的react-native項(xiàng)目，目標(biāo)是在混亂的代碼中梳理出一個(gè)清晰的結(jié)構(gòu)來(lái)，為了實(shí)現(xiàn)這個(gè)目標(biāo)，首先需要對(duì)項(xiàng)目的結(jié)構(gòu)做分層處理，將各個(gè)邏輯分離出來(lái)，這里我是基于典型的MVC模型，那么為了將現(xiàn)有代碼重構(gòu)為理想的模型，我需要做以下幾步： 拆分組件 邏輯處理 抽象、...
摘要：最近在寫(xiě)公司活動(dòng)頁(yè)的時(shí)候，由于歷史原因，活動(dòng)頁(yè)跟公司的主站點(diǎn)放在同一個(gè)下，且活動(dòng)頁(yè)的訪問(wèn)路徑也是在主站之后，并未單獨(dú)分配二級(jí)域名。 最近在寫(xiě)公司 h5 活動(dòng)頁(yè)的時(shí)候，由于歷史原因，活動(dòng)頁(yè)跟公司的主站點(diǎn)放在同一個(gè) repo 下，且活動(dòng)頁(yè)的 url 訪問(wèn)路徑也是在主站之后，并未單獨(dú)分配二級(jí)域名?，F(xiàn)在想著將活動(dòng)頁(yè)面項(xiàng)目單獨(dú)拆分出來(lái)。 現(xiàn)有小問(wèn)題 現(xiàn)有項(xiàng)目中也有幾點(diǎn)不好在這也說(shuō)一下: ng...
摘要：好好打基礎(chǔ)，然后多嘗試不同風(fēng)格的框架，因?yàn)橹挥袊L試過(guò)后才能理解比如徐飛提到的各種權(quán)衡，也只有嘗試過(guò)后才能知道哪個(gè)能真正提升自己的開(kāi)發(fā)效率。 今天看了幾篇關(guān)于這三個(gè)主流框架的PK，如標(biāo)題：react.js,angular.js,vue.js學(xué)習(xí)哪個(gè)好？相信每個(gè)人都有這種問(wèn)題。 現(xiàn)在的前端框架層出不窮，作為前端開(kāi)發(fā)者何去何從？fackbook的react.js盛世火熱，react nati...
閱讀 3409·2021-09-22 15:01
閱讀 535·2019-08-30 11:11
閱讀 965·2019-08-29 16:17
閱讀 1218·2019-08-29 12:23
閱讀 2036·2019-08-26 11:48
閱讀 3189·2019-08-26 11:48
閱讀 1427·2019-08-26 10:33
閱讀 1938·2019-08-26 10:30
