前言

會不會寫代碼，很大一個衡量標(biāo)準(zhǔn)是，你寫完代碼以后花多少時間在調(diào)試代碼上面。

調(diào)試代碼的時間花費和很多都有關(guān)系，作為框架設(shè)計者，或者機制設(shè)計者，如何讓使用框架的小伙伴能方便的調(diào)試數(shù)據(jù)和找出相關(guān)問題，這個是我們要思考的。

今天給大家分享框架設(shè)計中方便定位錯誤的幾個點，供大家參考。

01 保證每個模塊數(shù)據(jù)源頭，底層準(zhǔn)確上報與及時的數(shù)據(jù)錯誤日志。

不是所有的小伙伴都懂得框架的全部內(nèi)容，清楚框架的所有流程，對很多人而言，做的模塊清楚就可以了。

比如所有代碼都從main入口開始，初學(xué)者不用管前面OS的一些列復(fù)雜操作。這樣就要求每個模塊有統(tǒng)一的入口來獲取輸入數(shù)據(jù)。

比如網(wǎng)絡(luò)模塊。假設(shè)你懷疑某個網(wǎng)絡(luò)事件沒有收到或數(shù)據(jù)不對，這個時候，只要比對驗證網(wǎng)絡(luò)模塊收到的所有輸入即可。

而框架要做的，就是保證這個模塊輸入的準(zhǔn)確性。比如我底層收到的數(shù)據(jù)一定都傳給了這個模塊，而邏輯開發(fā)者在調(diào)試代碼的時候，就可以從網(wǎng)絡(luò)模塊的收到數(shù)據(jù)的地方來追蹤，而不用管底層是如何取上來的，框架設(shè)計就是要保證傳入的數(shù)據(jù)的準(zhǔn)確性。

底層要保證上報數(shù)據(jù)的準(zhǔn)確性，當(dāng)?shù)讓影l(fā)現(xiàn)數(shù)據(jù)錯誤的時候，要有詳細的打印，必要時拋出異常，從框架層面上保證數(shù)據(jù)的準(zhǔn)確和追蹤錯誤。

當(dāng)?shù)讓訏伋鲥e誤后，可以和框架設(shè)計者聯(lián)調(diào)，這樣不至于到處甩鍋，當(dāng)設(shè)計框架模塊的時候一定要做好異常數(shù)據(jù)的打印日志維護和錯誤斷言。

02 框架機制盡量保證業(yè)務(wù)模塊的工作獨立，移除成本低。

協(xié)作就會有成本，溝通就會有成本?？蚣茉O(shè)計盡量要提供機制，讓開發(fā)各種功能的人的工作盡可能獨立，這樣降低這種溝通成本，而溝通成本中最大的就是聯(lián)調(diào)維護成本。

保證好數(shù)據(jù)的輸入，業(yè)務(wù)代碼給出對外的輸出。而輸出數(shù)據(jù)有可以作為其他模塊的輸入。這樣，開發(fā)人員只要驗證輸入，驗證輸出，核對中間處理邏輯，最壞的情況就是重寫這個模塊，而我們要從機制上保證重寫這個模塊的去掉成本要最低。

這樣移交代碼的時候，如果這個代碼能修正，就修正，如果實在不能修正，移除重寫即可，而移除不會造成系統(tǒng)性崩塌和癱瘓。你可以寫任何代碼，但是5分鐘我能把你的代碼從項目中移除，這個是我奉行的哲學(xué)，即使某些代碼開發(fā)者水平太菜，也不太影響整個項目的代碼質(zhì)量和開發(fā)進度。

03 每個框架機制最好配套使用文檔和調(diào)試的視頻教程。

使用文檔，大家都覺得稀松平常，不就是API的說明文檔么？但其實有這個還不夠，每個機制能配套好對應(yīng)的調(diào)試和跟蹤策略。

我?guī)ы椖堪l(fā)現(xiàn)很多初學(xué)者調(diào)試代碼沒有思路，埋頭就下斷點、就看，出了問題不知道如何下手，如何驗證比對。

調(diào)試方法不難，教一次，大部分人都能學(xué)會。

我?guī)У捻椖亢蛨F隊里面，一般會把重要的一些機制的調(diào)試方法和追蹤思路錄制成視頻，交給大家，這樣溝通成本比較低，同時新來的小伙伴能學(xué)會找問題的思路和方法。

這樣遇到問題大家就不慌，知道如何調(diào)試驗證。

核心開發(fā)只有那么少數(shù)幾個，而如何把這些思想和方法傳遞給其他的小伙伴，是打造一個技術(shù)過硬的核心團隊的根本。

一個人強，沒有用，要大家都強。

我發(fā)現(xiàn)這樣真的能幫助很多的人快速的提升，這也是我做在線教育的萌芽。

我現(xiàn)在做創(chuàng)業(yè)也保留這個習(xí)慣，就是給每個崗位的入職員工錄制視頻，講解目前公司的現(xiàn)狀和主要的運營思路和流程，真的可以節(jié)約很多時間管理成本。

04 框架與項目要盡早引入測試

項目一開始就引入測試，這個也是我?guī)F隊的一個經(jīng)驗。

有些項目，項目都開發(fā)完成了還沒有上android、 iOS做過一次真機測試，一上來就遇到了莫名的閃退。

隨著代碼比較龐大，也不容易調(diào)試出來，導(dǎo)致對整個項目的進度發(fā)生非常嚴重的誤判。

項目都快開發(fā)完了，才發(fā)現(xiàn)性能問題，再去做性能調(diào)優(yōu)，還不知道導(dǎo)致性能低下的是哪個模塊，哪部分代碼。

不要等到最后再爆所有的雷，真正項目管理者一開始就要關(guān)注框架+項目的整體性能穩(wěn)定度等。

我做開發(fā)的時候，每天17:30分，我一定要讓開發(fā)發(fā)一個完成的今天的功能測試包出來，給測試來進行主要的一些測試，并且自己也測試一下,找出一些不好的實現(xiàn)細節(jié)，盡早改正。

而且我要跑主流的我即將發(fā)布的平臺，android，iOS等，盡早發(fā)現(xiàn)問題，項目進度越可控；入口一開始就對質(zhì)量松懈，后面delay的可能性就越大，失敗的可能性就越大。

編輯器開發(fā)的時候沒有問題，不代表發(fā)布到其他平臺沒有問題。同時有重大功能完成后我一定會review代碼。從整體上把控一下代碼質(zhì)量與設(shè)計。

以上是我總結(jié)的框架快速定位錯誤的幾個點，希望能對框架設(shè)計者有所幫助。

盡量多閱讀別人的框架代碼，多看多學(xué)習(xí)，自己體會。

END

你的一切不如意，都源于自身的不強大。

贏得高薪、創(chuàng)業(yè)成功都是建立在強大的技術(shù)基礎(chǔ)之上。

如果我有以上需求，請持續(xù)關(guān)注《我的設(shè)計之道》連載，并積極分享給更多朋友。