Translate vi.md via GitLocalize

1 files changed, 1035 insertions, 0 deletions

diff --git a/translations/vi.md b/translations/vi.md
new file mode 100644
index 0000000..b36e604
--- /dev/null
+++ b/translations/vi.md
@@ -0,0 +1,1035 @@
+# 💻📖 luật của hacker
+
+Laws, Theories, Principles and Patterns that developers will find useful.
+
+[Translations](#translations): [🇮🇩](./translations/id.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md)
+
+Like this project? Please considering [sponsoring me](https://github.com/sponsors/dwmkerr) and the [translators](#translations). Also check out this podcast on [The Changelog - Laws for Hackers to Live By](https://changelog.com/podcast/403) to learn more about the project! You can also [download the latest PDF eBook](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf). Check the [Contributor Guide](./.github/contributing.md) if you are keen to contribute!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [Introduction](#introduction)
+- [Laws](#laws)
+    - [90–9–1 Principle (1% Rule)](#9091-principle-1-rule)
+    - [Amdahl's Law](#amdahls-law)
+    - [Lý thuyết cửa sổ vỡ](#the-broken-windows-theory)
+    - [Brooks' Law](#brooks-law)
+    - [CAP Theorem (Brewer's Theorem)](#cap-theorem-brewers-theorem)
+    - [Định luật Conway](#conways-law)
+    - [Định luật Cunningham](#cunninghams-law)
+    - [Dunbar's Number](#dunbars-number)
+    - [Hiệu ứng Dunning-Kruger](#the-dunning-kruger-effect)
+    - [Luật Fitts](#fitts-law)
+    - [Luật Gall](#galls-law)
+    - [Luật Goodhart](#goodharts-law)
+    - [Hanlon Razor](#hanlons-razor)
+    - [Luật Hick (Luật Hick-Hyman)](#hicks-law-hick-hyman-law)
+    - [Định luật Hofstadter](#hofstadters-law)
+    - [Định luật Hutber](#hutbers-law)
+    - [Chu kỳ Hype &amp; Định luật Amara](#the-hype-cycle--amaras-law)
+    - [Luật Hyrum (Luật của giao diện ngầm)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Định luật Kernighan](#kernighans-law)
+    - [Luật Linus](#linuss-law)
+    - [Định luật Metcalfe](#metcalfes-law)
+    - [Định luật Moore](#moores-law)
+    - [Định luật Murphy / Định luật Sod](#murphys-law--sods-law)
+    - [Dao cạo của Occam](#occams-razor)
+    - [Định luật Parkinson](#parkinsons-law)
+    - [Hiệu ứng tối ưu sớm](#premature-optimization-effect)
+    - [Định luật Putt](#putts-law)
+    - [Luật Reed](#reeds-law)
+    - [Định luật Bảo toàn Độ phức tạp (Định luật Tesler)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Định luật Demeter](#the-law-of-demeter)
+    - [Luật Sự rò rỉ của Trừu tượng](#the-law-of-leaky-abstractions)
+    - [Luật tầm thường](#the-law-of-triviality)
+    - [Triết lý Unix](#the-unix-philosophy)
+    - [Mô hình Spotify](#the-spotify-model)
+    - [Quy tắc hai chiếc bánh pizza](#the-two-pizza-rule)
+    - [Luật Wadler](#wadlers-law)
+    - [Định luật Wheaton](#wheatons-law)
+- [Nguyên tắc](#principles)
+    - [Tất cả các mô hình đều sai (Định luật George Box)](#all-models-are-wrong-george-boxs-law)
+    - [Chesterson's Fence](#chestersons-fence)
+    - [Hiệu ứng Biển Chết](#the-dead-sea-effect)
+    - [Nguyên tắc Dilbert](#the-dilbert-principle)
+    - [Nguyên tắc Pareto (Quy tắc 80/20)](#the-pareto-principle-the-8020-rule)
+    - [Nguyên tắc Shirky](#the-shirky-principle)
+    - [Nguyên tắc Peter](#the-peter-principle)
+    - [Nguyên tắc mạnh mẽ (Định luật Postel)](#the-robustness-principle-postels-law)
+    - [SOLID](#solid)
+    - [Nguyên tắc Trách Nhiệm Duy Nhất](#the-single-responsibility-principle)
+    - [Nguyên tắc Mở / Đóng](#the-openclosed-principle)
+    - [Nguyên tắc thay thế Liskov](#the-liskov-substitution-principle)
+    - [Nguyên tắc phân tách giao diện](#the-interface-segregation-principle)
+    - [Nguyên tắc đảo ngược phụ thuộc](#the-dependency-inversion-principle)
+    - [Nguyên tắc DRY](#the-dry-principle)
+    - [Nguyên tắc KISS](#the-kiss-principle)
+    - [YAGNI](#yagni)
+    - [Sự sụp đổ của máy tính phân tán](#the-fallacies-of-distributed-computing)
+- [Danh sách đọc](#reading-list)
+- [Những nguồn thông tin trên mạng](#online-resources)
+- [Sách điện tử PDF](#pdf-ebook)
+- [Tệp âm thanh](#podcast)
+- [Bản dịch](#translations)
+- [Các dự án liên quan](#related-projects)
+- [Đóng góp](#contributing)
+- [SẼ LÀM](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Giới thiệu
+
+Có rất nhiều luật mà mọi người thảo luận khi nói về phát triển. Kho lưu trữ này là tài liệu tham khảo và tổng quan về một số kho lưu trữ phổ biến nhất. Hãy chia sẻ và gửi bài PR!
+
+❗: Kho lưu trữ này chứa giải thích về một số luật, nguyên tắc và khuôn mẫu, nhưng không *ủng hộ* bất kỳ điều nào trong số đó. Liệu chúng có nên được áp dụng hay không sẽ luôn là vấn đề tranh luận và phụ thuộc rất nhiều vào những gì bạn đang làm.
+
+## Luật
+
+Và chúng ta bắt đầu!
+
+### Nguyên tắc 90–9–1 (Quy tắc 1%)
+
+[Quy tắc 1% trên Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
+
+Nguyên tắc 90-9-1 gợi ý rằng trong một cộng đồng internet như wiki, 90% người tham gia chỉ xem nội dung, 9% chỉnh sửa hoặc sửa đổi nội dung và 1% người tham gia thêm nội dung.
+
+Ví dụ trong thế giới thực:
+
+- Một nghiên cứu năm 2014 trên bốn mạng xã hội về sức khỏe, cho thấy 1% người dùng hàng đầu tạo ra 73% bài đăng, 9% tiếp theo chiếm trung bình ~ 25% và 90% còn lại chiếm trung bình 2% ( [Tham khảo](https://www.jmir.org/2014/2/e33/) )
+
+Xem thêm:
+
+- [Nguyên tắc Pareto](#the-pareto-principle-the-8020-rule)
+
+### Định luật Amdahl
+
+[Luật Amdahl trên Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)
+
+> Định luật Amdahl là một công thức cho thấy *tốc độ tiềm năng* của một tác vụ tính toán có thể đạt được bằng cách tăng tài nguyên của một hệ thống. Thường được ứng dụng trong tính toán song song, nó có thể dự đoán lợi ích thực tế của việc tăng số lượng bộ xử lý, điều này bị giới hạn bởi khả năng song song của chương trình.
+
+Minh họa tốt nhất với một ví dụ. Nếu một chương trình có hai phần: phần A, phần này chỉ có thể thực hiện bằng một bộ xử lý đơn lẻ và phần B, có thể được thực hiện song song trên nhiều bộ xử lý, thì chúng ta thấy rằng việc thêm nhiều bộ xử lý vào hệ thống thực thi chương trình chỉ có thể có một lợi ích hạn chế. Nó có khả năng cải thiện đáng kể tốc độ của phần B - nhưng tốc độ của phần A sẽ không thay đổi.
+
+Sơ đồ dưới đây cho thấy một số ví dụ về những cải tiến tiềm năng về tốc độ:
+
+<img width="480px" src="./images/amdahls_law.png" alt="Diagram: Amdahl's Law">
+
+*(Image Reference: By Daniels219 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Như có thể thấy, ngay cả một chương trình có thể chạy song song 50% sẽ được hưởng lợi rất ít khi vượt quá 10 đơn vị xử lý, trong khi một chương trình có thể song song 95% vẫn có thể đạt được những cải thiện tốc độ đáng kể với hơn một nghìn đơn vị xử lý.
+
+Như [Định luật Moore](#moores-law) chậm, và tốc độ tăng tốc của bộ xử lý đơn lẻ chậm lại, thì song song hóa là chìa khóa để cải thiện hiệu suất. Ví dụ như lập trình đồ họa - với tính toán dựa trên Shader hiện đại, các pixel hoặc mảnh riêng lẻ có thể được hiển thị song song - đây là lý do tại sao các card đồ họa hiện đại thường có hàng nghìn lõi xử lý (GPU hoặc Shader Units).
+
+Xem thêm:
+
+- [Luật Brooks](#brooks-law)
+- [định luật Moore](#moores-law)
+
+### Lý thuyết cửa sổ vỡ
+
+[Lý thuyết cửa sổ vỡ trên Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
+
+Lý thuyết Cửa Sổ Vỡ nói rằng các dấu hiệu xấu có thể nhìn thấy (cửa sổ kính bị vỡ) dẫn đến tội phạm ngày càng nghiêm trọng hơn (hoặc làm suy thoái môi trường hơn nữa).
+
+Lý thuyết này áp dụng cho phát triển phần mềm, rằng mã chất lượng kém (hoặc [Nợ kỹ thuật](#TODO) ) có thể dẫn đến nhận thức rằng các nỗ lực cải thiện chất lượng có thể bị bỏ qua hoặc định giá thấp, do đó dẫn đến mã chất lượng kém hơn. Hiệu ứng này giảm dần dẫn đến chất lượng giảm mạnh theo thời gian.
+
+Xem thêm:
+
+- [Nợ kỹ thuật](#TODO)
+
+Ví dụ:
+
+- [The Pragmatic Programming: Software Entropy](https://flylib.com/books/en/1.315.1.15/1/)
+- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
+- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Luật Brooks
+
+[Luật Brooks trên Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)
+
+> Thêm người vào một dự án phát triển phần mềm đang bị chậm tiến độ, sẽ làm nó chậm hơn.
+
+Luật này nói rằng trong nhiều trường hợp, việc cố gắng đẩy nhanh tiến độ giao một dự án đang chậm, bằng cách bổ sung thêm người, sẽ khiến việc giao dự án chậm hơn. Brooks nói rằng đây là một sự đơn giản hóa quá mức, tuy nhiên, lý do chung là với thời gian gia tăng của các nguồn tài nguyên mới và tổng chi phí liên lạc, tốc độ ngắn hạn tức thời sẽ giảm xuống. Ngoài ra, nhiều nhiệm vụ có thể không chia nhỏ được hơn nữa (chia nhỏ công việc là phân phối công việc ra các nguồn lực để xử lý) dẫn đến tốc độ tăng tiềm năng cũng thấp hơn.
+
+Nói kiểu quen thuộc hơn là "Chín phụ nữ không thể sinh con trong một tháng" liên quan đến Luật Brooks, đặc biệt, thực tế là một số loại công việc không thể phân chia hoặc làm song song.
+
+Đây là chủ đề trung tâm của cuốn sách ' [The Mythical Man Month](#reading-list) '.
+
+Xem thêm:
+
+- [Death March](#todo)
+- [Danh sách đọc: The Mythical Man Month](#reading-list)
+
+### Định lý CAP (Định lý Brewer)
+
+Định lý CAP (được Eric Brewer định nghĩa): đối với một kho lưu trữ dữ liệu phân tán, chỉ có thể hai trong ba điều sau được đảm bảo:
+
+- Tính đồng bộ (Consistency): khi đọc dữ liệu, mọi yêu cầu đều nhận được *dữ liệu gần đây nhất* hoặc lỗi được trả về
+- Tính sẫn sàng (Availability): khi đọc dữ liệu, mọi yêu cầu đều nhận được *phản hồi không lỗi* , mà không cần đảm bảo rằng đó là dữ liệu *mới nhất*
+- Tính chịu lỗi (Partition Tolerance): khi một số lượng tùy ý yêu cầu mạng giữa các nút không thành công, hệ thống tiếp tục hoạt động như thiết kế.
+
+Cốt lõi của lý do là như sau: với hệ thống phân tán, không thể đảm bảo được việc sai biệt cục bộ không xảy ra (xem [Sự sụp đổ của Máy tính Phân tán](#the-fallacies-of-distributed-computing) ). Do đó, trong trường hợp sai biệt cục bộ, chúng ta có thể hoặc ngưng công việc, để chờ đồng bộ (tăng tính đồng bộ và giảm tính sẫn sàng) hoặc tiếp tục công việc (tăng tính sẫn sàng nhưng giảm tính đồng bộ).
+
+Tên gọi xuất phát từ các chữ cái đầu tiên (Consistency, Availability, Partition Tolerance). Lưu ý rằng điều rất quan trọng cần lưu ý là điều này *không* liên quan đến [*ACID*](#TODO) , có định nghĩa khác về tính đồng bộ. Gần đây hơn, [định lý PACELC](#TODO) đã được phát triển để bổ sung các ràng buộc về độ trễ và tính đồng bộ khi mạng *không bị* sai biệt cục bộ (tức là khi hệ thống đang hoạt động như mong đợi).
+
+Hầu hết các nền tảng cơ sở dữ liệu hiện đại đều thừa nhận định lý này một cách ngầm định bằng cách cung cấp cho người dùng cơ sở dữ liệu tùy chọn để lựa chọn giữa việc họ muốn một hoạt động có tính khả dụng cao (có thể bao gồm 'đọc bẩn') hay một hoạt động nhất quán cao (ví dụ: một 'số đại biểu được thừa nhận ghi ').
+
+Ví dụ trong thế giới thực:
+
+- [Bên trong Google Cloud Spanner và Định lý CAP](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) - Đi vào chi tiết về cách hoạt động của Cloud Spanner, thoạt đầu có vẻ giống như một nền tảng có *tất cả* các đảm bảo của CAP, nhưng bên dưới cơ bản là một hệ thống CP.
+
+Xem thêm:
+
+- [ACID](#TODO)
+- [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing)
+- [PACELC](#TODO)
+
+### Định luật Conway
+
+[Luật Conway trên Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Luật này nói rằng các biên giới kỹ thuật của một hệ thống sẽ phản ánh cấu trúc của tổ chức. Nó thường được nhắc đến khi xem xét các cải tiến của tổ chức, Luật Conway gợi ý rằng nếu một tổ chức được cấu trúc thành nhiều đơn vị nhỏ, không kết nối thì phần mềm mà nó tạo ra sẽ là như vậy. Nếu một tổ chức được xây dựng nhiều hơn xung quanh 'ngành dọc' được định hướng xung quanh các tính năng hoặc dịch vụ, hệ thống phần mềm cũng sẽ phản ánh điều này.
+
+Xem thêm:
+
+- [Mô hình Spotify](#the-spotify-model)
+
+### Định luật Cunningham
+
+[Định luật Cunningham trên Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> Cách tốt nhất để có câu trả lời đúng trên Internet không phải là đặt câu hỏi, mà là hẫy đăng câu trả lời sai.
+
+Điều này đề cập đến quan sát rằng trên internet "mọi người nhanh sửa một câu trả lời sai hơn là trả lời một câu hỏi."<br><br>Theo Steven McGeady, Ward Cunningham đã khuyên anh ta vào đầu những năm 1980: "Cách tốt nhất để có câu trả lời đúng trên Internet không phải là đặt một câu hỏi, mà là đăng câu trả lời sai." McGeady gọi đây là định luật Cunningham, mặc dù Cunningham phủ nhận quyền sở hữu gọi nó là "trích dẫn sai". Mặc dù ban đầu đề cập đến các tương tác trên Usenet, luật đã được sử dụng để mô tả cách hoạt động của các cộng đồng trực tuyến khác (ví dụ: Wikipedia, Reddit, Twitter, Facebook).
+
+Xem thêm:
+
+- [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
+
+### Số Dunbar
+
+[Số Dunbar trên Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+"Con số của Dunbar là một giới hạn nhận thức được đề xuất cho số người mà một người có thể duy trì các mối quan hệ xã hội ổn định - các mối quan hệ trong đó một cá nhân biết mỗi người là ai và mối quan hệ của mỗi người với mọi người khác như thế nào." Không có một con số chính xác. "... [Dunbar] đề xuất rằng con người chỉ có thể thoải mái duy trì 150 mối quan hệ ổn định." Ông đặt con số vào một bối cảnh xã hội hơn, "số lượng người mà bạn sẽ không cảm thấy xấu hổ khi tham gia một cuộc uống không được mời nếu bạn tình cờ gặp họ trong một quán bar." Các ước tính cho con số thường nằm trong khoảng từ 100 đến 250.
+
+Giống như mối quan hệ ổn định giữa các cá nhân, mối quan hệ của nhà phát triển với cơ sở mã cần nỗ lực để duy trì. Khi đối mặt với các dự án lớn phức tạp, hoặc sở hữu nhiều dự án, chúng tôi dựa trên quy ước, chính sách và quy trình được mô hình hóa để mở rộng quy mô. Con số của Dunbar không chỉ quan trọng cần ghi nhớ khi văn phòng phát triển mà còn khi thiết lập phạm vi cho các nỗ lực của nhóm hoặc quyết định khi nào một hệ thống nên đầu tư vào công cụ để hỗ trợ mô hình hóa và tự động hóa chi phí hậu cần. Đặt con số vào bối cảnh kỹ thuật, đó là số lượng dự án (hoặc độ phức tạp được chuẩn hóa của một dự án) mà bạn cảm thấy tự tin khi tham gia vòng quay theo cuộc gọi để hỗ trợ.
+
+Xem thêm:
+
+- [Định luật Conway](#conways-law)
+
+### Hiệu ứng Dunning-Kruger
+
+[Hiệu ứng Dunning-Kruger trên Wikipedia](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
+
+> Nếu bạn không đủ năng lực, bạn không thể biết mình kém ... Kỹ năng cần để đưa ra một câu trả lời đúng cũng là kỹ năng để nhận ra một câu trả lời là đúng.
+>
+> ([David Dunning](https://en.wikipedia.org/wiki/David_Dunning))
+
+Hiệu ứng Dunning-Kruger là một khuynh hướng nhận thức lý thuyết được David Dunning và Justin Kruger mô tả trong một bài báo và nghiên cứu tâm lý năm 1999. Nghiên cứu cho thấy rằng những người có mức năng lực thấp trong một nhiệm vụ có khả năng đánh giá cao khả năng của họ khi thực hiện nhiệm vụ. Lý do được đề xuất cho sự thiên vị này là một người cần có *nhận thức* đầy đủ về mức độ phức tạp của một vấn đề hoặc lĩnh vực để có thể đưa ra ý kiến sáng suốt về khả năng làm việc của họ trong lĩnh vực đó.
+
+Hiệu ứng Dunning-Kruger đôi khi được sử dụng để mô tả một hiệu ứng có gần nó "Một người càng ít hiểu về một vấn đề, họ càng tin rằng họ có thể dễ dàng giải quyết nó, nhiều khả năng nhất là họ thấy nó *đơn giản* ". Hiệu ứng tổng quát hơn này rất phù hợp trong công nghệ. Nó sẽ gợi ý rằng những người ít quen thuộc với một vấn đề, chẳng hạn như thành viên nhóm không chuyên về kỹ thuật hoặc thành viên nhóm ít kinh nghiệm, có nhiều khả năng *đánh giá thấp* nỗ lực cần thiết để giải quyết một vấn đề.
+
+Khi một người có sự hiểu biết và kinh nghiệm trong một lĩnh vực tăng lên thì họ cũng có thể gặp phải một tác động ngược lại, là có xu hướng *đánh giá quá cao* khả năng của *người khác* hoặc *đánh giá thấp* khả năng của chính mình. Trong mọi trường hợp, những tác động này là *thành kiến về nhận thức*. Sự nhận thức về thành kiến sẽ rất hữu ích, vì khi có nhận thức về sự thành kiến, ta có thể tham khảo nhiều đầu vào và ý kiến. Một liên quan mật thiết là sự thiên vị về [ưu thế](https://en.wikipedia.org/wiki/Illusory_superiority) của Huyễn Ảnh.
+
+Ví dụ trong thế giới thực:
+
+- [Apple vs. FBI: Tại sao Diều hâu chống khủng bố này lại chuyển hướng](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) - Năm 2016, Thượng nghị sĩ Lindsey Graham đã thay đổi lập trường của mình về việc Apple tạo ra một 'cửa sau' trong mã hóa thiết bị của họ. Ban đầu, Graham đã chỉ trích Apple thách thức yêu cầu tạo một 'cửa sau', mà ông cho là cần thiết để điều tra các âm mưu khủng bố tiềm ẩn. Tuy nhiên, nhờ sự thừa nhận của chính Graham, khi anh ấy hiểu thêm về độ phức tạp kỹ thuật của miền, anh ấy nhận ra rằng anh ấy đã cho rằng nó đơn giản hơn nhiều so với những gì anh ấy đã nhận ra và rằng một cửa hậu như vậy có thể gây ra những hậu quả tiêu cực nghiêm trọng. Đây có thể được coi là một ví dụ về hiệu ứng Dunning-Kruger - một chuyên gia an ninh mạng có thể sẽ hiểu ngay lập tức về cách một cửa hậu như vậy có thể bị khai thác, vì họ có hiểu biết sâu sắc về miền, một người dân có thể cho rằng bảo mật điện thoại tương tự hơn đối với *bảo mật vật lý* khi có thể thực hiện được 'khóa chính' để thực thi pháp luật, nhưng sự tương tự này không áp dụng đủ tốt để mô tả mã hóa hiện đại trong an ninh mạng.
+
+### Luật Fitts
+
+[Luật Fitts trên Wikipedia](https://en.wikipedia.org/wiki/Fitts%27s_law)
+
+Định luật Fitts dự đoán rằng thời gian cần thiết để di chuyển đến một khu vực mục tiêu là một hàm của khoảng cách đến mục tiêu chia cho chiều rộng của mục tiêu.
+
+<img width="300px" src="./images/Fitts_Law.svg" alt="Diagram: Fitts Law">
+
+*(Image Reference: By Foobar628 at English Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)*
+
+Hệ quả của luật này quy định rằng khi thiết kế UI/UX, các phần tử tương tác phải càng lớn càng tốt và khoảng cách giữa vùng chú ý của người dùng và phần tử tương tác phải càng nhỏ càng tốt. Điều này có hậu quả về thiết kế, chẳng hạn như nhóm các nhiệm vụ thường được sử dụng với nhau.
+
+Nó cũng chính thức hóa khái niệm 'góc ma thuật', các góc của màn hình mà người dùng có thể 'quét' chuột của họ để dễ dàng nhấn - đó là nơi có thể đặt các phần tử giao diện người dùng chính. Nút Start của Windows nằm ở một góc kỳ diệu, giúp bạn dễ dàng lựa chọn và như một sự tương phản thú vị, nút 'đóng cửa sổ' của MacOS *không* nằm ở một góc ma thuật, nên khó có thể nhấn nhầm.
+
+Xem thêm:
+
+- [The information capacity of the human motor system in controlling the amplitude of movement.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d)
+
+### Luật Gall
+
+[Luật Gall trên Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Một hệ thống phức tạp luôn được phát triển từ một hệ thống đơn giản đã hoạt động. Một hệ thống phức tạp được thiết kế từ đầu không bao giờ hoạt động và không thể sửa chữa để làm cho nó hoạt động. Bạn phải luôn bắt đầu với một hệ thống đơn giản và hoạt động được.
+>
+> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+
+Định luật Gall ngụ ý rằng những nỗ lực *thiết kế* các hệ thống phức tạp có khả năng thất bại cao. Các hệ thống phức tạp cao hiếm khi được xây dựng trong một lần, mà thực tế là phát triển từ các hệ thống đơn giản hơn.
+
+Ví dụ cổ điển là world-wide-web. Ở trạng thái hiện tại, nó là một hệ thống rất phức tạp. Tuy nhiên, ban đầu nó được định nghĩa là một cách đơn giản để chia sẻ nội dung giữa các tổ chức học thuật. Nó đã rất thành công trong việc đáp ứng những mục tiêu này và ngày càng phát triển trở nên phức tạp hơn theo thời gian.
+
+Xem thêm:
+
+- [KISS (Giữ nó đơn giản, đến ngốc)](#the-kiss-principle)
+
+### Luật Goodhart
+
+[Định luật Goodhart trên Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Mọi hệ thống có xu hướng sụp đổ khi chịu áp bị lực quan sát với mục đích kiểm soát.
+>
+> *Charles Goodhart*
+
+Cũng thường được gọi là:
+
+> Khi đo lường là mục tiêu, nó là một đo lường xấu.
+>
+> *Marilyn Strathern*
+
+Luật nói rằng các tối ưu hóa theo hướng đo lường, có thể dẫn đến việc giảm giá trị của chính kết quả đo lường. Việc áp dụng một cách mù quáng các bộ đo lường ( [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ) cho một quy trình dẫn đến hiệu quả bị bóp méo. Mọi người có xu hướng tối ưu hóa cục bộ bằng cách "chơi" hệ thống để đáp ứng các chỉ số cụ thể, thay vì chú ý đến kết quả tổng thể của các hành động của họ.
+
+Ví dụ trong thế giới thực:
+
+- Các bài kiểm tra không có xác nhận đáp ứng kỳ vọng về độ bao phủ của mã, mặc dù thực tế là mục đích của số liệu là tạo ra phần mềm được kiểm tra tốt.
+- Khi điểm hiệu suất của nhà phát triển được tính bằng đếm số dòng lệnh, thì sẽ dẫn đến số dòng lệnh bị phình ra một cách vô cớ.
+
+Xem thêm:
+
+- [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
+
+### Dao cạo của Hanlon
+
+[Dao cạo của Hanlon trên Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> Không thể giải thích một kết quả xấu bằng sự thực hiện  ác ý, mà bằng sự ngu dốt.
+>
+> Robert J. Hanlon
+
+Nguyên tắc này gợi ý rằng những hành động dẫn đến một kết quả xấu không phải là do ý chí xấu. Thay vào đó, kết quả xấu có nhiều khả năng là do những hành động hoặc tác động không được hiểu một cách đầy đủ.
+
+### Luật Hick (Luật Hick-Hyman)
+
+[Luật Hick trên Wikipedia](https://en.wikipedia.org/wiki/Hick%27s_law)
+
+> Thời gian quyết định tăng theo logarit với số lượng tùy chọn bạn có thể chọn.
+>
+> William Edmund Hick và Ray Hyman
+
+Trong phương trình dưới đây, `T` là thời gian để đưa ra quyết định, `n` là số lựa chọn và `b` là hằng số được xác định bằng phân tích dữ liệu.
+
+![Hicks law](./images/hicks_law.svg)
+
+*(Image Reference: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)*
+
+Luật này chỉ áp dụng khi số lượng tùy chọn được *sắp xếp* , ví dụ, theo thứ tự bảng chữ cái. Điều này được ngụ ý trong lôgarit cơ số hai - ngụ ý người ra quyết định về cơ bản đang thực hiện *tìm kiếm nhị phân* . Nếu các tùy chọn không được sắp xếp hợp lý, các thử nghiệm cho thấy thời gian thực hiện là tuyến tính.
+
+Điều này có tác động đáng kể trong thiết kế giao diện người dùng; đảm bảo rằng người dùng có thể dễ dàng tìm kiếm thông qua các tùy chọn dẫn đến việc ra quyết định nhanh hơn.
+
+Một mối tương quan cũng đã được chỉ ra trong Định luật Hick giữa chỉ số IQ và thời gian phản ứng như được thể hiện trong [Tốc độ xử lý thông tin: Thay đổi phát triển và Liên kết với trí thông minh](https://www.sciencedirect.com/science/article/pii/S0022440599000369) .
+
+Xem thêm:
+
+- [Luật Fitts](#fitts-law)
+
+### Định luật Hofstadter
+
+[Luật Hofstadter trên Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+> Nó luôn mất nhiều thời gian hơn bạn dự tính, ngay cả khi bạn tính đến Định luật Hofstadter.
+>
+> (Douglas Hofstadter)
+
+Bạn có thể nghe thấy luật này được đề cập đến khi xem xét các ước tính về thời gian. Có vẻ như chúng ta có xu hướng không giỏi trong việc ước tính chính xác thời gian một thứ gì đó sẽ được phân phối, ví dụ cụ thể như trong phát triển phần mềm.
+
+Đây là từ cuốn sách ' [Gödel, Escher, Bach:  An Eternal Golden Braid](#reading-list) '.
+
+Xem thêm:
+
+- [Danh sách đọc: Gödel, Escher, Bach:  An Eternal Golden Braid](#reading-list)
+
+### Định luật Hutber
+
+[Luật Hutber trên Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Cải tiến đồng nghĩa là xấu đi.
+>
+> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+
+Luật này gợi ý rằng những cải tiến đối với một hệ thống sẽ dẫn đến sự hư hỏng ở các bộ phận khác, hoặc nó sẽ che giấu sự hư hỏng khác, dẫn đến sự suy thoái về tổng thể so với trạng thái hiện tại của hệ thống.
+
+Ví dụ: giảm độ trễ phản hồi trên mạng, có thể gây ra các vấn đề về thông lượng và dung lượng tăng thêm trong luồng yêu cầu, ảnh hưởng đến một hệ thống khác.
+
+### Chu kỳ cường điệu &amp; Định luật Amara
+
+[Chu kỳ cường điệu trên Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> Chúng ta có xu hướng đánh giá cao hiệu quả của một công nghệ trong ngắn hạn và đánh giá thấp về lâu dài.
+>
+> (Roy Amara)
+
+Hype Cycle là hình ảnh đại diện cho sự sôi động và phát triển của công nghệ theo thời gian, ban đầu được sản xuất bởi Gartner. Nó được hiển thị tốt nhất bằng hình ảnh:
+
+![The Hype Cycle](./images/gartner_hype_cycle.png)
+
+*(Image Reference: By Jeremykemp at English Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Nói tóm lại, hình vẽ cho thấy thường có sự bùng nổ về công nghệ mới và tác động tiềm tàng của nó. Các đội thường nhanh chóng tham gia vào các công nghệ này, và đôi khi cảm thấy thất vọng với kết quả. Điều này có thể là do công nghệ chưa đủ trưởng thành hoặc các ứng dụng trong thế giới thực vẫn chưa được thực hiện đầy đủ. Sau một khoảng thời gian nhất định, khả năng của công nghệ tăng lên và các cơ hội thực tế để sử dụng nó cũng tăng lên, và các nhóm cuối cùng có thể trở nên hiệu quả. Câu nói của Roy Amara tóm tắt điều này một cách ngắn gọn nhất - "Chúng ta có xu hướng đánh giá quá cao tác dụng của một công nghệ trong ngắn hạn và đánh giá thấp về lâu dài".
+
+### Luật Hyrum (Luật của các giao diện ngầm)
+
+[Luật Hyrum trên mạng](http://www.hyrumslaw.com/)
+
+> Với đủ số lượng người dùng đủ lớn, điều bạn ghi trong đặc tả không quan trọng: tất cả các hành vi có thể quan sát được trên hệ thống của bạn sẽ phụ thuộc vào ai đó khác.
+>
+> (Hyrum Wright)
+
+Luật của Hyrum tuyên bố rằng khi bạn có một *số lượng đủ lớn lời gọi đến bộ* API, tất cả các hành vi của API (ngay cả những hành vi không được định nghĩa là một phần của hợp đồng công khai) cuối cùng sẽ phụ thuộc vào ai đó. Ví dụ đơn giản có thể là các tính phi chức năng, như thời gian phản hồi của một API. Một ví dụ tinh tế hơn có thể là người tiêu dùng đang dựa vào việc áp dụng regex cho một thông báo lỗi để xác định *loại* lỗi của một API. Ngay cả khi hợp đồng công khai của API không nêu gì về nội dung của thông báo, cho biết người dùng nên sử dụng mã lỗi liên quan, *một số* người dùng có thể sử dụng thông báo và việc thay đổi thông báo về cơ bản sẽ phá vỡ API đối với những người dùng đó.
+
+Xem thêm:
+
+- [Luật sự rỉ mục của trừu tượng](#the-law-of-leaky-abstractions)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Định luật Kernighan
+
+> Gỡ lỗi khó gấp đôi so với viết mã ngay từ đầu. Do đó, nếu bạn viết mã một cách khéo léo nhất có thể, theo định nghĩa, bạn không đủ thông minh để gỡ lỗi nó.
+>
+> (Brian Kernighan)
+
+Định luật Kernighan được đặt tên cho [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) và bắt nguồn từ một trích dẫn từ cuốn sách [Các yếu tố của phong cách lập trình của](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) Kernighan và Plauger:
+
+> Mọi người đều biết rằng việc gỡ lỗi khó gấp đôi so với việc viết một chương trình ngay từ đầu. Vì vậy, nếu bạn thông minh hết mức có thể khi bạn viết nó, làm thế nào bạn sẽ gỡ lỗi nó?
+
+Luật Kernighan đưa ra lập luận rằng: mã đơn giản được ưu tiên hơn mã phức tạp, bởi vì việc gỡ lỗi bất kỳ vấn đề nào phát sinh trong mã phức tạp có thể tốn kém hoặc thậm chí không khả thi.
+
+Xem thêm:
+
+- [Nguyên tắc KISS](#the-kiss-principle)
+- [Triết lý Unix](#the-unix-philosophy)
+- [Dao cạo của Occam](#occams-razor)
+
+### Luật Linus
+
+[Luật Linus trên Wikipedia](https://en.wikipedia.org/wiki/Linus%27s_law)
+
+> Khi đủ số lượng người soi vào thì các lỗi đều sẽ bị phát hiện.
+>
+> *Eric S. Raymond*
+
+Luật này chỉ đơn giản nói rằng càng nhiều người có thể nhìn thấy vấn đề, thì khả năng một người nào đó đã nhìn thấy và giải quyết vấn đề đó tương tự trước đây.
+
+Mặc dù ban đầu nó được sử dụng để mô tả giá trị của các mô hình mã nguồn mở cho các dự án, nó có thể được chấp nhận cho bất kỳ loại dự án phần mềm nào. Nó cũng có thể được mở rộng cho các quy trình - nhiều đánh giá mã hơn, phân tích tĩnh hơn và các quy trình kiểm tra đa nguyên tắc sẽ làm cho các vấn đề hiển thị và dễ xác định hơn.
+
+Một tuyên bố chính thức hơn có thể là:
+
+> Với số người thử nghiệm và đồng-phát-triển đủ lớn, hầu hết mọi vấn đề sẽ được xác định một cách nhanh chóng và có thể được giải quyết bởi những người đã từng gặp sự cố tương tự trước đây.
+
+Luật này được đặt tên để vinh danh [Linus Torvalds](https://en.wikipedia.org/wiki/Linus_Torvalds) trong cuốn sách " [The Cathedral and the Bazaar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) " của Eric S. Raymond.
+
+### Định luật Metcalfe
+
+[Luật Metcalfe trên Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> Trong lý thuyết mạng, giá trị của một hệ thống tăng lên xấp xỉ bình phương của số lượng người dùng của hệ thống.
+
+Luật này dựa trên số lượng các kết nối theo cặp có thể có trong một hệ thống và có liên quan chặt chẽ với Định [luật Reed](#reeds-law) . Odlyzko và những người khác đã lập luận rằng cả Định luật Reed và Định luật Metcalfe đều phóng đại giá trị của hệ thống bằng cách không tính đến giới hạn nhận thức của con người về hiệu ứng mạng; xem [Số của Dunbar](#dunbars-number) .
+
+Xem thêm:
+
+- [Luật Reed](#reeds-law)
+- [Số Dunbar](#dunbars-number)
+
+### Định luật Moore
+
+[Định luật Moore trên Wikipedia](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Số lượng bóng bán dẫn trong một mạch tích hợp tăng gấp đôi khoảng hai năm một lần.
+
+Thường được sử dụng để minh họa tốc độ mà công nghệ bán dẫn và chip đã được cải thiện, dự đoán của Moore đã được chứng minh là có độ chính xác cao trong khoảng thời gian từ những năm 1970 đến cuối những năm 2000. Trong những năm gần đây, xu hướng đã thay đổi một chút, một phần do [những hạn chế vật lý về mức độ thu nhỏ của các thành phần](https://en.wikipedia.org/wiki/Quantum_tunnelling) . Tuy nhiên, những tiến bộ trong quá trình song song hóa và những thay đổi có khả năng mang tính cách mạng trong công nghệ bán dẫn và điện toán lượng tử có thể có nghĩa là Định luật Moore có thể tiếp tục đúng trong nhiều thập kỷ tới.
+
+### Định luật Murphy / Định luật Sod
+
+[Định luật Murphy trên Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Cái gì có thể xảy ra sai sót thì nó sẽ xảy ra.
+
+Liên quan đến [Edward A. Murphy, Định luật Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) *Murphy* nói rằng nếu một điều có thể sai, nó sẽ sai.
+
+Đây là một câu châm ngôn phổ biến giữa các nhà phát triển. Đôi khi điều không mong muốn xảy ra khi phát triển, thử nghiệm hoặc thậm chí trong quá trình sản xuất. Điều này cũng có thể liên quan đến Định *luật Sod* (phổ biến hơn trong tiếng Anh):
+
+> Nếu điều sai lầm đó có thể xảy ra, nó sẽ xảy ra vào thời điểm tồi tệ nhất.
+
+Những 'luật' này thường được sử dụng theo nghĩa truyện tranh. Tuy nhiên, các hiện tượng như [*Thiên lệch xác nhận*](#TODO) và [*Thiên lệch lựa chọn*](#TODO) có thể khiến mọi người có lẽ quá nhấn mạnh các định luật này (phần lớn khi mọi thứ hoạt động, chúng không được chú ý, tuy nhiên, thất bại lại được chú ý nhiều hơn và thu hút nhiều thảo luận hơn).
+
+Xem thêm:
+
+- [Thiên vị xác nhận](#TODO)
+- [Thiên vị lựa chọn](#TODO)
+
+### Dao cạo của Occam
+
+[Occam's Razor trên Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Không nhân các đối tượng lên khi không cần thiết.
+>
+> William of Ockham
+
+Dao cạo của Occam nói rằng trong số một số giải pháp khả thi, giải pháp tốt nhất là giải pháp có ít khái niệm và giả định nhất. Giải pháp đúng nhất là giải pháp đơn giản nhất để giải quyết được vấn đề, không tạo ra sự phức tạp, ngẫu nhiên và hậu quả tiêu cực có thể xảy ra.
+
+Xem thêm:
+
+- [YAGNI](#yagni)
+- [Không có viên đạn bạc: Sự phức tạp tình cờ và sự phức tạp thiết yếu](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Thí dụ:
+
+- [Phát triển phần mềm tinh gọn: Loại bỏ lãng phí](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Định luật Parkinson
+
+[Parkinson's Law on Wikipedia](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Công việc sẽ tự mở rộng để lấp đầy thời gian được cấp.
+
+Trong bối cảnh ban đầu, Luật này dựa trên các nghiên cứu về các bộ máy quan liêu. Nó có thể được áp dụng một cách bi quan cho các sáng kiến phát triển phần mềm, lý thuyết cho rằng các nhóm sẽ hoạt động kém hiệu quả cho đến khi thời hạn gần kề, sau đó vội vàng hoàn thành công việc trước thời hạn, do đó làm cho thời hạn thực tế hơi tùy tiện.
+
+Nếu luật này được kết hợp với Định luật [Hofstadter](#hofstadters-law) , một quan điểm thậm chí còn bi quan hơn - công việc sẽ mở rộng để lấp đầy thời gian có sẵn để hoàn thành và *vẫn mất nhiều thời gian hơn dự kiến* .
+
+Xem thêm:
+
+- [Định luật Hofstadter](#hofstadters-law)
+
+### Hiệu ứng tối ưu hóa sớm
+
+[Tối ưu hóa sớm trên WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Tối ưu sớm là gốc rễ của mọi xấu xa.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+Trong bài báo của Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) , ông đã viết: "Các lập trình viên lãng phí rất nhiều thời gian để suy nghĩ hoặc lo lắng về tốc độ của các phần không quan trọng trong chương trình của họ và những nỗ lực về hiệu quả này thực sự có tác động tiêu cực mạnh khi gỡ lỗi và bảo trì được xem xét. Chúng ta nên quên đi những hiệu quả nhỏ, nói rằng khoảng 97% thời gian: **tối ưu hóa sớm là gốc rễ của mọi điều xấu** . Tuy nhiên, chúng ta không nên bỏ qua cơ hội của mình trong 3% quan trọng đó. "
+
+Tuy nhiên, *Tối ưu hóa sớm* có thể được định nghĩa (đơn giản hơn) là: chưa biết làm gì đã lo tối ưu.
+
+### Putt's Law
+
+[Luật Putt trên Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Công nghệ bị chi phối bởi hai loại người, những người hiểu những gì họ không quản lý và những người quản lý những gì họ không hiểu.
+
+Định luật Putt thường được tuân theo bởi Hệ quả Putt:
+
+> Trong mọi hệ thống kỹ thuật được phân cấp, theo thời gian, nó sẽ phát triển theo hướng nghịch đảo của năng lực.
+
+Những tuyên bố này nói rằng do các tiêu chí lựa chọn khác nhau và xu hướng trong cách tổ chức, sẽ có một số người có kỹ năng  kỹ thuật và một số trong vai trò quản lý không nhận thức được sự phức tạp và thách thức của công việc mà họ đang quản lý. Điều này có thể là do các hiện tượng như [Nguyên tắc Peter](#the-peter-principle) hoặc [Nguyên tắc Dilbert](#the-dilbert-principle) .
+
+Tuy nhiên, cần nhấn mạnh rằng các Luật như thế này là khái quát rộng lớn và có thể áp dụng cho *một số* loại hình tổ chức và không áp dụng cho các loại hình khác.
+
+Xem thêm:
+
+- [Nguyên tắc Peter](#the-peter-principle)
+- [Nguyên tắc Dilbert](#the-dilbert-principle)
+
+### Luật Reed
+
+[Luật Reed trên Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Các tiện ích trên các mạng lớn, đặc biệt là mạng xã hội, sẽ có quy mô theo cấp số nhân so với quy mô của mạng.
+
+Luật này dựa trên lý thuyết đồ thị, trong đó tiện ích mở rộng theo số lượng các nhóm con có thể có, nhanh hơn số lượng người tham gia hoặc số lượng các kết nối theo cặp có thể có. Odlyzko và những người khác đã lập luận rằng Định luật Reed phóng đại quá mức tiện ích của hệ thống bằng cách không tính đến các giới hạn nhận thức của con người về các hiệu ứng mạng; xem [Số của Dunbar](#dunbars-number) .
+
+Xem thêm:
+
+- [Định luật Metcalfe](#metcalfes-law)
+- [Số Dunbar](#dunbars-number)
+
+### Định luật Bảo toàn Độ phức tạp (Định luật Tesler)
+
+[Luật bảo tồn sự phức tạp trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Luật này nói rằng có một sự phức tạp cố định trong một hệ thống và chúng không thể giảm bớt.
+
+Một số phức tạp trong một hệ thống là 'vô tình'. Đó là hệ quả của cấu trú