在上乙個專案中，得到乙個慘痛的教訓——系統的可擴充套件性不是隨便就能夠小視的。上乙個專案的時間很緊，所以我在考慮架構的可擴充套件性上下了功夫，現在如果加上什麼netmanage之類的應用並不是很困難。但是這次修改的焦點集中在展示的流程方面。老實說，這個地方的可擴充套件性，我考慮的不是很充足。
當初設定系統配置的出發點是加深運維人員對語音流程的理解，所以將按照流程來分組配置。這樣，運維人員通過系統配置能夠加深對流程的理解，方便在日常維護性測試中及時發現問題。但是這樣做的缺點是當系統流程的決定決定因素不斷增加是目前的分組方式是以幾何方式增加。這樣出現的可能分組多的難以想象。這樣的配置工作誰都難以完成。
但話說回來，如果按照不同的策略來配置的話，運維人員很難理解整個流程的細節，無法通過測試來發現問題，所以要給維護人員的培訓很重要。我在寫**的時候都能覺得讓人發昏，何況對細節不理解的運維人員。這樣的細節對使用者來說是有用的麼？這需要時間來證明。
通過這件事情，可以從中學到什麼？首先，在中國的國情下，需求誰都沒有辦法很好的控制它，它就像洪水猛獸隨時會撲過來。運營商不會從研發或者維護的角度來思考需求的影響，他們從來「跟著感覺走」。所以一切都要靠自己，自己需要設計出很容易擴充套件的介面。時間緊，不能壓縮design的時間。一切盡自己的努力做到最好而已！
只是因為可以做些事情
我經常重複的乙個模因是 總是有不止一種解決方案。我還經常寫關於企業應如何評估可用解決方案以及如何最好地滿足其需求的文章。我不常提及的是，在現實世界中，有很多很好的 而不是那麼好 的原因，為什麼最好的解決方案就不會發生，或者沒有在必要的時間範圍內發生 我大聲疾呼 太頻繁 當我發現自己處於最佳路線受阻的...
喜歡Vim，只因為可以不用滑鼠
看了網上有很多人寫教程，教你如何將vim打造成ide。總結起來，大部分就是教你如何語法高亮 補全 函式名顯示 跳轉 工程目錄瀏覽等，跟ide還是差很多。當然，也有geek確實能把vim當成ide使用。不過對於大多數新手來說，將vim當做ide使用門檻還是有點高。應該將更多的時間用於學習程式語言本身，...
判斷是否可以關燈
description 給你 n 個開關和 m 個燈。第 i 個開關開啟某一些燈。該資訊以矩陣形式 n 行 m 列 如果第 i 個開關能開啟第 j 個燈，則 a ij 1，如果不能開啟則 a ij 0 最初，所有 m 燈都關閉。開關狀態僅能從 關 變為 開 這意味著如果兩個或更多開關連線到同乙個燈，...