?? 這幾天讀了些UML用戶指南和設(shè)計模式面向?qū)ο箝_發(fā)，由于寫了很長時間的程序，突然發(fā)現(xiàn)體力勞動越來越嚴(yán)重，情緒有些低落和凌亂。

?? 實現(xiàn)雖然已經(jīng)結(jié)束，可是竟然在不知不覺中留下了一絲軟件開發(fā)的陰影。這幾天很不情愿去寫代碼，于是重新投入到軟件工程方面的知識的研讀和思考。很久以前一直在學(xué)習(xí)這方面的東西，而且很愿意投入自己的工程中使用。然而這次團隊合作我們卻陷入到深淵。

??? 3GCRM系統(tǒng)Android應(yīng)用開放算是告一段落，就此刻的心情可以對這次開發(fā)做一個總結(jié)就是：失敗的組織，混亂的開發(fā)，沒有統(tǒng)一標(biāo)準(zhǔn)，團隊軟件工程的思想?yún)T乏，工程進度控制不當(dāng)，缺乏人性化，總之沒有一樣值得稱贊。

??? 對這些問題想了想。

??? 首先團隊合作出現(xiàn)問題：隊員開發(fā)能力參差不齊，面對Android應(yīng)用開發(fā)這個新的技術(shù)沒能很好的接受；分工明確但是缺乏執(zhí)行力；個隊員開發(fā)速度不一致，存在了開發(fā)時間的浪費。

??? 其次,最重要的問題還要從軟件開放的工程化思考。

??? 總體上這次項目開放實在混亂中進行這，最后我在進行模塊組織的過程中并沒能較為輕松的合并，而是參與了很多的代碼的修改，錯誤調(diào)試等等。歸結(jié)了一下主要存在這些問題：

??? 1.在需求分析已經(jīng)做完整的前提下團隊開發(fā)沒能嚴(yán)格遵守

??? 2.各個模塊雖然獨立編程和實現(xiàn)，但是僅僅停留在面向功能編程的基礎(chǔ)上，直接導(dǎo)致的是項目中冗余代碼達(dá)到40%

??? 3.項目開發(fā)沒有用到合理的設(shè)計，沒能面向接口編程，封裝性差。

??? 4.布局文件和程序文件沒能進行有效的組織管理和命名

??? 5.在項目開發(fā)中沒有制定統(tǒng)一的命令規(guī)則，這導(dǎo)致不同人員在使用其它功能能模塊的時候出現(xiàn)命名混亂，代碼可讀性降低很多

??? 6.開發(fā)時間和模塊開發(fā)順序安排上不合理，致使開發(fā)周期變長，隊員自身要求不夠，沒能嚴(yán)格遵守開發(fā)組的約定

??? 7.各隊員對開發(fā)模塊測試不完整，沒能規(guī)定測試標(biāo)準(zhǔn)和測試要求，產(chǎn)生了模塊組合出現(xiàn)錯誤的現(xiàn)象

??? 最后，從開放的狀態(tài)和態(tài)度上，要求不夠。細(xì)想，出現(xiàn)一種常見的現(xiàn)象就是：激動編碼。共同存在的問題，遇到問題，總是第一時間想去編碼實現(xiàn)和解決，這樣產(chǎn)生的問題是問題解決了，項目中代碼組織一團糟糕，失去了面向?qū)ο蟪绦蛟O(shè)計的基本準(zhǔn)則和要求。

??? 激動編碼也是混亂開發(fā)的一種普遍的體現(xiàn)形式。面對一個問題，可以通過思考和小的CASE測試來實現(xiàn)，但是這樣的做法只能作為測試或者方法事例，絕不能投入到軟件項目中去，試想如何每一個參與者都本著解決問題的心態(tài)去進行項目開放，結(jié)果可以想象，問題將會越解決越多。既然是工程就應(yīng)該遵循規(guī)定和標(biāo)準(zhǔn)去做。

?? 遇到的問題還是很多，想想，看看然后真正的從軟件工程化的角度去對待，可以激動，但一定冷靜，畢竟編碼只是軟件開發(fā)的一個部分，不是全部。無論是從設(shè)計，還是使用，升級都需要而且必要合理和設(shè)計和規(guī)劃。

?? 實習(xí)超乎尋常的累，就是沒有重視軟件開發(fā)的工程化，到頭來精疲力盡而且感情備受打擊，一團談不上重用與健壯的代碼，非人的UI設(shè)計，簡略的開放文檔只能算是出了力，沒落好啊！

?? 已經(jīng)經(jīng)歷了，算做軟件開放的一個新的旅程的開始吧！大道至簡，我想軟件也是如此吧。

??

總結(jié)

以上是生活随笔為你收集整理的混乱开发，既伤身体又伤感情的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。