最近在公司負責技能系統，這塊兒想了很長時間了，最先還是在04年榮耀的時候就開始考慮的，因為那時欠考慮太多，被蘭大一指頭按死。但那之後並沒有停止思考，玩了一些遊戲，綜合考慮了一些情況，結合當前專案的情況形成了現在的方案。
從設計上，瑕疵什麼必然是有的，不然我可能現在也去開飛車造火箭了。這裡不想談具體的設計問題，而是想說一些衍生出來的問題。
乙個模組，部署實施的時候必然會有多人共同參與，在這些人中，溝通是個很重要，但也很講技術的工作，這點得承認，自己還有很長的路要走。
溝通的目的並不僅僅是把自己的意思傳達給別人，更重要的還有兩點，一是從別人那裡準確地獲知他人的意思，另外一點，是確保參與的所有人對同乙個問題的理解是相同的，等價都不行。
由於進度比較緊張，而且自己又有乙個特別想做的東西，於是馬馬虎虎開了兩次小會，與參與的同事溝通了幾個來回，從他們那裡知道了一些他們的想法，根據這些想法修改了一些設計，同時也把自己的想法知會了每位同事。但是，最後一點杯具了。
抽象的概念，最終體現到**，還有乙個過程，就是類似於偽**的過程。這個過程應該算作是具體細節的設計吧？這個階段，我忽視了。
只是布下了概念，大略地說了一下實現的模組和介面，但是，沒有說清楚某個方法究竟應該在**中如何體現為具體的類和方法，也沒有弄明白幾位同事各自的想法是不是有一些不同，就匆匆忙忙鋪起了量，結果就是：兩個人實現的模組從各自理解的角度上都是正確的，但是卻拿不到一起來用……一位同事嘗試從a角度來理解，構建了自己的整個介面集合，同時構建了對方的處理方式，而另一位同事同樣完成了這個過程，只不過是從b的角度去理解，於是就……
這確實是自己的問題，以後需要注意這些。
還好不是那種大的模組，浪費了一天的時間，又駛回正軌了。
說到細節設計，其實有時候想想，《最後期限》推薦「最後一分鐘編碼」，就是要求擴大和改進這個過程。但這一點對於習慣用debug和可見性來描述軟體的中國程式設計師，還是太過於遙遠了。我們所接受的教育，以及我們一直以來所維護的傳統，都是輕設計而重編碼、重除錯的。快速部署對我們總是比風暴設計要重要得多。但是，強化的設計還是值得一試。強化到什麼地步呢？《最後期限》給出了若干個標準，其中有乙個是，設計應該針對模組間的介面，而非重現需求的概念。需求的概念是乙個歸納過程，邏輯正常的人們只需要窮舉需求集就可以解出來等價的概念。但是介面，作為從概念的演繹，其變化性一下子就上去了，因此，應該得到重點的對待。
現在真的已經不能再像之前那樣，自己設計，自己實施，自己發現問題，自己修改了，因為首先，設計的修改導致的工作量，不僅僅是自己的，也是別人的。
所以更需要小心翼翼，安排好介面、流程，留下足夠靈活的空間。
希望自己能盡快成長起來。
溝通和交流
剛剛從外面回來，想起還要寫一篇關於上次培訓的心得體會文章，這不便坐下來寫這篇部落格，順便記錄一下日常的工作 這次培訓內容就是兩道題目 畫 簡單 的圖形，團隊中抽出乙個人描述問題，下面的其他成員要根據描述，畫出相應的圖形。第一道題目要描述的圖形是 要繪製在下面的圖紙是 第二道題目要描述的圖形是 要繪畫...
淺拷貝和拷貝的概念和實現
一.從簡單型別和複雜型別資料的儲存來認識深拷貝 二.區分常用操作是深拷貝還是淺拷貝 1.賦值 不論是簡單的物件或陣列還是複雜的物件或陣列，都是淺拷貝 以簡單陣列示例 let arr 1,2,3 let newarr arr newarr 0 0 console.log arr 0 0 2.迴圈賦值 ...
如何做到高效溝通和高效溝通的好處
高效溝通的好處 如何做到高效溝通 具體問題具體分析 示例一 計算機學習會有任務布置，那怎麼做到高效溝通呢，你寫出對應任務的偽碼，比如 示例二 在跟領導匯報事情時要將事情描述清楚 示例四 工作總結 之前工作總結 看了一會文章，除錯了一下自動入庫的 之後工作總結 一 把高效溝通的例子新增在了文章裡，並補...