iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 1
3
Software Development

30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)系列 第 1

30-01 之何謂一個好的系統呢 ?

黑色好看版 - 傳送門


何謂一個好的系統呢 ?

為什麼會問這個問題呢 ?

因為事實上這個是我原本想要撰寫的主題。咱們工程師在開發系統,所學習的大部份的技術,基本上都是為了追求『建立一個好的系統』,然後我本來想將建立一個好的系統的知識點,建立成一個 30 天的知識集,但就算進行精簡化,也很難進行有深度的探討。

因此後來才有了這 30 天這個主題 :

30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)

接下來我們來說說,上述的主題『性能』,在一個好的系統中,是那一個部份。

何謂一個好的系統呢 ?

這個主題事實上非常的抽象與盤大,問十個人可能有十種答案,在這裡筆者將來說明心中理想的系統。

一個好的系統我覺得最重要的一點為 :

要有人用

這個是我覺得是最重要的一點,如果沒有人用,除非你裡面的技術是可以改變世界的,不然基本上是沒啥價值性的,不論是科學或是商業價值。

『要有人用』這個基本上咱們搞技術的除非你和老闆是好麻吉,不然事實上很難干涉行銷策略這個層級的事情,所以這一塊咱們先不管。

不過也不代表我們不用學這個領域的知識。

你的知識越廣,就越不會被固定領域知識僵固,並且更能幫助你突然領域的深度。

忘了是誰說的,不過我很喜歡這句話。

不過這句話我覺的有個前提假設 :

不過你要先有一把刀,你才能去開拓世界。

也就是說如果你沒有先在你的領域打個底,那麼你也沒有本事將從其它領域學到的東西,融入你的領域。

某些方面,我覺得學程式語言就如同上面這一句話一樣。

在有人用的情況下,何謂一個好的系統呢 ?

我覺得一個好的系統只有一個重點 :

讓雙方愉悅

https://ithelp.ithome.com.tw/upload/images/20190916/20089358VF0mT7NJrr.jpg

這裡雙方是指『用戶』與『公司』。

  • 能夠讓使用者覺得好用,用起來就是愉悅兩字 (用戶愉悅)。
  • 能夠以最少的資源(機器)做最多的事情 (公司愉悅)。
  • 能夠讓開發人員未來花越少的時間在維護 (公司愉悅)。
  • 安全 (用戶與公司都愉悅)。

能夠讓使用者覺得好用,用起來就是愉悅兩字 (用戶愉悅)

  • 畫面讓人覺得愉悅。(設計)
  • 畫面操作讓人覺得愉悅。(UI/UX、性能)
  • 不會一下可以用,一下不能用。(可用性)

總結一句話 :

使用者不愉悅,我們就沒錢

能夠以最少的資源(機器)做最多的事情 (公司愉悅)

  • 能以最少的機器服務最多的客官。(性能)
  • 在多的客官,咱們都要能 hold 的住。(性能)

但這個要求事實上有一個前提假設,那就是要符合,讓使用者愉悅這特性,也就是說不會一下子可以用,一下不能用,不然會客戶會生氣的。

總結一句話 :

反正就是要省錢

能夠讓開發人員未來花越少的時間在維護 (公司愉悅)

時間就是金錢,省了開發人員的時間,就是省了錢。

  • 不要未來 bug 一堆,讓開發人員花時間抓。(測試)
  • 不要要抓 bug 時,花開發人員一堆時間。(log 機制)
  • 不要一個正常的需求來了,就大部份程式要重寫。(設計模式、軟體工程)
  • 不要光發佈或測試就花了一整天的時間。(CI/CD、測試)

總結一句話 :

時間就是金錢

安全 (用戶與公司都愉悅)

這個東東事實上非常的重要,資安沒做好,你是賠了時間與金錢

  • 被駭客要 $$。
  • 被駭客打爛系統,花時間回復。
  • 被駭客打爛系統,導致系統不能用,使用者不愉悅。

轉化成軟體工程領域名詞

假設將上面那好的系統要求,轉成軟體工程領域大概就會變的如下:

最基本上就是分以前後端,並且後端部份又分為以下幾個 :

  • 性能
  • 可用
  • 擴展
  • 維護性
  • 安全

但是我不算是很喜歡這種類型的分類,這些名詞太讓人覺得有太的想法分支。

假設有一個系統,它現在可以處理每秒 qps 大約有一百萬上下,你會稱它為高性能嗎 ? 這樣有點抽像,那就假設它是 fb 的系統,你會稱它為高性能嗎 ?

有些人可能會覺得,嗯它可以處理那麼多的量,它應該算高性能。

但是有些人卻覺得不會,因為它們可能用了很多機器。

嗯這就是高性能一詞的問題。

一個詞可能會讓人有多種解讀,例如我就想到下列三種 :

  • 一個系統可以處理非常大量的資料,所以它是高性能的。
  • 一個系統以最少的資源處理最多的事,所以它是高性能的。
  • 一個系統處理一件事情,非常快。

我覺得正解應該是第二句話,但是高性能會讓人想到三種解讀,所以我不太喜歡直接使用高性能這個詞。

結論

本篇文章我們簡單的探討了一個問題 :

何謂一個好的系統呢 ?

而接下來的 30 天,咱們就要針對以越少的資源,做越多的事情這個好的要點,來進行深入的探討。

以越少的機器,做越多的事情,也就是所謂的『性能』

筆者會選擇以性能為主題,有主要幾個原因 :

首先第一個,因為我想。

在來第二點,大部份的文章以高性能為主軸的文章,都是『系統如何處理大流量、大併發』,然後會發現大部份都是以分散式為主,但是如果只是以多開機器來處理這些問,我不覺得是高性能。所以這裡才能打算寫個 30 篇的『我覺得高性能的系統』為主題。

再來是很多初學者,在學習如何處理大流量時,大部份都是直接跳往往分散式架構來處理,但咱覺得這是錯的。因為如果你單機處理不好,那我不會相信你架出來的分散式架構性能會多好。

最後這三十天仍然是以『一個好的系統』為主題的原因在於,這才是我們學習技術的出發點。希望未來有時間還可以針對不同的地方來進行深入的探討。

接下來就開始吧。

注意事項

這 30 天的文章,所學習的東西,是幫助你可以開發一個『更好』的系統,所以它有一個前提假設那就是你需要的功能已經開發出了。如果只是開發功能就已經卡很久了,那這時還一直分心花很多時間來追求『更好』,那我覺得你一定會被老闆 fired 掉的。

追求『更好』不是壞事,但是不要還不會走路就想飛,這是人生的大忌喔。


下一篇
30-02 之單機架構的性能優化方向與目標
系列文
30天之從 0 至 1 盡可能的建立一個好的系統 (性能基礎篇)30

尚未有邦友留言

立即登入留言