程式，隨便紀錄

相關網站 安全性的header相關資訊都可在developer.mozilla.org找到。 網站header檢測：https://securityheaders.com/。 完整網站安全檢測：https://www.ssllabs.com/ssltest/ 前言 當使用者通過瀏覽器發送request到伺服器上，伺服器會回應response給瀏覽器，此時就會帶上一些header，其中有些header可以保證網站安全。 X-Content-Type-Options: nosniff 阻止瀏覽器探知檔案的 mime type ( disable Content sniffing )，一般情況下瀏覽器會去探知資源的  Content-Type  ，以判別資源類型，例如: image/png、text/css，而有些資源的 Content-Type 有可能是錯誤或缺少的，此時就會進行 Content sniffing猜測解析內容，將 X-Content-Type-Options 設成 nosniff，可阻止這種行為。 沒有設成 nosniff 的風險為攻擊者可能使用錯誤的 header 隱藏攻擊的 script ，例如   <script src="https://example.com/attacker.txt" ></script>，attacker.txt 實際是 js 檔，表面的 header 是 text/plain ，實際上瀏覽器會解析 scrip t的content type ，並且執行 script。 X-Frame-Options: DENY 代表不讓網頁載入 frame ( iframe 跟 object )。 沒有設成 DENY 的風險為可能被惡意嵌入 iframe ，若自己的網站想使用 iframe ，可以設成 SAMEORIGIN (符合同源政策)，或是 ALLOW-FROM，例如:  ALLOW-FROM: https://www.google.com/  https://github.com，可以嵌入 google 網域跟 github 網域下的網頁。 ALLOW-FROM已棄用。可能根據瀏覽器的不同而失效。 X-XSS-Protection: 1; mode=block 當瀏覽器發現跨站腳本攻擊時，

 Laravel Breeze Breeze為構建帶有身份驗證的Laravel應用程序提供了最小和簡單的起點。 Breeze採用Tailwind風格，將身份驗證控制器和視圖發佈到您的應用程序，可以根據您自己的應用程序的需求輕鬆地對其進行自定義。 laravel Jetstream Laravel Jetstream是為Laravel設計的精美應用程序支架。 Jetstream為您的下一個Laravel應用程序提供了完美的起點，包括登錄，註冊，電子郵件驗證，兩因素身份驗證，會話管理，通過Laravel Sanctum提供的API支持以及可選的團隊管理。 若覺得jetstream太大可以使用breeze。 TALL stack https://tallstack.dev/ Tailwind CSS + Alpine.js + Laravel + Livewire Tailwind CSS: Tailwind CSS是一個高度可定制的低級CSS框架，它為您提供了構建定制設計所需的所有構造塊，而無需煩惱要覆蓋的煩人的自以為是的樣式。 Alpine.js: Alpine.js是一個很小的聲明性JavaScript框架，它使您可以在頁面上創建簡單的交互式組件。 由同一個創作者與Livewire完美搭配。 Livewire:   Laravel視圖組件，無需編寫即可通過JavaScript無縫交付給用戶。 VILT Stack https://raison.co/vilt-stack-vue-inertia-laravel-tailwind/ Vue + Inertia + laravel + Tailwind Css Inertia允許您創建完全由客戶端呈現的單頁應用程序，而沒有現代SPA帶來的很多複雜性。 它通過利用現有的服務器端框架來做到這一點。

名詞 程式: program 次級儲存裝置:  Secondary storage，如硬碟。 主要儲存裝置: primary  storage ，如memory。 進程: process。 線程: thread。 程式指工程師寫的程式，放在次級儲存裝置 ，並未被執行。 進程指的是被載入記憶體的 程式。 進程 vs 線程 一個進程裡面一定會有一個線程。 一個進程裡面的多個線程共享進程的資源和內存。 每個進程獨立執行，各自有自己的資源和內存。 一個cpu上一次只能跑一個進程。 多線程 vs 多進程 vs 異步 多線程就是 一個CPU上面 ，可以用輪詢的方式執行多個程式，就是做一做跳去下一個，做一做再跳回來，看起來是一次處理多個程式，其實不是同時間做，可以有效利用等待IO的時間，也叫做併發。 多進程就是多個CPU上面處理多個程式，佔用資源會比較多，也叫做並行。 異步是非阻塞，解決了UI響應被阻塞的問題，可藉助線程技術或者硬件本身的計算能力解決。 單線程在CPU取向的情況下較快，多線程在多IO取向的情況下較快。

 1. 變數提升(hoisting) https://blog.techbridge.cc/2018/11/10/javascript-hoisting/ 2. 原型鍊 https://developer.mozilla.org/zh-TW/docs/Web/JavaScript/Inheritance_and_the_prototype_chain https://blog.techbridge.cc/2017/04/22/javascript-prototype/ 3. object.create vs new https://stackoverflow.com/questions/4166616/understanding-the-difference-between-object-create-and-new-somefunction 4. object.create = 繼承 5. class關鍵字實際上還是原型模式 6. javascript動態語言連this都會動態，掌握this 7. prototype constructor 8. oojs

