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úc kém, sai lầm hoặc chỉ là mô hình hóa vấn đ� cần giải quyết một cách tồi tệ. Sự phức tạp do sơ ý có thể được giảm bớt (hoặc loại b�). Tuy nhiên, một số phức tạp là 'nội tại' là hệ quả của sự phức tạp vốn có trong vấn đ� đang được giải quyết. Sự phức tạp này có thể được di chuyển, nhưng không được loại b�.
+
+Một yếu tố thú vị đối với luật này là gợi ý rằng ngay cả khi đơn giản hóa toàn bộ hệ thống, độ phức tạp nội tại vẫn không giảm, nếu nó được *chuyển đến ngư�i dùng*, thì ngư�i dùng xử lý phức tạp hơn.
+
+### Ä�á