結合這幾周來的團隊、個人項目經驗，主要針對閱讀材料的第一篇《No Silver Bullet: Essence and Accidents of Software Engineering》（下文中簡稱《No Silver》）談談自己的了解和心得。
個人項目的工作量還不足以算得上是開發一個軟體的工作量，在個人項目中單獨進行開發難度還不算很高，當然這種開發模式在短時間内所能開發得到的軟體一般功能上也不能滿足大多數使用者的要求，是以價值是不大的。
而在團隊項目中，很多軟體開發中的實際問題立馬就暴露了出來，從接到項目的一開始團隊就遇到了各種各樣的問題，這裡面有一部分是跟《No Silver》裡面提到的一些問題相類似的，也有一些其他的。
由于我們團隊選擇的是代碼移植的項目，首先必須讀懂已經寫好的網頁端代碼，這其實跟軟體維護所要做的工作是一樣的。在這個過程中我們發現學長寫好的代碼裡其實存在着很多的問題，也就是說代碼本身的功能是有錯誤的，這給我們移植無疑帶來了很大的問題，我們必須先糾正好原來代碼裡存在的問題，才能開始我們真正要做的工作——移植。不僅如此，我們發現代碼裡很多比較關鍵的功能其實還不完善，或者有的功能根本還沒實作，感覺代碼的開發者把精力都花在了一些無關要緊的地方，這在軟體開發裡是很忌諱的一件事，因為使用者在使用軟體的過程中就會很直覺地發現軟體的功能問題。這個問題在我們的團隊開發裡應注意避免。
其次，在《No Silver》裡提到了軟體開發中的一個困難來自于配合性（conformity），這在團隊開發裡也是很容易遇到的。由于團隊的各個個體負責不同的部分，在最後工程整合的時候必然會遇到配合性的問題。各個人負責的部分對接的時候，如果接口不一緻，各種各樣的問題會導緻錯誤百出，最後整個項目查錯起來工作量是巨大的。是以我們團隊決定盡量堅持沿用代碼原來的各個接口，以保證一緻性，配合性。關于配合性，在《worse is better》裡也提到了相似的一緻性問題，可知這個問題的重要程度不可小觑。
最後，在開發中每個人或多或少都會有一些自己的想法，這就導緻我們的移植項目可能最終有一些小地方和原來的代碼會有差異，這跟《No Silver》裡面所提到的易變性相似。在軟體的使用過程中，由于環境和人主觀意識的改變，軟體的各個小地方可能都會需要進行修改。對于這種某個地方所做的修改，可能會牽扯到其他各個地方的一緻性問題，這就需要團隊之間建立良好的溝通管道，修改的地方需要确認其他牽連代碼也一并進行了修改，進而保持一緻性。
軟體工程進行到目前的階段，以上就是我對軟體開發的一點體會。