簡單的系統容易成為【以數據為中心】的系統。 實際上也是這樣，因為這樣的系統只有crud操作，系統淪為資料庫的代理，資料庫本身提供的功能就可滿足業務需求。 而複雜的系統與簡單系統的差別在於，複雜系統除了crud之外，還擁有業務需求，而crud缺少【意圖】。 當一個帳戶的金額改變了，crud僅僅只是資料上的更新，並無法體現出原因，可能是轉帳了，可能是消費了，也可能是系統錯誤導致更改，在設計複雜系統時，單以crud的角度去設計，便會失去操作的意圖。

 1. 大function 行數過多的function。 2. 大class function、屬性過多的class。 3. Primitive Obsession (原始型態癡迷) 使用最基本的int, string，去取代應該要創的類。(如: Money class, Address class)。 USER_ADMIN_ROLE  = 1，這種常數，應該使用一個class，去列舉他所有的可能性。 4. 長參數 一個function有過多的參數。 5. 資料泥團 很多class裡面都出現一樣的資料群，如數據庫連線，應該要提出來。 6. 複雜的switch跟if 應該使用別的方法處理，例如多態。 7. 暫存欄位(class) class裡有很多暫存欄位，用來存某個function的結果，而不是在那個funciton內產生，這種暫存欄位多數時間是無用的。 8. Refused Bequest 僅僅只為了重用代碼而繼承，不考慮物件繼承的意義，繼承的意義為is a，可用委託模式(Delegation)。 9. Alternative Classes with Different Interfaces 指有完全相同的功能，但有不同的inferface和名稱出現在系統裡。 10. 發散的變化 (Divergent Change) 指有一個類有許多被更改的原因，違反srp原則。 11. 霰彈槍手術 (Shotgun surgery) 只重複的程式碼在多個類反覆出現，要修改時需要一個一個找出來。 12. 平行繼承結構 為一個繼承架構創一個子類，發現另一個繼承架構也要新增一個子類。 13. 過多註解 14. 重複的code 15. 不必要的類 16. Data Class 指那種只有getter setter的class，原因是因為屬性修改後，所有用到這個物件的地方都有可能會修改。 17. Dead Code 不再用的任何程式碼(過時)。 18. Speculative Generality 沒有用到的程式碼(為了以防萬一)。 19. Feature Envy function訪問另一個對象的數據比訪問其自身的數據更多。 20. Inappropriate Intimacy 兩個類別過度使用資料和function，職責拆分有問題。 21. Message Chains 出現 $a

TDD 、BDD和軟體開發 BDD: 將一個系統分成多個feature，每個feature會有多個scenarios lists，每個scenario會有多個Griven、When、Then，對應到tdd裡的3A(arrange，act，assert)。 TDD: TDD是一個開發方法，強迫開發者必須先思考需要做什麼，知道自己在做什麼，而不是悶下去寫code，TDD幫助開發者在寫一個功能時，先建立測試環境，再去寫產品代碼，之後不管怎麼重構，都可以確保正確性。 TDD不等於寫unit test，unit test可能是必要的，但TDD不是。 TDD步驟: 1. 理解需求     從scenario list去挑選一個scenario，先選重要的。 2. 先寫測試代碼，並執行，得到失敗結果     測試是為了讓開發者思考應該要測試的情境，讓寫出來的程式擁有可測性。 3. 寫實現代碼讓測試通過     以最快的速度通過，目的是為重構建立情境。 4. 重構代碼，並保證測試通過。     由於有了情境，可以任意重構，直到功能皆通過測試。 5. 反復實行這個步驟 測試失敗 -> 測試成功 -> 重構     TDD還是需要預先設計架構，理解需求，避免寫了一系列的test最後因為需求改變而被刪除，每個unit test的重構需遵守solid原則、grasp原則、design pattern、避免壞味道(尤其是重複的代碼)，TDD只告訴你要思考可測試性，而不會教你如何設計，要讓設計變好，還是要去了解軟體的設計原理。 先有大概架構，再去實踐TDD ( 也就是先寫測試，再去寫產品代碼，然後重構的TDD標準流程)，寫的時候思考如何測試這個function或是class，如何傳入mock物件，達到可以隨時抽換不同的實作(也就是面對接口編程)。 TDD不只包含unit test，驗收測試，整合測試也在TDD裡面，TDD是一個逐步增量的過程。 unit test應該只測那些該被測試的東西，不是追求100%覆蓋率。