本月的功能在踉蹌中勉強上線了，這個月有實驗的味道，有摸索的代價，有分工和銜接上的問題，有技術儲備方面的不足，有業務梳理方面的欠缺，也有個人能力和意識上的不足，梳理整個開發流程，目前存在的幾大問題：
1.效能層面：
從綜合維度看，*****壞取決於開發人員整體的程式設計經驗：比如作業系統，設計模式，資料結構和演算法，網路原理，資料庫，前端等等因素。
就目前系統整體上看，效能可能會出現的地方，從優先順序權重來排列，主要集中在：
2.規範層面
有些規範是可以文件化的。比如全域性變數全部大寫，區域性變數駝峰命名，檔案前字尾命名等等比較容易約定俗成；
有些規範無法約定的。比如作業排程有些人命名jobs，有些人命名schedule。如果要想規範必須把業務考慮進來。如果只是想表達定時作業，屬於技術術語job可能比較合適；如果是業務層面的任務排程可能schedule比較合適。也就是說如果碰到模稜兩可的命名的時候，需要增加考慮因子，通過擴大「視野」來更精確的命名它。
如果碰到乙個問題始終不清楚要如何命名的時候，首先應該要反省的是自己對業務熟悉不熟悉，對系統整體熟悉不熟悉。如果實在無法確認，最好請教和溝通，一般都能做好命名。說不定能發現一些自己無知的內容。
如果真的覺得用名字無法描述清楚，言不盡意，模稜兩可，那就增加**注釋。**注釋的前提是自解釋，實在無法達意才去做注釋，因為注釋太多也是有成本的。
一致性優先，也就是說一致性是可讀性的基礎，否則資料庫一種命名，業務**一種命名就是錯亂了。比如公司叫company，但是業務命名叫supplier，會員叫member。這裡會出現這種不一致的命名，主要原因還是對業務領域不清楚導致的。
所以在底層命名非常關鍵，比如資料模型的表和字段的命名，如果底層命名錯誤，從上下往上只能將錯就錯，讓人改也不是，不改也不是。
總之，**命名和給孩子取名字一樣，其實都是需要慎之又慎，不可隨意叫個阿貓阿狗什麼的。這裡有個原則就是要遵循：簡單，可讀，統一和優雅的原則，當然優雅是最高的要求。
規範僅僅寫個規範文件是很不夠的，寫好並持續完善規範文件只是萬里長征第一步。只有規範文件，沒有落地檢查，文件也會變成一紙空文。
定個原則是比較容易和簡單的，如果細細追究，裡面有很多坑。
首先大家對簡單，可讀，統一的理解各不相同，最後生成的**必然是千人前面，理論上需要對業務的深入了解，需要有很好的英文功底，同時在整體上要做經常性的檢查和覆盤。
但是引入**審查又需要成本，假設乙個月審查一次，那麼對每個成員編寫的乙個月的**，從月初到月底進行一番梳理和糾正，沒有1-2天是無法完成的。
所以審查是有成本的，要不要審查呢？
權衡利弊，必須要審查，而且要按照規範，引入嚴苛的**審查機制，每個月做一次**規範和**質量的檢查和考核。
為什麼要嚴苛來做**審核呢？因為**質量反應了我們的產品質量，**的好壞決定了未來運維的成本，技術債務的危害怎麼形容都不為過，輕則系統區域性異常，中等的會導致修改困難，嚴重的推翻重來。
如果因為進度一時妥協，回頭又忘記了修改，中間又出現人員變動，那麼這份**的後患是無窮的，因為沒有規範的**，對交接人來說從心態上是本能反抗的，但是又不得不改，於是就一通亂改，能貼膏藥就貼膏藥，能執行就可以，管他規範不規範。這樣導致的結果是對規範來說，只能從不規範走向更加不規範，最後走向無法維護。
1.效能層面：
磨刀不負砍柴功，開發之前進行技術評估，識別出其中技術複雜度和難度，及早發現效能方面可能會產生的問題。
把評估的內容逐條分解羅列並做文件化，對容易的功能盡量不要有心態上的藐視。
遇到沒有把握的技術問題，及時的拿出來討論，不要覺得不好意思。
主站需要生成靜態頁面進行快取。
多研究學習和參考別人寫的**，做好底層的技術沉澱，平時多練練內功。
通過針對性內部培訓來提高個人薄弱環節，讓技術均衡發展，又各有特長。
2.規範層面：
整合測試
開發人員內測：
1.業務層面
2.技術層面
1.業務層面
2.技術層面
以下從三個方面總結一下成員開發過程中的意識問題。
對開發來說，各個環節要持有嚴謹和一絲不苟的態度，樹立簡單並不簡單的意識。對於完成的功能，如果時間上允許，需要反覆回頭檢查可能出現的問題，不要滿目樂觀，或者覺得某個功能很簡單，要站在可能出現問題的立場上來看待正常的功能。因為我們要打造的是產品，而不是專案，不是小孩過家家的功能。
好的**是不斷重構出來的，因為業務和需求是不斷疊加的，不可能寫出一成不變的**。當業務倍增，需求變革的時候，再好的**都會出現生鏽，腐蝕和壞味道。所以在不忙的時候，需要經常性的整理自己的**。
重構解決的是長遠的質量和可維護，可擴充套件的根本問題。技術債務，如果不及時解決，隨著時間的推進和人員變動，後續花費的成本會逐漸疊加甚至無法解決，好比蓋房子，在有問題的基礎上蓋房子，蓋得越高危險越大，到了晚期可能就只能推倒重建。
三個臭皮匠賽過諸葛亮，技術越討論越進步，業務越討論越明白。對於模稜兩可或者完全不懂的問題，盡量多請教和討論。
討論的印象是最深刻的，對個人的成長和幫助也是最大的。比如對vue的學習和上手，對資料庫指令碼的編寫，對es的學習和討論等等……
樹立不懂不丟人，不懂裝懂才丟人的意識。不要忌諱或者不好意思討論。
討論講究效率和默契。要集中時間，充分準備。 有些開發人員經常問些沒頭沒腦的問題，既沒有背景鋪墊，也沒有上下文，然後想一出乙個問題，頻繁的打斷別人的思路而不自知。這種溝通是很浪費時間和成本的。
關於Contacts的那點事兒 續
昨天沒有寫delete update insert，今天又試了一下。我的需求不是整個新建聯絡人，是在現有聯絡人的基礎上新增乙個字段。所以 應該是 values.put data.raw contact id,long.tostring 1 values.put data.mimetype,commo...
關於Contacts的那點事兒 續
昨天沒有寫delete update insert，今天又試了一下。我的需求不是整個新建聯絡人，是在現有聯絡人的基礎上新增乙個字段。所以 應該是 values.put data.raw contact id,long.tostring 1 values.put data.mimetype,commo...
關於大資料的那點事兒
大資料的出現使得很多人開始研究這個新興的事物，因為通過對大資料的分析，可以找到未來發展的方向，同時也能發現企業自身的問題，但是大家是不是真正的懂得大資料呢？理解大資料需要了解什麼呢？這就需要了解大資料的定義 大資料的特徵 以及大資料處理。知道了這些，也就算是正式入門大資料了。一 大資料的定義 大資料...