這幾天學習了一下springcloud,微服務，本來以為很難弄，其實用還是很簡單的，畢竟是開發給我這樣的小白用的，太難不會用，沒有開發價值，像白居易的詩一樣，通俗易懂的詩才是好詩，其實**也一樣，**不僅僅是給自己看的，也是給人看的，你**寫的漂亮點，你的後人就容易摸索點。到了新公司最大的痛苦不是技術不會，而是看不懂前人的**，這是多難受的事,只有經歷過的人才知道。
這幾年比較流行的開發手冊，阿里巴巴的，所有人都在看，其實乙個公司有個開發手冊正的很重要。第
一、這個開發手冊代表了公司技術文化的沉澱，第
二、起到了**規範、環境統一等作用。其實每個公司都應該有自己的開發手冊，不一定用阿里的，因為專案同，所以不一定適用，和法律一樣的。 比如唯評會小冊子等，在阿里巴巴的基礎之上寫的。
專案在開發的過程中會遇到很多的問題，遇到問題就得花時間去解決，要是不解決問題越來越嚴重，到了最後就變成了乙個沒有人想要碰的專案，有的專案為了解決前期的乙個小問題，隨便寫了個**處理了一下，當別人用的時候不好用，又處理一下，這個方法只會越改越亂，最後乙個方法寫了幾百個if，上千行**，維護的人也不知道這個是什麼意思，重寫吧，自己不知道怎麼寫，生怕漏掉了業務，改吧，無從下手，看吧，看不懂，所以沒人想碰這個**。該解決問題解決問題，問題不能積累，和人一樣，小病不去看，積累成大病，已經無藥可救。有人會說18年後又是一條好漢，那你就估量一下去重寫專案吧。
架構很重要，專案的架構是很重要的，不同的專案，需要不同的架構，不是每個專案都用乙個架構。一般老是用一套架構的公司，都是傳統行業，或者他們家老大是個技術出生的，千辛萬苦搞出來一套架子，只能一直用到天昏地暗，下面的人也是搞的烏煙瘴氣。其實這個專案還不如老大乙個人去寫，我感覺更划算一些，我的第乙個公司搞erp的，就是老大發明的框架，自己乙個寫出來的，找了10多個人去開發,乙個月過去了，不能說沒有一點成效，只能說有那麼點成效。結果老大乙個下午把問題解決了，底下的小弟還沒明白為什麼。這難道就說我們技術不行嗎？不是的，也許你讓我們寫controller，service,dao。當初的我們也能寫的很快。畢竟學習的就是這個，沒有達到了心能與電腦溝通的狀態。架構師不能只懂架構，還應該分析你的團隊，你的手下是什麼人，能幹什麼。
團隊協作也很重要，專案不是乙個人能夠寫完的，我們除了要遵守公司的**規範，還因該相互協作，使用相關工具進行**的管理，和**的合併等等，提交注釋寫的詳細一些。
**注釋，關於注釋，比較複雜的業務，或者一眼看不明白的**應該寫注釋，有的人說寫到版本控制工具中就行，我覺得還是寫在**中比較好，應為一般很少有人會去翻commit message ，盡量寫的通俗易懂一些，不然注釋比**多，就不行了。
程式設計師感悟
在csdn上有程式設計師發表感慨，覺得自己將來也會遇到差不多的情況。看到很多csdner都有同感，並且積極開導lz，我也頗有感悟，先貼一貼他們說的。lz說的 昨天8年前的好友a通過qq告訴我，2000年一同分配到那個國有企業的b已經公升任副局了，昨晚一夜沒有睡好，反思畢業8年來的點點滴滴，不由百感交...
android程式設計師的感悟
來公司上班快3個約了，本人是新手。乙個剛剛還沒有畢業，參加過培訓的android新手。自我感覺學習很一般，很榮幸被現在的公司看中。我的公司是乙個剛剛成立的新公司，我倒是公司公司剛成立差不多就兩周。所以我在這個公司現在還算是個老程式設計師。老闆對我還不錯。公司就我乙個做android的。android...
程式設計師的調式感悟
最近在學習drp專案,在編寫 的過程中,必經的乙個過程就是 調式 而對於我來講,調式是最大的勁敵.在遇到 錯誤的時候,我們是不是應該總結一下調式經驗,作為日後工作,學習的經驗,以免在發生這樣的問題時束手無措.下面從兩方面入手總結一下,我在編碼過程中得到的調式收穫 對於乙個性急的程式猿,這一點應該是很...