個人閱讀作業Week7

標籤：

　　經曆了Alpha這一輪的狂轟亂炸之後，我深深的感到了軟體工程這種開發模式的可怕之處。

　　為什麼這樣說呢？我將分如下兩個方面來闡述

　　1、  軟體開發的複雜性：

　　　　物件導向的編程思想已經深入我們的骨髓。這種思想的好處在於我們可以方便的實現各種介面。尤其在軟體工程團隊開發過程中，開發人員分模組在各自的戰場上戰鬥數天之後，可以很容易的整合在一起，因為我們有好多好多定義好的，如此好用的介面。我們　　做的只是把它們拼接在一起。

　　　　然而事情真的像想象中那樣簡單嗎？

　　　　並非如此！

　　　　為何現實與理想相悖？開發人員拿到自己的任務之後，將進行為期一天，甚至數天的封閉式開發過程。作為電腦系的學生，想必我們都經曆過被“理想”扇耳光。這是什麼意思呢？在動手敲鍵盤之前，我們信心滿滿，圖繪好了整個工程的藍圖。然而，當真正著手　　去做的時候，我們往往會發現藍圖是需要被修改的，因為“當初”的我們，沒有遇到“現在”的問題。

　　　　團隊開發當然會遇到這樣的問題，但是我們的開發人員都各自進行著為期一天，甚至數天的敏捷開發。難道遇了一些小問題就要停下來開個會討論一下怎麼辦嗎？這顯然會嚴重拖慢開發進度。所以我們選擇進行一些必要的小修改，之後的事也就之後再說了。

　　當開發人員拿著各自的模組，準備進行整合的時候，卻發現這跟當初說好的不一樣啊。我們當初設計的東西，和做出來的東西，會有很大的出入。這就增加了軟體整合的難度，而且運氣好，也只是增加了那麼一點難度，運氣不好的話，整合可能要比重寫都要難（對　　於一個小規模工程來說）。

　　我們在開發過程中，當然也遇到了這種問題。實話實說嘛，真的有點難解決。畢竟相比於這樣的開發模式，我們暫且還沒找出更好的。

 

　　2、  軟體工程開發的可行性：

　　　　如果要讓我給軟體工程的團隊開發模式打一個分數來確定它的可行性，滿分10分，恐怕我只能給6分。

           為什麼是這樣？因為我還是個學生，而我的boss，我的老大，是老師。

　　軟體工程中的開發思想，起源於現代開發公司。學院給學生開設這門課程，我猜想，是想讓學生提前體驗一下公司的開發方式，提早適應社會，理解團隊開發與個人寫個小程式的區別。我很贊同這個想法，也確實從這門課程中收穫了不少。

　　　　然而這樣的“移植”，我認為其中存在BUG。

           原因很簡單，學生比不了職員，老師更是比不了老闆。因為能約束學生的除了分數之外，就只剩下自覺性。而能約束職員的，除了有了它就不用割腎買Iphone的獎金外，還有掌握在整個團隊以及老闆手中的，對每個人是去是留的生殺大權。

　　　　在公司的Team Dev中，消極怠工的人他們可以選擇將他踢出。而在學校的Team Dev中，消極怠工的人我們只能選擇忍。因為同學情不比同事情。

　　　　在公司的Team Dev中，我們可以選擇有能力的同事組隊。而在學校，我們完全不能保證隊裡的每個人都是具備一定能力的。而當這類同學表現出能力不足時，只能將任務轉給有能力的同學。這樣在無形中，給部分隊員就增加了壓力。然而在最後分配貢獻分的時　　候，同學情又會起很大作用。所以“能者多勞”這四個字得以充分體現，只是“多勞者”往往要礙於面子，不好意思“多得”。

 

個人閱讀作業Week7