# 以為 Developer Discipline 離我很遠，其實一直在身邊 - 楊捷凱

{%hackmd @DevOpsDay/BJXaW1_k6 %}

> 從這裡開始寫

## 背景


- 會因為codestyle而吵架
- 技術線選擇
- 一些錯誤的觀念被傳承下來（常常說以前的人怎麼做就這樣做）

## Three Aspects

- Tooling
- DevOps Flow
- What Now?

## Tooling


### Development Environment

- Development environment ready with pre-installed.
新人需要花多少時間準備環境？ 講者: 兩年前1個月，到現在的3小時等機器開。
(新人還是要 1-3天)
- Save Time. New engineers can often spend tow much time.
過時的文件、過時的設定，這些時間是可以被省下來的
透過工程的方式加速環境的設定，並確保環境與其他同事是相同的。
- Guarantees repeatable developer experience.
一致的開發環境很重要

### Programming Language, Frameworks and Libraries


語言框架選擇
- 常見的現象
- 30 年前跟 30 年後選擇語言不同，未來管理就會有困難
- Limit choices in programming languages available to use on new project
- 限縮內部技術可選技術選項框架或語言，有助於縮短新人的適應期，團隊中也會出現領域expert。
- Every library and framework is supported by a well-known "owner"
- One library per "thing" per tech stack
- 處理 log 要幾套 library? 選一套就好了
- One version per "thing" per tech stack (ideally)
- 版本控制一直都是做平台或是做管理者的痛，越多的版本管理的成本就越高
- 限制版本，不要過於發散
- 當開發風格標準化之後，可以減少非常多問題，讓跨團隊的溝通可以使用同一種語言。

總結：限縮選項、開發風格、限制版本，標準化來降低管理負擔 與 團隊溝通成本

### Why Standards and Opinions Inside a Company?


- Allow you to focus on just the important points of a design or implementation
- Fast communication between teams
- Makes it easier for engineers to help out other porjects
- More predicatable quality

`不要考驗幫你code review的人的心臟，他沒有這麼多精力去了解你奇異的code style`

改變開發習慣跟風格是很貴的事，用各種方式（脅迫?）讓大家改變
標準化讓同事間可以互相協助
當一個工作項目只有一個人可以完成的時候，整個是有問題的
用chat GPT review code，可行

- Quicker project startup
- Better mentoring and faster producitivity for new projects
- Limits the number of things an engieer needs to know to be good at the job
- Better suppor from Platform Engineering and Developer Experience teams
- easier to supply well-tested.
- Application of standards is the basis of developer discipline.

當前面的條件都成立，platform engineer 就只需要完成流程


### Example - Discipline in Action

- Google is well-known for having a disciplined engineering process.
- And somewhat unusually, they talk a lot about it publicly.
- Books
- Publishing coding standards
- Reearch paper
- Conference presentations
- Open-sourcing some tools

Google 在做 discipline 非常有名，本身也很強力的推廣。一個公司要限縮他的技術選擇，Google 也在做這件事情。當然有開放員工申請，但是要經過一定的申請流程。

