1. 程式人生 > >2015.09-2016.08年終總結 需求、設計、開發、測試、部署、運維……統統將矛頭指向了管理,目前認為會管理才是王道

2015.09-2016.08年終總結 需求、設計、開發、測試、部署、運維……統統將矛頭指向了管理,目前認為會管理才是王道

    15年9月和10月,是我們在學校的最後兩個月,那兩個月,迎來了小小徒弟,13期一波兒活蹦亂跳的孩子們,甚是喜歡。


    11月我們搬到萬達學習,新環境雖說不如學校方便,但給了我們一個新視野,讓我們嗅到了社會的氣息,在這裡,我們夜以繼日,馬不停蹄的學習。

    搬到萬達後,專案一個接一個,還有可能同時有多個,做專案的時候感覺時間過得飛快,一眨眼一星期就過去了。

    細細看來,這一年,善始善終的專案只有一個,那就是訂餐系統!


    從12月份開始,一直到16年8月,半年多的時間,全都耗在了這一個專案上,專案說大不大,說小不小,非常實用。

    需求篇:

    這半年,和志晟公司打交道頗多,每次都會丟一些需求過來,他們把想要什麼樣的東西跟我們說,我們去實現它,慢慢的,我發現,這是用技術在管理,技術在為管理服務。

    比如,三樓跟我們強調了很多遍想要語音播報,我們就想了,食堂亂哄哄的,而且播報的速度和打飯的速度怎麼去協調是個問題,後來,溫總跟我們一解釋,我們恍然大悟,他最想播報的是"您未訂餐,請到等候區等候!"   :

    如果員工不訂餐,但他上去吃飯,還排在隊伍前列,師傅是給他打飯呢還是不打呢,員工不想走,師傅也不好意思說他,但如果讓訂餐系統發聲,是系統讓他滯後取餐,那效果就不一樣了

    設計篇:

    軟體的特性是高效便捷,但如果自己開發的軟體使用起來比原來的效率還低,那無疑它的設計是失敗的,訂餐系統裡用滑鼠去點的臨時扣費計算器頁面就是一個很糟糕的設計

    在設計時,我們沒有在食堂頂崗幾天,或者蹲點兒,看看大家取餐就餐是怎麼樣的狀況,這是失敗的教訓

後來計算器頁面變成了硬體小鍵盤,效率提升了百倍,這是目前來說比較好的管理刷卡扣費的方式了

    開發篇:

    開發的時候,我們沒有規範使用SVN,全員使用一個地址,導致更新時衝突很多,如果使用上branch、trunk,由開發組長把關專案程式碼,那情況會好很多。這是用版本控制工具SVN管理程式碼。

    測試篇:

    這版訂餐系統和錢掛鉤了,而且每天上百人使用,我們一點兒也不敢懈怠,前前後後測試了不知道多少遍。

測試的關鍵是如何測試,測試哪些東西,要有一個清晰的流程,所以後來我們專門寫了一個測試文件用來管理測試流程。

    測試也不能僅僅是在本地PC上,要釋出到伺服器,一是伺服器相對安全穩定,二是測試系統的健壯性

    部署篇:

    因為訂餐系統需要進行IO操作,而且是BS專案,所以單純的釋出到伺服器上是不夠的,需要連線讀卡器的地方就需要釋出一版,所以我們在財務(負責讀卡充值)、餐廳(負責刷卡扣費)、伺服器,這三個地方各發布了一版。

    這些釋出地點的資訊同樣整理成了文件

    運維篇:

    專案上線後,產品的版本與功能對應表同樣需要清晰的管理

    專案篇總結一下:

    單純的從一個訂餐系統,我已經意識到管理相對技術來說,要有用的多,如果不會管理,那設計出來的產品會差很多。

    管理貫穿軟體的整個生命週期,靈活管理才能百戰不殆。

    後來投身ITOO系統的DBA,組長讓寫資料庫許可權如何分配的文件, 要知道,寫文件最怵頭了,尤其是寫那些一點兒也沒思路的文件

    可是,轉念一想,我豁達了,這哪是在寫文件,分明是在管理,你不會寫,說明你不懂管理,不知道怎麼管理許可權,想明白了這些,隨後寫文件那是行雲流水

    這一年裡,零零碎碎的還參與了一些其他專案,比如評教APP,組織部績效考核系統、未完待續的學籍異動,還有培養計劃上的牛腩,自己做的排班軟體等。這些經歷都給了我成長。

    生活中處處是管理,用心投入,才能收穫。

    這半年遺憾的是ITOO程式碼寫得太少了……

    java開發該抓緊了,,,

    其他方面:

    1.英語就不要說了吧,張嘴流利了些,但還是很笨拙

    2.自考還剩下四門,學習逐漸得法

    3.軟考又一次敗北,很意外,但貌似又是天註定,知識儲備不夠,另外學得不紮實,不靈活

    4.研究生的課程上完了,下一步就是寫研究生畢業論文了

    5.去外面實習的事兒告一段落,再沉澱沉澱

    新的學年不知不覺的開始了,10期的要畢業了,明年就到我們了,理論上在這裡還有一年的時間,讓最後的這一年不虛度,絢爛的綻放異彩吧!