乙個新專案要開始了,專案管理者找去吩咐:新專案要開始了云云......
於是,product spec. 拿過來,看要從**開始,實現什麼應用,開始做了:
先看人怎麼安排了.如果不須要新做某個應用,只是從已有的專案中搬過來,一般字典可以乙個人,如果字典多的話就兩個人,personal info management乙個人,tool乙個人, ***,錄音機等乙個人.如要新做一本字典則要單獨分乙個編碼經驗豐富一點的人,做字典資料就共用人.分完後上報領導安排人,叫他們先看一下相關資料,如product spec.相關應用從哪個專案搬啊,做些準備.
如果有乙個可以跑的底層**,我就可以輕鬆一下,傳上cvs上, 叫模組負責人更新下來,就可以開始工作了,各人搬各人的模組.如果沒有就從乙個相關的專案中搬過底層**來,編譯通過下小機試跑,順利的話2-3天可以搞定.
最多兩周可以完成模組移植,發布d1.0版給sqa測試.並填寫好new version release note,告訴sqa一些事情,如重點測試哪些模組啊,哪些功能啊,哪些先不測啊,等等.當然所有這些都必須是程式設計師經過初步測試通過的.
關於bug管理系統,專案經理在bug管理系統上建立好當前專案,並把相關工程師加進去.sqa發現bug後,new乙個bug單,填寫好bug出現的操作步驟.然後另乙個經過確認這個bug存在後,便confirm它.我們登陸bug系統後,便可以看到bug單了.我便按照模組負責 assign bug單.
解決後,便把bug單resolved, 如有不明便加入note,feedback給測出該bug的人,詢問相關事情.
發布下一版本時,sqa便會一一recheck 我們resolved的bug單,如發現沒解決便feedback給我們,有必要的話加些note.如解決了便close它.
bug單狀態常用的是new, confirm, assign, resolved, feedback, close.
正常情況是一周發乙個版本,當然如特殊情況也可縮短時間,如出現了大的改動,要急時測.等等.
一般如新專案和某個專案相近,而又沒什麼新功能加入的話,兩個月可以release.可以出乙個版本給客戶確認,如客戶沒什麼意見,就算over了.如有新功能或新字典加入,可能依情況要多些時間.
目前我們公司沒有需求說明書,沒有設計說明書,及其它相關文件,管理鬆鬆散散,基本靠的是個人能力和個人自覺.
所謂的智慧型雲端伺服器管理平台
2019年對於雲伺服器市場來說好訊息比較多,首先是amd針對伺服器處理器發布了7nm處理器,這已經把伺服器處理器的登記提高到新的階段,intel伺服器處理器還在打磨14nm 對於大局進攻伺服器處理器市場的amd來說是個好訊息,對於大的idc服務商,採購的 能夠節省大半,變相的我們使用者間接會在幾年內...
所謂的型別轉換
以前，你知道乙個變數的值儲存為二進位制位的序列，和變數的資料型別告訴編譯器如何翻譯成有意義的值的位。經常的情況是，需要將資料從一種型別轉換為另一種型別。這就是所謂的型別轉換。隱式型別轉換是自動完成的編譯器每當從不同型別資料的混合。當從一種型別的值分配給另乙個型別，編譯器會隱式地轉換為價值為價值的新型...
所謂的 雙向BFS
雙向bfs，既然是雙向的，那麼就得知道起點和終點，這樣，我們就可以進行雙向搜尋了。但是，雙向bfs是否真的可以提高效率呢？如果能，那麼又能提高多少呢？看到過乙個圖，說雙bfs可以在bfs的基礎上把時間和空間複雜度上都減半。實際上，在許多的實際應用中，往往不僅僅是減半！我們假設，單向bfs需要搜尋n層...