- Applications and Services
- C++ and python (early 2000's)
- Java added later(later 2000's after MUCH work)
- Go(early 2010's)
- TypeScript (本來是 angular, 2017年才正式成為公司內官方語言)
- Closure -> GWT -> Angular -> ??
- Developer Tools
- Eclipse -> intellij, heavily customized for cloud-based git, blaze (bazel) and the monorepo
把公司的政策寫成Plugin，讓所有人拿到IDE 都是一致的。
- Source Control
- Trunk-based development
- Supported b advanced code review and code understanding tools
Google 用 mono repo，當一個改動，會執行所有依賴專案的測試，改壞掉的人要負責修好


- Coding standards
- Testing and Code Review
- Third-party Libraries
- 只有經過認證的 lib 才能被使用
- Protocal
- 後端 [gRPC](https://ithelp.ithome.com.tw/articles/10255470)
- 前端 REST

參考書
- [ Google SRE Books](https://sre.google/books/)
- [Software Engineering At Google book (read online)](https://abseil.io/resources/swe-book)

### Reflect

- 目前的工作上，有沒有開發標準？
- 這樣的標準化對團隊會帶來什麼好處？

### Reflect What Tech Stack Do You Use?

團隊成員對技術架構的回覆是否一致，透過這個角度去思考

## DevOps Flow

### Best Practice and Standards


- Git practices
- 不是每個人都會 git
- 不會 Git 那就找五倍紅寶石龍哥內訓吧-> 趁機打廣告啊
- Coding Standard (抄google的)
- Code Review
- 多一個 PR 的動作，是為了讓大家多一個時間去檢視程式合不合理
- 經驗傳承（技術、Domain knowledge 等）
> 補充: Code Review 階段，會檢視 PR 的 Checklist 是否有完成，包含測試，AC 有沒有被滿足，相關的文件是否有被更新到 [name=Kevin]
- All of this information is widely shared and easily accessible.
- 這些資訊是要很容易被 shared，但工程師都不喜歡 share（寫文件是很神聖的）
- 為何不愛share:
- 怕被搶走工作
- 討厭寫文件（自己寫的都不一定看得懂）
- 有 Mentorship Program 的叫新人寫文件，然後 Mentor 來 Review

建立一致的標準，不要把事情當做理所當然，所有的東西應該被要記錄下來，並要求團隊Follow

### Testing and Build/Release Process


- well-known expectations, tools, tech stacks, and terminoloby for:
- unit testing
- system testing
什麼是好的測試？有測到重點嗎？
- Testing approach
- Security check and scan
- 工程師不喜歡，覺得被找麻煩，透過溝通去解決。
- 等到被拖庫就知道痛惹
- Common release flow

- 應依照各個產品線的性質來訂製專屬 release flow

### Others

- Infra
- Cloud or on-premises
- k8s or VMs?
這些會影響架構的規劃與設計
- Operation
- Observability / monitoring
- On-call
- Devs 不 care Ops的話，operation 就不能正常工作啦(這個不是講師講的吧？意思大概是這樣，所以才要推 DevOps)
> 補充: 開發者如果落入我只負責把東西寫出來的思維，對品質或是 Day2 的事情不在意的話，負責 opearation 的人會很辛苦，他們就活該要收拾這種爛攤子嗎? ownership 在這邊就變得很重要，工程師要對程式碼負責，包含上 production 的品質及穩定。[name=Kevin]

## What Now

[
](https://)

### Maintaining the Tech Stack

- Driven by a "platform engineering" team
會有一個專門的團隊在做這件事
- Run like a production team
- Customers are other devops teams and developers
- Includes
- Source and artifact repositories
- Automating a standard tech stack
- Tools
- Developer machine
- Development infrastructure
- Documentation
> 可參考下一場講師的內容，他有提到這部分的實踐[name=Kevin]

### Documenting Standards

- well-known location (a memorable url) to collaborate on
- Coding standards
- Code review checklist
- Approved libraries
- Documentation for common tools like IDEs, command-line utilities, testing tools, etc.
- Clear ownership of all documentation artifacts.

- base image以及使用套件都需要被管理
> security 很喜歡看這塊 [name=Kevin]
- document 都需要個owner，讓其他人可以找到對應的人來handle
`如果一個文件沒有owner，要嘛沒人在用要嘛沒交接好`

### Discipline Call to Action


- Think about where you can take a more disciplined approach
- Share your ideas and learnings with other developser

>

- 前期轉換成本高
- 能夠更容易的調度人員，或是其他團隊的支援
- 團隊不用在意支微末節的東西
- 當一個團隊享受到好處時，就會去幫忙宣傳，使用者的感想/感受是很重要的

### So, Do we have answers to these questions?


- Coding style？
- Tech Stack selection?
- 新人的mentor

## Take Away - Developer Discipline


- Speeds you up, not slow you down
- Leads to more predictable quality
- Focuses you on the things taht matter most.

discipline 的用意，最終的用意是要加快你的開發
透過 discipline ，解決繁瑣的問題，讓工程師專注於開發

## 來賓問題：

### Q. 哪一件事情，是講者最花時間的？

* code review
** 此件事情最難的原因在於：牽涉到人的立場（立場皆不同）
** 到底誰要來code review: 連senior 都會有盲點，junior也看不太出來
** code review在推廣時候是個大問題：可以靠tool解決，但是人工介入的時候會涉及到利益衝突

### 這題是什麼？－ㄅ

web客制需求多元化？

### Q. 台積電著名的就是留白，軟體領域上怎麼規劃留白？

* 這就牽扯到可愛 (client? ＸＤ) 的 PO 有沒有留時間？我到底要去跟 PM 談我要多少時間用來做改善？
* 要讓 PM 認知到這件事是有價值的
* 要嘗試溝通
* 本來就會有大量的溝通

### Q. 標準化的程度，大部分都希望透過標準化達成效率，但過度的標準化會不會讓工程師看不到不一樣或與時俱進的寫法？

* 規範本身就要與時俱進
* 有20%的空間讓工程師自由發揮
* 是可以持續改進，不是訂完就是憲法，目前應該比較算是「共識」，等 ok 了再變成規範，一次就太強硬下去的話，那個反彈不會讓事情變好
* 這是需要做溝通的 (溝通again)

### Q. 剛剛有提到有個平台溝通的團隊，他們平常是怎麼運做

* 類似委員會(專門的團隊)的東西，因為組織很大，所以不可能 platform 一對一去溝通，由事業體代表去收集意見，會做訪談之類的收集意見。這個團隊會 dedicated 做這件事。
* platform 工程師 可以把它視為一個 product

### Q.對於code discipline推進有沒有相關的監控或是指標來判斷是否成功(如何量化CODE REVIEW、PR的品質??)

* 有一個 metrics 平台在收集 tool chain 的數據

持續精進
自我評量表，了解自己的位置，適合怎麼輔導、改進
不知道前一題提到的委員會對於這個衡量有沒有權利?
> 其實是有的，畢竟委員也是需要扛業績，所以一些作法上的彈性 [name=Kevin]

---

## 聊天室

有點好奇，投影片用OCR掃描文字的話

我覺得事先有投影片的話比較可以專心聽內容 ：（
呼應講者「讓工程師可以專注做他應該做的事」
> Sorry, 我的習慣是簡報內容不會是重點－要專心在我不在簡報上的資訊 [name=Kevin]

code review 真的很難標準化

剛好最近 William 有篇文章在討論，分享一下
[從 Code Review 的小事看到大事](https://william-yeh.net/post/2023/09/on-code-review/)
感謝分享～

Coding Style 就是沒定義 guideline，大家有各自的解釋吧，不然直接拿 Google 或是其他大公司的來用？

solving problem後要怎麼賣出去

問題是要 follow 誰的

誰來維護開發環境自動建置腳本？資訊部門？
他們IT人力夠多.......
有專門的單位會去維護
公司資訊部門沒人力資源去定義維護規範？那就抄 Google 的吧，記得要備註引用

~~PHP 以及 .NET 派表示不服~~

然而技術選型有需要公司內有專門團隊作出決策，並且要能協助解決每一個團隊遇到的問題，甚至要協助做系統架構設計

工程師 === 藝術家
: 不要限制我！

人都不愛被限制阿 不只工程師

講者深深嘆了一口氣，不要逼我拿考績來跟你定孤支

pre-commit好用
python isort跟black可以解決很多事情唄

~~用了pre-commit照樣吵，難道其實是人品問題~~

工程師常常文人相輕

一起跳槽，不孤單

雙人開發？

新技術不會幫公司賺錢，穩定的產品才會
工程師學新技術，用下班時間學就好了 -> 或許對穩定的公司是如此吧？

新技術跟產品穩定一定是兩個面向，但是如何達到平衡是個很大的問題，覺得講者說的新技術下班再更新並不是100%認同

> 補充說明，可以上班研究新技術，只要這個技術是要用在公司產品服務上。我們在執行時，也會開所謂的 Spike 單，讓工程師可以用上班時間作技術評估 [name=Kevin]

穩定產品幫公司賺錢,不是新技術
不能賺錢的事情 不能報加班
抱歉了錢錢，但是那個新技術太香了

天降神諭
神說就是這些語言了

google不可能幫微軟啊

這種標準化的事情，每年都要拿出來講一下

講師今天嘆有夠多氣
> 這樣才能讓大家知道這件事情難度有多高 [name=Kevin]

看來是有看過 if(1 === 1) return true

我看過 expect(undefined).toBe(undefined)

我倒是一直笑 難道你要哭嗎(嘆x
我寫了文件 一個禮拜之後我自己可能也看不懂

如果覺得share就會被搶工作，反過來說是不是代表可被替代性太高

寫文件很重要，但是開發都沒時間了
文件能不能執行->看向 Google
Google 文件都寫不好了（Ｘ

GCP你查得到想查的...一定是寫文件那個人！！！
junior 連表達都會有問題了，寫個文件QQ

我覺得開發工程師 跟會表達的工程師已經是兩個領域了
會說人話的工程師更少之又少
--> 確實
--> LGTM
--> 山道猴子

關於code dicipline的重點之一是縮限跟規範，降低開發者的認知負荷，這塊是不是跟昨天ruddy老師講的DevX可以克服的?
--> 同意
--> 昨天的圖出來了
--> 有寫引用來源給過

不過讓 Junior 為 Senior 做 code review，雖然無法協助找出問題，但是可以視為讓 Junior 去學習 Senior 的寫法

已另外一個面向來說 很有可能有些小問題會被junior發現的可能 不過通常現時這種東西chat ai就有辦法達成了(

真的不能把CODE REVIEW 被量化

有人遇過有些團隊成員看到資深工程師的PR就直接按Approve的狀況嗎?
這樣資深工程師要怎麼透過code review找出自己的問題@@?

### 以下請問各位大大自家產品跑單元測試的時間

5分上下 不過我們的測試為了涵蓋率寫的 可信度存疑(？
3分鐘左右，但是我們是因為大家要寫不寫的，只能靠自己先把核心的功能保護起來QQ
4分鐘左右，一樣只能保護核心功能
10min+ > 被寫成integration test. level QQ

Unit Test 應該秒級時間要完成
數量多起來也是要跑一段時間的

求投影片翻拍
+1 敲碗
敲碗投影片

> 很抱歉，礙於公司規定沒法釋出簡報 [name=Kevin]

那可以把投影片的文字貼上來嗎XDDDD

![Uploading file..._tlm4v421j]()
![Uploading file..._375p42hnj]()