今天在解決
bug00174317
時有一點思考，
bug是個小問題，就是在2.5.2的時候新增了需求，在位元速率為64k純音訊會議時，會議資訊框中的清晰度顯示為：「純音訊（64k）」，而不是「標清（64k）」，跟蹤檢查了一下原因，原因是平台傳過來的結構體中有關清晰度的描述只有
u8 byconfmode;//會議模式：0-高畫質、1-標清、2-流暢、3-自定義
四種型別，沒有音訊型別，其實這個bug在上層根據會議位元速率來判斷，也能夠解決，但是還是跟終端與平台溝通了一下，看能不能新增乙個4-音訊標識。
在溝通後，因為以前舊終端版本的顯示相容問題，就決定不加此標識，由truelink區域性修改。
這讓我有點躊躇，在開發過程中，我們要如何解決這個「相容與重構」命題，這個名字起得有點大，不過我想大的問題，也是由這樣乙個個小問題丟擲，更大一點還可以說是「穩定與發展」的關係。
在系統設計的初期，依據架構師的經驗，來盡可能得設計簡單，高效，可擴充套件的模型，但是也不太可能面面俱到，何況面對後續紛繁更新的需求，更難以企及。而我們在遵循前人設計的基礎上，總時不經意之前遇到這樣的細小問題，這種小問題應該如何處理。在處理這些問題時應該秉承一種什麼態度。
一般的看法是，這種小問題，在終端層修改即可，這樣代價最小，相容性高，也確實如此。
而就這個問題上，我的看法是增加乙個型別，這樣的好處顯爾易見。往近了看，能夠良好地搞定此bug，稍遠點看，這樣終端在判斷清晰度時，就會位元速率與清晰度的耦合降低，而是一種單獨的清晰度型別來決定，更況且我們已經有了這樣的字段。比如說高畫質，如果按照位元速率來判斷，可能今年768以上的算是高畫質，h265出來後，可能明年業內普遍認通的是1080，甚至2160以上才是高畫質，那如果按照之前的邏輯，直到老的架構被推翻，新的架構推出來的那天前，這個永遠都無法更改。
如果在解決問題的同時能讓結構朝著合理的方向改變，一定是種欣然的感覺。在歷鍊的道路上，總要做出一點取捨，如果覺得方向是向前的，why not?
有關加密與解密的一點記錄
由於出於安全考慮，引數傳遞的時候需要進行加密和解密，乙個比較簡單的方法是直接使用php中的函式mcrypt encrypt mcrypt decrypt，乙個加密，乙個解密，但是問題又出現了，這個加密過程中會產生一些使url混亂的符號，於是在加密後對加密字元再進行一次處理，然後多了一一次解析 key...
BUG回歸的一點看法
測試人員找bug是個技術活,而且bug的回歸同樣也是技術活 bug回歸到不到位,關係到發現bug本身有沒有修復好,同樣也關係的因為修復bug而改動的 對其他功能的影響.bug回歸的幾點心得 1.首先弄清楚bug必現的配置和操作過程.因為有時候回歸的bug並不是測試人員自己提的,有可能工作時間的原因,...
有關生活的一點討論
今天和同事在一起討論生活難易的問題，看到乙個帖子，國外的乙個快50歲的軟體工程師寫的，說他失業也，再就業的難題，然後我們就發散開來了。今年28歲了，不知不覺，還感覺自己很年輕，但是其實已經不小了啊，之前一直都在逃避，逃避在上海買房的問題，逃避未來的發展，因為現在在一家外企做研發，自我感覺還很好，也許...