[CD心得] How To Deal With Unfriendly Technologies -如何應對不友善的技術
軟體工程一向都是複雜的, 很多問題都是藏在細節裡面一開始都不會發現, 直到他咬了你讓你感到頭痛
怎麼樣快速的找到不熟悉技術的通關密語或是秘訣,讓整個工作便順利, 這是本篇想要聊的重點
會有幾個徵兆或是信號代表系統或是開發過程可能會出現問題
- 使用大家都不熟悉的技術
- 缺乏專注, 團隊成員一開始可能都是以兼職的方式會是side project,並不是非常的在意
- 時間壓力
解決問題的第一步 : 版本控制 & 可部署性
利用docker 或是容器化技術讓local 和 real 環境跑的程式碼是一樣的, 差別只是要做管理設定配置 (configuration)
使用版本控制可以低風險的嘗試錯誤, 當發現下一步走錯的時候, 可以很簡單的回復成上一個可成的版本
雖然這件事看起來沒有什麼大不了的事...但是他對整體的工作模式有了很大的改變
你不能明智的期待我們會準確預測未來的事
所以了解當下的問題以及做出當下適合的決策很重要
即使這個決策在之後被證實他是錯誤的, 但是我們已經開始在執行且發現錯誤了
等待完美的方法 VS 快速面對失敗且快速學習
但在倡導快速的時候, 我們很常會掉入另一個陷阱裡....
當我們面對問題的時候, 可能會很快地提出解決方案, 但是我們看到的只是問題的表面
而忽略了我們想要解決的問題是什麼？ 導致走的方向偏離原本的目標
你對目標的猜測遠比你所決定採取的步驟更為重要
如何選擇正確的技術？
如果你的技術沒有做正確的事, 有時候他會讓你的工作變得更加困難,
技術選擇問題的時候應該這麼做
- 先釐清我們想要解決的問題是什麼？
- 再來尋找有哪些技術可以解決我們所遇到的問題？
- 這個技術能做到前面提到的版本控制嗎
- 再思考這些技術所帶來的限制或是缺點是什麼？ 是我們可以承受的嗎？
Goal over Tech
選擇王牌技術 (Feature of top trumps)可能不會是最好的, 每個問題都不一樣, 適用的技術也不一樣
只有適不適合的技術
Make it work before you change, Make one change at a time
在動手修改配置之前先確定他是可以正確運行的, 有點類似TDD 的概念, 先是綠燈再來重構
且不要隨機的改動配置, 應該要一次一個有系統的方式去調整配置, 在每個改變之前先預測改變的 (Decide where to find results before tou start)結果, 小步驟的變動且弄清楚的影響的範圍後, 再來驗證這個改變離我們的目標是越近還越遠, 這樣改變的就有個方向
有了系統性的嘗試方法之後, 我們就可以發花更多的時間去更深入的研究系統, 這樣有助我們縮小問題的範圍
更重要的是如果我們能寫一些驗收性的測試幫助我們在改變的時候, 快速的失敗且找到問題
這會使我們的效率大大提升
這完全是一個心理的問題, 在什麼時候工作模式值得變得有條理有效率？
人總是懶惰的, 總是想著說這些東西我手動10秒就可以做完了.... 為什麼要花兩個小時甚至半天或是更多的時間去做那些基礎建設呢？
但是過去的經驗告訴我們, 這些基礎設施的投資都是必要的而且越早做的效益越大
科學和軟體工程就是不斷反覆試驗的過程, 他們的價值是幫助我們更有條理的方式徹底地探索問題是否能簡單的重複驗證或是當改動小設定的時候能否快速得到回饋？
這些基礎建設可以幫助我們更快更輕鬆地達到我們的目標
Focus on the Goal
留言
發佈留言