2020/02 Cola Daily Build

Daily Build
#1

02/03

好像是內容沒儲存或是忘了寫?

#2

02/04

  • 寫文件的習慣, 幫助自己、解救別人
  • 避免太過吹毛求疵
  • 一直拆開 git commit, 重包花了很多時間, 其實不需要這麼做
  • 真的有需要才在最後一次搞定
#3

02/05

  • 拆解需求, 完成功能, 定義接口與輸入值、傳入參數(獨立化功能)
  • 完成功能後, 實做 interface , e.g. a 功能 + b 功能 + interface
  • 整合測試
#4

02/06, 02/07

  • 承 02/05, 將功能單獨為 service, function 後續開發的時候只要關注連接上的問題
  • 功能應該要是穩定, 輸入、輸出值已經被定義、固定; 這樣就能把關注點轉移到功能間的連結與 interface
#5

02/10

  • 應該試著找個方法記錄系統、開發的 domain 或 controller 或入口
  • 目前看起來以 domain 目錄做分類還算不錯

情境是, 接手的工程師想要修改訂單資訊

進到 domain/orderService 就可以找到大概方向

#6

02/11

  • 測試、開發環境的區分
  • 初期，開發時，如果沒有把測試、開發流程、環境考慮進去, 非常有可能在未來維護時造成諸多不便
  • e.g. 寄信功能: 後期增加信件樣版時, 有可能真的把客戶的信件寄出

應該在寄信中間擋一層 https://mailtrap.io 這樣的服務
好讓開發時, 專注在業務邏輯，而不是避免信件誤寄這類的旁枝細節

#7

02/12

  • 產品幫助你解決的問題而產生價值
  • 有效率的打發時間
  • 有效率的增加時間/延伸時間
  • 時間自主性的回歸 (免費與廣告)，『金錢誠可貴，自由價更高』

ps: 窮人看廣告省錢，富人花錢省時間
雖然標題這樣寫，但這裡的窮、富指的不完全是字面上的意思，方向上更接近效率、機會成本。

ref.

1個讚
#8

02/13

  • 如何查覺問題背後真正的問題(困難)
    • 網站、功能、程式有問題、很爛，背後可能有很多原因
      • 多次修改後的問題
      • 需求不明確
      • 不合理的時間要求
#9

02/14

  • 做了很多系統的行為測試，花很多時間確認行為或影響
    • 應該建立文件
    • 但因為這部份因為系統複雜，寫文件也要記得更新文件; 際上不太可能落實，目前還沒有好的解法
#10

02/17

  • 繁鎖、複雜流程應該記錄成文件
  • 記錄的過程可以是，先寫下大綱或方向或是一個過程(類似粗略手稿)
  • 事後再慢慢把細節補齊，完善這份文件; 就算最後沒時間補齊文件，也保有一份簡單的手稿做為回憶用的線索
#11

02/18

  • side effect，專案趕進度時無法避免便宜行事，愈便宜的動作未來的代價愈高
  • 添加、修改功能時無法迴避 side effect/副作用帶來的問題，除非有對系統的成員

解決方法:

  • 把完整的流程/code 爬完，但實際上只能盡量做到
  • 找熟悉系統的成員 review
#12

02/19

  • 離職不能心軟，時間會延
  • 不能提早曝光，態度會變
#13

02/20

  • 功能: 愈簡單的東西愈複雜，時間估算上要注意
  • 簡單用就需要做錯誤防制、檢查
#14

02/21

  • GTM, GA 分享; 事先演練、練習很重要
  • 事程與花費時間的拿捏點 & 技術債; 拉分檔案 class 比較方便處理
#15

02/24

  • 技術債的定義? 明知有缺失的部份應該要一次補完(花時間)，或是下次再處理
    • 這次的情況是，明知有缺資料想簡單處理，但事後發現這個資料是不可或缺的(仍需由 server 端處理)
#16

02/25

  • 一整天都在交接
    • 如果事前能先把更多的文章準備好，是不是能有幫助呢?
    • 一些軟實力的內容
#17

02/26

  • 重建、更新 docker 開發環境，舊有的文件幫助很大(不過有些部份可以更完整)
  • 因為開發環境使用 docker 的關係，工作與工作間(專案之間)的環境切換很快
#18

02/27