-
Notifications
You must be signed in to change notification settings - Fork 1
/
index_zh_TW.html
1138 lines (1040 loc) · 45.9 KB
/
index_zh_TW.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>選擇無聊的技術</title>
<link rel="stylesheet" href="presentation.css">
<meta charset="utf-8">
<meta content="IE=edge" http-equiv="X-UA-Compatible">
<meta content="width=device-width, height=device-height, initial-scale=1" name="viewport">
<style>
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+TC:wght@300&display=swap');
p {font-family: 'Noto Sans TC', sans-serif;}
td {font-family: 'Noto Sans TC', sans-serif;
line-height: 1.2}
</style>
</head>
<body>
<h3 class="club-index"><a href="http://dotclub.club">The .club Club</a></h3>
<header>
<h1>選擇無聊的技術</h1>
<p>
這是我的文章：<a href="http://mcfunley.com/choose-boring-technology">選擇無聊的技術</a> 的演講版本。我已經接受了它的熱門程度，還有我永遠擺脫不了的事實 </p>
<p>
我最近在 WikiMedia 基金會開發者大會演講這個題目，現場 <a href="https://twitter.com/cscottnet">Scott Ananian</a> 稱之為：「教導年輕人如何變老的演講」
</p>
<p>
我其他的演講在 <a href="https://speakerdeck.com/mcfunley">這裡 </a>、
<a href="http://mcfunley.com">我的網站</a> 、還有
<a href="https://medium.com/@mcfunley/latest">一些 Medium 文章</a>。
</p>
<div class="share">
<a class="bsky" href="https://bsky.app/profile/mcfunley.com">
<svg fill="none" viewBox="0 0 64 57" width="28" style="width: 28px; height: 24.9375px;"><path fill="#0085ff" d="M13.873 3.805C21.21 9.332 29.103 20.537 32 26.55v15.882c0-.338-.13.044-.41.867-1.512 4.456-7.418 21.847-20.923 7.944-7.111-7.32-3.819-14.64 9.125-16.85-7.405 1.264-15.73-.825-18.014-9.015C1.12 23.022 0 8.51 0 6.55 0-3.268 8.579-.182 13.873 3.805ZM50.127 3.805C42.79 9.332 34.897 20.537 32 26.55v15.882c0-.338.13.044.41.867 1.512 4.456 7.418 21.847 20.923 7.944 7.111-7.32 3.819-14.64-9.125-16.85 7.405 1.264 15.73-.825 18.014-9.015C62.88 23.022 64 8.51 64 6.55c0-9.818-8.578-6.732-13.873-2.745Z"></path></svg>
<span class="handle">@mcfunley.com</span>
</a>
</div>
</header>
<div class="presentation">
<table class="slides">
<tr>
<td class="slide">
<img src="slides/slides.001.jpeg" />
</td>
<td class="note">
<a name="1"></a>
<a href="#1">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.002.jpeg" />
</td>
<td class="note">
<a name="2"></a>
嘿
<a href="#2">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.003.jpeg" />
</td>
<td class="note">
<a name="3"></a>
我是 Dan McKinley。這是我在坑裡的照片，這是某種暗喻。
<a href="#3">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.004.jpeg" />
</td>
<td class="note">
<a name="4"></a>
我現在在 Mailchimp 工作，如果你有聽 Podcast 可能會叫它 Mailkimp。我以前是 Etsy 的早期員工，我的觀念在那裡慢慢成形，所以我會提到很多在那發生的事。但我也在其他很多地方工作過。
<a href="#4">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.005.jpeg" />
</td>
<td class="note">
<a name="5"></a>
我在大公司工作過、也在小公司工作過、還有我自己的小創業。過程中我注意到一些事。
<br /><br />
大公司可以為自己的工程方法貼牌。像是「Etsy 的工程方法」成為了某種獨自的東西。活在裡面你的需求會被滿足、也有人會回答你的問題，有時會寵壞人。
<br /><br />
但我也遇過所謂的「工程方法」就只是一直在找出路，或是一直身處過渡期中。在這些時刻我想過幾個問題。
<a href="#5">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.006.jpeg" />
</td>
<td class="note">
<a name="6"></a>
首先，你要如何選用技術來完成工作？
<a href="#6">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.007.jpeg" />
</td>
<td class="note">
<a name="7"></a>
另一個我關心的問題是：「要怎麼讓開發者快樂？」我是開發者，覺得這個問題很重要。如果可以的話我希望快樂地工作。
<a href="#7">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.008.jpeg" />
</td>
<td class="note">
<a name="8"></a>
如果你去找開發者問：「嘿，怎樣你會比較快樂？」，通常會得到很特定的答案。像是：「如我能在上班的時候寫 Clojure 就好了，你該讓我在工作時用 Clojure 寫程式。」我不會無視他們說的話，他們真的在描述某種大腦充滿腦內啡的體驗。
<br /><br />
可是我會懷疑他們描述的，是不是真的在心智的最佳狀態。
<a href="#8">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.009.jpeg" />
</td>
<td class="note">
<a name="9"></a>
但我也曾經是這樣。
<a href="#9">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.010.jpeg" />
</td>
<td class="note">
<a name="10"></a>
以 Etsy 為例，早期他是大一坨 PHP。是某個得邊寫邊學 PHP 的可憐人的作品。
<br /><br />
有好幾年的時間我都在逃避它。直到某一天我嘗試用 Scala 服務跟 MongoDB 來取而代之。我那時以為會改善 Infrastructure、解決我所有生產力問題、然後讓我快樂。但最後事與願違。
<br /><br />
那段時期產出的破爛現在還在網路上運行，你可以去找看看然後來笑我。現職的 Etsy 員工不時會臭我，而這完全合情合理。
<a href="#10">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.011.jpeg" />
</td>
<td class="note">
<a name="11"></a>
當我最後自行創業時，我選用了 Clojure。雖然我覺得 Clojure 不是罪魁禍首，但那個創業公司早就消失了。
<br /><br />
我提這些故事是想說我不是一個反對任何新技術的人。也不是從來沒有體驗過寫 Functional programming 的樂趣的人。
<br /><br />
你不需要 @ 我來跟我爭論 Scala 還是 Haskell。也不需要覺得像是被人身攻擊需要反擊，我都沒有提到你還是那些語言啊，Steve。
<a href="#11">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.012.jpeg" />
</td>
<td class="note">
<a name="12"></a>
即使講了這麼多，我大體上依然不是很執著於工具的工程師。我其他的演講也很少提到軟體工程。
<a href="#12">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.013.jpeg" />
</td>
<td class="note">
<a name="13"></a>
我覺得不是因為老了變得易怒才會這樣想。雖然我真的又老又愛生氣，但我覺得有這觀點是因為在過去某個時間點，我登上了馬斯洛需求層次三角的頂點。
<br /><br />
馬斯洛需求層次，簡單來說是你得先滿足個人基礎需求，才有可能追求更高層的心智實現。你沒辦法在擔心下一餐沒著落的時候寫出詩來。
<a href="#13">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.014.jpeg" />
</td>
<td class="note">
<a name="14"></a>
我們可以看看 <a href="https://zh.wikipedia.org/wiki/%E9%BD%90%E6%A0%BC%E5%BC%97%E9%87%8C%E5%BE%B7%C2%B7%E6%B2%99%E9%80%8A">Siegfried Sassoon</a> 的故事，想想詩歌創作是不是這樣。但我覺得軟體工程應該是這樣。在你忙著爭論用什麼資料庫或是警報系統時，是沒有辦法明智地討論產品的走向的。
<br /><br />
我有幸待過基礎需求都有被滿足的情況。也想幫助其他人到達那種狀態。
<a href="#14">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.015.jpeg" />
</td>
<td class="note">
<a name="15"></a>
要達到那種狀態最重要的一點是理解人的注意力很寶貴。
<br /><br />
人類處理細節的能力是有限的。
<a href="#15">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.016.jpeg" />
</td>
<td class="note">
<a name="16"></a>
我朋友 Andrew 每天都穿同樣牌子的黑色襯衫。他覺得不用挑要穿什麼可以節約他的腦力，省下來的可以用在其他事上。
<br /><br />
我不知道以時尚角度來看是否合理，但我覺得有某些道理在。
<a href="#16">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.017.jpeg" />
</td>
<td class="note">
<a name="17"></a>
我喜歡這樣來思考。咱們假設我們只有有限的創新點數（Innovation token）可以花費。這個點數是我虛構出來的東西，然後我下週要 ICO 這玩意兒。
<br /><br />
它代表我們對需要創意、詭異的、或是困難的事物的有限處理能力。我們真的沒有多少點數好花。在公司草創期，可能大概就只有三個點數，不會多太多。
<a href="#17">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.018.jpeg" />
</td>
<td class="note">
<a name="18"></a>
所以你的公司想做什麼？我前東家 Etsy 說過想要重塑全世界的經濟。
<br /><br />
我現在不知道要多嚴肅地去看待公司宣稱的使命，開始覺得我們不該當它一回事。
<br /><br />
但先假設我們是天真如菜鳥，想想如果真的要達到這目的要怎麼做。
<a href="#18">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.019.jpeg" />
</td>
<td class="note">
<a name="19"></a>
重塑全世界的經濟聽起來像個大工程，大概至少會吃掉你一個創新點數。
<a href="#19">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.020.jpeg" />
</td>
<td class="note">
<a name="20"></a>
我在 Etsy 之後的東家試圖要：「增加網際網路的 GDP」。
<a href="#20">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.021.jpeg" />
</td>
<td class="note">
<a name="21"></a>
這聽起來也是個非常複雜的任務。也許我們該花一個創新點數、甚至兩個、也許要三個 All-in。
<a href="#21">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.022.jpeg" />
</td>
<td class="note">
<a name="22"></a>
如果你把創新當成是種稀缺的資源，那麼把創新的精力放在資料庫還是程式範式上就不太有道理了。
<br /><br />
我不是說新東西動不起來。當然他們動得起來，也有許多成功運作的案例。
<br /><br />
但是存在已久的軟體通常比剛出爐的更不需要心力照顧。
<a href="#22">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.023.jpeg" />
</td>
<td class="note">
<a name="23"></a>
要解釋原因，我想談一下有關知識的哲學。我們對某項技術能有多少了解？這很重要，不是無聊的問題。
<a href="#23">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.024.jpeg" />
</td>
<td class="note">
<a name="24"></a>
我討厭 <a href="https://zh.wikipedia.org/wiki/%E5%94%90%E7%BA%B3%E5%BE%B7%C2%B7%E6%8B%89%E5%A7%86%E6%96%AF%E8%8F%B2%E5%B0%94%E5%BE%B7">Donald Rumsfeld</a>，希望他下油鍋。但他跟接下來要講的理論息息相關，所以我覺得有必要提他有多壞，讓我跟他保持點距離。
<a href="#24">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.025.jpeg" />
</td>
<td class="note">
<a name="25"></a>
當我們不知道某件事物，實際上分為兩種知識的缺乏。
<br /><br />
有「已知的未知」，我們知道我們不知道的東西。跟「未知的未知」，我們連「不知道」本身都不知道的東西。
<a href="#25">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.026.jpeg" />
</td>
<td class="note">
<a name="26"></a>
在技術上同理。舉個已知的未知例子，對於某個資料庫我們可能不知道它在網路分割（Network partition）時會有什麼行為。但我們知道網路分割是有可能發生的。因為我們知道可能發生這個問題，可以動手去做測試，或是雙手合十祈禱不會發生這種情況。總之我們知道有這種可能性存在。
<a href="#26">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.027.jpeg" />
</td>
<td class="note">
<a name="27"></a>
技術也有未知的未知。這是我過去看到的某個案例。這個人花了四個月試圖找出 GC pauses 的原因，結果是因為把 Stats 寫檔造成的。他完全不知道這樣會有問題，但問題就是蹦出來了。
<br /><br />
許多軟體的 Bug 都像這樣。我們根本不知道它的存在，也不知道要往哪邊注意。這就是未知的未知。
<a href="#27">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.028.jpeg" />
</td>
<td class="note">
<a name="28"></a>
重要的是所有軟體都有這兩種未知。用了十幾年的軟體應該會有個 JIRA 伺服器裡面放滿 Ticket 寫著什麼東西壞了，但沒人要修。然後還有至今仍沒有人見過的 Bug，即使這軟體已經被眾人使用了許久。
<a href="#28">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.029.jpeg" />
</td>
<td class="note">
<a name="29"></a>
但這不代表說所有技術都一樣。新技術這兩者基數都比較高。
<br /><br />
新技術已知的未知較多，然後未知的未知多更多。這個差異很重要。
<a href="#29">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.030.jpeg" />
</td>
<td class="note">
<a name="30"></a>
我用「選擇無聊的技術」這個簡單、SEO-friendly 的句子當作標題，現在我有些後悔。它有點誤導人。人們會想：「無聊聽起來蠻爛的，為什麼他說是好事？」之類的，情況變得很糟。
<br /><br />
但我說的「無聊的技術」不是像看 C-SPAN 電視台那種無聊，我指的無聊是已經被充分了解的事物。他可能爛，但你知道爛在哪裡。你能明確列出它可能讓你失望的地方。
<a href="#30">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.031.jpeg" />
</td>
<td class="note">
<a name="31"></a>
所以你的意思是資料庫就選 Postgres 就對了，是嗎？嗯，錯了。不幸的是你選擇出來的組合也有關係。
<a href="#31">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.032.jpeg" />
</td>
<td class="note">
<a name="32"></a>
假設你已經選擇了這個 Stack，有 Python、Memcached、MySQL、跟 Apache。
<a href="#32">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.033.jpeg" />
</td>
<td class="note">
<a name="33"></a>
現在有個新問題要解決。你覺得把 Ruby 加入現有的 Stack 合理嗎？
<a href="#33">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.034.jpeg" />
</td>
<td class="note">
<a name="34"></a>
幾乎每個有經驗的人回答大概都是：「呃，天呀，不好吧。」
<br /><br />
我們知道加入 Ruby 的邊際效益不可能抵過它帶來的複雜度成長。Ruby 跟 Python 基本上角色重複了。
<a href="#34">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.035.jpeg" />
</td>
<td class="note">
<a name="35"></a>
好，那 Redis 呢？我們已經有 MySQL 跟 Memcached，還要加 Redis 進來嗎？
<a href="#35">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.036.jpeg" />
</td>
<td class="note">
<a name="36"></a>
在我的經驗裡，這種情況就會開始變得混亂。人們開始起邱，鼓吹要當多語言開發者。想加入新的資料庫的人像是一群要衝進巴士底監獄的革命分子。喊著：「你不能阻止我們用最好的工具來開發！」
<br /><br />
當人們屈服於這種躁動的本能，他們會說這是給開發者「自由」來圓。當然這是種自由，但是是一種很狹隘的定義。
<a href="#36">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.037.jpeg" />
</td>
<td class="note">
<a name="37"></a>
我們到底在做什麼？來深入探究一下。
<a href="#37">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.038.jpeg" />
</td>
<td class="note">
<a name="38"></a>
當我們想加入一個有點冗餘的技術，我們通常會說這個新技術帶來的立即好處會超過未來持續維護它的成本。
<a href="#38">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.039.jpeg" />
</td>
<td class="note">
<a name="39"></a>
這個假說的前提沒有很複雜，我們可以以結構化思考去想它。
<a href="#39">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.040.jpeg" />
</td>
<td class="note">
<a name="40"></a>
拉回來一點，你的工作像是我的朋友 Coda 說的，應該是用技術解決商業問題。
<a href="#40">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.041.jpeg" />
</td>
<td class="note">
<a name="41"></a>
我們的領域跟電腦科學有點關係，可以假裝我們是電腦科學家一下，用二分圖來描述這種情況。
<br /><br />
左邊是商業問題，右邊是技術方案。
<a href="#41">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.042.jpeg" />
</td>
<td class="note">
<a name="42"></a>
我們要試著把左邊的點都連到右邊某點，代表我們的商業問題都解決了。加上一條邊就代表是一個技術的抉擇。
<a href="#42">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.043.jpeg" />
</td>
<td class="note">
<a name="43"></a>
每個選擇都有維護成本，但我們也會受益於我們所選的技術。我們解決問題，然後有能力解決更多問題，大致這樣。
<a href="#43">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.044.jpeg" />
</td>
<td class="note">
<a name="44"></a>
所以我們每個選擇都有好處也有成本。
<a href="#44">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.045.jpeg" />
</td>
<td class="note">
<a name="45"></a>
當我們要加額外的邊時，我們可以選擇用已經支付了成本的技術…
<a href="#45">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.046.jpeg" />
</td>
<td class="note">
<a name="46"></a>
或是我們可以選別的技術。得支付新技術相應的成本，但也許得到的開發速率提升或是什麼腦內啡是值得的。
<a href="#46">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.047.jpeg" />
</td>
<td class="note">
<a name="47"></a>
我們在嘗試儘量縮減開發成本。總營運成本是你所有選擇的技術的維護成本加總，減去開發速率諸如此類的好處。
<a href="#47">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.048.jpeg" />
</td>
<td class="note">
<a name="48"></a>
我們的行為跟你相信公式裡哪個變數在現實中比較大有關。
<br /><br />
如果技術操作成本高，就是成本主導。如果技術真的大幅改善了你的工作效率，那就是效益主導。
<a href="#48">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.049.jpeg" />
</td>
<td class="note">
<a name="49"></a>
根據情況，你可能選擇這樣的配置。我們為了解決所有問題挑選了許多不同的技術。
<a href="#49">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.050.jpeg" />
</td>
<td class="note">
<a name="50"></a>
如果額外的技術本身成本不高，這樣做是完全合理的。
<a href="#50">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.051.jpeg" />
</td>
<td class="note">
<a name="51"></a>
這是另一種做法。我們只選少量的技術來涵蓋我們的問題領域、解決所有問題。
<a href="#51">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.052.jpeg" />
</td>
<td class="note">
<a name="52"></a>
當加入技術帶來的包袱很大的時候，這是我們該採取的策略。
<a href="#52">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.053.jpeg" />
</td>
<td class="note">
<a name="53"></a>
現實中，新的技術都會伴隨著巨大的包袱。
<a href="#53">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.054.jpeg" />
</td>
<td class="note">
<a name="54"></a>
這就是現實，持續地操作某項新技術的成本總是會超過用新東西帶來的方便。
<a href="#54">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.055.jpeg" />
</td>
<td class="note">
<a name="55"></a>
通常這樣才是對的。我們應該用最小的技術集合來涵蓋我們的問題領域，把工作完成。
<a href="#55">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.056.jpeg" />
</td>
<td class="note">
<a name="56"></a>
因為要達到以專業水準操作某項技術實際上很難。很多技術起個頭容易，但是要做到出色很困難。
<a href="#56">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.057.jpeg" />
</td>
<td class="note">
<a name="57"></a>
加入新技術簡單，跟它長久相處下去很難。這些都是你要考慮的事。
<br /><br />
我能現在一邊演講一邊用 Homebrew 裝個資料庫，然後寫些資料進去。我做得到，但是不要逼我去做。這跟在 Production 環境下專業地操作是完全兩回事。
<a href="#57">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.058.jpeg" />
</td>
<td class="note">
<a name="58"></a>
因此 Polyglot persistence（使用不同資料庫儲存不同資料）不是我們該尋求的自由，我真心希望 Martin Fowler 把他那篇該死的 <a href="https://martinfowler.com/bliki/PolyglotPersistence.html">Polyglot persistence</a> 文章下架。
<br /><br />
如果你讓個別團隊、或是個人自由地做局部的 Infrastructure 決策，以全局來看你是在傷害自己。
<br /><br />
這是種自由沒錯，你等於是把腳鍊跟扣鎖交給開發者們，說你們可以自由地把自己綁在營運的痛苦上。直到專案終止。
<a href="#58">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.059.jpeg" />
</td>
<td class="note">
<a name="59"></a>
除了避免重工跟過多的操作成本，更糟的是因為 Polyglot persistence，你捨棄掉了所有人都在相同平台上才會出現的好處。
<a href="#59">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.060.jpeg" />
</td>
<td class="note">
<a name="60"></a>
從我的過往找到的好例子是 Etsy 的 Activity feeds。
<br /><br />
Twitter 是／曾是一個 Activity feeds，Facebook 的動態消息也是。Etsy 許多年來都在花 VC 的資金，我猜碰巧他們也想要一個像 Twitter 還是 Facebook 的 Activity feeds。
<br /><br />
我跟一個小團隊在 2010 開發了這個東西，過程還蠻有趣的。
<a href="#60">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.061.jpeg" />
</td>
<td class="note">
<a name="61"></a>
如果你嘗試建構 Activity feeds，合理的做法是：你從外在世界收到事件，把它們寫進資料庫。然後有些離線的程序會聚合（Aggregate）這些資料，再撒上一些機械學習魔法，將生成的 Activity feeds 放進 Redis 之類的東西送給前端。這樣就會動起來。
<a href="#61">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.062.jpeg" />
</td>
<td class="note">
<a name="62"></a>
但我們要開發 Activity feeds 時，沒有 Redis 只有 Memcached。它們 API 都有點像是塞一坨 Blob 跟取出一坨 Blob，但它們做的保證相當不同。對我們最重要的差異在 Redis 有持久性（Persistent），而 Memcached 沒有持久性。
<a href="#62">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.063.jpeg" />
</td>
<td class="note">
<a name="63"></a>
實際上的問題在你想要用 Memcached 建構 Activity feeds，你有很多額外的工作要做。你得處理 Memcached 丟掉你想當下想要的資料的問題。
<br /><br />
要這樣完成這個功能需要一堆額外的工作。但是我們衡量持續維護新資料庫的成本過後，決定牙一咬用 Memcached 建構這個功能。
<a href="#63">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.064.jpeg" />
</td>
<td class="note">
<a name="64"></a>
然後我們就去做別的事了，好幾年沒再碰過這個 Activity feeds。甚至連想都很少想到它。
<a href="#64">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.065.jpeg" />
</td>
<td class="note">
<a name="65"></a>
有天我想說：「嘿，我有點好奇 Activity feeds 現在怎樣了？」驚訝地發現從發佈到當時，使用率提高了二十倍。而且以我的認知，它運作起來完全正常。
<br /><br />
我覺得多了 2000% 的人在用 Activity feeds，然後我們根本沒有發現到，是我職涯中最大的技術成就。
<a href="#65">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.066.jpeg" />
</td>
<td class="note">
<a name="66"></a>
原因是因為我們用了共同的 Stack。有些負責處理 MySQL 跟 cron 機器的同事注意到我們需要更多資源，然後有人去資料中心接上更多台電腦。因為網站是全面地成長，所以它們做的是水平擴充（Horizontal scaling）。過程中沒有人注意到我們那個沒沒無聞的功能。
<a href="#66">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.067.jpeg" />
</td>
<td class="note">
<a name="67"></a>
如果我們只為了 Activity feeds 部屬 Redis，你可以想見某個時間點當需求成長二十倍時 Redis 會出大事。我們得要放下手邊工作回去自己處理 Redis 讓 Activity feeds 回復正常。
<a href="#67">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.068.jpeg" />
</td>
<td class="note">
<a name="68"></a>
更可能的是，某個倒楣鬼要替我們做。我們的團隊一年後就解散了，各奔東西。
<br /><br />
我知道大家寧可擦自己的屁股，也不想幫我擦我的屁股。所以如果真的發生 Redis 的問題的話會讓大家感到有點尷尬。
<a href="#68">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.069.jpeg" />
</td>
<td class="note">
<a name="69"></a>
我提這個故事是想說你應該偏好成熟的東西，然後盡量不要用太多東西。
<br /><br />
但這不是一個絕對的原則。顯然有時加新技術到你的 Stack 是合理的，甚至有時用又新又怪的東西也可能是合理的。
<a href="#69">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.070.jpeg" />
</td>
<td class="note">
<a name="70"></a>
所以我想談一下遇到這種狀況該怎麼下手。
<a href="#70">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.071.jpeg" />
</td>
<td class="note">
<a name="71"></a>
總而言之還是回到溝通
<br /><br />
技術對你的公司有著全面的影響，這不是該讓個別工程師決定的事。你要用溝通找出加入新技術的方法。
<br /><br />
你可能覺得這個答案蠻老調重彈的，但相信我，很多組織都還是做不到這一點。
<a href="#71">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.072.jpeg" />
</td>
<td class="note">
<a name="72"></a>
假設你成功地透過溝通將一款新技術拉回到要先討論再看要不要加入。
<br /><br />
第一個好問題是：「如果我們要解決這個問題而不用新技術要怎麼做？」
<a href="#72">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.073.jpeg" />
</td>
<td class="note">
<a name="73"></a>
這是個好問題，因為我們能立刻抓到想要用新技術槌子解決問題釘子的情境。像是：「呃，問題在我們沒有 Cassandra，也許我們該用。」這種回答。如果你發現這種情況，討論大致上就可以打住了。
<a href="#73">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.074.jpeg" />
</td>
<td class="note">
<a name="74"></a>
假設你遇到一個很難的問題，問題鮮少是你做不到。如果你有個已經在 Production 環境的複雜服務，然後你覺得某個特定問題非得引入新技術，我覺得問題可能是你想得不夠用力。
<br /><br />
你可能要在舊環境上做些不太自然的事，但是你其實能在最小的 Stack 上走很遠很久。
<a href="#74">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.075.jpeg" />
</td>
<td class="note">
<a name="75"></a>
列下用既有技術在舊環境上要做什麼不自然的事以達成目標會很有幫助。很多時候你條列了，會發現事情其實沒有那麼糟。或者是跟維護新東西比起來還是比較好。
<br /><br />
也有可能真的是採用新技術比較好，這樣你也有證實這個結論的參考。
<a href="#75">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.076.jpeg" />
</td>
<td class="note">
<a name="76"></a>
如果你要採用新技術，應該要盡量用低風險的方式開始。你的策略不該是一步登天地把整個應用一次改寫完。你應該在 Production 環境用最低風險的方式證實其價值，然後漸漸取得大家的信心。
<a href="#76">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.077.jpeg" />
</td>
<td class="note">
<a name="77"></a>
如果你要加入的是會造成冗餘的技術，你的最終目標該是替換到沒有冗餘，不應該同時操作兩個相互冗餘的技術下去。
<br /><br />
當你加入一個東西取代原有的東西，你應該堅持把舊東西徹底拿掉。這也許會是個長遠的計畫。如果新的工具最終證實沒有用，那也要把所有新的程式用舊的工具重寫。
<a href="#77">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.078.jpeg" />
</td>
<td class="note">
<a name="78"></a>
現在來做個收尾。
<a href="#78">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides_zh_TW/slides.079.jpeg" />
</td>
<td class="note">
<a name="79"></a>
你該使用已經被實證的技術。用被充分了解，包括失效模式（Failure mode）也都被探索過的技術。
<a href="#79">#</a>
</td>
</tr>
<tr>
<td class="slide">
<img src="slides/slides.080.jpeg" />
</td>
<td class="note">
<a name="80"></a>
優先考慮使用讓你能專注在真正問題的東西。
<a href="#80">#</a>
</td>
</tr>