機房收費系統感受

<b>機房收費系統感受</b>

暑假馬上就要過完了， 我們今天的任務是将自己的“機房收費系統”做一下展示。将自己的最美的一面展現在大家面前。在觀看中學習他人長處、凸顯自己的優點、發現和解決問題。

在今天的示範中，雖說大家都出了這樣那樣的一些小問題，但是在整體上還是相當不錯的。

在交流的時候，我們解決了自己徘徊許久的問題，大家對某一問題提出了多種解決方法。我們可以按照自己需求來選擇不同的解決方法。也對大家的程式中的不合理的地方及時的指出，這樣的交流很好提升的大家。

而對于這次做這個機房收費系統過程中體會到了好多關于工程的感受。再加上看了幾集視訊也有少許體會。

首先，我說一下在做這個程式的工程所走的彎路。

最大的問題就是對工程的分析太簡單。

在開始做機房收費系統的時候，雖說是知道應該先對程式的進行需求分析。但是具體需求分析要做成什麼樣，做到什麼程度，怎樣做需求分析，除了需求分析還需要做什麼……  都一無所知。

是以我還是按照了原來做哪些小例子的方法對工程的需求做了大概的分析，再按照功能塊建立了幾張表，就這樣大概用了半天時間。接下來就開始敲代碼，一開始感覺自己是跑到快了，大家還都在做需求（但是具體做什麼不清楚）。

可是越到後來越發現自己的腳步慢了下來，在分析的時候功能與功能之間的練習沒有搞明白，子產品與子產品之間的聯系就很難搞清楚。

具體表現在以下幾個方面：

1.       工程的前期工作做的不夠深

一開始做需求的時候，覺得能夠大體上知道工程具有什麼功能，需要用到哪些方面的知識就夠了。對于他們到底是什麼樣的關系到寫代碼的時候在去搞清楚就可以了。

這就是導緻我的工程看起來和大家的差不多，但是在代碼結構的清晰程度上就有了差距。

因為子產品與子產品之間的聯系都是在代碼實作的時候建立的。沒有次序，雖然是可以實作其功能，但如果是要進行拓展就費勁了。就像視訊上所說的那些階段，在我這裡完全沒有展現。

不過還好，這是剛剛開始，還有多的是時間進行調整。

2. 工程前期工作做的不夠廣

在我分析需求的時候不光沒有把現在的子產品明确出來，都有好多的子產品沒有想到。是以就直接影響了工程的整體性。可以這樣說這次做的這個程式完全是“拼”起來的。

需要什麼功能了才去對這個功能進行分析，從已經做的子產品中生生的扯在一起。那就避免不了不合乎情理或是聯系過于緊密。（牽一發而動全身啊！）

3.       沒能在在分析工程時把應該想到的功能列舉出來。

在這個系統中我添加了一些自己的功能，也改掉了一部分原來的功能。好多的功能都是在做的時候臨時變更的或是添加進去的。這樣就會使的在子產品接口上表現不出來, 有時候就更本分不清那部分是哪個子產品。

子產品與子產品間的聯系沒有減小，反而使他們的聯系更加緊密了。高内聚低耦合就無從談起了。

4.       子產品與接口沒有分開

在視訊的第二集中就講到，在做工程的前期工作的時候要有概要設計和詳細設計。這樣沒有将子產品提取出來就使得程式變成了一個整體，功能彼此之間沒有明确。随着編寫功能的增多，就感覺到了思路越來越不容易理清。

以上大概就是在做“機房收費系統”時的感受，不過還好程式不是太大，基本上能理清思路（雖然浪費了不少的力氣）。這樣也好，讓我更加感受到了做前期工程前期工作的重要性和挑戰性。