建站
咨詢
售后
建站咨詢
新聞中心
科學(xué)的分析方案文檔的利弊
貓會(huì)喵喵，狗會(huì)汪汪，雞會(huì)什么？
創(chuàng)新互聯(lián)建站網(wǎng)站建設(shè)公司，提供成都網(wǎng)站建設(shè)、網(wǎng)站設(shè)計(jì)，網(wǎng)頁(yè)設(shè)計(jì)，建網(wǎng)站，PHP網(wǎng)站建設(shè)等專(zhuān)業(yè)做網(wǎng)站服務(wù);可快速的進(jìn)行網(wǎng)站開(kāi)發(fā)網(wǎng)頁(yè)制作和功能擴(kuò)展；專(zhuān)業(yè)做搜索引擎喜愛(ài)的網(wǎng)站，是專(zhuān)業(yè)的做網(wǎng)站團(tuán)隊(duì)，希望更多企業(yè)前來(lái)合作!
機(jī)會(huì)留給有準(zhǔn)備的人。
先說(shuō)點(diǎn)虛（?）的，等我們的需求或者項(xiàng)目出名了、別人需要學(xué)習(xí)需要你給出一波裝逼Time的時(shí)候，丟出一個(gè)圖文并茂的設(shè)計(jì)文檔?？隙ū葋G一個(gè)代碼倉(cāng)庫(kù)獲得的敬仰多吧？
或者說(shuō)點(diǎn)實(shí)在的等回頭職級(jí)評(píng)審的時(shí)候，一個(gè)復(fù)雜的需求你都想不起來(lái)怎么設(shè)計(jì)的了還得現(xiàn)畫(huà)流程圖貼代碼貼效果......（噓！）
掌控力
先說(shuō)說(shuō)對(duì)個(gè)人成長(zhǎng)的意義，
往日我們提到前端最大的優(yōu)勢(shì) -- 所見(jiàn)即所得。
要說(shuō)這確實(shí)上手門(mén)檻低，比起客戶端的編譯動(dòng)輒一根煙（就目前來(lái)說(shuō)咱們客戶端需要一個(gè)小時(shí)編譯，一包煙都抽完了）。服務(wù)端部署還要上云要滾動(dòng)來(lái)看，前端的試錯(cuò)成本實(shí)在是太低了，這是一個(gè)巨大的優(yōu)勢(shì)，特別是在試水的時(shí)候。
如果用一個(gè)模塊的開(kāi)發(fā)比作一道考試題，我觀察過(guò)一些同學(xué)（當(dāng)然包括我自己）都是寫(xiě)幾行切一下屏幕看看情況，但那就好比推導(dǎo)寫(xiě)完第一行就去對(duì)標(biāo)準(zhǔn)答案一樣。獲得的是很碎片化的思路，長(zhǎng)期這樣少了一些 “服務(wù)端式” 的錘煉，對(duì)較大的模塊或是復(fù)雜場(chǎng)景就很難在腦海中形成一個(gè)比較清晰的響應(yīng)。
技術(shù)方案可以在一定程度上起到強(qiáng)制大家先想好再寫(xiě)的作用，補(bǔ)上這部分練習(xí)。時(shí)間久了貌似就能發(fā)現(xiàn)自己能在腦子里推導(dǎo)整個(gè)代碼的運(yùn)行狀態(tài)了，這樣bug率就會(huì)自然而然的低下來(lái)，也更容易做出一些前瞻性的設(shè)計(jì)。
當(dāng)然我最初的想法其實(shí)只是留下一份好得設(shè)計(jì)文檔可以供以后維護(hù)代碼或者需求或者方案的人能夠知道最初的開(kāi)發(fā)者到底是怎么思考的，如何設(shè)計(jì)的。以及有哪些隱性的問(wèn)題可以從文檔中找到答案，讓開(kāi)發(fā)人員的心智負(fù)擔(dān)更低。但近一段時(shí)間的思考和詢問(wèn)讓我覺(jué)得上面這些問(wèn)題也有必要說(shuō)出來(lái)。但是否需要先寫(xiě)文檔再繼續(xù)開(kāi)發(fā)這點(diǎn)我覺(jué)得到要看具體的落地場(chǎng)景。
試錯(cuò)
俗話說(shuō)，船小好調(diào)頭。
我相信大家一定都有這樣的經(jīng)歷：比如我們需要寫(xiě)一個(gè)精巧的多模塊重業(yè)務(wù)的組件。
一開(kāi)始模塊劃分非常合理，狀態(tài)傳遞井井有條，然后QA提了一個(gè)BUG，在X條件下X元素的位置沒(méi)有對(duì)齊，于是需要補(bǔ)一個(gè)透?jìng)麈溌穫鞯侥骋粋€(gè)sub組件里，或是Sub組件需要一路開(kāi)回調(diào)開(kāi)到頂層之類(lèi)的?；蚴悄阍O(shè)計(jì)了一個(gè)完美的組件，然后PM說(shuō)，我需要在X條件下加一個(gè)X元素位置在X坐標(biāo)，并在后續(xù)的一個(gè)月時(shí)間內(nèi)增加了Y、Z、α、δ.......
當(dāng)然這還算好得，更坑爹一點(diǎn)的是，可能開(kāi)發(fā)末期發(fā)現(xiàn)， 誒？？我怎么特么不把這幾個(gè)組件抽成一層讓他來(lái)負(fù)責(zé) XXX 然后集中在 XXX 里 XXX 呢？------ 算了來(lái)不及了等下次重構(gòu)吧 、 下個(gè)需求在重構(gòu)吧 、這特么這么多東西重構(gòu)成本太高PM不會(huì)同意的 就這樣吧。
有了更好的思路，卻因?yàn)闀r(shí)間和工期卡點(diǎn)的原因無(wú)法訴諸實(shí)現(xiàn)，只能被迫補(bǔ)丁上線的感覺(jué)，相信我這并不好受。打開(kāi)beetle看看上線分支，序號(hào)都快四位數(shù)了？
而方案就能很好的避免這一切，比如在方案進(jìn)行的過(guò)程中發(fā)現(xiàn)了這個(gè)問(wèn)題，可能還沒(méi)到模塊設(shè)計(jì)階段，后面直接就按更好的方向去設(shè)計(jì)了，或者只是改幾個(gè)圖就行。因?yàn)檫€沒(méi)進(jìn)入Coding階段，進(jìn)行大塊的調(diào)整，一般都沒(méi)什么風(fēng)險(xiǎn)，就算真有，如果在項(xiàng)目前期提出 叫“風(fēng)險(xiǎn)”，在項(xiàng)目末期提出那就變成“事故”了
當(dāng)然文檔不是萬(wàn)能的，我相信這世上不存在一勞永逸的事情。但我相信這能避免大多數(shù)此類(lèi)問(wèn)題，能減少多少會(huì)隨著代碼掌控力的提升同步提升。具體怎么做會(huì)在下述中展開(kāi)。
回憶
- 溝通成本與記憶成本
隨著業(yè)務(wù)復(fù)雜度的提升，能夠單打獨(dú)斗的項(xiàng)目會(huì)越來(lái)越少，更多的項(xiàng)目會(huì)要求大家合作進(jìn)行（后端合作也是合作-不是），也有很多時(shí)候會(huì)隨著時(shí)間推移加入進(jìn)來(lái)共同開(kāi)發(fā)，此時(shí)有個(gè)文檔給新同學(xué)介紹，起碼能節(jié)約本人70%的口舌吧。（特別是我們作為開(kāi)發(fā)人員口舌也不是特別好得情況下，應(yīng)該也沒(méi)人愿意一整天給新同學(xué)講解吧。）
在剛開(kāi)始的時(shí)候，凡事兒寫(xiě)文檔里再說(shuō)確實(shí)會(huì)在短期內(nèi)提升溝通成本，但是隨著開(kāi)發(fā)進(jìn)度過(guò)半，大家的記憶力開(kāi)始逐漸衰退的時(shí)候，開(kāi)頭寫(xiě)的方案可以起到的喚醒記憶的作用就會(huì)逐漸凸顯。
- 代碼之外的額外信息（我認(rèn)為目前最重要的部分）
從代碼中，大部分時(shí)候我們只能看到他做了什么事情，但是“不做的事情” 其實(shí)也是很重要的信息。比如有時(shí)候看代碼你可能會(huì)疑惑，這里怎么不做個(gè)緩存呢？這里怎么不加個(gè)回調(diào)呢？這里為啥......
不做的事情無(wú)法通過(guò)代碼本身來(lái)傳達(dá)，但是如果在方案中有討論，并記錄。就可以很好的解答這部分的疑惑。并且也可以在方案中宣講自己設(shè)計(jì)的動(dòng)機(jī)，不僅講 what 還講 how，加深參與同學(xué)的理解，降低這個(gè)同學(xué)的心智負(fù)擔(dān)。就可以避免你設(shè)計(jì)的精美的模塊被來(lái)支援的同學(xué)隨便加了個(gè)跨組件的回調(diào)，再被后來(lái)入職的萌新同學(xué)濫用導(dǎo)致最后變成屎山。
When i wrote this, only God and I understood what I was doing.
Now, God only knows
套路化的文檔解決方案（當(dāng)然這是我的套路 - 一家之言）
其實(shí)這個(gè)也是一篇文檔，也能看出我的性格和風(fēng)格是比輕松而無(wú)拘無(wú)束的，（你以為我是瞎寫(xiě)？其實(shí)我就是瞎寫(xiě)的。瞎寫(xiě)又不用有負(fù)擔(dān).jpg）
方案文檔通常要包含一些必要信息，只要信息到位了，章節(jié)標(biāo)題我認(rèn)為可以隨意發(fā)揮。
簡(jiǎn)單來(lái)說(shuō)就是：
- 我要干什么
- 我要怎么干
- 我為什么要這樣干（我為什么不那樣干？）
- 當(dāng)然還有我比較關(guān)注的：你是不是有啥坑需要標(biāo)注一下。
那我們就娓娓道來(lái)，這幾部分應(yīng)該如何展開(kāi)。
我要干什么?
這一階段我想把他稱(chēng)之為 需求分析， 隨著我們的level提升，對(duì)語(yǔ)焉不詳?shù)男枨蟮某薪幽芰π枰粋€(gè)提升。
明確產(chǎn)品的需求
萌新階段，產(chǎn)品：“抄這個(gè)”，這種需求要我我肯定懟回去了。（其實(shí)我沒(méi)膽子懟，都是鈺哥懟的）。但是很多時(shí)候?qū)τ谝恍?fù)雜場(chǎng)景并不是產(chǎn)品自己可以hold住的，也會(huì)提前接觸部分技術(shù)同學(xué)進(jìn)行預(yù)研，我們需要把產(chǎn)品不明確的需求轉(zhuǎn)變?yōu)槊鞔_的需求，進(jìn)而轉(zhuǎn)變?yōu)榧夹g(shù)描述的需求。
在小風(fēng)還沒(méi)走的時(shí)候，他經(jīng)常問(wèn)我一些問(wèn)題，大部分都是這種情況。當(dāng)然我感覺(jué)我已經(jīng)鍛煉的還可以了。
比如“抄這個(gè)” 這種需求，我們就可以進(jìn)一步追問(wèn)來(lái)獲取更多細(xì)節(jié)（其實(shí)想想我做的也不好，我大部分說(shuō)的都是 都可以做排期就行了，但其實(shí)我沒(méi)概念。），到比如“你是不是想抄他的這個(gè)布局機(jī)制，為了這個(gè)機(jī)制有這樣的利這樣這樣的弊，我們可以這樣這樣，你看怎么樣”，這時(shí)候我們的段位就高起來(lái)了。也能更好的讓我們有更多機(jī)會(huì)去接觸產(chǎn)品設(shè)計(jì)，讓技術(shù)更多的融入產(chǎn)品。這一過(guò)程是一方面是協(xié)助產(chǎn)品明確自己想要的東西到底是什么，另一方面也是幫你自己減少后續(xù)風(fēng)險(xiǎn)點(diǎn)。
拆解為技術(shù)點(diǎn)
明確了產(chǎn)品的訴求之后，我們就需要再把產(chǎn)品的需求轉(zhuǎn)變?yōu)榭梢员患夹g(shù)描述的需求。并且先給定優(yōu)先級(jí)，有些需要取舍的場(chǎng)景可能會(huì)需要這個(gè)。
拿之前奢侈品的篩選需求來(lái)舉例子，大概就能拆成這么幾塊。
- 產(chǎn)品想要一個(gè)通用的篩選組件（基礎(chǔ)能力）
- 產(chǎn)品想要在這個(gè)通用的能力上大有作為做一大堆事情，期望能把配置化做好，能提供解決產(chǎn)品各種各樣稀奇古怪的要求的能力。（明確要做到的技術(shù)點(diǎn)）
我要怎么干，我為什么要這么干？（上）
一般寫(xiě)方案文檔有兩種情形
- 我基本已經(jīng)有了較為明確的思路，我需要論證他的可行性。
- 我是誰(shuí)，我在哪，我怎么就tm接了這個(gè)活？這玩意兒咋做？毫無(wú)思路！
對(duì)于第一種，我認(rèn)為，我思考這個(gè)問(wèn)題的時(shí)候已經(jīng)有了大致思路，接下來(lái)就是在紙上進(jìn)行推演，避免落地后翻車(chē)。這種暫時(shí)先不展開(kāi)，后邊會(huì)討論到。
那第二種對(duì)于一個(gè)無(wú)從下手的方案，我該如何展開(kāi)呢？
我認(rèn)為該有這么一節(jié)：【方案思路】
怎么說(shuō)呢，寫(xiě)方案之前肯定也沒(méi)啥思路，但是隨著這一節(jié)的討論，我的思路會(huì)逐漸清晰，我完全明白應(yīng)該怎么做了！（其實(shí)我也沒(méi)經(jīng)歷過(guò)這一步，后續(xù)的技術(shù)需求可以這么搞。）
梳理核心鏈路
大多數(shù)調(diào)研類(lèi)需求都會(huì)涉及一個(gè)“如何打通XX”的問(wèn)題，這樣的需求大多可以歸納成為一條或多條核心鏈路，然后圍繞著如何確保核心鏈路順利運(yùn)轉(zhuǎn)來(lái)展開(kāi)。所以對(duì)于這類(lèi)需求，第一件事：先畫(huà)流程圖。
以我之前做過(guò)的停留時(shí)長(zhǎng)來(lái)舉例 - 需求是停留時(shí)長(zhǎng)，停留時(shí)長(zhǎng)是怎么被計(jì)算的呢？這一套鏈路是什么。如果需要多端適配，那么每個(gè)端的這套鏈路如何被打通呢?
組件設(shè)計(jì)類(lèi)方案則不一定會(huì)有如此顯著的流程圖，可能更注重模塊劃分，比如比較復(fù)雜的頁(yè)面有20個(gè)組件，他們之間說(shuō)是相互獨(dú)立但又有微妙的聯(lián)系，不過(guò)即便如此，也并不是沒(méi)有核心鏈路， 可能是需要提煉。（這一點(diǎn)在和浪總多次的希望zzui能夠提供一些組件時(shí)能很好的體現(xiàn)，我們并不能給浪總說(shuō)我這個(gè)需求是啥，而是需要提煉一下，我需要zzui提供一個(gè)什么樣的組件，他需要有什么樣的能力，和一個(gè)什么樣的API讓我使用。）
這里可能也有一些經(jīng)驗(yàn)層面的判斷在里面，如果大家要是拿捏不準(zhǔn)我覺(jué)得可以拋出來(lái)大家討論一下。
舉個(gè)例子吧
- 比如篩選組件，核心在于 - 多組件之間的聯(lián)動(dòng)和數(shù)據(jù)解析。
- 比如停留時(shí)長(zhǎng)，核心在于 - 計(jì)算之后的數(shù)據(jù)應(yīng)該在什么時(shí)間節(jié)點(diǎn)發(fā)送且數(shù)據(jù)如何保存。當(dāng)然這還伴隨著多端兼容的問(wèn)題
篩選組件的核心鏈路
細(xì)化流程
確定了核心鏈路之后，就需要進(jìn)一步細(xì)化了。怎么細(xì)化呢？- 靠捫心自問(wèn)。
我和一位大佬聊天的時(shí)候聽(tīng)他講過(guò)信息論的一些東西，最讓我印象深刻的叫做：“信息是不確定性的減少”。什么意思呢？比如我現(xiàn)在有一個(gè)比較復(fù)雜的需求，還需要server的同學(xué)提供一些能力。我需要盤(pán)一下手頭的信息，然后整理一波，問(wèn)問(wèn)自己要做這個(gè)事情還差什么。（到目前為止主要差時(shí)間和想法）
比如前期：
- 是不是要用到一些奇奇怪怪的知識(shí)點(diǎn)？比如webRTC、webSocket之類(lèi)的，我不會(huì)？怎么辦？，那方案里標(biāo)記一下我不會(huì)（然后學(xué)）
- 比如用到一個(gè)第三方的庫(kù)或者解決方案，怎么用？不知道。得去看一下。
- 怎么對(duì)接服務(wù)端？不知道，需要問(wèn)服務(wù)端的兄弟或者讓他們給出文檔。
然后上面第一輪問(wèn)題問(wèn)了一遍，繼續(xù)問(wèn)自己第二輪
- 我和server端的鏈接是否是穩(wěn)固的？斷線了斷網(wǎng)了咋整？
- 服務(wù)端和RTC穩(wěn)固嗎？？
類(lèi)似這種問(wèn)題，當(dāng)然第二點(diǎn)貌似看起來(lái)不需要我太去關(guān)心，但是我認(rèn)為還是問(wèn)一下比較穩(wěn)妥。萬(wàn)一這個(gè)問(wèn)題去問(wèn)服務(wù)端的同學(xué)說(shuō)不定他們沒(méi)想到但是被你提醒以后風(fēng)險(xiǎn)-1
那還可以換個(gè)方向問(wèn)
- 前端會(huì)出現(xiàn)什么意外需要處理嗎？
- server端會(huì)出現(xiàn)什么意外，導(dǎo)致我需要處理嗎？
這些疑問(wèn)又會(huì)讓我們催生出更加完整且有強(qiáng)度的設(shè)計(jì)。
還有一些常規(guī)問(wèn)題。
- 這套方案的api該怎么設(shè)計(jì)。我需要讓別人怎么用，接入成本小一些？
- 如果方案過(guò)于復(fù)雜是不是這套方案就行不通？是不是該放棄這個(gè)想法？
類(lèi)似， 總之就是不斷給自己的方案挑刺的過(guò)程，用一輪一輪的badcase來(lái)惡心自己，看看自己的方案能否扛住。
就我之前停留時(shí)長(zhǎng)的經(jīng)歷來(lái)說(shuō)，我對(duì)于走一步看一步的實(shí)現(xiàn)感到非常的畏懼。一遍一遍的寫(xiě)出來(lái)卻遇到了各種各樣的問(wèn)題非常折磨人，而且代碼一遍一遍的改，到后邊根本就不在意代碼怎么組織了，只想快點(diǎn)完成這個(gè)任務(wù)。
經(jīng)過(guò)一輪又一輪的“捫心自問(wèn)”，我們會(huì)發(fā)現(xiàn)一系列的不確定性的東西正在漸漸變少，以往這些沒(méi)想明白的點(diǎn)在項(xiàng)目中后期會(huì)表現(xiàn)為風(fēng)險(xiǎn)，這個(gè)項(xiàng)目可能就會(huì)相對(duì)穩(wěn)的多。
我傾向于用問(wèn)答的方式來(lái)維護(hù)這些問(wèn)題， 確保是能得到解答的。當(dāng)然我這個(gè)是在最后QA環(huán)節(jié)。當(dāng)然也不是所有問(wèn)題都能找到答案的，解決不了的，那就只能找leader或者拋出來(lái)一起討論了。
最終，所有的問(wèn)題都得到了解答，或者有了臨時(shí)方案頂替不至于捅婁子。那這個(gè)方案就八九不離十了。接下來(lái)我認(rèn)為就進(jìn)入到下一個(gè)階段，模塊設(shè)計(jì)了。
我要怎么干，我為什么這么干？（下）
同樣的標(biāo)題，用了兩次，是因?yàn)檫@兩部分很多時(shí)候是混在一起的起碼是掛鉤的，所以大部分時(shí)候他倆都是寫(xiě)在一起的。至少我貌似就是寫(xiě)在一起的。
比如，我可以方案思路之后直接形成完備的模塊劃分方案。
那模塊劃分到底是什么呢？前半截的思路部分，其實(shí)是挖掘出需求的全貌，降低不確定性，提升技術(shù)性。而這里的模塊劃分，則更偏向于代碼組織，確保設(shè)計(jì)的良好，可行的落地方式。
舉例來(lái)說(shuō)，思路一節(jié)里發(fā)現(xiàn)我們要做的事情有 A,B, CDEFGH。這要這些事全做了，基本這個(gè)大需求就穩(wěn)了。但是落地上肯定不能函數(shù)套函數(shù)塞進(jìn)一個(gè)文件完事對(duì)吧。那其實(shí)我們需要一個(gè)邏輯層面的劃分。
我們把每個(gè)即將分配的模塊都視為一個(gè)個(gè)的工人， 我們接下來(lái)就需要把之前的ABCDEDF分配給這些人。那怎么分呢？這個(gè)就很藝術(shù)了，基于每個(gè)項(xiàng)目的具體情況都有極大地側(cè)重點(diǎn)的不同。這個(gè)就只能具體項(xiàng)目具體分析了。
舉個(gè)例子吧，對(duì)于奢侈品來(lái)說(shuō)大部分的能力是通用的，所以奢侈品的組件需要盡可能的通用。但游戲的需求可能更多更靈活，更流程他就更需要更靈活的組件，等等。而且我們應(yīng)該保證一些指標(biāo)，比如現(xiàn)在在提的加載速度優(yōu)化。（我之前設(shè)計(jì)篩選的時(shí)候就沒(méi)有顧及到這個(gè)）
模塊劃分需要有多細(xì)呢？
其實(shí)把主要的一些大塊拆出來(lái)，能維護(hù)就行了。咱們的需求也沒(méi)有大到那么離譜，還記得我前幾個(gè)月說(shuō)的compositionAPI嗎？hooks拆起來(lái)啊 同學(xué)們！
紙上談兵到運(yùn)籌帷幄
其實(shí)我說(shuō)了這么多也在紙上談兵，對(duì)于我之前踩到的坑來(lái)說(shuō)，我覺(jué)得我可以提供一些想法。
快速展開(kāi)
首先，寫(xiě)方案并不是線性的。并不是思路完全好了以后在去寫(xiě)方案，因?yàn)榍懊嬉蔡岬搅嗽囧e(cuò)，其實(shí)在方案上掉頭的成本還是挺低的。先列出來(lái)一堆問(wèn)題，在去一個(gè)個(gè)解決把他們都記下來(lái)其實(shí)方案就寫(xiě)好一半了。
高效傳達(dá)
圖片 >> 文字
我們都知道視覺(jué)的傳達(dá)比文字更容易理解，所以引入更多的圖，引入更少的直接代碼，都可以很好的幫別人理解你的方案，而良好的圖也可以更好的組織自己的語(yǔ)言。
這也是為什么我認(rèn)為用飛書(shū)寫(xiě)文檔會(huì)好一些，因?yàn)閐ashen畫(huà)圖的體驗(yàn)實(shí)在是太差了。差到極致了！
這里其實(shí)還有個(gè)題外話，以前我畫(huà)圖感覺(jué)很有包袱，比如流程圖必須圓角矩形起止，菱形判斷節(jié)點(diǎn)，（都是大學(xué)論文害的。）但是我的一個(gè)好朋友幫我破除了這個(gè)包袱，whatever，我覺(jué)得重點(diǎn)應(yīng)該是抓住核心：傳達(dá)信息， 只要把想傳達(dá)的信息傳達(dá)到位了，圖其實(shí)丑一點(diǎn)都無(wú)所謂。而且不用嚴(yán)絲合縫的畫(huà)圖其實(shí)真的挺快的。我上一篇例子文檔的3張圖我原本以為要畫(huà)幾十分鐘，結(jié)果10分鐘3張都畫(huà)完了。如果不是什么正式場(chǎng)合，這種非標(biāo)準(zhǔn)的圖我覺(jué)得大家都可以隨便畫(huà)畫(huà)，意思到位就行了。不需要有那么多負(fù)擔(dān)。
顏色的使用（構(gòu)想）
畫(huà)圖的時(shí)候如果有什么側(cè)重點(diǎn)，可以用顏色的變化來(lái)解決這個(gè)問(wèn)題。（當(dāng)然我覺(jué)得這個(gè)可以當(dāng)做職級(jí)評(píng)審時(shí)的一種手段？？）
我覺(jué)得效果還是挺明顯的，不過(guò)這里有一點(diǎn)，顏色應(yīng)該相對(duì)少。因?yàn)?nbsp;都突出 = 都不突出了
回收驗(yàn)證
在方案完畢，開(kāi)始進(jìn)行開(kāi)發(fā)以后，也不是把方案就丟一邊了。我覺(jué)得應(yīng)該在適當(dāng)?shù)臅r(shí)候打開(kāi)方案再看看當(dāng)時(shí)是怎么想的。
- 一開(kāi)始我說(shuō)了對(duì)答案的故事？在開(kāi)發(fā)中也能驗(yàn)證自己的方案設(shè)計(jì)水平。
設(shè)計(jì)模塊是否按預(yù)期落地了？差別有多大？為什么？
選擇性寫(xiě)方案/重復(fù)利用
并不是每個(gè)需求都要寫(xiě)方案，一些小需求排期在1、2天我覺(jué)得就沒(méi)有必要寫(xiě)。方案應(yīng)該對(duì)應(yīng)的是一些自己不能拿到需求就清楚那些東西該劃分成什么樣模塊需要怎么寫(xiě)的時(shí)候才需要寫(xiě)文檔。
當(dāng)PM反復(fù)在對(duì)一次設(shè)計(jì)的文檔中的內(nèi)容反復(fù)進(jìn)行迭代時(shí)，我們應(yīng)該基于該文檔去維護(hù)，而不是重寫(xiě)。這樣也能在重復(fù)整理的過(guò)程中更加清晰的認(rèn)識(shí)這套需求是如何運(yùn)作的，且方案在重復(fù)修改的過(guò)程中，也能知道未來(lái)對(duì)于該項(xiàng)目如何進(jìn)行重構(gòu)。（找到優(yōu)化點(diǎn)進(jìn)行優(yōu)化、是否能更加自動(dòng)化......）
總結(jié)
-- 設(shè)計(jì)階段 --
- 明確產(chǎn)品需求 背景和為什么寫(xiě)清楚。
- 為了完成這個(gè)需求我們具體要做哪些事情。
- 梳理核心鏈路，這一套實(shí)現(xiàn)的核心鏈路流程是怎么樣的。
- 把鏈路的各個(gè)節(jié)點(diǎn)細(xì)化一下，具體我們需要如何實(shí)現(xiàn)這個(gè)節(jié)點(diǎn)。
-- 項(xiàng)目組織階段 --
- 把實(shí)現(xiàn)各個(gè)節(jié)點(diǎn)的抽象邏輯細(xì)化到模塊圖。我們?nèi)绾谓M織這個(gè)節(jié)點(diǎn)。
- 方案并不是一蹴而就的，他可能是伴隨著你的開(kāi)發(fā)而編寫(xiě)的。
- 開(kāi)發(fā)完以后回頭拿方案驗(yàn)證一下落地效果如何，和方案有什么偏差，在去把方案修正一下這就是一份存根文檔。
- 當(dāng)這個(gè)需求有迭代或者功能追增的時(shí)候，這個(gè)文檔就是你下一篇方案的起點(diǎn)。
PS：過(guò)程中遇到各種各樣的意外問(wèn)題，或者一些不尋常的坑記得備注。不僅要寫(xiě)how 還要寫(xiě)why
什么樣的需求需要文檔呢？
舉個(gè)例子：
- 這個(gè)需求需要長(zhǎng)期維護(hù)
- 這個(gè)東西他有一定的復(fù)雜度，他不容易直接從代碼中能窺見(jiàn)整個(gè)需求的全貌。
- 這個(gè)東西需要提供給第三方使用。
- 這個(gè)東西需要各端協(xié)作，有依賴(lài)除業(yè)務(wù)側(cè)技術(shù)外的其他關(guān)聯(lián)，如中臺(tái) 搜索等。
就這么多~ 大家有問(wèn)題可以討論下。我在這里只是提供了我的一些思路。文檔這個(gè)事情我不能要求大家去寫(xiě)，我提出了一些問(wèn)題，也提出了這個(gè)解決辦法。希望大家在遇到上述問(wèn)題時(shí)能用方案文檔的解決方案來(lái)解決。嘔心瀝血之作！希望大家輕噴～～
本文題目：科學(xué)&紙上談兵&前端技術(shù)方案怎么寫(xiě)
網(wǎng)站鏈接：http://m.5511xx.com/article/cdpiiii.html
