Merge pull request #370 from k0gen/main

pl.md

1 files changed, 1058 insertions, 0 deletions

diff --git a/translations/pl.md b/translations/pl.md
new file mode 100644
index 0000000..23df2ec
--- /dev/null
+++ b/translations/pl.md
@@ -0,0 +1,1058 @@
+# 💻📖 prawa-hakerskie
+
+Prawa, teorie, zasady i wzorce, które programiści uznają za przydatne.
+
+[Tłumaczenia](#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) [🇵🇱](./translations/pl.md) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md) [🇺🇦](./translations/uk.md)
+
+Podoba Ci się ten projekt? Proszę rozważyć [sponsorowanie mnie](https://github.com/sponsors/dwmkerr) i [tłumaczy](#translations) . Sprawdź również ten podcast na [The Changelog - Laws for Hackers to Live By,](https://changelog.com/podcast/403) aby dowiedzieć się więcej o projekcie! Możesz także [pobrać najnowszy e-book w formacie PDF](https://github.com/dwmkerr/hacker-laws/releases/latest/download/hacker-laws.pdf) . Sprawdź [Przewodnik](./.github/contributing.md) dla twórców, jeśli chcesz wnieść swój wkład!
+
+---
+
+<!-- vim-markdown-toc GFM -->
+
+- [Wstęp](#introduction)
+- [Prawa](#laws)
+    - [Zasada 90-9-1 (zasada 1%)](#9091-principle-1-rule)
+    - [Prawo Amdahla](#amdahls-law)
+    - [Teoria zepsutych okien](#the-broken-windows-theory)
+    - [Prawo Brooksa](#brooks-law)
+    - [Twierdzenie CAP (Twierdzenie Brewera)](#cap-theorem-brewers-theorem)
+    - [Prawo Conwaya](#conways-law)
+    - [Prawo Cunninghama](#cunninghams-law)
+    - [Numer Dunbara](#dunbars-number)
+    - [Efekt Dunninga-Krugera](#the-dunning-kruger-effect)
+    - [Prawo Fittsa](#fitts-law)
+    - [Prawo Galla](#galls-law)
+    - [Prawo Goodharta](#goodharts-law)
+    - [Brzytwa Hanlona](#hanlons-razor)
+    - [Prawo Hicka (Prawo Hicka-Hymana)](#hicks-law-hick-hyman-law)
+    - [Prawo Hofstadtera](#hofstadters-law)
+    - [Prawo Hutbera](#hutbers-law)
+    - [Cykl szumu i prawo Amary](#the-hype-cycle--amaras-law)
+    - [Prawo Hyruma (prawo niejawnych interfejsów)](#hyrums-law-the-law-of-implicit-interfaces)
+    - [Prawo Kernighana](#kernighans-law)
+    - [Prawo Linusa](#linuss-law)
+    - [Prawo Metcalfego](#metcalfes-law)
+    - [prawo Moore'a](#moores-law)
+    - [Prawo Murphy'ego / Prawo Soda](#murphys-law--sods-law)
+    - [Brzytwa Ockhama](#occams-razor)
+    - [Prawo Parkinsona](#parkinsons-law)
+    - [Przedwczesny efekt optymalizacji](#premature-optimization-effect)
+    - [Prawo Putta](#putts-law)
+    - [Prawo Reeda](#reeds-law)
+    - [Prawo zachowania złożoności (prawo Teslera)](#the-law-of-conservation-of-complexity-teslers-law)
+    - [Prawo Demeter](#the-law-of-demeter)
+    - [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions)
+    - [Prawo trywialności](#the-law-of-triviality)
+    - [Filozofia Uniksa](#the-unix-philosophy)
+    - [Zasada Skauta](#the-scout-rule)
+    - [Model Spotify](#the-spotify-model)
+    - [Zasada dwóch pizzy](#the-two-pizza-rule)
+    - [Prawo Wadlera](#wadlers-law)
+    - [Prawo Wheatona](#wheatons-law)
+- [Zasady](#principles)
+    - [Wszystkie modele są błędne (prawo George'a Boxa)](#all-models-are-wrong-george-boxs-law)
+    - [Płot Chestertona](#chestertons-fence)
+    - [Efekt Morza Martwego](#the-dead-sea-effect)
+    - [Zasada Dilberta](#the-dilbert-principle)
+    - [Zasada Pareto (Zasada 80/20)](#the-pareto-principle-the-8020-rule)
+    - [Zasada Shirky](#the-shirky-principle)
+    - [Zasada Piotra](#the-peter-principle)
+    - [Zasada solidności (prawo Postela)](#the-robustness-principle-postels-law)
+    - [SOLIDNY](#solid)
+    - [Zasada pojedynczej odpowiedzialności](#the-single-responsibility-principle)
+    - [Zasada otwarcia/zamknięcia](#the-openclosed-principle)
+    - [Zasada substytucji Liskov](#the-liskov-substitution-principle)
+    - [Zasada segregacji interfejsów](#the-interface-segregation-principle)
+    - [Zasada odwrócenia zależności](#the-dependency-inversion-principle)
+    - [Zasada SUSZENIA](#the-dry-principle)
+    - [Zasada KISS](#the-kiss-principle)
+    - [YAGNI](#yagni)
+    - [Błędy przetwarzania rozproszonego](#the-fallacies-of-distributed-computing)
+- [Lista rzeczy do przeczytania](#reading-list)
+- [Zasoby online](#online-resources)
+- [eBook w formacie PDF](#pdf-ebook)
+- [Podcast](#podcast)
+- [Tłumaczenia](#translations)
+- [Powiązane projekty](#related-projects)
+- [Przyczynianie się](#contributing)
+- [DO ZROBIENIA](#todo)
+
+<!-- vim-markdown-toc -->
+
+## Wstęp
+
+Istnieje wiele praw, o których ludzie dyskutują, mówiąc o rozwoju. To repozytorium jest odniesieniem i przeglądem niektórych z najczęstszych. Podziel się i prześlij PR!
+
+Odpowiedź: To repozytorium zawiera wyjaśnienie niektórych praw, zasad i wzorców, ale nie *zaleca* żadnego z nich. To, czy należy je zastosować, zawsze będzie kwestią dyskusyjną i w dużej mierze zależy od tego, nad czym pracujesz.
+
+## Prawa
+
+No to zaczynamy!
+
+### Zasada 90-9-1 (zasada 1%)
+
+[Reguła 1% na Wikipedii](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
+
+Zasada 90-9-1 sugeruje, że w społeczności internetowej, takiej jak wiki, 90% uczestników tylko korzysta z treści, 9% edytuje lub modyfikuje treść, a 1% uczestników dodaje treść.
+
+Przykłady ze świata rzeczywistego:
+
+- Badanie z 2014 roku czterech cyfrowych portali społecznościowych poświęconych zdrowiu wykazało, że 1% najpopularniejszych tworzy 73% postów, kolejne 9% stanowiło średnio ~25%, a pozostałe 90% stanowiło średnio 2% ( [Odniesienie](https://www.jmir.org/2014/2/e33/) )
+
+Zobacz też:
+
+- [Zasada Pareto](#the-pareto-principle-the-8020-rule)
+
+### Prawo Amdahla
+
+[Prawo Amdahla na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Amdahla)
+
+> Prawo Amdahla to wzór pokazujący *potencjalne przyspieszenie* zadania obliczeniowego, które można osiągnąć zwiększając zasoby systemu. Zwykle używany w obliczeniach równoległych, może przewidzieć rzeczywiste korzyści ze zwiększenia liczby procesorów, co jest ograniczone przez możliwość równoległości programu.
+
+Najlepiej zilustrowane przykładem. Jeśli program składa się z dwóch części, części A, która musi być wykonywana przez pojedynczy procesor, i części B, która może być zrównoleglona, to widzimy, że dodanie wielu procesorów do systemu wykonującego program może mieć tylko ograniczoną korzyść . Potencjalnie może znacznie poprawić prędkość części B - ale prędkość części A pozostanie niezmieniona.
+
+Poniższy diagram pokazuje kilka przykładów potencjalnej poprawy szybkości:
+
+<img width="480px" alt="Schemat: Prawo Amdahla" src="/images/amdahls_law.png" />
+
+*(Odniesienie do obrazu: Daniels219 z angielskiej Wikipedii, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*
+
+Jak widać, nawet program, który można zrównoleglać w 50%, przyniesie niewiele korzyści poza 10 jednostkami przetwarzania, podczas gdy program, który można zrównolelizować w 95%, nadal może osiągnąć znaczną poprawę szybkości przy ponad tysiącu jednostek przetwarzania.
+
+Ponieważ [prawo Moore'a](#moores-law) zwalnia, a przyspieszenie szybkości poszczególnych procesorów zwalnia, równoległość jest kluczem do poprawy wydajności. Programowanie graficzne jest doskonałym przykładem - przy nowoczesnych obliczeniach opartych na Shader, pojedyncze piksele lub fragmenty mogą być renderowane równolegle - dlatego współczesne karty graficzne często mają wiele tysięcy rdzeni przetwarzających (GPU lub Shader Units).
+
+Zobacz też:
+
+- [Prawo Brooksa](#brooks-law)
+- [prawo Moore'a](#moores-law)
+
+### Teoria zepsutych okien
+
+[Teoria rozbitycg okien na Wikipedii](https://pl.wikipedia.org/wiki/Teoria_rozbitych_okien)
+
+Teoria rozbitych okien sugeruje, że widoczne oznaki przestępczości (lub braku dbałości o środowisko) prowadzą do kolejnych i poważniejszych przestępstw (lub dalszego pogorszenia stanu środowiska).
+
+Teoria ta została zastosowana do rozwoju oprogramowania, co sugeruje, że kod niskiej jakości (lub [dług techniczny](#TODO) ) może prowadzić do przekonania, że wysiłki na rzecz poprawy jakości mogą być ignorowane lub niedoceniane, co prowadzi do dalszej złej jakości kodu. Ten efekt kaskadowo prowadzi do znacznego spadku jakości z biegiem czasu.
+
+Zobacz też:
+
+- [Dług techniczny](#TODO)
+
+Przykłady:
+
+- [Programowanie pragmatyczne: entropia oprogramowania](https://flylib.com/books/en/1.315.1.15/1/)
+- [Horror kodowania: teoria rozbitego okna](https://blog.codinghorror.com/the-broken-window-theory/)
+- [OpenSource: Radość z programowania — teoria rozbitego okna](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)
+
+### Prawo Brooksa
+
+[Prawo Brooksa na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Brooksa)
+
+> Dodanie zasobów ludzkich do spóźnionego projektu rozwoju oprogramowania sprawia, że jest to później.
+
+Prawo to sugeruje, że w wielu przypadkach próba przyspieszenia realizacji projektu, który jest już spóźniony, poprzez dodanie większej liczby osób, spowoduje, że realizacja będzie jeszcze późniejsza. Brooks nie ma wątpliwości, że jest to nadmierne uproszczenie, jednak ogólne rozumowanie jest takie, że biorąc pod uwagę czas narastania nowych zasobów i ogólne koszty komunikacji, w krótkim czasie prędkość spada. Ponadto wiele zadań może nie być podzielnych, tj. łatwo rozdzielonych między więcej zasobów, co oznacza, że potencjalny wzrost prędkości jest również mniejszy.
+
+Powszechne zdanie przy porodzie „Dziewięć kobiet nie może spłodzić dziecka w ciągu jednego miesiąca” odnosi się do prawa Brooksa, w szczególności do faktu, że niektóre rodzaje pracy nie są podzielne ani równoległe.
+
+Jest to tematem przewodnim książki „ [Miesiąc mitycznego człowieka](#reading-list) ”.
+
+Zobacz też:
+
+- [Marsz śmierci](#todo)
+- [Lista lektur: Miesiąc Mitycznego Człowieka](#reading-list)
+
+### Twierdzenie CAP (Twierdzenie Brewera)
+
+Twierdzenie CAP (zdefiniowane przez Erica Brewera) stwierdza, że w przypadku rozproszonego magazynu danych można uzyskać tylko dwie z trzech następujących gwarancji (co najwyżej):
+
+- Spójność: podczas odczytu danych każde żądanie otrzymuje *najnowsze* dane lub zwracany jest błąd
+- Dostępność: podczas odczytu danych każde żądanie otrzymuje *odpowiedź* bez błędu, bez gwarancji, że są to *najnowsze* dane
+- Tolerancja partycji: gdy dowolna liczba żądań sieciowych między węzłami nie powiedzie się, system nadal działa zgodnie z oczekiwaniami
+
+Sedno rozumowania jest następujące. Nie można zagwarantować, że partycja sieciowa nie wystąpi (zobacz [The Fallacies of Distributed Computing](#the-fallacies-of-distributed-computing) ). Dlatego w przypadku partycji możemy albo anulować operację (zwiększając spójność i zmniejszając dostępność) albo kontynuować (zwiększając dostępność, ale zmniejszając spójność).
+
+Nazwa pochodzi od pierwszych liter gwarancji (spójność, dostępność, tolerancja partycji). Należy pamiętać, że bardzo ważne jest, aby mieć świadomość, że *nie* dotyczy to [*ACID*](#TODO) , który ma inną definicję spójności. Niedawno [opracowano](#TODO) twierdzenie PACELC, które dodaje ograniczenia dotyczące opóźnień i spójności, gdy sieć *nie* jest podzielona na partycje (tj. gdy system działa zgodnie z oczekiwaniami).
+
+Większość nowoczesnych platform bazodanowych potwierdza to twierdzenie pośrednio, oferując użytkownikowi bazy danych opcję wyboru między operacją o wysokiej dostępności (która może obejmować „brudny odczyt”) a operacją wysoce spójną (na przykład „zapis z potwierdzeniem kworum ').
+
+Przykłady ze świata rzeczywistego:
+
+- [Wewnątrz Google Cloud Spanner i twierdzenia CAP](https://cloud.google.com/blog/products/gcp/inside-cloud-spanner-and-the-cap-theorem) – omawia szczegóły działania Cloud Spanner, które na pierwszy rzut oka wydaje się platformą, która ma *wszystkie* gwarancje CAP, ale pod maską jest zasadniczo system CP.
+
+Zobacz też:
+
+- [KWAS](#TODO)
+- [Błędy przetwarzania rozproszonego](#the-fallacies-of-distributed-computing)
+- [PACELC](#TODO)
+
+### Prawo Conwaya
+
+[Prawo Conwaya na Wikipedii](https://en.wikipedia.org/wiki/Conway%27s_law)
+
+Prawo to sugeruje, że granice techniczne systemu będą odzwierciedlać strukturę organizacji. Często mówi się o tym, gdy patrzymy na ulepszenia organizacji. Prawo Conwaya sugeruje, że jeśli organizacja jest podzielona na wiele małych, niepowiązanych ze sobą jednostek, tak będzie tworzone oprogramowanie. Jeśli organizacja jest zbudowana bardziej wokół „branż”, które są zorientowane na funkcje lub usługi, systemy oprogramowania również to odzwierciedlą.
+
+Zobacz też:
+
+- [Model Spotify](#the-spotify-model)
+
+### Prawo Cunninghama
+
+[Prawo Cunninghama na Wikipedii](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
+
+> Najlepszym sposobem na uzyskanie prawidłowej odpowiedzi w Internecie nie jest zadawanie pytań, ale zamieszczenie błędnej odpowiedzi.
+
+Według Stevena McGeady'ego Ward Cunningham poradził mu na początku lat 80.: „Najlepszym sposobem na uzyskanie prawidłowej odpowiedzi w Internecie jest nie zadawanie pytań, ale zamieszczenie złej odpowiedzi”. McGeady nazwał to prawo Cunninghama, chociaż Cunningham zaprzecza własności, nazywając to „błędem”. Chociaż pierwotnie odnosiło się do interakcji w Usenecie, prawo zostało użyte do opisania działania innych społeczności internetowych (np. Wikipedia, Reddit, Twitter, Facebook).
+
+Zobacz też:
+
+- [XKCD 386: „Wezwania do służby”](https://xkcd.com/386/)
+
+### Numer Dunbara
+
+[Numer Dunbara na Wikipedii](https://en.wikipedia.org/wiki/Dunbar%27s_number)
+
+„Liczba Dunbara jest sugerowanym limitem poznawczym liczby osób, z którymi można utrzymywać stabilne relacje społeczne – relacje, w których jednostka wie, kim jest każda osoba i jak każda osoba odnosi się do każdej innej osoby”. Istnieje pewna niezgodność co do dokładnej liczby. „... [Dunbar] zaproponował, że ludzie mogą wygodnie utrzymywać tylko 150 stabilnych związków”. Umieścił tę liczbę w bardziej społecznym kontekście, „liczbę osób, których nie czulibyście się zawstydzeni dołączeniem do nieproszonych drinków, gdybyście wpadli na nich w barze”. Szacunki dotyczące liczby wahają się od 100 do 250.
+
+Podobnie jak w przypadku stabilnych relacji między jednostkami, utrzymanie relacji programisty z bazą kodu wymaga wysiłku. W obliczu dużych, skomplikowanych projektów lub posiadania wielu projektów opieramy się na konwencji, zasadach i modelowanych procedurach w celu skalowania. Liczba Dunbar jest ważna nie tylko w miarę rozwoju biura, ale także przy ustalaniu zakresu działań zespołu lub decydowaniu, kiedy system powinien zainwestować w narzędzia, które pomogą w modelowaniu i automatyzacji ogólnych kosztów logistycznych. Umieszczając liczbę w kontekście inżynierskim, jest to liczba projektów (lub znormalizowana złożoność pojedynczego projektu), w przypadku których możesz czuć się pewnie, dołączając do rotacji na wezwanie, aby wesprzeć.
+
+Zobacz też:
+
+- [Prawo Conwaya](#conways-law)
+
+### Efekt Dunninga-Krugera
+
+[Efekt Dunninga-Krugera na Wikipedii](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect)
+
+> Jeśli jesteś niekompetentny, nie możesz wiedzieć, że jesteś niekompetentny... Umiejętności potrzebne do uzyskania prawidłowej odpowiedzi to dokładnie te umiejętności, których potrzebujesz, aby rozpoznać, jaka jest właściwa odpowiedź.
+>
+> ( [Dawid Dunning](https://en.wikipedia.org/wiki/David_Dunning) )
+
+Efekt Dunninga-Krugera to teoretyczne zniekształcenie poznawcze, które zostało opisane przez Davida Dunninga i Justina Krugera w badaniu psychologicznym i artykule z 1999 roku. Badanie sugeruje, że osoby o niskim poziomie umiejętności w zadaniu prawdopodobnie przeceniają swoją zdolność do zadania. Proponowaną przyczyną tego nastawienia jest to, że *wymagana jest wystarczająca świadomość* złożoności problemu lub dziedziny, aby osoba była w stanie wyrobić sobie świadomą opinię na temat swojej zdolności do pracy w tej dziedzinie.
+
+Efekt Dunninga-Krugera był czasami używany do opisania powiązanego, ale niekoniecznie dorozumianego efektu, który można opisać jako „Im mniej dana osoba rozumie daną dziedzinę, tym bardziej prawdopodobne jest, że uwierzy, że może łatwo rozwiązać problemy w tej dziedzinie, ponieważ są bardziej skłonni do postrzegania domeny jako *prostej* ”. Ten bardziej ogólny efekt jest bardzo istotny w technologii. Sugerowałoby to, że ludzie mniej zaznajomieni z daną domeną, na przykład nietechniczni członkowie zespołu lub mniej doświadczeni członkowie zespołu, częściej *nie doceniają* wysiłku wymaganego do rozwiązania problemu w tej przestrzeni.
+
+Wraz ze wzrostem zrozumienia i doświadczenia danej osoby w danej domenie, może ona napotkać inny efekt, który polega na tym, że mają tendencję do *przeceniania* zdolności *innych* lub *niedoceniania* własnych zdolności, ponieważ są tak doświadczeni w tej domenie. We wszystkich przypadkach skutki te są *zniekształceniami poznawczymi* . Podobnie jak w przypadku każdego uprzedzenia, zrozumienie, że może ono być obecne, często wystarczy, aby uniknąć wyzwań – ponieważ gdy istnieje świadomość uprzedzenia, można uwzględnić więcej danych wejściowych i opinii, aby spróbować wyeliminować te uprzedzenia. Ściśle pokrewnym jest nastawienie [iluzorycznej wyższości](https://pl.wikipedia.org/wiki/Z%C5%82udzenie_ponadprzeci%C4%99tno%C5%9Bci) .
+
+Przykłady ze świata rzeczywistego:
+
+- [Apple kontra FBI: Dlaczego ten Anti-Terror Hawk zmienił strony](https://fortune.com/2016/03/10/apple-fbi-lindsay-graham/) – w 2016 roku senator Lindsey Graham zmienił swoje stanowisko wobec Apple, tworząc „tylne drzwi” w szyfrowaniu urządzeń. Początkowo Graham był krytyczny wobec Apple kwestionującego prośbę o stworzenie „tylnych drzwi”, które uważał za konieczne do zbadania potencjalnych spisków terrorystycznych. Jednak, jak sam przyznał Graham, gdy dowiedział się więcej o technicznej złożoności tej domeny, zdał sobie sprawę, że założył, iż jest ona o wiele prostsza, niż sądził, i że takie tylne drzwi mogą mieć poważne negatywne konsekwencje. Potencjalnie można to uznać za przykład efektu Dunninga-Krugera – ekspert ds. cyberbezpieczeństwa prawdopodobnie natychmiast zrozumie, w jaki sposób można wykorzystać takie tylne drzwi, ponieważ mają dogłębne zrozumienie domeny, laik może założyć, że zabezpieczenia telefonu są bardziej podobne do *bezpieczeństwa fizycznego,* gdzie praktyka posiadania „klucza głównego” dla organów ścigania jest możliwa, ale ta analogia nie ma wystarczającego zastosowania do opisania współczesnego szyfrowania w cyberbezpieczeństwie.
+
+### Prawo Fittsa
+
+[Prawo Fittsa na Wikipedii](https://pl.wikipedia.org/wiki/Prawo_Fittsa)
+
+Prawo Fittsa przewiduje, że czas potrzebny do przemieszczenia się do obszaru docelowego jest funkcją odległości do celu podzielonej przez szerokość celu.
+
+<img width="300px" alt="Schemat: Prawo dopasowania" src="/images/Fitts_Law.svg">
+
+*(Odniesienie do obrazu: Foobar628 z angielskiej Wikipedii, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Fitts%27s_law#/media/File:Fitts_Law.svg)*
+
+Konsekwencje tego prawa nakazują, aby przy projektowaniu UX czy UI elementy interaktywne były jak największe, a odległość między obszarem uwagi użytkownika a elementem interaktywnym była jak najmniejsza. Ma to konsekwencje dla projektu, takie jak grupowanie zadań, które są często używane blisko siebie.
+
+Formalizuje również koncepcję „magicznych rogów”, rogów ekranu, do których użytkownik może „przesuwać” myszą, aby łatwo trafić – czyli tam, gdzie można umieścić kluczowe elementy interfejsu użytkownika. Przycisk Start systemu Windows znajduje się w magicznym rogu, co ułatwia wybór, a jako interesujący kontrast, przycisk „zamknij okno” systemu MacOS *nie* znajduje się w magicznym rogu, co utrudnia przypadkowe trafienie.
+
+Zobacz też:
+
+- [Zdolność informacyjna układu ruchu człowieka w sterowaniu amplitudą ruchu.](https://www.semanticscholar.org/paper/The-information-capacity-of-the-human-motor-system-Fitts/634c9fde5f1c411e4487658ac738dcf18d98ea8d)
+
+### Prawo Galla
+
+[Prawo Galla na Wikipedii](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
+
+> Niezmiennie okazuje się, że złożony system, który działa, wyewoluował z prostego systemu, który działał. Złożony system zaprojektowany od podstaw nigdy nie działa i nie można go załatać, aby działał. Musisz zacząć od nowa z działającym prostym systemem.
+>
+> ( [John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)) )
+
+Prawo Galla sugeruje, że próby *zaprojektowania* bardzo złożonych systemów mogą się nie powieść. Bardzo złożone systemy rzadko są budowane za jednym razem, ale zamiast tego ewoluują z prostszych systemów.
+
+Klasycznym przykładem jest sieć ogólnoświatowa. W obecnym stanie jest to bardzo złożony system. Jednak początkowo został zdefiniowany jako prosty sposób udostępniania treści między instytucjami akademickimi. Odniósł duży sukces w realizacji tych celów i z czasem ewoluował, by stać się bardziej złożony.
+
+Zobacz też:
+
+- [KISS (Keep It Simple, Stupid)](#the-kiss-principle)
+
+### Prawo Goodharta
+
+[Prawo Goodharta na Wikipedii](https://en.wikipedia.org/wiki/Goodhart's_law)
+
+> Jakakolwiek zaobserwowana prawidłowość statystyczna będzie miała tendencję do załamania się, gdy zostanie na nią nałożona presja w celach kontrolnych.
+>
+> *Karola Goodharta*
+
+Również powszechnie określany jako:
+
+> Kiedy miara staje się celem, przestaje być dobrą miarą.
+>
+> *Marilyn Strathern*
+
+Prawo stanowi, że optymalizacje oparte na pomiarach mogą prowadzić do dewaluacji samego wyniku pomiaru. Nadmiernie selektywny zestaw miar ( [KPI](https://en.wikipedia.org/wiki/Performance_indicator) ) zastosowany na ślepo do procesu powoduje zniekształcony efekt. Ludzie mają tendencję do optymalizacji lokalnie, „ogrywając” system w celu spełnienia określonych wskaźników, zamiast zwracać uwagę na całościowy wynik swoich działań.
+
+Przykłady ze świata rzeczywistego:
+
+- Testy bez asertywności spełniają oczekiwania dotyczące pokrycia kodu, mimo że intencją metryki było stworzenie dobrze przetestowanego oprogramowania.
+- Wynik wydajności programisty wskazywany przez liczbę zatwierdzonych wierszy prowadzi do nieuzasadnionego rozdęcia bazy kodu.
+
+Zobacz też:
+
+- [Prawo Goodharta: jak mierzenie niewłaściwych rzeczy prowadzi do niemoralnych zachowań](https://coffeeandjunk.com/goodharts-campbells-law/)
+- [Dilbert o oprogramowaniu wolnym od błędów](https://dilbert.com/strip/1995-11-13)
+
+### Brzytwa Hanlona
+
+[Brzytwa Hanlona na Wikipedii](https://en.wikipedia.org/wiki/Hanlon%27s_razor)
+
+> Nigdy nie przypisuj złośliwości tego, co adekwatnie tłumaczy się głupotą.
+>
+> Robert J. Hanlon
+
+Zasada ta sugeruje, że działania prowadzące do negatywnych skutków nie były wynikiem złej woli. Zamiast tego negatywny wynik jest bardziej prawdopodobnie przypisywany tym działaniom i/lub wpływowi, który nie jest w pełni zrozumiały.
+
+### Prawo Hicka (Prawo Hicka-Hymana)
+
+[Prawo Hicka na Wikipedii](https://en.wikipedia.org/wiki/Hick%27s_law)
+
+> Czas podejmowania decyzji rośnie logarytmicznie wraz z liczbą opcji do wyboru.
+>
+> William Edmund Hick i Ray Hyman
+
+W poniższym równaniu `T` to czas na podjęcie decyzji, `n` to liczba opcji, a `b` to stała określona na podstawie analizy danych.
+
+![Prawo Hicksa](/images/hicks_law.svg)
+
+*(Odniesienie do obrazu: Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/Hick%27s_law)*
+
+To prawo ma zastosowanie tylko wtedy, gdy liczba opcji jest *uporządkowana* , na przykład alfabetycznie. Jest to implikowane w logarytmie o podstawie dwa, co oznacza, że osoba podejmująca decyzje zasadniczo przeprowadza *wyszukiwanie binarne* . Jeśli opcje nie są dobrze uporządkowane, eksperymenty pokazują, że czas potrzebny jest liniowy.
+
+Ma to znaczący wpływ na projektowanie interfejsu użytkownika; zapewnienie, że użytkownicy mogą łatwo przeszukiwać opcje, prowadzi do szybszego podejmowania decyzji.
+
+W prawie Hicka wykazano również korelację między IQ a czasem reakcji, jak pokazano w [Speed of Information Processing: Developmental Change and Links to Intelligence](https://www.sciencedirect.com/science/article/pii/S0022440599000369) .
+
+Zobacz też:
+
+- [Prawo Fittsa](#fitts-law)
+
+### Prawo Hofstadtera
+
+[Prawo Hofstadtera na Wikipedii](https://en.wikipedia.org/wiki/Hofstadter%27s_law)
+
+> Zawsze trwa to dłużej niż się spodziewasz, nawet biorąc pod uwagę prawo Hofstadtera.
+>
+> (Douglas Hofstadter)
+
+Możesz usłyszeć to prawo, o którym mowa, patrząc na szacunki, jak długo coś potrwa. Wydaje się truizmem w tworzeniu oprogramowania, że nie jesteśmy zbyt dobrzy w dokładnym szacowaniu, ile czasu zajmie dostarczenie czegoś.
+
+To jest z książki ' [Gödel, Escher, Bach: Wieczny złoty warkocz](#reading-list) '.
+
+Zobacz też:
+
+- [Lista lektur: Gödel, Escher, Bach: wieczny złoty warkocz](#reading-list)
+
+### Prawo Hutbera
+
+[Prawo Hutbera na Wikipedii](https://en.wikipedia.org/wiki/Hutber%27s_law)
+
+> Poprawa oznacza pogorszenie.
+>
+> ( [Patryk Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber) )
+
+To prawo sugeruje, że ulepszenia systemu doprowadzą do pogorszenia innych części lub ukryją inne pogorszenie, prowadząc ogólnie do degradacji obecnego stanu systemu.
+
+Na przykład, zmniejszenie opóźnienia odpowiedzi dla określonego punktu końcowego może spowodować dalsze problemy z przepustowością i pojemnością w przepływie żądań, wpływając na zupełnie inny podsystem.
+
+### Cykl szumu i prawo Amary
+
+[Cykl szumu na Wikipedii](https://en.wikipedia.org/wiki/Hype_cycle)
+
+> Mamy tendencję do przeceniania wpływu technologii na krótką metę i niedoceniania jej na dłuższą metę.
+>
+> (Roy Amara)
+
+Hype Cycle to wizualna reprezentacja ekscytacji i rozwoju technologii na przestrzeni czasu, pierwotnie wyprodukowana przez firmę Gartner. Najlepiej pokazać to za pomocą wizualizacji:
+
+![Cykl szumu](/images/gartner_hype_cycle.png)
+
+*(Odniesienie do obrazu: Jeremykemp z angielskiej Wikipedii, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*
+
+Krótko mówiąc, ten cykl sugeruje, że nowa technologia i jej potencjalny wpływ zwykle budzi ogromne zainteresowanie. Zespoły często szybko wskakują w te technologie i czasami są rozczarowane wynikami. Może to być spowodowane tym, że technologia nie jest jeszcze wystarczająco dojrzała lub aplikacje w świecie rzeczywistym nie są jeszcze w pełni zrealizowane. Po pewnym czasie zwiększają się możliwości technologii i praktyczne możliwości jej wykorzystania, a zespoły mogą wreszcie stać się produktywne. Cytat Roya Amary podsumowuje to w najbardziej zwięzły sposób: „Mamy tendencję do przeceniania wpływu technologii na krótką metę i niedoceniania na dłuższą metę".
+
+### Prawo Hyruma (prawo niejawnych interfejsów)
+
+[Prawo Hyruma w Internecie](http://www.hyrumslaw.com/)
+
+> Przy wystarczającej liczbie użytkowników API nie ma znaczenia, co obiecujesz w kontrakcie: wszystkie obserwowalne zachowania Twojego systemu będą przez kogoś zależne.
+>
+> (Hyrum Wright)
+
+Prawo Hyrum stanowi, że gdy masz *wystarczająco dużą liczbę konsumentów* API, wszystkie zachowania API (nawet te, które nie są zdefiniowane jako część umowy publicznej) w końcu staną się przez kogoś zależne. Trywialnym przykładem mogą być elementy niefunkcjonalne, takie jak czas odpowiedzi API. Bardziej subtelnym przykładem mogą być konsumenci, którzy polegają na zastosowaniu wyrażenia regularnego do komunikatu o błędzie w celu określenia *typu* błędu interfejsu API. Nawet jeśli kontrakt publiczny interfejsu API nie mówi nic o zawartości komunikatu, wskazując, że użytkownicy powinni użyć powiązanego kodu błędu, *niektórzy* użytkownicy mogą korzystać z komunikatu, a zmiana komunikatu zasadniczo przerywa interfejs API dla tych użytkowników.
+
+Zobacz też:
+
+- [Prawo nieszczelnych abstrakcji](#the-law-of-leaky-abstractions)
+- [XKCD 1172](https://xkcd.com/1172/)
+
+### Prawo Kernighana
+
+> Debugowanie jest dwa razy trudniejsze niż pisanie kodu. Dlatego, jeśli piszesz kod tak sprytnie, jak to tylko możliwe, z definicji nie jesteś wystarczająco sprytny, aby go debugować.
+>
+> (Brian Kernighan)
+
+Prawo Kernighana zostało nazwane na cześć [Briana Kernighana](https://en.wikipedia.org/wiki/Brian_Kernighan) i pochodzi z cytatu z książki Kernighana i Plaugera „ [Elementy stylu programowania”](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style) :
+
+> Każdy wie, że debugowanie jest dwa razy trudniejsze niż pisanie programu. Więc jeśli jesteś tak sprytny, jak potrafisz, kiedy to piszesz, jak możesz to kiedykolwiek debugować?
+
+Choć hiperboliczne, prawo Kernighana przedstawia argument, że prosty kod ma być lepszy od kodu złożonego, ponieważ debugowanie wszelkich problemów pojawiających się w kodzie złożonym może być kosztowne lub nawet niemożliwe.
+
+Zobacz też:
+
+- [Zasada KISS](#the-kiss-principle)
+- [Filozofia Uniksa](#the-unix-philosophy)
+- [Brzytwa Ockhama](#occams-razor)
+
+### Prawo Linusa
+
+[Prawo Linusa na Wikipedii](https://en.wikipedia.org/wiki/Linus%27s_law)
+
+> Biorąc pod uwagę wystarczającą liczbę gałek ocznych, wszystkie błędy są płytkie.
+>
+> *Eric S. Raymond*
+
+To prawo po prostu mówi, że im więcej ludzi widzi problem, tym większe prawdopodobieństwo, że ktoś już wcześniej widział i rozwiązał problem lub coś bardzo podobnego.
+
+Chociaż pierwotnie był używany do opisywania wartości modeli open-source dla projektów, może być zaakceptowany dla każdego rodzaju projektu oprogramowania. Można go również rozszerzyć na procesy - więcej przeglądów kodu, więcej statycznej analizy i wielobranżowe procesy testowe sprawią, że problemy będą bardziej widoczne i łatwiejsze do zidentyfikowania.
+
+Bardziej formalnym oświadczeniem może być:
+
+> Mając wystarczająco dużą bazę beta-testerów i programistów, prawie każdy problem zostanie szybko scharakteryzowany i może zostać rozwiązany przez kogoś, kto już wcześniej spotkał się z podobnym problemem.
+
+Prawo to zostało nazwane na cześć [Linusa Torvaldsa](https://en.wikipedia.org/wiki/Linus_Torvalds) w książce Erica S. Raymonda „ [Katedra i bazar](https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar) ”.
+
+### Prawo Metcalfego
+
+[Prawo Metcalfe'a na Wikipedii](https://en.wikipedia.org/wiki/Metcalfe's_law)
+
+> W teorii sieci wartość systemu rośnie w przybliżeniu do kwadratu liczby użytkowników systemu.
+
+Prawo to opiera się na liczbie możliwych połączeń parami w systemie i jest ściśle związane [z prawem Reeda](#reeds-law) . Odlyzko i inni argumentowali, że zarówno prawo Reeda, jak i prawo Metcalfe'a zawyżają wartość systemu, nie uwzględniając granic ludzkiego poznania na efektach sieciowych; zobacz [Numer Dunbara](#dunbars-number) .
+
+Zobacz też:
+
+- [Prawo Reeda](#reeds-law)
+- [Numer Dunbara](#dunbars-number)
+
+### prawo Moore'a
+
+[Prawo Moore'a na Wikipedii](https://en.wikipedia.org/wiki/Moore%27s_law)
+
+> Liczba tranzystorów w układzie scalonym podwaja się mniej więcej co dwa lata.
+
+Prognozy Moore'a, często używane do zilustrowania szybkości, z jaką poprawiła się technologia półprzewodników i chipów, okazały się bardzo dokładne w okresie od lat 70. do późnych lat 2000. W ostatnich latach trend nieznacznie się zmienił, częściowo ze względu na [fizyczne ograniczenia dotyczące stopnia miniaturyzacji komponentów](https://en.wikipedia.org/wiki/Quantum_tunnelling) . Jednak postępy w zrównoleglaniu i potencjalnie rewolucyjne zmiany w technologii półprzewodnikowej i obliczeniach kwantowych mogą oznaczać, że prawo Moore'a może nadal obowiązywać przez dziesięciolecia.
+
+### Prawo Murphy'ego / Prawo Soda
+
+[Prawo Murphy'ego na Wikipedii](https://en.wikipedia.org/wiki/Murphy%27s_law)
+
+> Wszystko, co może pójść nie tak, pójdzie nie tak.
+
+Powiązane z [Edwardem A. Murphym, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) *Murphy's Law* stwierdza, że jeśli coś może pójść nie tak, to pójdzie nie tak.
+
+To powszechne powiedzenie wśród programistów. Czasami nieoczekiwane dzieje się podczas tworzenia, testowania, a nawet produkcji. Może to być również związane z (bardziej powszechnym w brytyjskim angielskim) *Prawie Soda* :
+
+> Jeśli coś może pójść nie tak, to w najgorszym możliwym momencie.
+
+Te „prawa” są na ogół używane w komicznym sensie. Jednak zjawiska takie jak błąd [*potwierdzenia*](#TODO) i błąd [*selekcji*](#TODO) mogą skłaniać ludzi do nadmiernego podkreślania tych praw (w większości przypadków, gdy coś działa, pozostają niezauważone, jednak niepowodzenia są bardziej zauważalne i wywołują więcej dyskusji).
+
+Zobacz też:
+
+- [Błąd potwierdzenia](#TODO)
+- [Odchylenie selekcji](#TODO)
+
+### Brzytwa Ockhama
+
+[Brzytwa Ockhama na Wikipedii](https://en.wikipedia.org/wiki/Occam's_razor)
+
+> Nie należy mnożyć jednostek bez konieczności.
+>
+> Wilhelm z Ockhama
+
+Brzytwa Ockhama mówi, że spośród kilku możliwych rozwiązań najbardziej prawdopodobnym rozwiązaniem jest to, które ma najmniejszą liczbę koncepcji i założeń. To rozwiązanie jest najprostsze i rozwiązuje tylko zadany problem, bez wprowadzania przypadkowych złożoności i ewentualnych negatywnych konsekwencji.
+
+Zobacz też:
+
+- [YAGNI](#yagni)
+- [Brak srebrnej kuli: przypadkowa złożoność i zasadnicza złożoność](https://en.wikipedia.org/wiki/No_Silver_Bullet)
+
+Przykład:
+
+- [Rozwój oprogramowania szczupłego: eliminuj marnotrawstwo](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
+
+### Prawo Parkinsona
+
+[Prawo Parkinsona na Wikipedii](https://en.wikipedia.org/wiki/Parkinson%27s_law)
+
+> Praca rozwija się tak, aby wypełnić czas dostępny na jej wykonanie.
+
+W swoim pierwotnym kontekście ustawa ta opierała się na badaniach biurokracji. Można to pesymistycznie zastosować do inicjatyw rozwoju oprogramowania, zgodnie z teorią, że zespoły będą nieefektywne do czasu, gdy zbliżają się terminy, a następnie spieszą się, aby ukończyć pracę w terminie, co sprawia, że rzeczywisty termin jest nieco arbitralny.
+
+Gdyby to prawo zostało połączone z prawem [Hofstadtera](#hofstadters-law) , osiągnięto jeszcze bardziej pesymistyczny punkt widzenia - praca rozszerzy się, aby wypełnić czas dostępny na jej ukończenie i *nadal będzie trwać dłużej niż oczekiwano* .
+
+Zobacz też:
+
+- [Prawo Hofstadtera](#hofstadters-law)
+
+### Przedwczesny efekt optymalizacji
+
+[Przedwczesna optymalizacja na WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
+
+> Przedwcześnie optymalizacja jest źródłem wszelkiego zła.
+>
+> [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
+
+W artykule Donald Knuth's [Structured Programming with Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) napisał: „Programiści marnują ogromne ilości czasu na myślenie lub martwienie się o szybkość niekrytycznych części swoich programów, a te próby wydajności mają naprawdę silny negatywny wpływ podczas debugowania i konserwacja są brane pod uwagę. Powinniśmy zapomnieć o małych wydajnościach, powiedzmy w 97% przypadków: **przedwczesna optymalizacja jest źródłem wszelkiego zła** . Jednak nie powinniśmy przepuszczać naszych możliwości w tych krytycznych 3%.”
+
+Jednak *przedwczesną optymalizację* można zdefiniować (w mniej obciążonych terminach) jako optymalizację, zanim zorientujemy się, że jest to konieczne.
+
+### Prawo Putta
+
+[Prawo Putta na Wikipedii](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat)
+
+> Technologia jest zdominowana przez dwa typy ludzi, tych, którzy rozumieją to, czym nie zarządzają, i tych, którzy zarządzają tym, czego nie rozumieją.
+
+Po prawie Putta często następuje następstwo Putta:
+
+> Każda hierarchia techniczna z czasem rozwija inwersję kompetencji.
+
+Stwierdzenia te sugerują, że ze względu na różne kryteria selekcji i trendy w organizacji grup, na szczeblach pracy organizacji technicznych znajdzie się pewna liczba wykwalifikowanych osób oraz pewna liczba osób na stanowiskach kierowniczych, które nie są świadome złożoności i wyzwań związanych z pracę, którą zarządzają. Może to być spowodowane zjawiskami takimi jak [Zasada Petera](#the-peter-principle) lub [Zasada Dilberta](#the-dilbert-principle) .
+
+Należy jednak podkreślić, że takie przepisy są szerokimi uogólnieniami i mogą mieć zastosowanie do *niektórych* typów organizacji, a nie do innych.
+
+Zobacz też:
+
+- [Zasada Piotra](#the-peter-principle)
+- [Zasada Dilberta](#the-dilbert-principle)
+
+### Prawo Reeda
+
+[Prawo Reeda na Wikipedii](https://en.wikipedia.org/wiki/Reed's_law)
+
+> Użyteczność dużych sieci, w szczególności sieci społecznościowych, rośnie wykładniczo wraz z rozmiarem sieci.
+
+Prawo to opiera się na teorii grafów, gdzie użyteczność skaluje się jako liczba możliwych podgrup, czyli szybciej niż liczba uczestników lub liczba możliwych połączeń parami. Odlyzko i inni argumentowali, że prawo Reeda zawyża użyteczność systemu, nie uwzględniając ograniczeń ludzkiego poznania w zakresie efektów sieciowych; zobacz [Numer Dunbara](#dunbars-number) .
+
+Zobacz też:
+
+- [Prawo Metcalfego](#metcalfes-law)
+- [Numer Dunbara](#dunbars-number)
+
+### Prawo zachowania złożoności (prawo Teslera)
+
+[Prawo zachowania złożoności na Wikipedii](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity)
+
+Prawo to mówi, że w systemie występuje pewna złożoność, której nie można zredukować.
+
+Pewna złożoność systemu jest „nieumyślna”. Jest to konsekwencja złej struktury, błędów lub po prostu złego zamodelowania problemu do rozwiązania. Przypadkową złożoność można zmniejszyć (lub wyeliminować). Jednak pewna złożoność jest „wewnętrzna” jako konsekwencja złożoności nieodłącznie związanej z rozwiązywanym problemem. Tę złożoność można przenieść, ale nie można jej wyeliminować.
+
+Ciekawym elementem tego prawa jest sugestia, że nawet uproszczenie całego systemu nie zmniejsza wewnętrznej złożoności, lecz *przenosi się na użytkownika* , który musi zachowywać się w bardziej złożony sposób.
+
+### Prawo Demeter
+
+[Prawo Demeter na Wikipedii](https://en.wikipedia.org/wiki/Law_of_Demeter)
+
+> Nie rozmawiaj z nieznajomymi.
+
+Prawo Demeter, znane również jako „zasada najmniejszej wiedzy”, jest zasadą projektowania oprogramowania, szczególnie istotną w językach obiektowych.
+
+Stwierdza, że jednostka oprogramowania powinna rozmawiać tylko ze swoimi bezpośrednimi współpracownikami. Obiekt `A` z odwołaniem do obiektu `B` może wywoływać swoje metody, ale jeśli `B` ma odwołanie do obiektu `C` , `A` nie powinien wywoływać `C` s. Tak więc, jeśli `C` ma `doThing()` , `A` nie powinien wywoływać jej bezpośrednio; `B.getC().doThis()` .
+
+Przestrzeganie tej zasady ogranicza zakres zmian, czyniąc je łatwiejszymi i bezpieczniejszymi w przyszłości.
+
+### Prawo nieszczelnych abstrakcji
+
+[Prawo nieszczelnych abstrakcji dotyczących Joela na oprogramowaniu](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/)
+
+> Wszystkie nietrywialne abstrakcje są do pewnego stopnia nieszczelne.
+>
+> ( [Joel Spolsky](https://twitter.com/spolsky) )
+
+Prawo to stanowi, że abstrakcje, które są zwykle używane w obliczeniach w celu uproszczenia pracy ze skomplikowanymi systemami, w pewnych sytuacjach „wyciekają” elementy systemu bazowego, co powoduje, że abstrakcja zachowuje się w nieoczekiwany sposób.
+
+Przykładem może być wczytanie pliku i odczytanie jego zawartości. Interfejsy API systemu plików są *abstrakcją* systemów jądra niższego poziomu, które same w sobie są abstrakcją fizycznych procesów związanych ze zmianą danych na talerzu magnetycznym (lub pamięci flash w przypadku dysku SSD). W większości przypadków zadziała abstrakcja traktowania pliku jako strumienia danych binarnych. Jednak w przypadku dysku magnetycznego sekwencyjny odczyt danych będzie *znacznie* szybszy niż dostęp losowy (ze względu na zwiększony narzut błędów stron), ale w przypadku dysku SSD ten narzut nie będzie obecny. Aby poradzić sobie z tym przypadkiem, należy zrozumieć podstawowe szczegóły (na przykład pliki indeksu bazy danych są skonstruowane tak, aby zmniejszyć obciążenie losowego dostępu), szczegóły implementacji „przecieków” abstrakcji, o których programista może być świadomy.
+
+Powyższy przykład może stać się bardziej złożony, gdy zostanie wprowadzonych *więcej abstrakcji.* System operacyjny Linux umożliwia dostęp do plików przez sieć, ale reprezentowane lokalnie jako „normalne” pliki. Ta abstrakcja „przecieka” w przypadku awarii sieci. Jeśli programista traktuje te pliki jako „normalne” pliki, nie biorąc pod uwagę faktu, że mogą one podlegać opóźnieniom i awariom sieci, rozwiązania będą zawierały błędy.
+
+Artykuł opisujący prawo sugeruje, że nadmierne poleganie na abstrakcjach w połączeniu ze słabym zrozumieniem procesów leżących u ich podstaw w rzeczywistości sprawia, że radzenie sobie z danym problemem w niektórych przypadkach *staje się bardziej złożone.*
+
+Zobacz też:
+
+- [Prawo Hyruma](#hyrums-law-the-law-of-implicit-interfaces)
+
+Przykłady ze świata rzeczywistego:
+
+- [Powolne uruchamianie programu Photoshop](https://forums.adobe.com/thread/376152) — problem, który napotkałem w przeszłości. Photoshop uruchamiałby się wolno, czasami zajmując kilka minut. Wydaje się, że problem polegał na tym, że podczas uruchamiania odczytuje informacje o bieżącej domyślnej drukarce. Jeśli jednak ta drukarka jest w rzeczywistości drukarką sieciową, może to zająć bardzo dużo czasu. *Abstrakcja* drukarki sieciowej prezentowanej systemowi podobnie do drukarki lokalnej powodowała problem dla użytkowników w sytuacjach słabej łączności.
+
+### Prawo trywialności
+
+[Prawo trywialności na Wikipedii](https://en.wikipedia.org/wiki/Law_of_triviality)
+
+To prawo sugeruje, że grupy będą poświęcać znacznie więcej czasu i uwagi błahym lub kosmetycznym kwestiom niż poważnym i istotnym.
+
+Powszechnie używanym fikcyjnym przykładem jest komitet zatwierdzający plany elektrowni jądrowej, który spędza większość czasu na omawianiu struktury szopy na rowery, a nie na znacznie ważniejszym projekcie samej elektrowni. Wniesienie wartościowego wkładu w dyskusje na bardzo du