最近想把下單介面中耦合的營銷邏輯剝離掉，不然每次修改營銷工具或者新增營銷工具的時候，下單介面都得改動，下單介面本身就非常複雜了，每次改動都得小心翼翼，深怕出錯，從而影響下單。
公司的營銷工具非常多，像砍價、滿減、優惠券、拼團、秒殺等。那麼到底是將全部營銷邏輯一次性剝離還是乙個乙個來呢？當時老闆的建議是，乙個乙個來，降低風險。但是我沒有聽從，理由是：
營銷邏輯應該有專門的營銷系統負責，提供介面給訂單系統使用，如果下單介面的營銷邏輯乙個乙個剝離，那麼部分營銷邏輯通過呼叫新介面實現，部分營銷邏輯仍然冗餘耦合在下單邏輯中，這樣不徹底也很難適配。另外，也將占有很多測試資源，每次剝離一點營銷邏輯，測試人員都得把主流程測試一遍。後來老闆同意我的說法，開幹。
由於公司業務的發展，營銷工具越來越多，原有的營銷工具也不斷演進，導致下單介面需要頻繁的改動。而我們小組又在做下單介面的重構，需要同步需求和**。更可怕的是，我們當時是想剝離所有營銷邏輯的。最後發現，做不到。
只能用回老闆原來的方案，乙個乙個的剝離，不然下單介面剝離營銷邏輯這個任務，好幾個月都無法上線。
1、如果當時能多跟產品經理溝通，了解營銷工具未來的迭代計畫，那麼我當時就不會衝動的想一下子剝離所有營銷邏輯了。
2、變化太快太多的，只能小步小步的重構，步伐太大，很難有階段性的里程碑。
記一次失誤造成的影響
在使用salt給機器新增時間同步的計畫任務的時候，忘記salt的cron模組的寫法了，於是偷懶直接使用echo追加到 var spool cron root的方法新增了計畫任務。如下 salt cmd.run echo 10 usr sbin ntpdate ntp1.aliyun.com dev ...
對一次Task延期的反思
最近由於自己的原因,導致一次task延期了一周,在那週內就開始了瘋狂地加班,值得欣慰的是 周五順利完成了該task,事後想想,從該次事件之中也發現了自己的很多問題 1 對需求的理解不到位,導致db的schema一改再改,事後諸葛亮真的不好.2 對實用的技術盲目自信,之前簡單實用過apache poi...
一次介面設計的反思
現在的設計流程是 使用者未繫結的情況需要 init 查繫結關係 繫結使用者，放快取 根據使用者號獲取商戶列表 使用者已繫結的情況下需要 init 查繫結關係，放快取 根據使用者號獲取商戶列表 看上去有兩種其他選擇 1，增加乙個判斷是否繫結的介面，這樣 在使用者未繫結的情況下，init 查繫結關係 使...