從2023年5月16日到2023年6月5日，歷時21天，工時289個小時，與小夥伴一起完成了一次合作開發機房收費系統。這個過程中肯定少不了磕絆，但最終我們三個都向著做好這個專案前進，共同商討，一同除錯問題，一起完善。這個過程中充分展現了合作的輕鬆。
整個過程我將它分為前中後期四個時期，每個時期都存在一定的問題，當然更多的是收穫和學習。
前期是最重要的，也是用時最長的乙個階段。這個時期有兩個工作。
首先是查，查相關的機房合作專案，這裡不是去看**，而是去諮詢機房合作的注意事項，學習合作開發的經驗，從而能夠準確高效的完成專案。
其次，就是針對文件有乙個全面的詳細的設計。好的專案離不開好的設計。而乙個好的設計，在這裡就需要小組內共同參與了。做為組長，我並沒有比組員對機房合作有更深的設計，思路比較古板，故而，採用小組內共同討論，可以有更合理的設計。
在這個階段中，我們存在的主要問題就是對於uml圖的認識存在異議和對設計模式的運用不清楚。在uml圖上，我們三個每個人都有各自的理解，主要是針對b層設計存在異議，經常因為b層的設計討論半天，然後也沒有什麼結果，從而浪費了時間。在設計模式上，有主張多用設計模式，有人則不敢用，也有人是不知道怎麼用，從而是誰也說服不了誰的結局。不過，由於我們意識到時間問題，從而最終想到統一想法，先設計出來看看，這才沒有產生更壞的結果。
所以，在這個階段中，我個人認為，專案開發討論時可以有的，但是不能不注重效率問題，當想法得不到認可時，先去設計出來或者多去考慮別人的想法，試著去統一，而不是浪費太多的時間在爭吵上。
中期就是**部分，通過前面uml圖的繪製，用ea生成**，這少了我們重新寫框架的過程，從而在很大程度上提高了效率問題。只不過，在**中我們容易犯乙個錯誤，就是沒有完全按照生成的類和方法寫，可能今天想到這個方法沒有，就填上，後天想到那個方法沒有再補上，等到寫到後來的時候，才發現，原來方法是存在的，自己補充的是多餘的，而在這個過程中存在了時間浪費的問題。計畫中**時間是3天，結果用了5天，超出了計畫60%，從這能體現出亮點：一是對於分工認識不到位，基本還是走的個人路線；二是前期準備不足，對於詳細的內容設計不足。
不過也通過這個**，學習到：盡量先將自己前期設計好的寫，畢竟前期的設計中一條線是成功，不會出現明顯性錯誤。如果確定是忽略了什麼，應該記錄下來，積極反應，可能乙個人理解不了，多個人能理解。如果是都認為存在問題才可以修改。
則是專案**完成，進行調錯的過程。在這個期間，我們能更好的發現自己程式設計中的問題。
比如在使用者介面，考慮步驟，對使用者的輸入或選擇忽略限制條件，經常容易導致資料無法繼續進行，說白了就是資料型別設計的不合理，對於使用者該輸入什麼，不該輸入什麼說明的不充分，從而導致使用者操作了得不到想要的結果。
並且，在調錯的過程中，異常經常出現，然後導致專案終止，才發現原來沒有異常處理的過程。如果使用者因為各種原因導致系統崩潰，難道還要讓使用者看到內部**的異常？這明顯是不合適的。所以異常處理是有必要的。
所以，從這個除錯階段，能夠 發現我們並未站在使用者的角度去設計系統，雖然實現了使用者的要求，但是實現這個要求，完全是按照「我們」的思想設計，從而導致系統脫離使用者，最終只會導致使用者不接受這個系統，付出得不到回報，因為使用者認為這個系統不值得有回報！！！
這個環節是將我們在合作上所花費的時間記錄下來，以便我們能夠更好的了解我們的效率問題。
通過上面資料顯示出，我們在合作上面肯用時間，努力去做好它。只不過，看著時間的積累，也暴露出乙個問題，那就是效率問題。
效率為什麼會存在問題，又是如何產生的，應該如何提高效率？
網搜一下，效率（efficiency）是指有用功率對驅動功率的比值，同時也引申出了多種含義。效率也分為很多種，比如機械效率（mechanical efficiency）、熱效率（thermal efficiency ）等。效率與做功的快慢沒有直接關係。而這裡我們主要是介紹一下工作效率，這個在網上也有介紹。
工作效率，一般指工作產出與投入之比，通俗地講就是在進行某任務時，取得的成績與所用時間、精力、金錢等的比值。產出大於投入，就是正效率；產出小於投入，就是負效率。工作效率是評定工作能力的重要指標。提高工作效率就是要求正效率值不斷增大。乙個人的
工作能力
如何，很大程度上看工作效率的高低。
那麼為什麼會存在這個問題呢？原因在於我們對工作細節的不重視，從而導致點點滴滴的原因導致工作效率出現問題。
回想到合作的點點滴滴，我個人認為產生效率的因素有以下幾點：
首先，計畫模糊。再開始之初，只是做了大概的計畫，比如文件什麼時候完成，**什麼時候敲，測試什麼時候開始什麼的，沒有認真詳細的去設計每一天該做什麼。每天的工作是摸稜兩可的，任務是不確定的，沒有規定每一天具體的工作，從而導致每天需要大量時間考慮需要做什麼，應該做什麼，應該完成什麼等。
其次，有心無力。對於機房合作的七層，我們都有了一定的了解，但是在重構的時候總感覺**還是重複率比較高，希望可以再重構一下。想法是好的，但是不知道該怎麼去實現，尤其是在b層設計的時候，我們小組前前後後討論了有三四天的時間，一直確定不下來。最後我們設計的是按照方法分，但是現在系統設計完成之後，發現這樣也並不合適，因為方法太過散亂，從而導致b層類「氾濫成災」，我不知道給系統的會造成什麼影響，但是就我自己去找，都感覺有點累，相信電腦也會累吧。而這恰恰反映了乙個問題，那就是知識量。由於身為組長的我對於七層理解不夠好，導致出現這種問題，責任怪我。所以這個時間段造成的浪費，我該負全責的。
然後，**拖延。在機房合作中，有時候總會出現拖延的症狀，並且每次都認為那是合理的，故而每天開始想好的計畫，這一天的結束仍舊完不成，乙個人完不成，其他層也就需要放緩速度，從而導致全組拖延，造成時間的浪費。
根據上面總結的效率產生因素，做出對應的解決方法：
第一，計畫清晰。不僅僅要計畫概況，還要在每一階段中計畫好每一天的工作任務。最好每天結束前找個時間開個小組會議，總結一下當天的工作。
第二，博覽群書。這裡不僅僅是只是讀書哦，更多的是我們去查查相關的設計思路，可以去問做過的或做過類似的專案的人，或者去網上查查，總有人也會存在相同問題的。專案啟動前的必要了解是不可或缺的！
第三，實行責任制。每天規定必須完成額任務，完成有獎，反之有罰。如果出去工作了，這肯定不只是這麼友善的處理了，可能公司就因為你的乙個完不成給專案拖延了時間，從而導致公司虧損，那時候公司讓你「辭退」都是好的了。所以這個每天工作任務是必須要完成的。當然，前提是安排額或被安排的任務是合理的，如果不合理，及時調整或向上反映，不要不聲不吭的，那樣出了問題，都沒地方「哭爹喊娘」的了。
第四，積極活躍。積極的人，每天都會按時完成工作，並且還可以學習其他知識，還能為團隊其他人帶來正能量，能夠間接為專案按時或提前完成做出貢獻。
第五，勞逸結合。做事，比較忌諱一直不停的做一件事，那樣極容易產生煩躁、厭惡的心情，合適的作息時間，可以讓我們保持充足的活力投入到工作中。所以，有個時間管理軟體是不錯的主意哦！
Dongle 機房合作 下機之職責鏈模式
機房合作下機之職責鏈模式 首先需要獲得消費時間，由上機時間和下機時間可以獲得，這不是難點。而我們計算下機結賬的時候使用的職責鏈模式，理由就是不同分段的時間由不同的消費標準，通過傳時間引數，依次處理，並得到最後的結果返回。前提獲取基本資料 例如在準備時間內，是不收費的，即消費為0 public cla...
機房合作之裝飾模式
用裝飾模式管實現理員登陸 b層public bool loginadmin admininfo admin if onworklist.count 0 else flag true return flag adminlogin namespace decoratormodel adminlogin ...
機房合作總結
機房合作結束有一段時間了，現在回想一下我們合作時我們所學到的知識，個人版編碼在 上已經學到了很多，這次合作主要在開發前期感悟比較深刻。軟體開發工具 1 axure rp 原型工具 軟體需求設計的時候需要用到原型圖，給客戶看，讓客戶看看，是否滿意我們這樣的設計，避免最後程式設計出來客戶不滿意。2 ed...