每個企業都經常會因為戰略或市場進行市場調整，也會因為公司規模的不斷擴大而對公司內部進行擴張和改造，我一直在思考我如何應對這種變化，有沒有軟體的銀彈可以讓我解決這一切的變化呢，事實上我現在還沒有發現它的存在。
前段時間接到指示，將原來的系統，乙個一對一的銷售、庫存、採購系統變成多對多的銷售採購系統，這個問題實質上是對原有架構的修改，因為最初該系統並不是為多對多銷售、庫存、採購而設計的，很多地方都是單一的點對點業務流程，若擴充套件成為多對多的話必有大動作。
如果你的老闆一點兒也不懂技術，他用天真的眼神看著你，然後試探性的問你，這個不需要多少時間吧，修改起來應該不是太難吧，這個時候我應該如何回答呢？第一，我清楚這種軟體架構性的修改是在應對企業擴張的戰略計畫，每個公司或軟體的每個階段都存在這種情況，從企業管理的角度來考慮，這種戰略計畫的擴張所引發的軟體的適應，在軟體功能本身來說應該是容易按需而變的，應該是方便擴充套件的，如果不能做到這些，那就是這個軟體不夠優秀，這是從企業角度出發去思考；第二，從軟體或開發者角度去考慮，企業的變化是不定的，軟體是否可以在不改動架構的前提下靈活適應企業變化，本身是乙個架構師能否深入了解企業，並且對企業接下來的動作具有前詹性，並且，該架構師還應知道從軟體設計的角度，哪些是不需要過度設計，哪些是應該留有擴充套件的架構，並對軟體開發工作量和時間有乙個大致預期。
事實上，以上的架構師是理想的情況下所存在的角色，大多數時間裡，業務流程是裝在一些人的腦代里，軟體設計是裝在另一些人的腦袋裡，而對企業前詹和重要計畫的又裝在另一批人的腦袋裡，要將這些東西組合起來，是一件相當困難的事情，而且，重要的，重要的是軟體在第一次投入巨大成本進行開發後，如果很大的架構問題或是企業的擴張已經超過了該軟體所服務的範圍了，那麼該軟體就必須進行重新設計，這個過程就算是強大到微軟這種公司，也會在幾年之後重新設計一些軟體的核心。
但不是每個老闆都能理解這些事情的，我遇到的這個老闆呢，他在整個軟體的生命週期的過程都在開發新的業務邏輯，而且有些業務功能剛剛開發完成，業務流程就改變了，當業務流程改變的時候，有時關聯的財務，採購，庫存，統計等一流程就全都改變了，可謂系統越到後來，修改起來就越小心翼翼，越是複雜和費解。
我正在花業餘的時間寫新的架構的產品的文件，我希望我寫好後老闆可以採納或提出修改意見，而且可以同意對系統進行重構，另外乙個重要的問題是重構的時候，資料遷移的問題，在多在五百多張表的系統裡，資料遷移將是另乙個很重要的問題。
如果我的計畫不能得到實施的話，我必須做出選擇。
軟體隨企業需求按需而變，我的思索......
設計中應對變化的方法
sicp習題2.76 乙個帶有通用型操作的大型系統可能不斷演化，在演化中常需要加入新的資料物件型別或者新的操作。對於上面提出的三種策略 帶有顯式分派的通用型操作，資料導向的風格，以及訊息傳遞的風格 請描述在加入乙個新型別 或者新操作時，系統所必須做的修改。哪種組織方式最適合那些經常需要加入新型別的系...
設計，為了更好的應對變化
什麼是設計模式？1.是解決某些問題的辦法 2.不是憑空想象的，是經驗的積累和總結 不可 的變化。產品的上線只是第一步，維護和拓展才是我們花很長時間去做的。1.當前期設計不合理，後期維護出現重大問題如何處理？立即修復 接著挖坑 推倒重做 2.你永遠不可預知產品經理和老闆的idea，被動的接受擺布去實現...
如何應對流量的變化
對於站長來說，我們不可能每天都呆在自已的伺服器面前查詢我們的 資料，一般而言，我們都是隔三差五的去檢視我們 的流量，當然，也有部分站長，他們養成乙個很好的習慣的習慣 每天都會在上班前或者是在下班時都會看一下自個的流量。這是一種非常之好的習慣。當然，每一次我們看電腦流量時，都會有些疑問，今天，我們要討...