# Stacking Insight / Andrew Howden

{%hackmd @ModernWeb/SyA2U6SmT %}

Andrew Howden 特別提前分享的愛心[中文版演講簡報](https://ccms.ithome.com.tw/api/slideapi/1242/click?l=https%3A%2F%2Fs.itho.me%2Fccms_slides%2F2023%2F11%2F9%2F39f16a33-bf49-40d7-9984-f02f7f4f3052.pdf)

> 共筆請從這開始

> 聊天室

gdpr

[GDPR](https://www.ndc.gov.tw/Content_List.aspx?n=F98A8C27A0F54C30) 這東西真的難搞
~~歐盟是阻礙世界進步的機構~~
現在開始不止歐盟友這些問題加拿大還有美國也開始再採取相對應的措施
>《一般資料保護規則》，又名《通用資料保護規則》，是在歐盟法律中對所有歐盟個人關於資料保護和隱私的規範，涉及了歐洲境外的個人資料出口。GDPR主要目標為取回個人對於個人資料的控制，以及為了國際商務而簡化在歐盟內的統一規範。

敏捷開發再執行上，真的是敏捷了？
-> 敏捷 =/= 快速 （但老闆通常會以為）(嗆他啊)
> 很多數的敏捷說詞上，再實際情況是瀑布流或是隕石術並非真敏捷開發 QAQ
> 敏捷是適應變化，不是寫code 會變快 (對) +2
很多老闆或pm以為去聽個敏捷的課就會了

或是每天開站立會議 = 敏捷 ==> That's true. totally wrong!
>但是資訊交流是敏捷的一部分ＸＤ
>資訊交流是敏捷的一大重點
>敏捷開發宣言
個人與互動 重於 流程與工具
可用的軟體 重於 詳盡的文件
與客戶合作 重於 合約協商 
 回應變化 重於 遵循計劃 

也就是說，雖然右側項目有其價值，
但我們更重視左側項目。

[偽工商XD] 歡迎來敏捷攤位聊聊敏捷宣言，還有免費星巴克冰咖啡～

> 本部門站會 = 個人講個人的，其他人都沒在聽
>> 帶會議的人要處理啊 +1 (帶會議的人懂敏捷嗎問題是) QQ
>>> 提出這問題的人知道有問題就要回報 有溝通有改進才是正常循環
>> 問題溝通應該是雙向，我覺得常常變成2個單向，各說各的都沒想聽對方講什麼，做自己開心或自以為的方式 xd
>> 除了帶會議的人要注意之外，也希望所有與會的人可以理解為什麼要開站會
> 但資訊交流僅此於有參加會議的人 www (達成部分目的摟)
> 當要有其他部門合作反而資訊對等成落差程度更嚴重
> 但有些時候是工程師不覺得自己做的事有重要到需要SHARE，這個也很吃個人判斷
> 所以要養成團隊的氛圍，不容易，就讓大家養成share的氣氛，有時候個人也會被氣氛影響
>> 同意！！
> 這真的也是一個很重要的點，希望從個人轉由團隊面向去思考，目標是交付產品
> 很多人不知道做產品跟做專案的差別，常常只是在交差 （nice!)
> 但這個也會講到現今大環境份為了
>> ~~上面富間 我等你打完很久了 ~~ （XDDD） xdd

> 主要是大多數的人的概念開始轉換重心回歸生活型態，到公司只是賣你時數事情做好就沒事，至於什麼設計等有好的 \$$ 再來看看瞧瞧
> 但是要多少 $$ 才會想要設計，設計出來的東西真符合所其價值又...

最後長官的KPI就是一份精美PPT

magento <- 這東西很可怕...
magento <- 這玩意真的很恐怖...
> 能賺錢就是好東西。 反正後來也換掉了ＸＤ
> 至少撐過公司初期成長啦
> 但很多死在從1到100，因為技術債越累越多
> 所以像講者這樣可以溝通到換掉底層真的蠻厲害的
>> php to JAVA 工程師應該大吐血
> 我們光 c# 2.0 -> 7.0就團隊抗拒了
>> 深深覺得東西會被換掉真的是有其原因LOL

可是我覺得有時候stackholder就堅持要，即便東西沒價值又要花時間，這就違反敏捷想做的事啊

之前聽kkbox裡一個講者，就說他們團隊狀況平常就會相互了解支援，他也知道狀況是什麼，所以就沒必要流於形式開立會了。目的都達到了就不用再花時間走過場。

cncf

2010的php真的沒辦法護航ＸＤＤＤ
好歹要到2013了

conway's law
> The first step in dealing with Conway's Law is know not to fight it.
> —— [ConwaysLaw - Martin Fowler](https://martinfowler.com/bliki/ConwaysLaw.html)

Microservice
> 這東西是個雙面刃
> 技術就是一連串的trade off(取捨) (+1)
> 個人覺的如何定義與切分，就是一個很大的學問
> 看向DDD，就算知道理論也很難全面推動
> ddd 需要領域專家的參與，與開發對齊，但實務很難抓專家來討論到雙方共識，畢竟幫助開發好的系統不關專家的事（我指在一般企業內部的專案/系統）(+1)
> 所以後來有人說單體都做不好，微服務也不會好
> 單體元件相依有拆好，才能去想使用微服務到底想解決什麼
> 大部分的問題都是在為xx而xx，不是為了解決問題而使用工具 （同意）
>

壓力測試

sunrise

~~p99.9 這玩意只是 寫好看低~~ (XD)
> 如果你是在雙11的電商平台，如果是在流水很大的站台
> 也不能這樣講，就看公司多在意你的服務斷線帶來的影響
> 大多的斷線可以用錢解決 www ??
> 只是多少錢的問題 (yes)
想到昨天早上的keynote提到的DevRel engineer, how do you all think?

> 這花了十幾年的經歷根本就是cloud native生態系發展歷史
>> 很多人沒經歷過啊ＸＤ ><
>> 所以直接就是告訴你沒這樣做可能會起火，前人種樹、後人乘涼
>>> 用現在的資訊回顧以前的決策有時候就會覺得當初幹嘛這麼做
>>> 但是在當下可能沒其他選擇
>>> 所以有時候只能是當下最好的選擇
>>>> 畢竟之前當下的條件就是這樣，以前老闆給預算只給 $10，現在老闆有錢給你 $1000 你就會有不一樣的東西很合理
>>> 我會說最適合 也是
>>>> 這是一個無限輪迴設計東西都會這樣，所以我們才會感受到科技真的進步神快
>>>>> 想到這個梗圖 
>>>> 就循環摟
>>>> 所以才要迭代
>>>>> 這也要看產品可不可以迭代這麼快，只能說 web 可以
>>>>> 我覺得是看想不想 (?)
>>>>> 不同產業在運用迭代都是可以討論的，做法很彈性，但就是要試-> 優化->試->優化
>>>>>> 如果是這樣 恭喜你公司產業結構技術力很棒，有些傳產 硬體出去就要無限維護舊版api 這要馬開新api 處理但硬體部 跟不跟的上 又是一回事
>>>>>> 的確不同產業的產業循環周期不一樣
>>>>>> 工作本身也是可以迭代的 (打開104) （XD）
>>>>>> 直接人體迭代
>>>>>> 感情也可以迭代的 (咦)
>>>>>>
> CNCF出現了wwwwww

WORM -> 每週營運審查會議 (weekly operational review meeting)

真心覺的 SRE 要夠強大不然真的很痛苦，而且又要推 IAC 真的難上加難
> SLO做完就被裁了嗎?(X) （XD）
> 每次都可以感受到SRE在調整跟維運的糾結
> 他們糾結開發也很糾結變成大家都在糾結 有苦說不出

請問有英文版簡報嗎XD
> 我也比較想要英文版的XD
> 英文+1+1+1
> 想要英文的+100
> 特地翻譯成中文真是有心了

今天外面有敏捷的攤位，有聽到在聊每日立會的事，或許也可以找他們聊聊。