真的太久沒寫過部落格了。自從msn的blog關掉以後就就沒怎麼正經寫過（好像之後還寫過一編年終總結）。就得blog沒了，搬遷到sina之後在公司有不好登入，趁今天生病在家修養，稍微記錄一下流水漲。
最近一段時間得到了公司支援，推行了一段不太完整的」敏捷開發「。不完整，是因為只有開發在做，並沒有推行到測試、銷售、財務等其他的部門；「敏捷開發」加引號，是因為迫於壓力，我們還有很多需要改進的地方（比如生產力的估計、比如code review...）。之前我也yy過一篇關於敏捷的blog(url)，內容純屬yy，而且也的確沒有把握住一些敏捷的核心價值觀。那些太巨集觀的東西每個人的理解都不一樣，我只能按照自己的理解來指導自己的實踐。但關於實踐方面，我們倒可以稍微深入一點。
一.，要有編碼規範（這當然，還用說？）
對，但要很完整的編碼規範（比如像google c++ code style那樣詳盡，編碼風格遠不止縮排空格之類的問題）。這一方面避免新人加入的時候所寫的code風格與傳統太格格不入，另一方面源於我暫時對程式設計的理解。
插點題外話，說說暫時我心裡面的程式設計。經常聽到有人自稱it民工，但其實我更喜歡自稱為工匠（craftsman ，其實這也不是我提出的觀點，很多程式設計方面的書已經提到）。事實上，如果我們要以建築工程來模擬軟體工程的話，從角色上說，我們更像建築設計師而不是民工。工程要求的是精確構建設計，這部分的工作是編譯器或者直譯器完成的。所有的程式設計師都通過**影響整個系統的設計，我們可能更像設計師而不是民工。建築設計師根據客戶的要求來設計各種建築，我們則根據客戶（如果你在做產品，那你的客戶就是自己公司）的要求來構建軟體。
有人說那是架構師或者cto的事情。且不說架構師跟cto在不同的公司裡面有著不同只能，他們做的不一定是軟體設計的事情。但就從程式設計師的角度去看，至少程式設計師自己也有可能在細節上去影響整個系統設計的權力。如果你是乙個敏捷的追隨者，那麼你應該聽說敏捷團隊中的架構師角色已經被淡化，敏捷團隊賦予了所有開發人員更多的設計權力跟責任。不過話說回來，我想在構建大型系統的時候，如果有乙個有經驗的架構師坐鎮，應該還是能省下不少功夫。
從如果工作方式上去解釋，那我覺得我們更像雕刻家或者畫家。我們首先了解客戶的需求，知道我們雕刻的是人像還是動物又或者是其他抽象的創作。然後，我們先通過user story（或者需求文件）來勾勒出作品的輪廓（如果你做的是敏捷，那麼作出大體的架構，大家認同就行。如果你用傳統方式，那就要把各種的設計文件都準備好）。再下來，我們需要對作品的每一部分進行細緻刻畫：一邊畫，一邊觀察，一邊修改（編碼、測試迭代或者乾脆就tdd，還要加上客戶的迭代驗收）直到最終完成作品。不過給我們作畫的時間實在少得可憐。我們必須依賴集體創作來保證作品完工的時間，所以我們可能需要每個人完成一部分的工作。另一方面，軟體幾乎就是變形金剛，客戶想怎麼改就得怎麼改（在技術可行的情況下），修改的成本比起建築或者雕刻低得多，幾乎與作畫相當（剛剛網購了一本書《黑客與畫家》，裡面會不會有類似的觀點？^_^）。不過，多數的畫家和雕刻家都是根據自己的思想來創作的，他們把自己價值觀融入到作品當中，並通過作品來影響大眾（突然想起了steve jobs）
扯太遠了，我們回來說說編碼規範。如果你同意上述的觀點，如果你也認同藝術創作需要統一的風格，那麼你就應該能理解編碼風格為什麼重要。最關鍵的一點在於，我們是在集體創作，而且時間緊迫，統一的風格有助於別人理解你的**，省下更多的時間。
二，要有持續整合
曾經看過一編文章，作者說了一句話「連持續整合都沒有，我實在不知道他們敏捷在**」。持續整合的好處很多書上都已經作了闡述，但我想補充我的一些另類觀點：懶惰是程式設計師的美德！很多苦逼的程式設計師實在太勤奮了，手工測試、手工release、沒時間研究工具只好手工做各種各樣的事情。當然，我也知道他們背後肯定有著各種各樣的壓力，直到我看完了《浮現式設計》以後，我覺得我認同作者對這些壓力背後原因的總結：我們還不夠專業！這是後話，我們現在要說的是持續整合。很重要一點，在it本來就有幫助人們處理工作的能力，如果作為程式設計師的我們都不能善用我們自己的能力來幫助自己處理工作，那自然，我們就不得不苦逼下去了。懶惰是程式設計師的美德，但這需要建立在工作必須被完成的前提下，不然哪家公司請得起你？所以，作為程式設計師的我們，盡可能熟悉各種工具，把能自動化的工作最大化，那才是懶惰的生存之道。我知道，我知道，面對面的溝通重於工具和過程！但人家說的是，面對面交流更重要，也沒說工具不重要。事實上，我覺得善用工具是工匠的必備能力。花時間去自動化盡可能多的東西：測試、發布、部署，最終的結果是省下了大量手工的重複勞動時間，程式設計師都是設計師，都喜歡做新鮮的事，而不想重複做同樣的事情，這也會跟他們更大的工作積極性。
三，tdd
一開始接觸tdd的時候很彆扭，思維混亂導致生產力不高。不過習慣了以後，我就越發的離不開他了。事實上我覺得這是跟作畫過程是一致的先勾勒出輪廓然後填充細節，先通過驗收測試來確定乙個story在各個模組中要做的改動或者要增加的功能，然後保證這個輪廓不變的情況下修整各個模組；同樣，各個模組的修整（增加）也先通過單元測試保證模組的輪廓。
有了之前留下的各種測試，我們會更加有勇氣來修改**。再一次用作畫對比，我想沒幾個人畫畫能一蹴而就，甚至有些名畫是被重複畫了好幾次才成現在我們看到的樣子。所以，我並不期望我寫的**不被修改甚至推翻重來。最近看一些文章甚至認為**至少被重複寫兩遍（是至少！）。如果我們以作畫跟軟體模擬，那是再自然不過的事情（可能我太不專業了，誰不用橡皮檫的舉手^_^）。
但tdd用的越多，我們就越注重它在改善設計方面的幫助。當測試不容易寫的時候，我們會修改我們的設計（通常會通過設計模式來指導）。另外，我們也注意的tdd需要大量的使用依賴注入的方式來編碼。事實上我覺得這不是乙個壞事，它最大的乙個好處是把物件建立跟物件使用分離（通過工廠或者類當中的靜態方法）。
說點題外話，前段時間蔡大溼（蔡學墉）翻出來多年前linus對c++的評價。他提到c++最有用的部分其實就是當中c的子集，所以他覺得人們應該使用c而非c++。我想我贊同他的關於c++缺點的觀點，但我試圖反其道而行之，摒棄純粹只是為了跟c相容而存在的部分。比如說不直接new物件，甚至把類的建構函式都私有化。通過靜態方法模板來建立指向物件智慧型指標（這有點像jvm的處理方式？）我想這會是一件值得嘗試的事情把。c++11出來了，還沒時間去讀草案（標準太貴了），不知道會不會有些什麼新發現。
先胡亂寫到這，以後想到什麼繼續。
啥 啥 啥，服務治理是個啥
首先，先說下服務治理的邊界，本質上任何能提公升服務可用性，效能，讓服務更穩定等等，只要是能讓服務執行的更好，都屬於服務治理的範疇。服務治理比較常見的話題 服務發現，服務變更管理，服務監控，服務擴容縮容，服務自我保護，服務降級，服務授權防攻擊，服務上線驗證和灰度發布，服務問題定位和跟蹤，服務負載，服務...
轉int啥啥啥的
1 string轉int型別的話。需要用double.valueof 這寫string型別的資料 intvalue 2 保留小數點 float scale float 100 decimalformat fnum new decimalformat 0.00 string dd fnum.forma...
樹狀陣列的那啥啥啥
emmmmm，在我們學習樹狀陣列之前，我們應該知道lowbit n 運算，lowbit n 定義為非負整數n在二進位制下 最低位的1及後面所有的0 構成的數值，例如n 10的二進位制表示為 1010 2 則 lowbit n 2 10 2 顯然可知 lowbit n n and sim n 1 n ...