最近工作中，遇到乙個快捷鍵相關的問題，在修改這個問題的整個過程中，經歷多次思考、討論和回顧，對此問題以及對應解決思路的演進有較為深刻的體驗，在本文中進行完整記錄，已沉澱經驗。
當前系統有2類賬戶，以下稱為賬戶a和賬戶b，a\b賬戶下具有相同的業務功能，以下簡稱為查詢功能。使用者在修改b賬戶的查詢功能快捷鍵，提示修改無效。修改a賬戶的查詢功能快捷鍵功能是正常。
a、b賬戶下的查詢功能，復用的是同乙份**。因之前設計失誤，導致a、b賬戶下的查詢功能id以及快捷鍵是不同的，在使用時會被認為是兩個獨立的功能。之前沒有問題的原因是因為查詢功能只在a賬戶下有，後來有新需求，b賬戶也要增加該項功能，具體在增加時，簡單的複製a賬戶下的配置到b賬戶下，導致該功能在a、b賬戶下的功能id一樣，這就給後續操作買下隱患。
軟體在初始化時是以功能id為key來讀取，如果遇到2個功能id一樣的key，只會以第乙個為準。因此，在修改b賬戶下的查詢功能時，修改後的值不會被讀取，自然也就無法生效。
最開始思索解決方案時，想著以改動最小的思路去解決，將b賬戶下的查詢功能id設定為不一樣，即可解決這個問題。改動範圍小，只影響特定功能。
在和同事討論之後，如果按照目前的改法，是沿著之前不好的設計思路繼續前進，這只會解決目前看到的問題，而沒有徹底解決a/b賬戶下同乙個業務快捷鍵不同，這個設計本身的問題。這會導致越往後改會越繁重，屬於只解決表面現象問題的解法。就像自己之前腦海裡想的問題觸發鏈條：
問題根源 -> 鏈條1 -> 鏈條2 -> ... -> 鏈條n -> 問題具體表現越靠近問題具體表現去修改，改動越小，但問題根源沒有改動，本次修改只堵住了這條鏈條，根源未改，後續隨著需求的演化，還會有其他分支出問題。這種，頭痛醫頭腳痛醫腳的修改思路是短期行為，但工程上和實現上是需要權衡。從已有的工作經驗來看，越靠近問題具體表現那層，改動以及影響的範圍越少，越靠近問題根源，改動以及影響的範圍相對越多。越往上追溯，涉及到的依賴者越多，改動的可控性以及能否一次改好並且不會由此引發其他關聯問題，這需要更多的分析以及測試用例覆蓋。特別是在鄰近版本發布時間視窗，如果不是特別重要、緊急的bug，可以先緩一緩或者採取影響範圍面小的解決措施，同時加以備註，需要在下一版中，採取更為徹底有效的解決方式。
下面以上述問題為例子，進一步更深層次去解決並完善已有設計。
a、b賬戶下的查詢功能支援鏈結屬性。既支援b賬戶的查詢功能鏈結到a賬戶的查詢功能，兩者公用同一功能id以及其他屬性。在初始化時，針對鏈結節點進行特殊處理，從被連線的節點拷貝相關屬性到鏈結節點上。
上述設計可以解決相同功能在不同賬號下的屬性不一致問題，但也帶來了新的問題，修改功能屬性時的關聯改動。
修改功能屬性，具體可細分為以下三種情況：
只修改非鏈結節點，例如a。
同時修改非鏈結節點和鏈結節點，例如a，b。
只修改鏈結節點，例如b。
在增加鏈結屬性的設計下，場景1自然而然的實現了，但場景2和3還無法支援，需要額外處理。下面就解決場景3下的同步修改，給出具體思路分析。
通過上述分析，大的方案方向確定的，各種場景也區分開了，下面就具體分析場景3的實現思路，目的是為了修改鏈結節點時，同步修改回到被鏈結節點上。
經過與同事多次討論、分析，大的解決思路有兩個方向：應用層和資料層，下面分別來闡述。
從應用層去實現鏈結節點修改的同步邏輯，分析需要多次分離和查詢，實現較為複雜。在該版實現中，對於場景2的解決，是按被鏈結節點為主。在這版實現中，考慮了場景2和場景3，需要新增許多輔助**，邏輯複雜。
這種實現思路的複雜性在於，從應用層的角度來看，鏈結節點在初始化後，其內容是被鏈結節點資料的副本，他們是兩個完全獨立的功能，只不過屬性內容是一模一樣的。鏈結屬性只用在賦值，沒有指向關係。因此，在實現同步寫回時，需要全域性遍歷去尋找對應的鏈結節點，然後將改動寫回。
這裡就有另外一種思路，除了鏈結屬性外，增加鏈結父節點指標，這就是從資料層實現的方案。
從資料層視角去實現，增加鏈結節點父指標，在初始化時就設定指向物件，後續在同步修改時，將同步時機前移，直接將鏈結節點的改動同步到父節點中，以此同時，拋棄掉鏈結節點自身的改動。這樣，可大大簡化同步流程，整個過程簡潔清楚，一目了然。
對於a、b類賬號下共有的功能，對外只提供乙個修改入口，不提供多個可見入口，這樣，在需求層面上，就迴避了鏈結功能的關聯修改問題，這種改法需要和產品討論再做決定。
在軟體開發中，每乙個需求都有且應該有多種設計方案，每種設計方案下，又有多種實現方式。
有時在提出解決方案後，除了它預期要解決的問題外，可能會隱含地引出其他問題，這些問題在前期討論時是很難預見全的，只有具體實現時，才會碰到。因此，在每得到乙個解決方案後，可以先進行小步嘗試，發現一些在方案討論階段沒有考慮到的場景或者路徑，再進一步反饋完善。
警惕以下這些懶惰心態：
多思考，多討論，多閱讀已寫過的**，在不斷的否定、質疑、討論中，完善已有想法或者解決方案的思路，可從應用層、資料層、需求層面去擴充套件思路，在沒想清楚所有分支和可能的錯誤之前，不要貿然動手改動。
從一次失敗的比賽經歷引發的思考
這個學期初，老主任給我介紹了乙個專案 本人是校雜誌社辦公室副主任哦 之前有推了老主任的邀請，這次總覺得不太好意思。仔細看了一下比賽內容，智慧型。急忙給好友小西發去訊息，他常常想和我一起做些東西，而智慧型正是他感興趣的話題。就這樣，我，小西，老主任，又找了兩個同班同學。第一次開會，大家都很踴躍 第二次...
記一次idea快捷鍵
ctrl r，替換文字 ctrl f，查詢文字 ctrl s，存保 ctrl c，複製 ctrl v，貼上 ctrl x，刪除行 ctrl y，刪除當前行 ctrl d，複製行 ctrl z，回退 ctrl n，可以快速開啟類 shift f6，重構 重新命名 shift shift，可以快速查詢類...
一次快遞經歷引發的思考
最近一次蛋疼的寄快遞經歷引發了我對企業發展的思考，為什麼有的企業可以發展的很好，而為什麼有的企業卻面臨倒閉？2.1 底層員工是企業門面 企業的底層員工是直接接觸客戶的，他們是公司的門面和形象，他們做事的態度和方式直接影響著使用者對企業的印象。乙個企業對底層員工沒有基本的要求，任由其胡亂作為，這對公司...