From 3949974900a4918281ebecc97680f94666d49e6e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?nguy=C3=AAn?= Date: Wed, 12 Jan 2022 04:10:54 +0000 Subject: Translate vi.md via GitLocalize --- translations/vi.md | 1035 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1035 insertions(+) create mode 100644 translations/vi.md 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! + +--- + + + +- [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 & Äị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) + + + +## 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 Ä‘á»™: + +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."

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. + +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 & Äị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. + +### Äịnh luật Demeter + +[Äịnh luật Demeter trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_Demeter) + +> Äừng nói chuyện vá»›i ngÆ°á»i lạ. + +Äịnh luật Demeter, còn được gá»i là "Nguyên tắc Kiến Thức It Nhất" là má»™t nguyên tắc cho thiết kế phần má»m, đặc biệt thích hợp trong các ngôn ngữ hÆ°á»›ng đối tượng. + +Nó nói rằng má»™t Ä‘Æ¡n vị phần má»m chỉ nên nói chuyện vá»›i các cá»™ng tác viên trá»±c tiếp của nó. Má»™t đối tượng `A` có tham chiếu đến đối tượng `B` có thể gá»i các phÆ°Æ¡ng thức của nó, nhÆ°ng nếu `B` có tham chiếu đến đối tượng `C` , `A` không nên gá»i các phÆ°Æ¡ng thức của `C` Vì vậy, nếu `C` có phÆ°Æ¡ng thức `doThing()` `A` không nên gá»i nó trá»±c tiếp; `B.getC().doThis()` . + +Việc tuân theo nguyên tắc chính này sẽ giá»›i hạn phạm vi thay đổi, giúp chúng dá»… dàng hÆ¡n và an toàn hÆ¡n trong tÆ°Æ¡ng lai. + +### Luật Sá»± rỉ mục của Trừu tượng + +[Luật vá» Luật sá»± rỉ mục của Trừu tượng Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) + +> Tất cả những trừu tượng, ở má»™t mức Ä‘á»™ nào đó Ä‘á»u bị rỉ mục. +> +> ([Joel Spolsky](https://twitter.com/spolsky)) + +- Trừu Tượng(abstraction) là những phác thảo, mô tả má»™t cách tổng quát.
- Rỉ mục (leaky): ví dụ nhÆ° thùng phi sắt, theo thá»i gian hÆ° hại, mục, rỉ má»™t số chá»— mà không há»ng hoàn toàn.
Luật này quy định rằng Trừu Tượng , thÆ°á»ng được sá»­ dụng trong máy tính để Ä‘Æ¡n giản hóa làm việc vá»›i các hệ thống phức tạp, trong má»™t số tình huống nhất định sẽ bị 'rỉ mục (nghÄ©a là rỉ mục hay có má»™t số chá»— bị hÆ° há»ng)' , Ä‘iá»u này làm cho các Trừu Tượng hoạt Ä‘á»™ng theo cách không mong muốn. + +Má»™t ví dụ có thể Ä‘ang tải má»™t tệp và Ä‘á»c ná»™i dung của nó. Các API hệ thống tệp là má»™t phần *trừu tượng* của các hệ thống nhân cấp thấp hÆ¡n, bản thân chúng là má»™t phần trừu tượng đối vá»›i các quá trình vật lý liên quan đến việc thay đổi dữ liệu trên Ä‘Ä©a từ tính (hoặc bá»™ nhá»› flash cho SSD). Trong hầu hết các trÆ°á»ng hợp, việc xá»­ lý má»™t tệp nhÆ° má»™t luồng dữ liệu nhị phân sẽ hoạt Ä‘á»™ng. Tuy nhiên, đối vá»›i ổ Ä‘Ä©a cÆ¡ há»c, việc Ä‘á»c dữ liệu tuần tá»± sẽ *nhanh hÆ¡n đáng kể* so vá»›i truy cập ngẫu nhiên (do lá»—i trang tăng lên), nhÆ°ng đối vá»›i ổ Ä‘Ä©a SSD, chi phí này sẽ không xuất hiện. Cần phải hiểu chi tiết cÆ¡ bản để đối phó vá»›i trÆ°á»ng hợp này (ví dụ: các tệp chỉ mục cÆ¡ sở dữ liệu được cấu trúc để giảm chi phí truy cập ngẫu nhiên), chi tiết triển khai 'rò rỉ' trừu tượng mà nhà phát triển có thể cần phải biết. + +Ví dụ trên có thể trở nên phức tạp *hÆ¡n khi có nhiá»u ná»™i dung* trừu tượng hÆ¡n. Hệ Ä‘iá»u hành Linux cho phép các tệp được truy cập qua mạng nhÆ°ng được trình bày cục bá»™ dÆ°á»›i dạng tệp 'bình thÆ°á»ng'. Tóm tắt này sẽ 'rỉ mục' nếu có lá»—i mạng. Nếu nhà phát triển coi các tệp này là tệp 'bình thÆ°á»ng' mà không xem xét đến thá»±c tế là chúng có thể phải chịu Ä‘á»™ trá»… và lá»—i mạng, thì các giải pháp sẽ có lá»—i. + +Bài báo mô tả luật cho thấy rằng việc phụ thuá»™c quá nhiá»u vào những Ä‘iá»u trừu tượng, kết hợp vá»›i sá»± hiểu biết kém vá» các quy trình cÆ¡ bản, thá»±c sá»± khiến việc xá»­ lý vấn Ä‘á» trong má»™t số trÆ°á»ng hợp *trở nên phức tạp hÆ¡n.* + +Xem thêm: + +- [Äịnh luật Hyrum](#hyrums-law-the-law-of-implicit-interfaces) + +Ví dụ trong thế giá»›i thá»±c: + +- [Photoshop khởi Ä‘á»™ng chậm](https://forums.adobe.com/thread/376152) - má»™t vấn Ä‘á» tôi gặp phải trong quá khứ. Photoshop khởi Ä‘á»™ng chậm, đôi khi mất vài phút. Có vẻ nhÆ° vấn Ä‘á» là khi khởi Ä‘á»™ng, nó Ä‘á»c má»™t số thông tin vá» máy in mặc định hiện tại. Tuy nhiên, nếu máy in đó thá»±c sá»± là má»™t máy in mạng, thì quá trình này có thể mất rất nhiá»u thá»i gian. Sá»± *trừu tượng* của má»™t máy in mạng được trình bày cho hệ thống tÆ°Æ¡ng tá»± nhÆ° má»™t máy in cục bá»™ đã gây ra sá»± cố cho ngÆ°á»i dùng trong các tình huống kết nối kém. + +### Luật Tầm ThÆ°á»ng + +[Luật Tầm ThÆ°á»ng trên Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) + +Luật này gợi ý rằng các nhóm sẽ dành nhiá»u thá»i gian và sá»± chú ý hÆ¡n cho những vấn Ä‘á» nhá» nhặt hoặc thẩm mỹ hÆ¡n là những vấn Ä‘á» nghiêm trá»ng và thá»±c chất. + +Ví dụ hÆ° cấu phổ biến được sá»­ dụng là má»™t ủy ban phê duyệt kế hoạch cho nhà máy Ä‘iện hạt nhân, há» dành phần lá»›n thá»i gian để thảo luận vá» cấu trúc của nhà để xe đạp, thay vì thiết kế quan trá»ng hÆ¡n nhiá»u cho chính nhà máy Ä‘iện. Có thể khó Ä‘Æ°a ra ý kiến đóng góp có giá trị cho các cuá»™c thảo luận vá» các chủ Ä‘á» rất lá»›n, phức tạp nếu không có sá»± chuẩn bị hoặc chuyên môn cao vá» chủ Ä‘á». Tuy nhiên, má»i ngÆ°á»i muốn được xem là có đóng góp ý kiến có giá trị. Do đó, có xu hÆ°á»›ng tập trung quá nhiá»u thá»i gian vào những chi tiết nhá», không quan trá»ng. + +Ví dụ hÆ° cấu ở trên đã dẫn đến việc sá»­ dụng thuật ngữ 'Nhà giữ Xe đạp' nhÆ° má»™t cách diá»…n đạt cho việc lãng phí thá»i gian vào những chi tiết nhá» nhặt. Má»™t thuật ngữ liên quan là ' [Yak Shaving](https://en.wiktionary.org/wiki/yak_shaving) ', có nghÄ©a là má»™t hoạt Ä‘á»™ng dÆ°á»ng nhÆ° không liên quan nhÆ°ng là má»™t phần của chuá»—i dài các Ä‘iá»u kiện tiên quyết đối vá»›i nhiệm vụ chính. + +### Triết lý Unix + +[Triết lý Unix trên Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy) + +Triết lý của Unix là các thành phần phần má»m phải nhá» và tập trung vào làm tốt má»™t việc cụ thể. Äiá»u này có thể giúp dá»… dàng hÆ¡n trong việc xây dá»±ng hệ thống vá»›i các Ä‘Æ¡n vị nhá», Ä‘Æ¡n giản, được xác định rõ ràng, thay vì sá»­ dụng các chÆ°Æ¡ng trình lá»›n, phức tạp, Ä‘a mục đích. + +Các thá»±c hành hiện đại nhÆ° 'Kiến trúc Microservice' có thể được coi là má»™t ứng dụng của luật này, trong đó các dịch vụ nhá», tập trung và thá»±c hiện má»™t việc cụ thể, cho phép hành vi phức tạp bao gồm các khối xây dá»±ng Ä‘Æ¡n giản. + +### Mô hình Spotify + +[Mô hình Spotify trên Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) + +Mô hình Spotify là má»™t phÆ°Æ¡ng pháp tiếp cận cấu trúc tổ chức và nhóm đã được phổ biến bởi 'Spotify'. Trong mô hình này, các nhóm được tổ chức xung quanh các tính năng, thay vì công nghệ. + +Mô hình Spotify cÅ©ng phổ biến các khái niệm vá» Bá»™ lạc, Bang há»™i, Chi há»™i, là các thành phần khác trong cÆ¡ cấu tổ chức của chúng. + +Các thành viên của tổ chức đã mô tả rằng ý nghÄ©a thá»±c tế của các nhóm này thay đổi, phát triển và là má»™t thá»­ nghiệm Ä‘ang diá»…n ra. Thá»±c tế là mô hình là má»™t *quá trình Ä‘ang vận Ä‘á»™ng* , chứ không phải là má»™t mô hình cố định tiếp tục dẫn đến các cách hiểu khác nhau vá» cấu trúc, có thể dá»±a trên các bài thuyết trình của nhân viên tại các há»™i nghị. Äiá»u này có nghÄ©a là 'ảnh chụp nhanh' có thể được bên thứ ba 'đóng gói lại' nhÆ° má»™t *cấu trúc cố định* , vá»›i thá»±c tế là mô hình Ä‘á»™ng sẽ bị mất. + +### Quy tắc hai chiếc bánh pizza + +> Nếu 2 chiếc bánh pizza không đủ cho má»™t nhóm, thì nhóm đã quá lá»›n. +> +> (Jeff Bezos) + +Quy tắc này cho thấy rằng bất kể quy mô của công ty, các Ä‘á»™i nên đủ nhỠđể có thể ăn hai chiếc pizza. Äược gán cho Jeff Bezos và Amazon, niá»m tin này cho thấy rằng các Ä‘á»™i lá»›n vốn đã không hiệu quả. Äiá»u này được há»— trợ bởi thá»±c tế là khi quy mô nhóm tăng tuyến tính, liên kết giữa má»i ngÆ°á»i sẽ tăng theo bậc hai; do đó chi phí phối hợp và giao tiếp cÅ©ng tăng theo bậc hai. Nếu chi phí phối hợp này vá» cÆ¡ bản là tổng chi phí, thì các nhóm nhá» hÆ¡n nên được Æ°u tiên hÆ¡n. + +Số lượng liên kết giữa má»i ngÆ°á»i có thể được biểu thị bằng `n(n-1)/2` trong đó n = số ngÆ°á»i. + +Complete graph; Links between people + +### Luật Wadler + +[Luật của Wadler trên wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) + +> Trong bất kỳ thiết kế ngôn ngữ nào, tổng thá»i gian dành để thảo luận vá» má»™t tính năng trong danh sách này tá»· lệ thuận vá»›i hai phần được nâng lên vá»›i sức mạnh của vị trí của nó. +> +> 1. Ngữ nghÄ©a há»c +> 2. Cú pháp +> 3. Cú pháp từ vá»±ng +> 4. Cú pháp của ghi chú +> +> (Nói tóm lại, cứ má»—i giá» dành cho ngữ nghÄ©a thì 8 giá» sẽ dành cho cú pháp của chú thích). + +TÆ°Æ¡ng tá»± nhÆ° [Äịnh luật vá» tính tầm thÆ°á»ng](#the-law-of-triviality) , Äịnh luật của Wadler cho biết khi thiết kế má»™t ngôn ngữ, lượng thá»i gian dành cho các cấu trúc ngôn ngữ cao hÆ¡n má»™t cách tÆ°Æ¡ng xứng so vá»›i tầm quan trá»ng của những tính năng đó. + +Xem thêm: + +- [Luật tầm thÆ°á»ng](#the-law-of-triviality) + +### Äịnh luật Wheaton + +[Liên kết](http://www.wheatonslaw.com/) + +[Ngày chính thức](https://dontbeadickday.com/) + +> Äừng là trẻ ranh. +> +> *Wil Wheaton* + +Äược đặt ra bởi Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), luật Ä‘Æ¡n giản, ngắn gá»n và mạnh mẽ này nhằm mục đích tăng cÆ°á»ng sá»± hòa hợp và tôn trá»ng trong má»™t tổ chức chuyên nghiệp. Nó có thể được áp dụng khi nói chuyện vá»›i đồng nghiệp, thá»±c hiện đánh giá mã, phản bác các quan Ä‘iểm khác, phê bình và nói chung, hầu hết các tÆ°Æ¡ng tác chuyên nghiệp mà con ngÆ°á»i có vá»›i nhau. + +## Nguyên tắc + +Các nguyên tắc thÆ°á»ng có nhiá»u khả năng là các hÆ°á»›ng dẫn liên quan đến thiết kế. + +### Tất cả các mô hình Ä‘á»u sai (Äịnh luật George Box) + +[Tất cả các mô hình Ä‘á»u sai](https://en.wikipedia.org/wiki/All_models_are_wrong) + +> Tất cả các mô hình Ä‘á»u sai, nhÆ°ng má»™t số mô hình hữu ích. +> +> *George Box* + +Nguyên tắc này cho thấy rằng tất cả các mô hình hệ thống Ä‘á»u có sai sót, nhÆ°ng miá»…n là chúng không *quá* sai thì chúng có thể sá»­ dụng. Nguyên tắc này có nguồn gốc từ thống kê nhÆ°ng cÅ©ng áp dụng cho các mô hình khoa há»c và máy tính. + +Yêu cầu cÆ¡ bản của hầu hết các phần má»m là mô hình hóa má»™t hệ thống nào đó. Bất kể hệ thống được mô hình hóa là mạng máy tính, thÆ° viện, biểu đồ kết nối xã há»™i hay bất kỳ loại hệ thống nào khác, nhà thiết kế sẽ phải quyết định mức Ä‘á»™ chi tiết thích hợp để mô hình hóa. Quá nhiá»u chi tiết có thể dẫn đến quá nhiá»u phức tạp, quá ít chi tiết có thể khiến mô hình không hoạt Ä‘á»™ng được. + +Xem thêm: + +- [Luật sá»± rỉ mục của trừu tượng](#the-law-of-leaky-abstractions) + +### Chesterson's Fence + +[Chesterson's Fence trên Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence) + +> Không cải cách cho đến khi hiểu được lý do đằng sau tình trạng hiện tại. + +Nguyên tắc này có liên quan trong kỹ thuật phần má»m khi loại bá» nợ kỹ thuật. Má»—i dòng của má»™t chÆ°Æ¡ng trình ban đầu được viết bởi má»™t ngÆ°á»i nào đó vì má»™t lý do nào đó. Chesterson's Fence gợi ý rằng ngÆ°á»i ta nên cố gắng hiểu ngữ cảnh và ý nghÄ©a của mã má»™t cách đầy đủ, trÆ°á»›c khi thay đổi hoặc loại bá» nó, ngay cả khi thoạt nhìn nó có vẻ thừa hoặc không chính xác. + +Tên của nguyên tắc này bắt nguồn từ má»™t câu chuyện của [GK Chesterson](https://en.wikipedia.org/wiki/G._K._Chesterton) . Má»™t ngÆ°á»i đàn ông băng qua hàng rào giữa Ä‘Æ°á»ng. Anh ta phàn nàn vá»›i thị trưởng rằng hàng rào vô dụng này Ä‘ang cản trở, và yêu cầu dỡ bá» nó. Thị trưởng há»i tại sao lại có hàng rào ngay từ đầu. Khi ngÆ°á»i đàn ông nói rằng anh ta không biết, thị trưởng nói, "Nếu bạn không biết mục đích của nó, tôi chắc chắn sẽ không để bạn gỡ bá» nó. Hãy Ä‘i tìm hiểu công dụng của nó, và sau đó tôi có thể cho phép bạn phá hủy. nó." + +### Hiệu ứng Biển Chết + +[Hiệu ứng Biển Chết đối vá»›i Bruce F. Webster](http://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/) + +> Các kỹ sÆ° CNTT tài năng là những ngÆ°á»i có nhiá»u khả năng ra Ä‘i, ... [những ngÆ°á»i có xu hÆ°á»›ng] ở lại [là] - những kỹ sÆ° CNTT kém tài năng và hiệu quả. +> +> *Bruce F. Webster* + +"Hiệu ứng Biển Chết" cho thấy rằng trong bất kỳ tổ chức nào, kỹ năng / tài năng / hiệu quả của các kỹ sÆ° thÆ°á»ng tá»· lệ nghịch vá»›i thá»i gian của há» trong công ty. + +Thông thÆ°á»ng, các kỹ sÆ° có tay nghá» cao sẽ dá»… dàng kiếm được việc làm ở nÆ¡i khác và là những ngÆ°á»i đầu tiên làm nhÆ° vậy. Những kỹ sÆ° có kỹ năng lạc hậu hoặc yếu kém sẽ có xu hÆ°á»›ng ở lại công ty, vì rất khó tìm việc làm ở nÆ¡i khác. Äiá»u này đặc biệt rõ ràng nếu há» nhận được mức lÆ°Æ¡ng tăng dần theo thá»i gian làm việc tại công ty, vì việc nhận được mức thù lao tÆ°Æ¡ng Ä‘Æ°Æ¡ng ở những nÆ¡i khác có thể là má»™t thách thức. + +### Nguyên tắc Dilbert + +[Nguyên tắc Dilbert trên Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle) + +> Các công ty có xu hÆ°á»›ng thăng chức má»™t cách có hệ thống những nhân viên không đủ năng lá»±c lên ban quản lý để Ä‘Æ°a há» ra khá»i quy trình làm việc. +> +> *Scott Adams* + +Là má»™t khái niệm quản lý được phát triển bởi Scott Adams (tác giả của bá»™ truyện tranh Dilbert), Nguyên tắc Dilbert được lấy cảm hứng từ [Nguyên tắc Peter](#the-peter-principle) . Theo Nguyên tắc Dilbert, những nhân viên chÆ°a từng có năng lá»±c sẽ được thăng chức lên cấp quản lý để hạn chế thiệt hại mà há» có thể gây ra. Adams lần đầu tiên giải thích nguyên tắc này trong má»™t bài báo trên Tạp chí Phố Wall năm 1995, và mở rá»™ng nó trong cuốn sách kinh doanh năm 1996 của ông, [Nguyên tắc Dilbert](#reading-list) . + +Xem thêm: + +- [Nguyên tắc Peter](#the-peter-principle) +- [Äịnh luật Putt](#putts-law) + +### Nguyên tắc Pareto (Quy tắc 80/20) + +[Nguyên tắc Pareto trên Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle) + +> Hầu hết má»i thứ trong cuá»™c sống không được phân bổ đồng Ä‘á»u. + +Nguyên tắc Pareto gợi ý rằng trong má»™t số trÆ°á»ng hợp, phần lá»›n kết quả đến từ má»™t số ít đầu vào: + +- 80% má»™t phần má»m nhất định có thể được viết trong 20% tổng thá»i gian được phân bổ (ngược lại, 20% mã khó nhất chiếm 80% thá»i gian) +- 20% ná»— lá»±c tạo ra 80% kết quả +- 20% công việc tạo ra 80% doanh thu +- 20% lá»—i gây ra 80% sá»± cố +- 20% các tính năng được sá»­ dụng 80% + +Vào những năm 1940, kỹ sÆ° ngÆ°á»i Mỹ-Romania, Tiến sÄ© Joseph Juran, ngÆ°á»i được công nhận rá»™ng rãi là cha đẻ của kiểm soát chất lượng, [đã bắt đầu áp dụng nguyên tắc Pareto cho các vấn Ä‘á» chất lượng](https://en.wikipedia.org/wiki/Joseph_M._Juran) . + +Nguyên tắc này còn được gá»i là: Quy tắc 80/20, Quy luật số ít và Nguyên tắc vá» yếu tố thÆ°a thá»›t. + +Ví dụ trong thế giá»›i thá»±c: + +- Vào năm 2002, Microsoft đã báo cáo rằng bằng cách sá»­a 20% lá»—i được báo cáo nhiá»u nhất, 80% lá»—i liên quan và sá»± cố trong windows và office sẽ bị loại bá» ( [Tham khảo](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm) ). + +### Nguyên tắc Shirky + +[Nguyên tắc Shirky được giải thích](https://kk.org/thetechnium/the-shirky-prin/) + +> Các tổ chức sẽ cố gắng duy trì vấn Ä‘á» mà há» là giải pháp. +> +> *Clay Shirky* + +Nguyên tắc Shirky gợi ý rằng các giải pháp phức tạp - má»™t công ty, má»™t ngành hoặc má»™t công nghệ - có thể trở nên quá tập trung vào vấn Ä‘á» mà há» Ä‘ang giải quyết, đến ná»—i chúng có thể vô tình kéo dài vấn Ä‘á». Äiá»u này có thể là cố ý (má»™t công ty Ä‘ang cố gắng tìm ra những sắc thái má»›i cho má»™t vấn đỠđể biện minh cho việc tiếp tục phát triển má»™t giải pháp), hoặc vô tình (không thể hoặc không sẵn sàng chấp nhận hoặc xây dá»±ng má»™t giải pháp giải quyết được hoàn toàn hoặc loại bá» nó). + +Có quan hệ vá»›i: + +- Câu nói nổi tiếng của Upton Sinclair, *"Rất khó để khiến má»™t ngÆ°á»i đàn ông hiểu Ä‘iá