path: root/translations/lv.md

# 💻 📖 hacker-laws

[![gitlocalized](https://gitlocalize.com/repo/2513/whole_project/badge.svg)](https://gitlocalize.com/repo/2513/whole_project?utm_source=badge)

Likumi, teorijas, principi un apraksti, kas izstrādātājiem šķitīs noderīgi.

- 🇨🇳 [中文/Chinese Version](https://github.com/nusr/hacker-laws-zh) - paldies [Steve Xu](https://github.com/nusr)!
- 🇮🇹 [traduzione Italiano](https://github.com/dwmkerr/hacker-laws/blob/master/translations/it-IT.md) - paldies [Claudio Sparpaglione](https://github.com/csparpa)!
- 🇰🇷 [한국어/korejiešu versija](https://github.com/codeanddonuts/hacker-law-kr) - paldies [Doughnut](https://github.com/codeanddonuts)!
- 🇷🇺 [Русская версия/Krievijas versija](https://github.com/solarrust/hacker-laws) - paldies [Alena Batitskaya](https://github.com/solarrust)!
- 🇹🇷 [türkçe/Turkish Version](https://github.com/umutphp/hacker-laws-tr) - paldies [Umut Işık](https://github.com/umutphp)
- 🇧🇷 [Brasileiro/Brazīlijas versija](./translations/pt-BR.md) - paldies [Leonardo Costa](https://github.com/LeoFC97)
- 🇪🇸 [Castellano/Spānijas versija](./translations/es-ES.md) - paldies [Manuel Rubio](https://github.com/manuel-rubio)

Kā šis projekts? Lūdzu, apsveriet iespēju [Sponsoring Me](https://github.com/sponsors/dwmkerr)!

---

<!-- VIM-markdown-toc GFM -->

* [ievads](#introduction)
* [likumi](#laws)
    * [Amdahla likums](#amdahla-likums)
    * [The Broken Windows Theory](#the-broken-windows-theory)
    * [Brūku likums](#bruku-likums)
    * [Konveja likums](#conways-likums)
    * [Kaningemas likums](#cunninghams-likums)
    * [Danbara numurs](#dunbars-numurs)
    * [Galla likums](#galls-likums)
    * [Goodharta likums](#goodharts-likums)
    * [Hanona Razora](#hanlons-razor)
    * [Hofstadtera likums](#hofstadtera-likums)
    * [Hutber's Law](#hutbers-law)
    * [Hype Cycle & Amara's Law](#the-hype-cycle-amaras-law)
    * [Hyruma likums (Perifērisko saskarņu likums)](#hyruma-likums-perifērisko-saskarņu-likums)
    * [Kernigana likums](#Kernigana-likums)
    * [Metkalfa likums](#Metkalfa-likums)
    * [Mora likums](#mora-likums)
    * [Mērfija likums/Soda likums](#murphys-sods-likums)
    * [Occam's Razor](#occams-razor)
    * [Parkinsona likums](#parkinsons-Law)
    * [Priekšlaicīgas optimizēšanas efekts](#premature-optimizēšanas-efekts)
    * [Putt's Law](#putts-law)
    * [Reed's Law](#reeds-law)
    * [Taisnīguma saglabāšanas likums (Teslera likums)](#youth-of-teslers-law-of-conservation-complexity-law)
    * [Leaky Abstractions likums](#the-law-of-dioxide-freshctions)
    * [Trivialitātes likums](#the-law-of-triviality)
    * [Unix Philosophy](#the-unix-philosophy)
    * [Spotify modelis](#the-spotify-model)
    * [Wadler's Law](#wadlers-law)
    * [Wheaton's Law](#wheatons-likums)
* [principi](#principles)
    * [Dilbert princips](#the-dilbert-principle)
    * [Pareto Principle (The 80/20 Rule)](#the-pareto-principle-the-8020-rule)
    * [Peter Principle](#the-peter-principle)
    * [Uzturības princips (Postel's Law)](#the-rorigness-principle-postels-law)
    * [SOLID](#solid)
    * [Vienotās atbildības princips](#the-single-responsibility-principle)
    * [Atklātais/slēgtais princips](#the-openclosed-principle)
    * [Liskova aizstāšanas princips](#the-liskov-substitution-principle)
    * [Interfeisa segmenta noteikšanas princips](#the-interface-segregation-principle)
    * [rights-dependence-inversion-principle](#the-dependent-inversion-principle)
    * [DRY princips](#the-dry-principle)
    * [KISS princips](#the-kiss-principle)
    * [YAGNI](#yagni)
    * [dalītās datošanas Fallacies](#the-fallacies-of-illicit-computing)
* [Lasitaja saraksts](#Lasīšanas-saraksts)
* [Ieguldījums](#Ieguldījums)
* [Uzdevums](#TODO)
    
<!-- VIM-markdown-toc -->

## Ievads

Ir daudz likumu, kurus cilvēki apspriež, runājot par attīstību. Šis repozitorijs ir atsauce un pārskats par dažiem visbiežāk sastopamajiem. Lūdzu, kopīgojiet un iesniedziet PRs!

❗: šis repo satur dažu likumu, principu un modeļu skaidrojumu, bet ne _aizstāv_ nevienam no tiem. Tas, vai tās jāpiemēro, vienmēr būs debašu jautājums un lielā mērā atkarīgs no tā, ar ko jūs strādājat.

## Tiesību akti

Un te nu mēs ejam!

### Amdahl likums

[Amdahl likums par Wikipedia](https://en.wikipedia.org/wiki/Amdahl%27s_law)

> Amdahl likums ir formula, kas parāda skaitļošanas uzdevuma _increedup_, ko var sasniegt, palielinot sistēmas resursus. Parasti izmanto paralēlā skaitļošanā, tā var paredzēt faktisko labumu no procesoru skaita palielināšanas, ko ierobežo programmas paralēliskās iespējas.

Vislabāk ilustrēts ar piemēru. Ja programma sastāv no divām daļām, daļas A, kas jāizpilda vienam procesoram, un daļas B, ko var līdzināt, mēs redzam, ka vairāku procesoru pievienošana sistēmai, kas izpilda programmu, var sniegt tikai ierobežotu labumu. Tas var ievērojami uzlabot B daļas ātrumu, bet daļas a ĀTRUMS paliks nemainīgs.

Turpmāk redzamajā diagrammā ir parādīti daži iespējamo ātruma uzlabojumu piemēri.

<img alt="Diagram: Amdahl's Law" src="../images/amdahls_law.png" width="480px"/>

*(Atsauce uz attēlu: Daniels220 angļu valodā Wikipedia, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)*

Kā redzams, pat programma, kas ir 50% parallelisable, gūs ļoti maz vairāk nekā 10 procesoru vienību, bet programma, kas ir 95% parallelisable, joprojām var sasniegt ievērojamus ātruma uzlabojumus ar vairāk nekā tūkstoš procesoriem.

Tā kā [Moore's Law](#mora-likums) palēninās un individuālā procesora ātruma paātrināšanās palēninās, paralelizācija ir būtiska, lai uzlabotu veiktspēju. Grafikas programmēšana ir lielisks piemērs - ar mūsdienu Shader bāzes skaitļošanu, atsevišķiem pikseļiem vai fragmentiem var renderēt paralēli - tāpēc mūsdienu grafikas kartēs bieži vien ir daudz tūkstošu apstrādes kodolu (GPUs vai Shader Units).

Skatīt arī:

- [Brūku likums](#brooks-likums)
- [Mora likums](#mora-likums)

### Apgrieztās sistēmas teorija

[The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)

“Broken Windows” teorija liecina, ka redzamas nozieguma pazīmes (vai kādas vides rūpju trūkums) noved pie tālākiem un smagākiem noziegumiem (vai tālākas vides pasliktināšanās).

Šī teorija ir izmantota programmatūras izstrādei, kas liek domāt, ka sliktas kvalitātes kods (vai [Technical Debt](#TODO)) var radīt priekšstatu, ka kvalitātes uzlabošanas centieni var tikt ignorēti vai nepietiekami novērtēti, tādējādi radot vēl vairāk sliktas kvalitātes kodu. Šī efekta kaskādes izraisa ievērojamu kvalitātes samazināšanos laika gaitā.

Skatīt arī:

- [Tehniskais parāds](#TODO)

Piemēri:
- [Pracistic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
- [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-break-window-theory/)
- [OpenSource: Joy of Programming - The Broken Window Theory](https://opensourceforu.com/2011/05/joy-of-programming-broken-window-theory/)

### Brūku likums

[Brūku likums par Wikipedia](https://en.wikipedia.org/wiki/Brooks%27s_law)

> Personāla resursu pievienošana vēlākam programmatūras izstrādes projektam to dara vēlāk.

Šis likums liek domāt, ka daudzos gadījumos mēģinājums paātrināt tāda projekta īstenošanu, kas jau ir novēlots, pieskaitot vairāk cilvēku, padarīs piegādi vēl vēlāku. Bruks ir skaidrs, ka tā ir pārmērīga vienkāršošana, tomēr vispārīgie apsvērumi ir tādi, ka, ņemot vērā jaunu resursu ieviešanas laiku un sakaru pieskaitāmās izmaksas, tuvākajā laikā ātrums samazinās. Turklāt daudzi uzdevumi var nebūt dalāmi, t. i., viegli sadalāmi starp lielākiem resursiem, kas nozīmē, ka arī potenciālais ātruma pieaugums ir mazāks.

Izplatītā frāze “Deviņi sievietes nevar dzemdēt bērnu vienā mēnesī” attiecas uz Brūku likumu, jo īpaši uz faktu, ka daži darba veidi nav dalāmi vai parallelisable.

Šī ir grāmatas “[The Mythical Man Monthly](#reading-list)” galvenā tēma.

Skatīt arī:

- [Nāves marts](#TODO)
- [reading List: The Mythical Man Month](#reading saraksts)

### Konveja likums

[Conway's Law on Wikipedia](https://en.wikipedia.org/wiki/Conway%27s_law)

Šis likums paredz, ka sistēmas tehniskās robežas atspoguļos organizācijas struktūru. Parasti tas tiek pieminēts, aplūkojot organizācijas uzlabojumus, Konveja likums liecina, ka, ja organizācija ir strukturēta uz daudzām mazām, atvienotām vienībām, tad tā ražotā programmatūra būs. Ja organizācija ir vairāk izveidota, izmantojot "vertikāles”, kas ir orientētas uz līdzekļiem vai pakalpojumiem, arī programmatūras sistēmas to atspoguļo.

Skatīt arī:

- [Spotify modelis](#the-spotify-model)

### Kaningemas likums

[Kaningemas likums par Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham_likums)

> Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.

Pēc Stīvena McGeady teiktā, Vords Kaningems astoņdesmito gadu sākumā viņam ieteicis: “Labākais veids, kā iegūt pareizo atbildi internetā, ir neuzdot jautājumu, tas ir, izlikt nepareizu atbildi.” Mcgeady šo Kaningemas likumu nodēvēja par “nepatiesu”, lai gan Kaningems to noliedz. Lai gan sākotnēji tas attiecās uz mijiedarbību ar Usenet, likums ir izmantots, lai aprakstītu, kā darbojas citas tiešsaistes kopienas (piemēram, Wikipedia, Reddit, Twitter, Facebook).

Skatīt arī:

- [XKCD 386: “Duty Calls”](https://xkcd.com/386/)

### Danbara numurs

[Danbara numurs on Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)

“Danbara skaitlis ir ieteicams izziņas ierobežojums to cilvēku skaitam, ar kuriem var uzturēt stabilas sociālās attiecības — attiecības, kurās indivīds zina, kas ir katrs cilvēks un kā katrs cilvēks ir saistīts ar katru citu cilvēku.” Ir kādas domstarpības ar precīzu skaitli. “..” “Dunbar” ierosināja, ka cilvēki var mierīgi uzturēt tikai 150 stabilas attiecības.” Viņš ievietoja numuru vairāk sabiedriskā kontekstā, “tik daudz cilvēku, cik jūs nejustos apmulsuši, ka pievienojaties nelūgtam dzērienam, ja jums gadītos ar viņiem ieskrieties bārā.” Aptuvenie skaitļi parasti ir no 100 līdz 250.

Tāpat kā stabilas attiecības starp indivīdiem, arī izstrādātāja attiecības ar kodebīlu prasa pūles uzturēt. Saskaroties ar lieliem sarežģītiem projektiem vai daudzu projektu īpašumtiesībām, mēs paļaujamies uz konvencionālo, politiku un modelēto procedūru mērogu. Danbara numurs ir svarīgs ne tikai biroja izaugsmei, bet arī, nosakot darba grupas darba apjomu vai lemjot par to, kad sistēmai jāiegulda līdzekļi, lai palīdzētu modelēt un automatizēt loģistikas pieskaitāmās izmaksas. Skaitlis tiek iekļauts tehniskā kontekstā, tas ir tādu projektu skaits (vai atsevišķa projekta normalizēta sarežģītība), kuriem jūs justos droši, pievienojoties zvanu rotācijai, lai atbalstītu.

Skatīt arī:

- [Conway's Law](#conways-likums)

### Galla likums

[Galla likums on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(autors)#Gall's_law)

> Salikta sistēmā, kas darbojas, pastāvīgi tiek atrasta, ka tā ir attīstījusies no vienkāršas sistēmas, kas darbojās. Sarežģīta sistēma, kas veidota no nulles, nekad nedarbojas, un to nevar patukšot, lai tā darbotos. Jāsāk ar vienkāršu darba sistēmu.
>
> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(autors)))

Gall likums nozīmē, ka mēģinājumi _izstrādāt_ ļoti sarežģītas sistēmas var neizdoties. Ļoti sarežģītas sistēmas reti tiek veidotas vienā paņēmienā, bet attīstās no vienkāršākām sistēmām.

Klasiskais piemērs ir vispasaules tīmeklis. Pašreizējā stāvoklī tā ir ļoti sarežģīta sistēma. Tomēr sākotnēji tas tika definēts kā vienkāršs veids satura koplietošanai starp akadēmiskajām institūcijām. Tas bija ļoti veiksmīgs šo mērķu sasniegšanā un attīstījās, lai laika gaitā kļūtu sarežģītāks.

Skatīt arī:

- [KISS (keep It Simple, Stupid)](#the-kiss-principle)

### Goodharta likums

[Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)

> jebkura novērotā statistiskā regularitāte var sabrukt, kad uz to tiek izdarīts spiediens kontroles nolūkā.
>
> _Charles Goodhart_

Bieži minēts arī kā:

> kad pasākums kļūst par mērķi, tas vairs nav labs pasākums.
>
> _Merilinas Strathern_

Likums nosaka, ka pasākuma virzītā optimizācija var izraisīt paša mērījumu rezultāta devalvāciju. Pārāk selektīvs pasākumu kopums ([KPI](https://en.wikipedia.org/wiki/Performance_indicator)), ko akli piemēro procesam, rada izkropļotu ietekmi. Cilvēki mēdz optimizēt vietējā līmenī, “spēlējot” sistēmu, lai tā atbilstu īpašiem rādītājiem, nevis pievērstu uzmanību viņu darbību visaptverošajiem rezultātiem.

Reālpasaules piemēri:
- izmēģinājumi bez pārbaudes atbilst koda pārklājuma prognozēm, neskatoties uz to, ka metrikas nolūks bija izveidot labi pārbaudītu programmatūru.
- izstrādātāja snieguma rezultāts, ko norāda veikto rindu skaits, noved pie nepamatoti uzpūstas kodebāzes.

Skatīt arī:

- [Goodhart's Law: How Measuring The Wrong Things Drive Immoral Bemoral haviour](https://coffeeandjunk.com/goodharts-campbells-law/)
- [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)

### Hanlons Razors

[Hanlon's Razor on Wikipedia](https://en.wikipedia.org/wiki/Hanlon%27s_razor)

> nekad nepiedēvē ļaunprātību, kas ir pietiekami izskaidrota ar muļķību.
>
> Roberts J. HanlonsŠis princips liek domāt, ka darbības, kas rada negatīvu rezultātu, nav sliktas gribas rezultāts. Tā vietā negatīvais iznākums drīzāk tiek attiecināts uz šīm darbībām un/vai ietekme netiek pilnībā izprasta.

### Hofstadter's Law

[Hefstadter's Law on Wikipedia](https://en.wikipedia.org/wiki/Hofstadter%27s_law)

> Tas vienmēr aizņem vairāk laika, nekā jūs domājat, pat ņemot vērā Hofštera likumu.
>
> (Duglass Hofstadters)

Jūs varētu dzirdēt, kā šis likums tiek pieminēts, skatoties uz aprēķiniem, cik ilgi kaut kas notiks. Šķiet, ka programmatūras izstrādes triks ir tāds, ka mēs nemēdzam precīzi novērtēt, cik ilgs laiks būs vajadzīgs, lai to paveiktu.

Tas ir no grāmatas “[Gödel, Escher, Bahs: An Mūžīgais Zelta Breidijs](#Lasīšanas-saraksts)”.

Skatīt arī:

- [Lasīšanas saraksts: Gödel, Escher, Baach: An Mūžīgais zelta Breids](#Lasīšanas-saraksts)

### Hutber's Law

[Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)

> Uzlabošanās nozīmē nolietošanos.
>
> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))

Šis likums liek domāt, ka sistēmas uzlabojumi novedīs pie citu daļu pasliktināšanās vai arī apslēps citu pasliktināšanos, kas kopumā novedīs pie degradācijas no sistēmas pašreizējā stāvokļa.

Piemēram, atbildes latentuma samazināšanās konkrētā galapunktā varētu radīt papildu caurlaidspējas un jaudas problēmas pieprasījuma plūsmā, ietekmējot pilnīgi citu apakšsistēmu.

### Hype Cycle & Amara likums

[Hype Cycle Vikipedijā](https://en.wikipedia.org/wiki/Hype_cycle)

> Mēs pārāk augstu vērtējam tehnoloģijas ietekmi īstermiņā un nepietiekami novērtējam tās ietekmi ilgtermiņā.
>
> (Rojs Amara)

Hype Cycle ir Gārtnera sākotnēji ražotās tehnoloģijas saviļņojuma un attīstības vizuāls attēlojums laika gaitā. Vislabāk to rāda vizuāli:

![The Hype Cycle](../images/gartner_hype_cycle.png)

*(Atsauce uz attēlu: angļu valodā Wikipedia, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)*

Īsāk sakot, šis cikls liecina, ka parasti rodas satraukums par jaunām tehnoloģijām un to iespējamo ietekmi. Komandas bieži vien ātri iesoļo šajās tehnoloģijās un reizēm jūtas vīlušās ar rezultātiem. Tas varētu būt tāpēc, ka tehnoloģija vēl nav pietiekami izstrādāta vai arī reālie lietojumi vēl nav pilnībā īstenoti. Pēc zināma laika tehnoloģijas iespējas palielinās un praktiskās iespējas to izmantot palielinās, un komandas beidzot var kļūt ražīgas. Rojs Amars (Roy Amara) citēja šo jautājumu visskaļāk: “Mums ir tendence pārvērtēt tehnoloģijas ietekmi īstermiņā un novērtēt to par zemu ilgtermiņā.”

### Hiruma likums (Perifērisko saskarņu likums)

[Hiruma likums Online](http://www.hyrumslaw.com/)

> Ar pietiekamu API lietotāju skaitu,
> nav svarīgi, ko jūs solāt līgumā:
> visas novērojamās sistēmas darbības
> būs atkarīgs no kāda.
>
> (Hyrum Wright)

Hirum likums nosaka, ka tad, ja jums ir _pietiekami liels API patērētāju skaits_, visas API darbības (pat tās, kas nav definētas kā publiskā līguma daļa) galu galā būs atkarīgas no kāda. Triviāls piemērs var būt nefunkcionāli elementi, piemēram, API atbildes laiks. Smalkāks piemērs varētu būt patērētāji, kas paļaujas uz regex piemērošanu kļūdas ziņojumam, lai noteiktu API kļūdas *tipu*. Pat tad, ja API publiskajā līgumā nav norādīts ziņojuma saturs, norādot, ka lietotājiem jālieto saistītais kļūdas kods, _daži_ lietotāji var izmantot ziņojumu un, mainot ziņojumu, būtībā tiek pārtraukta API šiem lietotājiem.

Skatīt arī:

- [Leaky Abstractions likums](#the-law-of-dioxide-freshctions)
- [XKCD 1172](https://xkcd.com/1172/)

### Kernigana likums

> Atkļūdošana ir divreiz smagāka nekā koda rakstīšana pirmajā vietā. Tāpēc, ja jūs uzrakstāt kodu pēc iespējas gudrāk, jūs pēc definīcijas neesat pietiekami gudrs, lai to atkļūdotu.
>
> (Brian Kernighan)

Kernigana likums ir nosaukts [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) un atvasināts no citāta no Kernighan un Plaugera grāmatas [Programmēšanas stila eleme