谈谈个人代码对团队合作影响
這幾天正接手一個項目,屬于后期功能拓展,要拓展這個項目,一定程度上要看到源碼的部分,然后煩心的事情就來了,這代碼寫的真是讓人挺無語的,原先寫完整個項目的是已有多年工作經驗的開發者,但是整個代碼下來,邏輯性不強,單看完整個流程,各個模塊的作用,就花了一兩天的時間,這還沒涉及到代碼部分,缺乏相應的注釋。這也給了我很深的印象和感悟,不管是個人寫代碼,還是團隊合作,對于框架要明確,有結構圖,有相應的注釋,命名規范相當重要,盡管項目不大,也要邏輯分明,這是對于日后拓展和維護都是有好處的,所謂在實戰中學習,真的是學到了好多,寫自己的代碼改動日志,將任務,思路,想法,原先基礎上改動地方全部記錄下來,這對于自己來說真的是很有用的事情,或許寫著日志的時候,項目中不足的地方也會一并解決。
?
具體談談這次項目中看到的哪些不足之處:
???? 首先,在整個框架設計上,就完全是依據要有功能就實現功能的思路來,結果如何呢,造成了很多代碼上的冗余,比如說,在訪問數據庫上,由于這是一個WPF的窗體應用程序,在窗體后臺,直接用上了訪問數據庫的語句,不是單單的SQL語句,而是實在的數據庫訪問,連接數據庫,CRUD操作,一并封裝到了所要的功能中,這里造成了代碼的太多冗余,從框架的角度考慮,本應該是SQLHelper的活,卻被一個人承包了,UI,BLL,DAL,SQLHelper全部集中在一個里面,真的是不敢想象。代碼看完,就在那想,以后的自己真的是不要這樣,畢竟現在就有了仇恨,哈哈。
??? 其次,代碼部分的注釋是相當少,沒有明確的解釋,就連命名上也是大打折扣,使用中文拼英的縮寫作為部分命名,看著這些東西,唉,心累,代碼部分也只是看了我要拓展部分的相關代碼,既然出自同一人之手,并且我看的還是整個項目的主干線,想也知道,其它部分的風格應該如出一轍,不管如何,這一次的拓展工程,真的是學到了太多太多,團隊合作時,需提前進行規范,框架規范,命名規范,這些真的是很重要,想要一個可以日后維護,拓展輕松的項目,那么開始制定計劃的時候就要提前規劃好需要的東西,寧可費點時間,也是值得的。
??? 最后,最想吐槽的一部分就是在于我的拓展需要用到已經搭建好的數據庫,但是當我編寫訪問數據庫的方法時,竟然發現,連數據庫名字都是中文的,這就尷尬了,一個下午找著解決方案,我天吶,最后的辦法居然還是利用原先項目中已經存在的連接數據庫語句搞定的,代碼也沒深究了。
轉載于:https://www.cnblogs.com/CKExp/p/10520096.html
總結
以上是生活随笔為你收集整理的谈谈个人代码对团队合作影响的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 算法复杂度的理解
- 下一篇: 编写高性能的托管应用程序:入门