專案簡介：
現在做的專案，根據我們一開始的口號，就是國產替代。已看上去就覺得很牛逼，當時自己也是熱血沸騰，覺得這個專案可能會有所不同。然而實際上到目前為止發現專案跟原來的口號根本不匹配。甚至還比不上其他部門不打這口號的專案。
論現在專案「失速」的原因有很多。主要總結一下幾點，其實這篇文章的目的是看一下自己手中的牌到底是怎麼樣的乙個爛牌。
第乙個原因：專案不事先定立細節標準。從一開始我就盡力去勸hw se，盡量定立乙個規範去支撐我們的api的開發，甚至我們可以直接把其他部門的api標準直接搬過來。但是hw se覺得，這啥標準，差不多就行了。
導致狀況：風格迥異的api，有的甚至談不上合理。
第二個原因：定立方案沒有做充分的基準測試。序列化為了使方法簡便，就直接用個map，放著物件不用，甚至連jsonobject都不考慮（實際上也是map的變種）。理由是hw se 覺得map比物件快。實際上通過微基準發現根本不是這一回事。
導致狀況：實際上map帶來的負擔遠遠大於hw se 帶來的益處。後面關於map導致的物件不能被釋放還沒有體現出來。目前也沒有記憶體監控測試方面去查這個問題。map帶來的除錯困難，遠比例項化物件要複雜。
第三個原因：決策失誤。目標上，我們應該達到多少毫秒，通過這種方向來定立自己的實現方案，如果兩個方向差不多就選擇對問題定位更好的方案。實際上，我們從map的選擇就可以窺見一斑，我們選擇微服務，不是因為我們真做微服務，而是覺得微服務吊，
覺得微服務流行而去選擇的。緊接著為了迎合領導，上了乙個四不像的ddd（領域驅動開發），中間各種物件的轉化也就是去copy實際產生的作用幾乎為零，還拖慢的速度。然而map就推翻了上面想要的結論，沒有業務物件，只有map乙個。對於快取的選擇， hw se傾向於自己寫jvm快取，而不是用現在主流的ehcache，放著redis不用，也是覺得慢。
跟我想的如果真在要實現國產替代，首先要做好的是自己要有足夠的包容心，然後要細緻的去用測試來支撐自己的結論，而不是猜，而不是就跟著理解來。決策失誤往往就是太多自信導致的。
理想化的狀態：
1.專案開始之前定立自己標準規範。
2.遵照個規範去定立自己api介面，並進行線上化管理。
3.定立好物件類圖，仔細分析ddd，怎麼運用在專案上，如果分析不好，後面改也行。不能強上。
4.對於微服務與單體專案做謹慎的評估，不能認為單體專案就是落後。無論哪種技術合適的才是最好的。
5.開發介面的時候，要考慮呼叫方怎麼方便，盡量統一自己的風格（實際上這一步在api設計的時候就應該考慮好）。
6.開發過程中謹慎選擇技術方案，實際上下結論之前做好，微基準測試並不是一件很困難的事情。
目前專案已經很難想理想的方向發展：
如果是我，我覺得專案應該是。首先定立好api規範，然後在設計中心對api進行線上化設計並且管理。無論是哪種介面，對內對外。緊接著選擇gson 作為專案工具，物件化合理設計為基準而不是用map。 評估redis與ehcache，選擇乙個或者綜合兩個作為我們快取方案。或者直接用ehcache，專案變成單體應用。
乙個專案的總結
這篇文章是針對自己剛剛做過的乙個專案，自己的一些體會。其中在 中的內容是專案中的一些情況，不要求他人理解 做專案的經常出現的一種情況是弄乙個方案解決客戶的某乙個問題。通常會產生三種做法。1.問題和放案都是客戶提出來的。客戶很明確的告訴我們，有什麼問題，要用什麼方式解決。我們只需要針對客戶的解決方案，...
乙個專案的總結
我是移動網際網路行業的新手，這個月是來到這個公司的第12個月了，寫這篇東西是因為最近自己的乙個專案宣告掛起，偶爾維護不開發的狀態，在這裡有些感慨。這個專案是乙個lbs的交友軟體具體說明不能說，失敗的原因我總結了有以下幾個原因 1 我是新手 雖然已經參與開發了幾個專案了，但是我畢竟還是新手，而且我們服...
乙個失敗專案的總結
2013年 2014年，筆者參與了乙個大型專案，雲平台下做資源 資產 電子運維管理，由德勤負責需求整合 hp負責系統門戶和硬體整合，pccw負責實施整合。ibm 中興 亞聯 億陽等十幾家廠家做開發分包。專案合同額好幾億。當時我在pccw負責資源的實施管理，與中興 亞聯 億陽一起完成所有省份的實施，一...