原創： 丶平凡世界
公衆号：SQL資料庫開發
原文連結：
https://mp.weixin.qq.com/s/z4I16VNgZsqdhbp0AwfTvQ
最近一直在忙公司的一個SQL項目，好久都沒有給小夥伴們寫原創文章了。
趁着項目上線的空閑，給大家總結一下，在開發項目過程中遇到的一些問題。之是以說它是"失敗的"項目，是因為遇到的一些問題是完全可以避免，即使最後按要求完成了任務需求。
項目背景
公司新上線了一套OA系統，希望将公司成本類的真實資料實時反應到報表上，并且使用新的OA系統來呈現。希望從各個角度監控公司在産品開發上所花的成本情況。
已有資源
成本類的部分資料已經存在于BI報表平台，每天都有更新，這些業務邏輯的名額可以直接從BI報表平台擷取。
待開發内容
此次項目開發需求新增了不同時期的名額對比，部分名額的經營曲線。
遇到的問題
1、需求未明确
在項目開發過程中，因為是公司内部開發，沒有明确的需求文檔，都是依靠口口相傳，或通過郵件等來确認名額定義。
可能有些同學對需求這方面不太了解，覺得我表述清楚，你做出來就是了呀。道理是這個道理，但是這個做出來的過程，如果有很多不确定的因素存在，那麼就會極大的影響開發效率。
在每開發一個名額之前，總是需要人再三确認才能開始寫代碼。開發過程中還是遇到一個“我以為”是這樣，而實際上并非是這樣的名額。導緻之前寫的邏輯需求推翻重寫。
2、整體未規劃好
整個項目，看着不大，無非就是新增幾個版本對比和一些曆史記錄曲線而已。正是由于這種想法，導緻一開始沒有一個整體的規劃，代碼寫到哪裡就是哪。
原本有一些可以複用的代碼，最後還是一個個單獨使用。導緻後續因為修改代碼邏輯，得一個一個的全部再修改一遍。
如果前期規劃好，可以将能複用的代碼做成視圖，把其他邏輯需要的字段予以保留，在開發其他邏輯時直接使用該視圖即可。
例如，有一個總成本費用，需要看到各個項目的總成本，各個區域公司的總成本，以及集團的總成本。從項目——>區域公司——>集團這是一個非常清晰的向上彙總邏輯。
隻需要把項目的總成本做成視圖，在取區域公司和集團的資料時，向上彙總項目的總成本即可。
但因為沒有做前期規劃，從一開始做成了從集團——>區域公司——>項目的邏輯，導緻每一個都是獨立的代碼，這樣就浪費了很多開發時間和後續的邏輯修改時間。
3、代碼版本未控制
剛開始在沒有遇到頻繁的修改邏輯時，代碼檔案的名稱直接按照代碼的功能進行了命名。等到後來邏輯頻繁的修改後，儲存的代碼檔案越來越多，名稱也越來越亂。因為沒有使用版本控制，已經分不清最後正确的檔案是哪個了。
說到底還是對項目開發不夠重視，比較随性，當然這也有項目整體規劃不足的原因。
如果在一開始就想到這些問題，給每個邏輯代碼加一個版本編号就可以很好區分問題了，同時也可以做好版本對比。
可取之處
1、業務邏輯清晰，注釋完整
不管業務邏輯如何修改，每次修改後的代碼，都會在其中更新目前代碼的功能和注釋，以防下次更新時不知道代碼片段意義。
但是與标準的代碼聲明還是有差别，标準的代碼聲明如下：
/*
代碼功能：XXXX
作者：XXX
修改人：XXX
建立日期：XXXX
修改日期：XXXX
*/
--代碼片段功能注釋
SQL代碼
SQL代碼 ...
由于整個項目由我負責，是以沒有寫作者和修改日期等内容。
2、代碼執行效率較高
雖然開發的項目資料量較小，但是考慮到未來資料量增多帶來的效率問題，代碼統一做了優化處理。
最基本的優化處理方法就是減少傳回的資料行，盡量保持代碼的簡潔。具體的優化方法可以檢視公衆号裡的曆史文章，這裡就不贅述了。
3、将所有功能單獨做成視圖
由于要内嵌到OA系統，減少代碼在OA系統上産生不可預見的異常，将報表的所有邏輯功能均建立為視圖，OA系統直接查詢視圖即可傳回所需的資料。
類似這種跨系統之間的資料傳輸，視圖是比較好的規避異常的方式，在排查異常時隻需檢查視圖上的查詢邏輯即可。
反思
從上面的問題可以發現，一個優秀的項目：
首先要明确業務需求，磨刀不誤砍柴工，需求不明确乃開發大忌；
其次需要有一個整體的規劃然後才能實施，什麼地方可以簡化開發步驟，什麼地方可以優化需要安排好；
最後要對代碼的版本進行控制，不管是使用工具，還是在做一些小項目手動控制。
總結
從這個簡單的項目中發現，我在開發方面能力尚可，但是項目管理方面的經驗不足。導緻開發效率較低，這也為以後開發新的項目做了一個很好的警醒。
從失敗中總結，從失敗中成長，希望這個“失敗的”項目對你有所啟發和幫助。