├── .github ├── CODE_OF_CONDUCT.md ├── contributing.md └── pull_request_template.md ├── .gitignore ├── LICENSE ├── README.md ├── _config.yml ├── assets ├── banner.png ├── banner.psd ├── diagrams.bmpr ├── repository-open-graph-template.png └── sharing.md ├── images ├── amdahls_law.png ├── gartner_hype_cycle.png └── gitlocalize.png └── translations ├── it-IT.md └── tr.md /.github/CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, sex characteristics, gender identity and expression, 9 | level of experience, education, socio-economic status, nationality, personal 10 | appearance, race, religion, or sexual identity and orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at dwmkerr@gmail.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html 72 | 73 | [homepage]: https://www.contributor-covenant.org 74 | 75 | For answers to common questions about this code of conduct, see 76 | https://www.contributor-covenant.org/faq 77 | -------------------------------------------------------------------------------- /.github/contributing.md: -------------------------------------------------------------------------------- 1 | # Contributing Guidelines 2 | 3 | 4 | 5 | 6 | * [Example Law: The Law of Leaky Abstractions](#example-law-the-law-of-leaky-abstractions) 7 | * [Localisation](#localisation) 8 | 9 | 10 | 11 | The goal of this project is to have a set of _concise_ definitions to laws, principles, methodologies and patterns which hackers will find useful. They should be: 12 | 13 | 1. Short - one or two paragraphs. 14 | 2. Include the original source. 15 | 3. Quote the law if possible, with the author's name. 16 | 4. Link to related laws in the 'See also' section. 17 | 5. Include real-world examples if possible in the 'Real-world examples' section. 18 | 19 | Some other tips: 20 | 21 | - It is fine to include laws which are humorous or not serious. 22 | - If a law does not obviously apply to development or coding, include a paragraph explaining the relevance to technologists. 23 | - Don't worry about managing the table of contents, I can generate it. 24 | - Feel free to include images, but aim to keep it down to one image per law. 25 | - Be careful not to copy-and-paste content (unless it is explicitly quoted), as it might violate copyright. 26 | - Include hyperlinks to referenced material. 27 | - Do not advocate for the law, or aim to be opinionated on the correctness or incorrectness of the law, as this repository is simply the descriptions and links. 28 | 29 | An example law is shown below, which covers most of the key points: 30 | 31 | --- 32 | 33 | ### Example Law: The Law of Leaky Abstractions 34 | 35 | [The Law of Leaky Abstractions on Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 36 | 37 | > All non-trivial abstractions, to some degree, are leaky. 38 | > 39 | > (Joel Spolsky) 40 | 41 | This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way. 42 | 43 | An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of. 44 | 45 | The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network, but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy. 46 | 47 | The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases. 48 | 49 | See also: 50 | 51 | - [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces) 52 | 53 | Real-world examples: 54 | 55 | - [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations. 56 | 57 | ### Localisation 58 | 59 | We are currently using [GitLocalize](https://gitlocalize.com) to handle translations. This provides features to make it easier for people to manage translations as changes come in: 60 | 61 | ![GitLocalize Screenshot](../images/gitlocalize.png) 62 | 63 | This is still work in progress - if you would like to be a maintainer for a language just open an issue to get in touch! 64 | -------------------------------------------------------------------------------- /.github/pull_request_template.md: -------------------------------------------------------------------------------- 1 | **Pull Request Checklist** 2 | 3 | Please double check the items below! 4 | 5 | - [ ] I have read the [Contributor Guidelines](./.github/contributing.md). 6 | - [ ] I have not directly copied text from another location (unless explicitly indicated as a quote) or violated copyright. 7 | - [ ] I have linked to the original Law. 8 | - [ ] I have quote the law (if possible) and the author's name (if possible). 9 | - [ ] I am happy to have my changes merged, so that I appear as a contributor, but also the text altered if required to keep the language consistent in the project. 10 | 11 | And don't forget: 12 | 13 | - I can handle the table of contents, feel free to leave it out. 14 | - Check to see if other laws should link back to the law you have added. 15 | - Include your **Twitter Handle** if you want me to include you when tweeting this update! 16 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2018 Dave Kerr 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/README.md -------------------------------------------------------------------------------- /_config.yml: -------------------------------------------------------------------------------- 1 | theme: jekyll-theme-cayman 2 | -------------------------------------------------------------------------------- /assets/banner.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/assets/banner.png -------------------------------------------------------------------------------- /assets/banner.psd: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/assets/banner.psd -------------------------------------------------------------------------------- /assets/diagrams.bmpr: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/assets/diagrams.bmpr -------------------------------------------------------------------------------- /assets/repository-open-graph-template.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/assets/repository-open-graph-template.png -------------------------------------------------------------------------------- /assets/sharing.md: -------------------------------------------------------------------------------- 1 | # Sharing 2 | 3 | Copy paste the below for sharing on social media. The channels are: 4 | 5 | - [Hacker News](https://news.ycombinator.com) 6 | - [`r/programming`](https://reddit.com/r/programming/) 7 | - LinkedIn 8 | - Twitter 9 | 10 | ## LinkedIn 11 | 12 | #hackerlaws - - 13 | 14 | 15 | 16 | Hacker Laws is a set of theories, principles and patterns that developers will find useful. 17 | 18 | Thanks 19 | 20 | #hacking #programming #coding #development #computerscience #logic 21 | -------------------------------------------------------------------------------- /images/amdahls_law.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/images/amdahls_law.png -------------------------------------------------------------------------------- /images/gartner_hype_cycle.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/images/gartner_hype_cycle.png -------------------------------------------------------------------------------- /images/gitlocalize.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/csparpa/hacker-laws-it/1df15aedc120e32f4b1f29fc55a9d7a8b1d8eb57/images/gitlocalize.png -------------------------------------------------------------------------------- /translations/it-IT.md: -------------------------------------------------------------------------------- 1 | # 💻📖 hacker-laws 2 | 3 | Leggi, teorie, principi e pattern utili agli sviluppatori. 4 | 5 | - 🇨🇳 [中文 / Traduzione in Cinese](https://github.com/nusr/hacker-laws-zh) - grazie [Steve Xu](https://github.com/nusr)! 6 | - 🇮🇹 [Traduzione in Italiano](https://github.com/csparpa/hacker-laws-it) - grazie [Claudio Sparpaglione](https://github.com/csparpa)! 7 | - 🇰🇷 [한국어 / Traduzione in Coreano](https://github.com/codeanddonuts/hacker-laws-kr) - grazie [Doughnut](https://github.com/codeanddonuts)! 8 | - 🇷🇺 [Русская версия / Traduzione in Russo](https://github.com/solarrust/hacker-laws) - grazie [Alena Batitskaya](https://github.com/solarrust)! 9 | - 🇹🇷 [Türkçe / Traduzione in Turco](https://github.com/umutphp/hacker-laws-tr) - grazie [Umut Işık](https://github.com/umutphp)! 10 | - 🇺🇸 [Original English Version - Versione Originale in Inglese](https://github.com/dwmkerr/hacker-laws) - grazie [Dave Kerr](https://github.com/dwmkerr)! 11 | 12 | --- 13 | 14 | 15 | 16 | * [Introduzione](#introduzione) 17 | * [Leggi](#leggi) 18 | * [Legge di Amdahl](#legge-di-amdahl) 19 | * [Legge di Brooks](#legge-di-brooks) 20 | * [Legge di Conway](#legge-di-conway) 21 | * [Numero di Dunbar](#numero-di-dunbar) 22 | * [Legge di Gall](#legge-di-gall) 23 | * [Rasoio di Hanlon](#rasoio-di-hanlon) 24 | * [Legge di Hofstadter](#legge-di-hofstadter) 25 | * [Legge di Hutber](#legge-di-hutber) 26 | * [Hype Cycle e Legge di Amara](#hype-cycle-e-legge-di-amara) 27 | * [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) 28 | * [Legge di Moore](#legge-di-moore) 29 | * [Legge di Parkinson](#legge-di-parkinson) 30 | * [Ottimizzazione Prematura](#effetto-di-ottimizzazione-prematura) 31 | * [Legge di Putt](#legge-di-putt) 32 | * [Legge di Conservazione della Complessità (Legge di Tesler)](#legge-di-conservazione-della-complessita-legge-di-tesler) 33 | * [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) 34 | * [Legge di Irrilevanza](#legge-di-irrilevanza) 35 | * [Filosofia Unix](#filosofia-unix) 36 | * [Il modello Spotify](#il-modello-spotify) 37 | * [Legge di Wadler](#legge-di-wadler) 38 | * [Principi](#principi) 39 | * [Il Principo di Pareto (La regola dell'80/20)](#principio-di-pareto-regola-dell-80-20) 40 | * [Il Principio di Robustezza (Legge di Postel's)](#principio-di-robustezza-legge-di-postel) 41 | * [SOLID](#solid) 42 | * [Il Principio di Singola Responsabilità](#principio-di-singola-responsabilita) 43 | * [Il Principio dell'Aperto/Chiuso](#principio-dell-open-closed) 44 | * [Il Principio di Sostituzione di Liskov](#principio-di-sostituzione-di-liskov) 45 | * [Il Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) 46 | * [Il Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) 47 | * [Il Principio DRY](#principio-dry) 48 | * [YAGNI](#yagni) 49 | * [Reading List](#reading-list) 50 | * [TODO](#todo) 51 | 52 | 53 | 54 | ## Introduzione 55 | 56 | Quando si parla di sviluppo software, si discute di tanti principi. Questo repository fornisce un riferimento e un'introduzione a quelli più comuni. I contributi sono sono ben accetti! 57 | 58 | 59 | ❗: Questo repo contiene la spiegazione di alcune leggi, principi e pattern, ma tuttavia non ne _sponsorizza_ nessuno. La loro applicabilità dovrebbe sempre essere discussa ed è sempre dipendente dal progetto specifico su cui state lavorando. 60 | 61 | ## Leggi 62 | 63 | Si parte! 64 | 65 | ### Legge di Amdahl 66 | 67 | [Legge di Amdahl su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Amdahl) 68 | 69 | > La legge di Amdahl mostra lo _speedup potenziale_ che può essere raggiunto nell'esecuzione di un calcolo aumentando le risorse del sistema di calcolo. Di norma si usa nel calcolo parallelo e può stimare il beneficio atteso, limitato dalla porzione parallelizzabile del programma, e raggiungibile aumentando il numero di core di calcolo. 70 | 71 | Ecco un esempio illustrativo. Se un programma è costituito da due parti - una parte A che deve essere eseguita da un singolo core di calcolo e una parte B che può essere parallelizzata - possiamo notare che aggiungere nuovi core al sistema di calcolo produce un beneficio limitato. L'aggiunta potenzia di molto la velocità di esecuzione della parte B - ma la velocità di esecuzione della parte A resterà la stessa. 72 | 73 | Il diagramma sotto riportato illustra gli andamenti nel tempo della velocità di esecuzione in alcuni casi: 74 | 75 | ![Diagram: Amdahl's Law](./images/amdahls_law.png) 76 | 77 | *(Crediti Immagine: Daniels220 su Wikipedia in lingua inglese, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* 78 | 79 | Come si può vedere, anche un programma che è al 50% parallelizzabile beneficerà molto poco dell'aggiunta di più di 10 core di calcolo, mentre un programma che è parallelizzabile al 95% può raggiungere speedup significativi nella velocità di esecuzione anche oltre 1000 core di calcolo aggiunti. 80 | 81 | Dal momento che [la legge di Moore](#legge-di-moore) sta rallentando, e l'aumento della velocità dei singoli core di calcolo diminuisce, parallelizzare diventa la chiave per migliorare le performance. Un eccellente esempio è la grafica computerizzata: con i moderni Shader, è possibile renderizzare in parallelo pixel e frammenti - questo è il motivo per cui le schede grafiche hanno migliaia di core di calcolo (GPU o Shader Unit) 82 | 83 | Vedi anche: 84 | 85 | - [Legge di Brooks](#legge-di-brooks) 86 | - [Legge di Moore](#legge-di-moore) 87 | 88 | ### Legge di Brooks 89 | 90 | [Legge di Brooks su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Brooks) 91 | 92 | > L'aggiunta di risorse umane ad un progetto di sviluppo software già in ritardo lo fa tardare ancora di più. 93 | 94 | Questa legge suggerisce che in molti casi il tentativo di accelerare, tramite aggiunta di ulteriori persone a staff, la delivery di un progetto che è già in ritardo risulterà nell'aumento del ritardo progettuale. Brooks sottolinea che questo scenario è certamente molto semplificato, ma che tuttavia il ragionamento alla base è che il tempo necessario alle nuove risorse per diventare produttive e l'overhead di comunicazione introdotto causano una decrescita della velocità nel breve termine. Inoltre molti task risultano non suddivisibili o facilmente distribuibili tra più risorse, causando un corrispondente minor aumento nella velocità potenziale. 95 | 96 | La famosa frase "Nove donne non fanno un figlio in un solo mese" è relativa alla Legge di Brook, in particolare al fatto che alcuni tipi di operazioni non sono suddivisibili o parallelizzabili. 97 | 98 | Questo è un tema centrale del libro '[The Mythical Man Month](#reading-list)'. 99 | 100 | Vedi anche: 101 | 102 | - [Death March](#todo) 103 | - [Reading List: The Mythical Man Month](#reading-list) 104 | 105 | ### Legge di Conway 106 | 107 | [Legge di Conway su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Conway) 108 | 109 | Questa legge indica che i confini di un sistema software riflettono la struttura dell'organizzazione che lo produce. Comunemente citata quando si parla di miglioramenti organizzativi, la legge di Conway afferma che se un'organizzazione è strutturata in tante piccole unità tra loro disconnesse, il software che essa produrrà avrà la stessa struttura. Se un'organizzazione invece è costruita attorno a "silo" verticali dedicati a funzionalità o servizi, i suoi sistemi software rifletteranno questa caratteristica. 110 | 111 | Vedi anche: 112 | 113 | - [Il modello Spotify](#il-modello-spotify) 114 | 115 | ### Numero di Dunbar 116 | 117 | [Numero di Dunbar su Wikipedia](https://it.wikipedia.org/wiki/Numero_di_Dunbar) 118 | "Il numero di Dunbar è stato suggerito come valore cognitivo che limita il numero di persone con cui un individuo riesce a mantenere relazioni sociali stabili - relazioni in cui l'individuo sa chi è ciascuna controparte e come tutte le controparti si relazionano tra di loro". Non c'è concordanza sull'esatto valore di questo limite. "... Dunbar ha affermato che un essere umano può mantenere solo 150 relazioni stabili". Egli ha inserito questa affermazione in un contesto più sociale: "il numero di persone con cui ti sentiresti a tuo agio a prendere un drink se entrassi in un bar e le incontrassi casualmente". Le stime per il numero generalmente stanno tra 100 e 250. 119 | 120 | Come le relazioni stabili tra individui, le relazioni di uno sviluppatore con una codebase necessitano di impegno per essere mantenute. Quando ci troviamo di fronte a progetti grandi e complicati, o abbiamo la responsabilità di molti progetti, ci affidiamo a convenzioni, policy e procedure disegnate per scalare. Il numero di Dunbar non solo è importante da ricordare quando un ufficio cresce di dimensioni, ma anche quando si stabilisce il perimetro per l'operato di un team o quando si deve decidere se investire nella strumentazione per modellizzare e automatizzare l'overhead logistico. Inquadrando il numero di Dunbar in un contesto ingegneristico, esso rappresenta il numero di progetti (o la comoplessità normalizzata di un singolo progetto) sui quali un individuo si sentirebbe sicuro di lavorare a chiamata. 121 | 122 | Vedi anche: 123 | 124 | - [Legge di Conway](#legge-di-conway) 125 | 126 | ### Legge di Gall 127 | 128 | [Legge di Gall su Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) 129 | 130 | > Un sistema di complessità elevata e che funziona è inevitabilmente evoluto a partire da un sistema più semplice che funzionava. Un sistema complesso disegnato da zero non funziona per definizione e non può essere modificato per funzionare: bisogna partire ripartire da un sistema semplice che funziona. 131 | > 132 | > ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author))) 133 | 134 | La Legge di Gall implica che i tentativi di _disegnare_ un sistema ad alta complessità hanno alta probabilità di fallire. I sistemi complessi raramente sono costruiti in una sola iterazione, al contrario sono il risultato dell'evoluzione di sistemi più semplici. 135 | 136 | Un classico esempio è il World Wide Web. Al suo stato attuale, è un sistema fortemente complesso. Tuttavia, inizialmente fu definito come un sistema semplice per condividere contenuti tra istituti accademici. Realizzò questo obiettivo con grande successo ed mutò nel tempo divenendo sempre più complesso al passare del tempo. 137 | 138 | Vedi anche: 139 | 140 | - [KISS (Keep It Simple, Stupid)](#TODO) 141 | 142 | ### Rasoio di Hanlon 143 | 144 | [Rasoio di Hanlon su Wikipedia](https://it.wikipedia.org/wiki/Rasoio_di_Hanlon) 145 | 146 | > Non attribuire mai a malafede quel che si può ragionevolmente spiegare con la stupidità. 147 | > 148 | > Robert J. Hanlon 149 | 150 | Questo principio suggerisce che l'ottenimento di un risultato negativo con ogni probabilità non è dovuto alla volontà perversa di fallire quanto alla mancata comprensione (totale o parziale) dell'impatto delle proprie azioni. 151 | 152 | ### Legge di Hofstadter 153 | 154 | [Legge di Hofstadter su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Hofstadter) 155 | 156 | > Per fare una cosa ci vuole sempre più tempo di quanto si pensi, anche tenendo conto della Legge di Hofstadter. 157 | > 158 | > (Douglas Hofstadter) 159 | 160 | Questa legge è citata quando si fanno le stime sulla durata di qualcosa. Nello campo dello sviluppo software sembra essere un assioma la tendenza ad essere poco bravi nello stimare con precisione quanto tempo verrà richiesto per le delivery. 161 | 162 | La legge viene dal libro '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)'. 163 | 164 | Vedi anche: 165 | 166 | - [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) 167 | 168 | ### Legge di Hutber 169 | 170 | [Legge di Hutber su Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law) 171 | 172 | > I miglioramenti spesso celano altri peggioramenti. 173 | > 174 | > ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) 175 | 176 | La legge indica che i miglioramenti apportati ad una parte di un sistema porteranno ad un inevitabile deterioramento in altre sue parti, causando quindi un globale deterioramento nello stato corrente del sistema. 177 | 178 | Per esempio, la diminuzione nella latenza di risposta di uno specifico end-point provoca un amumento nel throughput e problemi di capacity nel workflow di gestione delle richieste, impattando altri sottosistemi correlati. 179 | 180 | ### Hype Cycle e Legge di Amara 181 | 182 | [Hype Cycle su Wikipedia](https://it.wikipedia.org/wiki/Hype_cycle) 183 | 184 | > Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine. 185 | > 186 | > (Roy Amara) 187 | 188 | L'Hype Cycle è una rappresentazione visuale del clamore attorno allo sviluppo di una tecnologia nel tempo, originariamente ideata da Gartner. Un esempio: 189 | 190 | ![The Hype Cycle](./images/gartner_hype_cycle.png) 191 | 192 | *(Crediti Immagine: Jeremykemp su Wikipedia in lingua inglese, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* 193 | 194 | In sintesi, il Cycle dice che tipicamente esiste un picco di frenesia quando nasce una nuova tecnologia riguardo i suoi potenziali impatti. I team di lavoro di solito adottano velocemente tali tecnologie e a volte si trovano scontenti del risultato. Ciò può essere dovuto all'immaturità della tecnologia, oppure alla mancanza di applicazioni reali significative. Dopo un certo periodo di tempo, le potenzialità della tecnologia aumentano e aumenta il numero delle opportunità concrete che essa offre, per cui i team di lavoro possono finalmente aumentare la loro produttività adottandola. La citazione di Roy Amara riassume in breve questa situazione - "Tendiamo a sovrastimare l'impatto di una tecnologia sul breve termine e nel sottostimarlo sul lungo termine". 195 | 196 | ### Legge di Hyrum (Legge delle Interfacce Implicite) 197 | 198 | [Legge di Hyrum Online](http://www.hyrumslaw.com/) 199 | 200 | > Dato un numero sufficientementa elevato di utenti di un'API, 201 | > il contenuto del contratto di interfaccia non conta: 202 | > tutti i comportamenti osservabili del sistema che espone l'API 203 | > saranno utilizzati da questi utenti. 204 | > 205 | > (Hyrum Wright) 206 | 207 | La lagge di Hyrum dice che quando un'API ha un _numero sufficientementa elevato di consumer_, tutti i comportamenti di essa (anche quelli non definiti come parte dell'interfaccia pubblica) prima o poi costituiranno una dipendenza lato consumer. Un esempio banale è quello degli aspetti non-funzionali come il tempo di risposta di un'API. Un esempio più profondo è quello di consumer che applicano una regex sui messaggi di errore dell'API per determinarne la *tipologia*. Anche se il contratto pubblico di interfaccia un'API non dice nulla riguardo al contenuto dei messaggi e suggerisce agli utentil'utilizzo dei codici di errore associati ai messaggi, _alcuni_ utenti possono comunque utilizzare i messaggi di errore a tal fine e dunque una modifica dei messaggi sostanzialmente rompe l'integrazione per questi utenti. 208 | 209 | Vedi anche: 210 | 211 | - [Legge dell'Astrazione Fallata](#legge-dell-astrazione-fallata) 212 | - [XKCD 1172](https://xkcd.com/1172/) 213 | 214 | ### Legge di Moore 215 | 216 | [Legge di Moore su Wikipedia](https://it.wikipedia.org/wiki/Legge_di_Moore) 217 | 218 | > Il numero di transistor in un circuito integrato raddoppia approssimativamente ogni due anni. 219 | 220 | Spesso utilizzata per illustrare il tasso con cui le tecnologie a semiconduttori e i chip migliorano nel tempo, la legge di Moore si è dimostrata molto accurata dagli anni Settanta fino alla fine dei Duemila. Più di recente il trend è lievemente cambiato, in parte a causa delle [limitazioni fisiche alla miniaturizzazione delle componenti elettroniche](https://it.wikipedia.org/wiki/Effetto_tunnel) ma tuttavia avanzamenti nel campo della parallelizzazione del calcolo e scoperte potenzialmente rivoluzionarie nel campo delle tecnologie a semiconduttori e nel quantum computing potrebbero portare la legge di Moore a valere anche nei prossimi decenni. 221 | 222 | ### Legge di Parkinson 223 | 224 | [Legge di Parkinson su Wikipedia](https://it.wikipedia.org/wiki/La_legge_di_Parkinson) 225 | 226 | > Il lavoro tende ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo. 227 | 228 | Nel suo contesto originale, questa legge era riferita agli studi sulla gestione della burocrazia. Può essere applicata in ottica pessimistica alle iniziative di sviluppo software, e in sostanza afferma che i team saranno inefficienti fino all'approssimarsi delle deadline e lavoreranno quindi di corsa per rispettare tali deadline rendendole, in un certo senso, arbitrarie. 229 | 230 | Combinando la legge di Parkinson con la [Legge di Hofstadter](#legge-di-hofstadter), si ottiene una vista ancora più pessimistica: il lavoro tenderà ad espandersi fino ad impiegare tutto il tempo disponibile per svolgerlo e *in ogni caso richiederà più tempo di quanto previsto*. 231 | 232 | Vedi anche: 233 | 234 | - [Legge di Hofstadter](#legge-di-hofstadter) 235 | 236 | ### Effetto di Ottimizzazione Prematura 237 | 238 | [Ottimizzazione Prematura su WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization) 239 | 240 | > L'ottimizzazione prematura è la radice di ogni male. 241 | > 242 | > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) 243 | 244 | 245 | Nella sua pubblicazione [Programmazione Strutturata con clausole Go To](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), 246 | Donald Knuth scrisse: "I programmatori perdono un'enormità di tempo a preoccuparsi delle performance delle sezioni non critiche dei loro programmi, e i tentativi di efficientarle hanno in realtà un forte impatto negativo durante il debugging e la manutenzione. Dovremmo dimenticarci dei piccoli efficientamenti, che impattano circa il 97% del tempo di esecuzione: **l'ottimizzazione prematura è la radice di ogni male**. Di contro non dovremmo mai lasciarci sfuggire l'occasione di migliorare quel critico 3% del tempo di esecuzione." 247 | 248 | L'_Ottimizzazione Prematura_ può essere definita (in termini meno coloriti) come l'attività di efficientamento fatta prima di avere evidenza della sua necessità. 249 | 250 | ### Legge di Putt 251 | 252 | [Legge di Putt su Wikipedia](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) 253 | 254 | > Il mondo della tecnologia è dominato da due tipi di persone: coloro che comprendono ciò che non gestiscono e coloro che gestiscono ciò che non comprendono. 255 | 256 | La Legge di Putt è spesso accompagnata dal Corollario di Putt: 257 | 258 | > Ogni gerarchia tecnica, genera un'inversione delle competenze con il passare del tempo. 259 | 260 | Queste frasi suggeriscono che, a causa di svariati criteri di selezione e trend con cui i gruppi di lavoro si organizzano, ci sarà un certo numero di persone di vasta esperienza con ruoli tecnici operativi e un certo numero di ruoli manageriali che non sono in grado di comprendere la complessità e le sfide del contesto lavorativo che sono chiamati a gestire. Ciò si spiega con fenomeni come il [Principio di Peter](#TODO) o [La Legge di Dilbert](#TODO). 261 | 262 | Tuttavia, è corretto specificare che Leggi come queste sono una grande generalizzazione e si applicano ad _alcuni_ tipi di organizzazione e non ad altri. 263 | 264 | Vedi anche: 265 | 266 | - [Principio di Peter](#TODO) 267 | - [Legge di Dilbert](#TODO). 268 | 269 | 270 | ### Legge di Conservazione della Complessità (Legge di Tesler) 271 | 272 | [Legge di Conservazione della Complessità su Wikipedia](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) 273 | 274 | Le Legge dice che in ogni sistema esiste un certo livello di complessità che non può essere ridotto. 275 | 276 | Parte della complessità di un sistema è introdotta "inavvertitamente" ed è conseguenza della struttura imperfetta, degli errori o semplicemente di una modellizzazione errata del problema da risolvere. La complessità involontaria può essere ridotta (o eliminata). Tuttavia, parte della complessità è "intrinseca" ed è conseguenza della complessità inerente al problema da risolvere. Questa complessità può essere spostata ma non eliminata. 277 | 278 | Un elemento interessante di questa Legge è che ci dice che anche semplificando l'intero sistema, la complessità intrinseca non viene ridotta ma viene _spostata sull'utente_, che deve di conseguenza interagire in modo più sofisticato con il sistema. 279 | 280 | 281 | ### Legge dell'Astrazione Fallata 282 | 283 | [La Legge dell'Astrazione Fallata su Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 284 | 285 | > Tutte le astrazioni non banali sono in qualche modo fallate. 286 | > 287 | > ([Joel Spolsky](https://twitter.com/spolsky)) 288 | 289 | Questa legge afferma che le astrazioni generalmente usate in informatica per semplificare l'uso di sistemi complessi, in certe situazioni, lasceranno "trapelare" il dettaglio dei sistemi sottostanti facendo così funzionare l'astrazione in modo inaspettato. 290 | 291 | Un esempio è l'apertura di un file e la lettura del suo contenuto. L'API di un file system è un'_astrazione_ del kernel di sistema, il quale è a sua volta un'astrazione dei processi fisici di modifica dei dati su un disco magnetico (o su una memoria flash nel caso di SSD). Nella maggior parte dei casi, l'astrazione di considerare il file come uno stream di dati binario funzionerà senza problemi. Tuttavia, nel caso di un disco magnetico, la lettura sequenziale dei dati sarà *significativamente* più veloce di un accesso random (per via dell'overhead dovuto ai page fault), ma nel caso di un disco SSD tale overhead non è presente. I dettagli implementativi dell'astrazione dovranno dunque essere compresi se si vuole gestire questo comportamento (ad esempio, i file indice di un database sono strutturati per ridurre l'overhead dell'accesso random), l'astrazione "fallata" lascerà trapelare questi dettagli che possono essere di interesse per il programmatore. 292 | 293 | L'esempio di cui sopra può diventare anche più complesso quando vengono introdotte astrazioni _multiple_. Il sistema operativo Linux consente di accedere file attraverso una rete, rappresentandoli localmente come file "normali". Questa astrazione "farà acqua" se la rete verrà interrotta. Se uno sviluppatore trattasse questi file come file "noemali", senza considerare il fatto che possono essere soggetti alla latenza e alle interruzioni della rete, la soluzione sviluppata avrà un baco. 294 | 295 | L'articolo che descrive questa Legge suggerisce che un'eccessiva fiducia nelle astrazioni, combinata con una scarsa comprensione del sistema sottostante, di fatto in alcuni casi _aumenta_ la complessità del problema da risolvere. 296 | 297 | Vedi anche: 298 | 299 | - [Legge di Hyrum (Legge delle Interfacce Implicite)](#legge-di-hyrum-legge-delle-interfacce-implicite) 300 | 301 | Esempi dal mondo reale: 302 | 303 | - [Partenza lenta di Photoshop](https://forums.adobe.com/thread/376152) - problema incontrato nel passato su Photoshop, che a volta impiegava minuti per avviarsi. Sembra che il problema fosse che all'avvio Photoshop leggeva informazioni sulla stampante di default. Tuttavia, se la stampante era una stampante di rete, questa lettura poteva impiegare un tempo molto lungo. L'_astrazione_ per cui la stampante di rete era presentata al sistema esattamente come una stampante locale causava quindi una situazione di estrema lentezza per gli utenti in condizioni di rete lenta. 304 | 305 | ### Legge di Irrilevanza 306 | 307 | [Legge di Irrilevanza su Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality) 308 | 309 | La Legge afferma che i team di lavoro tendono a dedicare molto più tempo e attenzione a dettagli irrilevanti o legati alla cosmesi del lavoro piuttosto che alle questioni serie e sostanziali. 310 | 311 | Il tipico esempio fittizio usato per illustrare la Legge è quello di un comitato incaricato di approvare i piani per un impianto nucleare, che passa più tempo a discutere i dettagli del ripostiglio delle biciclette che a discutere il ben più importante design dell'impianto stesso. Può essere difficile a volte dare il giusto contributo quando si discute di argomenti grandi e complessi senza avere una preparazione o esperienza adeguata in merito. Tuttavia, le persone vogliono in genere mostrarsi attive nel collaborare fornendo input di valore. Da qui la tendenza a concentrarsi troppo sul dettaglio spiccio, che può essere discusso facilmente, ma non ha necessariamente rilevanza. 312 | 313 | L'esempio fittizio ha portato all'utilizzo del termine "ripostiglio delle biciclette" come metafora della perdita di tempo sui dettagli di poca rilevanza. 314 | 315 | ### Filosofia Unix 316 | 317 | [La Filosofia Unix su Wikipedia](https://it.wikipedia.org/wiki/Filosofia_Unix) 318 | 319 | La Filosofia Unix predica che le componenti software debbano essere piccole e mirate a implementare bene un solo scopo. Ciò rende più semplice costruire sistemi mediante composizione di unità piccole, semplici e ben definite, piuttosto che mediante composizione di programmi grossi, complessi e multi-purpose. 320 | 321 | Le moderne prassi come le "Architettura a Microservizi" possono essere viste come applicazioni di questa Filosofia, per cui i servizi sono piccoli e focalizzati sul fare una cosa specifica, consentendo la creazione di comportamenti complessi mediante composizione di mattoni più semplici. 322 | 323 | ### Il modello Spotify 324 | 325 | [Il modello Spotify su Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) 326 | 327 | Il modello Spotify è un approccio alla strutturazione del lavoro e dell'azienda che è stato reso popolare da Spotify. In questo modello, i team di lavoro sono organizzati attorno alle features invece che alle tecnologie. 328 | 329 | Il modello Spotify rende inoltre popolari i concetti di Tribù, Gilda, Capitolo, che sono altre componenti della struttura organizzativa. 330 | 331 | 332 | ### Legge di Wadler 333 | 334 | [Legge di Wadler su wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) 335 | 336 | > Nella progettazione di qualsiasi linguaggio, il tempo totale impiegato a discutere un elemento di questa lista è proporzionale a 2 elevato alla potenza corrispondente alla posizione dell'elemento: 337 | > 338 | > 0. Semantica 339 | > 1. Sintassi 340 | > 2. Sintassi lessicale 341 | > 3. Sintassi lessicale dei commenti 342 | > 343 | > (In breve: per ogni ora spesa a discutere della semantica, 8 ore saranno spese sulla sintassi dei commenti). 344 | 345 | Similmente alla [Legge di Irrilevanza](#legge-di-irrilevanza), la Legge di Wadler afferma che nel design di un linguaggio di programmazione il tempo speso sulla discussione della struttura del linguaggio è sproporzionatamente alto se comparato con l'importanza delle feature discussa. 346 | 347 | Vedi anche: 348 | 349 | - [Legge di Irrilevanza](#legge-di-irrilevanza) 350 | 351 | ## Principi 352 | 353 | I Principi sono in generale usabili come linee guida per il design. 354 | 355 | 356 | ### Principio di Pareto (regola dell'80-20) 357 | 358 | [Il Principio di Pareto su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_Pareto) 359 | 360 | > Nella vita, la maggior parte delle cose non è distribuita equamente. 361 | 362 | Il Principio di Pareto suggerisce che in alcuni casi, la maggior parte dei risultati è effetto di una minoranza degli input 363 | 364 | - l'80% di un software è scrivibile nel 20% del tempo totale allocato per la sua scrittura (di contro, il 20% del codice, ossia le parti più complicate di esso, impiega l'80% del tempo) 365 | - il 20% dell'effort produce l'80% del risultato 366 | - il 20% del lavoro genera l'80% della revenue 367 | - il 20% dei bachi genera l'80% dei crash 368 | - il 20% delle features soddisfa l'80% degli utenti 369 | 370 | Negli anni Quaranta l'ingegnere Americano-Rumeno Dr.Joseph Juran, che è riconosciuto universalmente come il padre del controllo di qualità, [iniziò ad applicare il Principio di Pareto alla quality assurance](https://en.wikipedia.org/wiki/Joseph_M._Juran) 371 | 372 | Questo Principio è anche noto come: Regola dell'80/20, Legge dei Pochi ma Vitali e il Principio della Scarsità dei Fattori. 373 | 374 | Esempi dal mondo reale: 375 | 376 | - Nel 2002 la Microsoft riferì che sistemando il 20% dei bachi nella lista tra i più segnalati vennero sistemati l'80% degli errori e dei crash correlati su Windows e Office ([Riferimento](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). 377 | 378 | ### Principio di Robustezza (Legge di Postel) 379 | 380 | [Il Principio di Robustezza su Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle) 381 | 382 | > Siate conservativi nelle vostre azioni, ma liberali in ciò che accettate dagli altri. 383 | 384 | Spesso applicato allo sviluppo di applicazioni lato server, questo principio afferma che ciò viene inviato alle terze parti dovrebbe essere il più contenuto e standard possibile, e di contro si dovrebbe accettare anche input non-standard - fintanto che è processabile - in arrivo dalle terze parti. 385 | 386 | L'obiettivo di questo principio è la costruzione di sistemi robusti in quanto possono gestire input malformato, a patto che l'intento degli input si possa ancora cogliere. Tuttavia l'accettazione di input malformati pone potenziali implicazioni a livello di sicurezza, soprattutto laddove non si testi a fondo l'ingestione di tali input. 387 | 388 | ### SOLID 389 | 390 | SOLID è un acronimo: 391 | 392 | * S: [Principio di Singola Responsabilità](#principio-di-singola-responsabilita) 393 | * O: [Principio dell'Open Closed](#principio-dell-open-closed) 394 | * L: [Principio di Sotituzione di Liskov](#principio-di-sostituzione-di-liskov) 395 | * I: [Principio di Segregazione delle Interfacce](#principio-di-segregazione-delle-interfacce) 396 | * D: [Principio di Inversione delle Dipendenze](#principio-di-inversione-delle-dipendenze) 397 | 398 | These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems. 399 | 400 | ### Principio di Singola Responsabilità 401 | 402 | [Principio di Singola Responsabilità su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_singola_responsabilit%C3%A0) 403 | 404 | > Ogni modulo o classe dovrebbe avere una sola responsabilità. 405 | 406 | Il primo dei Principi '[SOLID](#solid)'. Afferma che i moduli o le classi software dovrebbero fare una e una sola cosa. In termini più pratici, ciò significa che una piccola modifica ad una feature di un programma dovrebbe richiedere la corrispondente modifica di una sola sua componente. Per esempio, cambiare il modo in cui la complessità di una password viene validata dovrebbe richiedere la modifica di una sola parte del programma. 407 | 408 | In teoria, ciò dovrebbe garantire una maggiore robustezza del codice, con maggiore facilità di modifica. Sapere che un componente da cambiare ha una sola responsabilità ne semplifica grandemente il _testing_. Riprendendo l'esempio fatto prima, la modifica del componente che gestisce la validazione della password dovrebbe impattare solo le features di programma che sono correlate con la complessità della password. Di contro, testare un componente che ha svariate responsabilità diventa molto più difficoltoso. 409 | 410 | Vedi anche: 411 | 412 | - [Object-Oriented Programming](#todo) 413 | - [SOLID](#solid) 414 | 415 | ### Principio dell'Open Closed 416 | 417 | [Il Principio dell'Open Closed su Wikipedia](https://it.wikipedia.org/wiki/Principio_aperto/chiuso) 418 | 419 | > Le entità software dovrebbero essere aperte all'estensione ma chiuse alla modifica. 420 | 421 | Il secondo dei Principi '[SOLID](#solid)' afferma che le entità software (classi, moduli, funzioni) dovrebbero incoraggiare la possibilità di _estendere_ il proprio comportamento e scoraggiare la modifica del loro _comportamento esistente_ 422 | 423 | Ad esempio, si prenda un modulo in grado di trasformare un documento Markdown in HTML. Se il modulo può essere esteso per gestire una nuova feature proposta per il Markdown, senza doverne modificare il funzionamento interno, allora può definirsi aperto all'estensione. Se al contrario il modulo _non_ può essere modificato dai consumer nel modo in cui gestisce le feature correnti di Markdown, allora sarebbe _chiuso_ alla modifica. 424 | 425 | Questo Principio è particolarmente rilevante nella programmazione orientata agli oggetti, dove è desiderabile progettare tipi di oggetti facilmente estendibili e il cui comportamento corrente non venga modificato in maniera inaspettata. 426 | 427 | Vedi anche: 428 | 429 | - [Object-Oriented Programming](#todo) 430 | - [SOLID](#solid) 431 | 432 | ### Principio di Sotituzione di Liskov 433 | 434 | [Il Principio di Sotituzione di Liskov su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_sostituzione_di_Liskov) 435 | 436 | > Deve essere possibile sostituire l'istanza di un tipo con l'istanza di un suo sottotipo senza rompere il codice. 437 | 438 | Il terzo dei Principi '[SOLID](#solid)' afferma che se un componente software fà affidamento su un tipo, allora deve essere possibile utilizzare dei suoi sottotipi al suo posto senza causare errori né dover conoscere il dettaglio di quale sottotipo si sta utilizzando. 439 | 440 | A titolo di esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Se il metodo accetta il tipo base 'file' come input, allora qualsiasi tipo derivi da 'file' dovrebbe poter essere utilizzato come input al metodo. Se 'file' supporta la ricerca dalla fine all'inizio e il parser XML usa tale funzione, ma il tipo derivato 'network file' non supporta tale funzione, allora 'network file' violerebbe il Principio. 441 | 442 | Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove le gerarchie di tipo devono essere modellizzate con cautela in modo da non generare confusione negli utilizzatori del codice. 443 | 444 | Vedi anche: 445 | 446 | - [Object-Oriented Programming](#todo) 447 | - [SOLID](#solid) 448 | 449 | ### Principio di Segregazione delle Interfacce 450 | 451 | [Il Principio di Segregazione delle Interfacce su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_segregazione_delle_interfacce) 452 | 453 | > Nessun client dovrebbe dipendere da comportamenti che non usa. 454 | 455 | Il quarto dei Principi '[SOLID](#solid)' afferma che i consumer di una componente software non dovrebbero dipendere da funzionalità del componente che non utilizzano. 456 | 457 | Ad esempio, si immagini di avere un metodo che legge un documento XML da una struttura dati che rappresenta un file. Deve limitarsi a leggere i byte e a muoversi avanti/indietro sul file. Se tale metodo deve essere aggiornato perchè una caratteristica della struttura del file cambia in modo scorrelato (es. modifica al modello di permessi di sicurezza sul file), allora il Principio non viene rispettato. Sarebbe meglio a questo punto che il file implementasse un'interfaccia 'seekable-stream' e che il lettore XML la sfruttasse. 458 | 459 | Il Principio ha particolare rilevanza nella programmazione orientata agli oggetti, dove interfacce, gerarchie e tipi astratti sono utilizzati per [minimizzare l'accoppiamento](#todo) tra le diverse componenti software. Il [Duck typing](#todo) è un meccanismo che implementa il Principio attraverso l'eliminazione delle interfacce esplicite. 460 | 461 | Vedi anche: 462 | 463 | - [Object-Oriented Programming](#todo) 464 | - [SOLID](#solid) 465 | - [Duck Typing](#todo) 466 | - [Disaccoppiamento](#todo) 467 | 468 | ### Principio di Inversione delle Dipendenze 469 | 470 | [Il Principio di Inversione delle Dipendenze su Wikipedia](https://it.wikipedia.org/wiki/Principio_di_inversione_delle_dipendenze) 471 | 472 | > I moduli di alto livello non dovrebbero dipendere dalle implementazioni di basso livello. 473 | 474 | 475 | 476 | 477 | Il quinto dei Principi '[SOLID](#solid)' afferma che le componenti di alto livello che orchestrano l'esecuzione non dovrebbero conoscere i dettagli delle loro dipendenze. 478 | 479 | Ad esempio, si immagini di avere un programma che legge metadati da un sito web. Si potrebbe pensare che le componenti principali debbano conoscere dell'esistenza di un componente adibito al download del contenuto di una pagina web e anche di un componente in grado di leggere i metadati. Tenendo conto dell'inversione delle dipendenze, il componente principale dipenderebbe solo su un componente astratto in grado di recuperare byte e su un componente astratto in grado di leggere i metadati da uno stram di byte. Il componente principale dunque non dovrebbe sapere nulla di TCP/IP, HTTP, HTML, etc. 480 | 481 | Questo Principio è complesso perchè sembra 'invertire' le dipendenze attese di un sistema (da qui il suo nome). In pratica, ciò significa anche che ci deve essere un componente orchestrante di alto livello per assicurare la corretta implementazione dei tipi astratti sui quali si dipende (eg. nell'esempio di prima, _qualcosa_ deve in ogni caso fornire al componente lettore di metadati un file downloader su HTTP e un lettore di metatag HTML). Questo porta all'uso di pattern come l'[Inversione del Controllo](#todo) e l'[Iniezione delle Dipendenze](#todo). 482 | 483 | Vedi anche: 484 | 485 | - [Object-Oriented Programming](#todo) 486 | - [SOLID](#solid) 487 | - [Inversione del Controllo](#todo) 488 | - [Iniezione delle Dipendenze](#todo) 489 | 490 | ### Principio DRY 491 | 492 | [Il Principio DRY su Wikipedia](https://it.wikipedia.org/wiki/Don%27t_repeat_yourself) 493 | 494 | > Ogni elemento di conoscenza deve avere una sola, non ambigua, autorevole rappresentazione all'interno di un sistema. 495 | 496 | DRY è l'acronimo dell'inglese _Don't Repeat Yourself_ (Non Reinventare la Ruota). Questo Principio mira ad aiutare gli sviluppatori a ridurre le duplicazioni nel codice e mantenere le informazioni in un solo punto, e fu citato nel 1999 da Andrew Hunt e Dave Thomas nel libro [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer) 497 | 498 | > Il contrario di DRY è _WET_ (Write Everything Twice or We Enjoy Typing - Scrivi Tutto In Doppio o Adoriamo Scrivere alla Tastiera). 499 | 500 | In pratica, se lo stesso elemento informativo si trova duplicato in due (o più) posti differenti, si può usare DRY per fondere insieme gli elementi in un solo posto e riusarlo laddove serva. 501 | 502 | Vedi anche: 503 | 504 | - [The Pragmatic Programmer](https://it.wikipedia.org/wiki/The_Pragmatic_Programmer) 505 | 506 | ### YAGNI 507 | 508 | [YAGNI su Wikipedia](https://it.wikipedia.org/wiki/You_aren%27t_gonna_need_it) 509 | 510 | Si tratta dell'acronimo dell'inglese _**Y**ou **A**ren't **G**onna **N**eed **I**t_ (_Non Ne Avrai Bisogno_) 511 | 512 | > Scrivi una porzione di codice sempre e solo quando ne hai un bisogno reale, e mai quando sai solo prevedere il suo uso futuro. 513 | > 514 | > ([Ron Jeffries](https://twitter.com/RonJeffries)) (co-fondatore dell'eXtreme Programming e autore del libro "Extreme Programming Installed") 515 | 516 | Questo Principio dell'_Extreme Programming_ (XP) afferma che gli sviluppatore dovrebbero implementare solo le funzionalità che sono necessarie sulla base dei requisiti immediati ed evitare la tentazione di predire il futuro implementando funzionalità di cui potrebbero avere bisogno più avanti. 517 | 518 | L'aderenza a questo principio dovrebbe ridurre nella codebase la quantità di codice non utilizato, evitando così di sprecare tempo ed effort per sviluppare funzionalità che non portano valore immediato. 519 | 520 | Vedi anche: 521 | 522 | - [Reading List: Extreme Programming Installed](#reading-list) 523 | 524 | 525 | ## Reading List 526 | 527 | Se avete trovato questi concetti interessanti, potrebbero interessarvi anche i seguenti libri. 528 | 529 | - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Tratta i principi fondamentali dell'Extreme Programming. 530 | - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Un grande classico sull'ingegneria del software. La [Legge di Brooks](#legge-di-brooks) è un tema centrale del libro. 531 | - [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Questo libro è difficile da classificare. La [Legge di Hofstadter](#legge-di-hofstadter) è presa da qui. 532 | 533 | ## TODO 534 | 535 | Salve! Se vi trovate qui è perchè avete cliccato sul link ad un argomento che ancora non è stato trattato, mi dispiace - questa pagina è un cantiere aperto! 536 | 537 | Sentitevi liberi di [Segnalare un Problema](https://github.com/dwmkerr/hacker-laws/issues), richiedere più dettaglio o [Aprire una Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) per proporre la vostra definizione dell'argomento. 538 | -------------------------------------------------------------------------------- /translations/tr.md: -------------------------------------------------------------------------------- 1 | # 💻📖 hacker-laws 2 | 3 | Programcıların faydalı bulacağı yasalar, teoriler, prensipler ve desenler. 4 | 5 | - 🇨🇳 [中文 / Çince İçin](https://github.com/nusr/hacker-laws-zh) - Teşekkürler [Steve Xu](https://github.com/nusr)! 6 | - 🇮🇹 [Italyanca için](https://github.com/csparpa/hacker-laws-it) - Teşekkürler [Claudio Sparpaglione](https://github.com/csparpa)! 7 | - 🇰🇷 [한국어 / Korece İçin](https://github.com/codeanddonuts/hacker-laws-kr) - Teşekkürler [Doughnut](https://github.com/codeanddonuts)! 8 | - 🇷🇺 [Русская версия / Rusça İçin](https://github.com/solarrust/hacker-laws) - Teşekkürler [Alena Batitskaya](https://github.com/solarrust)! 9 | - 🇹🇷 [Türkçe / Turkçe İçin](https://github.com/umutphp/hacker-laws-tr) - Teşekkürler [Umut Işık](https://github.com/umutphp) 10 | 11 | --- 12 | 13 | 14 | 15 | - [Giriş](#introduction) 16 | - [Yasalar](#laws) 17 | - [Amdahl Yasası](#amdahls-law) 18 | - [Brooks Yasası](#brooks-law) 19 | - [Conway Yasası](#conways-law) 20 | - [Dunbar Sayısı](#dunbars-number) 21 | - [Gall Yasası](#galls-law) 22 | - [Hanlon'un Usturası](#hanlons-razor) 23 | - [Hofstadter Yasası](#hofstadters-law) 24 | - [Hutber Yasası](#hutbers-law) 25 | - [Hype Döngüsü ve Amara Yasası](#the-hype-cycle--amaras-law) 26 | - [Hyrum Yasası (Arabirimlerin Örtülü Hukuku)](#hyrums-law-the-law-of-implicit-interfaces) 27 | - [Moore Yasası](#moores-law) 28 | - [Murphy Yasası / Sod Yasası](#murphys-law--sods-law) 29 | - [Parkinson Yasası](#parkinsons-law) 30 | - [Olgunlaşmamış Optimizasyon Etkisi](#premature-optimization-effect) 31 | - [Putt Yasası](#putts-law) 32 | - [Karmaşıklığın Korunması Yasası (Tesler Yasası)](#the-law-of-conservation-of-complexity-teslers-law) 33 | - [Sızdıran Soyutlamalar Yasası](#the-law-of-leaky-abstractions) 34 | - [Önemsizlik Yasası](#the-law-of-triviality) 35 | - [Unix Felsefesi](#the-unix-philosophy) 36 | - [Spotify Modeli](#the-spotify-model) 37 | - [Wadler Yasası](#wadlers-law) 38 | - [Prensipler](#principles) 39 | - [Dilbert Prensibi](#the-dilbert-principle) 40 | - [Pareto Prensibi (80/20 Kuralı)](#the-pareto-principle-the-8020-rule) 41 | - [Peter Prensibi](#the-peter-principle) 42 | - [Dayanıklılık Prensibi (Postel Yasası)](#the-robustness-principle-postels-law) 43 | - [SOLID](#solid) 44 | - [Tek Sorumluluk Prensibi](#the-single-responsibility-principle) 45 | - [Açık/Kapalı Prensibi](#the-openclosed-principle) 46 | - [Liskov Yerine Geçme Prensibi](#the-liskov-substitution-principle) 47 | - [Arayüz Ayrım Prensibi](#the-interface-segregation-principle) 48 | - [Bağımlılığın Ters Çevrilmesi](#the-dependency-inversion-principle) 49 | - [DRY Prensibi](#the-dry-principle) 50 | - [YAGNI](#yagni) 51 | - [Ek Kaynaklar](#reading-list) 52 | - [TODO](#todo) 53 | 54 | 55 | 56 | ## Giriş 57 | 58 | İnsanların geliştirme hakkında konuşurken tartıştıkları birçok yasa var. Bu depo, en yaygın olanlardan bazılarının referanslarını ve özetini barındırır. Katkıda bulunmak için PR açıp gönderebilirsiniz! 59 | 60 | ❗: Bu depo yasaların, prensiplerin ve modellerin bilgi vermek amaçlı açıklamalarını içerir ve hiçbirini *savunma* amacı gütmez. Bunların hangisinin uygulanıp uygulanmayacağı tamamen tartışma konusudur ve yapılan işe bağlıdır.. 61 | 62 | ## Yasalar 63 | 64 | Tek tek başlayalım! 65 | 66 | ### Amdahl Yasası 67 | 68 | [Wikipedia Amdahl Yasası](https://en.wikipedia.org/wiki/Amdahl%27s_law) 69 | 70 | > Amdahl Yasası kaynakları artırarak bir hesaplama işleminin *olası* hızlanma miktarını hesaplayan bir formülü tanımlar. Genellikle paralel işleme hesaplarında kullanılır ve işlemci sayısının artırılmasının programın paralelleştirilebilme kapasitesine bağlı olarak etkisinin doğru şekilde saplanmasını sağlar. 71 | 72 | En güzel şu örnekle anlatılabilir. Bir programın iki bölümden oluştuğunu düşünelim. Bölüm A sadece tek işlemci ile çalıştırılabilir. Bölüm B ise paralelleştirilebilecek şekilde yazılmış. Bu durumda bu programı çok işlemci ile çalıştırdığımızda Bölüm B'de oluşacak kadar bir kazanım sağlayabiliriz. Bölüm A'da her hangi bir katkı olamayacaktır. 73 | 74 | Aşağıdaki diyagram bazı olası hız geliştirmelerine örnekler içeriyor: 75 | 76 | ![Diagram: Amdahl's Law](../images/amdahls_law.png) 77 | 78 | *(Diyagramın kaynağı: Daniels220 tarafından İngilizce Wikipedia'da, Creative Commons Attribution-Share Alike 3.0 Unported, https://en.wikipedia.org/wiki/File:AmdahlsLaw.svg)* 79 | 80 | Diyagramdaki örneklerden görüldüğü üzere, eğer bir programın sadece %50'si paralelleştirilebiliyorsa 10 işlemciden sonra işlemci eklemek hızda gözle görünür bir artış sağlamıyor ama %95 paralelleştirilebilen bir programda 1000 işlemciden sonra bile işlemci eklemenin hızı artırdığı gözlenebilir. 81 | 82 | [Moore Yasasında](#moores-law) söylenen artışın azalma eğiliminde olması ve aynı zamanda işlemci hızının artışında da ivme kaybı olması, paralelleştirilebilme özelliğini performans artışında anahtar duruma getirdi. Grafik programlama bu konuda en belirgin örnek. Shader tabanlı modern işleme ile pixel ve fragmanların paralel olarak render edilebilmesi sayesinde modern grafik kartlarında binlerce işlemci çekirdeği olabiliyor. 83 | 84 | Ek kaynaklar: 85 | 86 | - [Brooks Yasası](#brooks-law) 87 | - [Moore Yasası ](#moores-law) 88 | 89 | ### Brooks Yasası 90 | 91 | [Wikipedia'da Brooks Yasası](https://en.wikipedia.org/wiki/Brooks%27s_law) 92 | 93 | > Gecikmesi kesinleşmiş projeye yeni insan kaynağı eklemek projeyi daha da geciktirir. 94 | 95 | Bu yasa, gecikmiş bir projeyi hızlandırmak için ek insan kaynağı koymanın projeyi daha geciktireceğini iddia ediyor. Brook'a göre bunun gereksiz bir sadeleştirme olduğu kesin. Yeni katılanların adapte edilmesi ve iletişim karmaşası hemen etkisini göstererek hızın yavaşlamasına sebep olur. Ayrıca, yapılacak işlerin birçoğu genellikle daha küçük parçalara bölünemez ve birden fazla kaynak bu işlerin yapılması için kullanılmaz. Bu durum beklenen artışın sağlanmaması ile sonuçlanır. 96 | 97 | Meşhur "Dokuz kadın ile 1 ayda doğum sağlanamaz" deyimi bu yasanın en pratik anlatımıdır. Bazı işlerin bölünemediği veya paralelleştirilemediği gerçeğini unutmamak lazım. 98 | 99 | '[The Mythical Man Month](#reading-list)' adlı kitabın ana konularından biri budur. 100 | 101 | Ek kaynaklar: 102 | 103 | - [Death March](#todo) 104 | - [Reading List: The Mythical Man Month](#reading-list) 105 | 106 | ### Conway Yasası 107 | 108 | [Wikipedia'da Conway Yasası](https://en.wikipedia.org/wiki/Conway%27s_law) 109 | 110 | Conway yasası der ki; üretilen sistemler kendilerini üreten organizasyonun teknik sınırlarını yansıtır. Bu yasa daha çok organizasyon değişiklikleri sırasında dikkate alınır. Eğer bir organizasyon birbirinden bağımsız küçük birimlerden oluşuyorsa üretilen yazılımlar da buna uygun olacaktır. Eğer bu organizasyon servis odaklı dikey yapılandırılmışsa, yazılımlar bunu yansıtacaktır. 111 | 112 | Ek kaynaklar: 113 | 114 | - [Spotify Modeli](#the-spotify-model) 115 | 116 | ### Dunbar Sayısı 117 | 118 | [Wikipedia'da Dunbar Sayısı](https://en.wikipedia.org/wiki/Dunbar%27s_number) 119 | 120 | "Dunbar'ın sayısı, bir kişinin istikrarlı bir sosyal ilişkide bulunabileceği kişilerin sayısının kavramsal sınırıdır - bu ilişki bireyin ilişkide olduğu her bir kişinin kim olduğunu ve her bir kişinin diğer bir kişiler ile ilişkisini bildiği ilişkidir." Sayının tam değeri konusunda bir anlaşmazlık vardır. "... [Dunbar] insanların ancak 150 kişilik ilişkiler istikrarlı bir şekilde bulunabileceğini söylemiş."... Dunbar sayıyı daha sosyal bir bağlam içine koydu, "sayıyı bir barda içki içmeye davet edildiğinizde sıkılmadan ya da utanmadan kabul edebileceğiniz kişi sayısı olarak değerlendirdi". Bu da 100 ile 250 arasındaki bir sayı olarak düşünülebilir. 121 | 122 | Kişiler arası insani ilişkilerde olduğu gibi, insanlarla kod arasındaki ilişki de sürüdürülebilmek için çaba gerektirir. Karmaşık projelerle karşılaştığımızda ya da bu projeleri yönetmek sorunda kaldığımızda, projeyi ölçekleyebilmek için eğilimlere, politikalara ve modellenmiş prosedürlere yaslanmaya çalışırız. Dunbar sayısını sadece çalışan sayısı büyüdüğünde değil, takımın harcayacağı emeğin kapsamını belirlerken ya da sistemdeki lojistik ek yükün modellenmesine ve otomatikleştirilmesine yardımcı olmak için takımlara yatırım yaparken de göz önünde bulundurulmalıdır. Bir başka mühendislik bağlamında düşünürsek, bu sayı müşteri destek sisteminde nöbetçi olunurken sorumluluğunu alabileceğiniz proje/ürün sayısını belirlerken de rehber olabilir. 123 | 124 | Ek kaynaklar: 125 | 126 | - [Conway Yasası](#conways-law) 127 | 128 | ### Gall Yasası 129 | 130 | [Wikipedia'da Gall Yasası](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law) 131 | 132 | > Çalışan karmaşık bir sistemin her zaman işe yarayan daha basit bir sistemden evrimleştiği kesinlikle söylenebilir. Başlangıçtan itibaren karmaşık tasarlanmış bir sistemin asla çalışmayacağı ve sonradan da düzeltilemeyeceği kesindir. Çalışsan daha basit bir sistem ile başlamanız gerekir. 133 | > ([John Gall](https://en.m.wikipedia.org/wiki/John_Gall_(author))) 134 | 135 | Gall Yasası der ki, çok karmaşık sistemleri *tasarlamaya* çalışmak her zaman başarısızlıkla sonuçlanır. Bu tür sistemlerin ilk denemede başarılı olmaları çok nadir görülür ama genellikle basit sistemlerden evrilirler. 136 | 137 | En klasik örnek günümüzdeki internettir. Şu an çok karmaşık bir sistemdir. Aslında başlangıçta sadece akademik kurumlar arası içerik paylaşımı olarak tanımlanmıştı. Bu tanımı karşılamada çok başarılı oldu ve zamanla gelişerek bugünkü karmaşık halini aldı. 138 | 139 | Ek kaynaklar: 140 | 141 | - [KISS (Keep It Simple, Stupid)](#TODO) 142 | 143 | ### Hanlon'un Usturası 144 | 145 | [Wikipedia'da Hanlon'un Usturası](https://en.wikipedia.org/wiki/Hanlon%27s_razor) 146 | 147 | > Aptallıkla layıkıyla açıklanabilecek bir şeyi, asla kötü niyete bağlamayın. 148 | > Robert J. Hanlon 149 | > Robert J. Hanlon 150 | 151 | Bu prensip, olumsuz sonuçlara yol açan eylemlerin, çoğunlukla kötü niyetin sonucu olmadığını savunmaktadır. Aksine, olumsuz sonuç daha büyük olasılıkla bu eylemlerin ve/veya etkinin tam olarak anlaşılamamasına bağlıdır. 152 | 153 | ### Hofstadter Yasası 154 | 155 | [Wikipedia'da Hofstadter Yasası](https://en.wikipedia.org/wiki/Hofstadter%27s_law) 156 | 157 | > Bir iş her zaman umduğundan daha uzun sürer, Hofstadter yasasını göz önünde bulundursan bile. 158 | > (Douglas Hofstadter) 159 | > (Douglas Hofstadter) 160 | 161 | Bu yasayı bir işin ne kadar süreceğini tahminlenirken hatırlatıldığı için duymuş olabilirsiniz. Herkesin kabul ettiği bir gerçek var ki, yazılım geliştirmede en kötü olduğumuz alan işin ne kadar sürede biteceğini tahmin etmektir. 162 | 163 | '[Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list)' adlı kitaptan bir alıntı. 164 | 165 | Ek kaynaklar: 166 | 167 | - [Reading List: Gödel, Escher, Bach: An Eternal Golden Braid](#reading-list) 168 | 169 | ### Hutber Yasası 170 | 171 | [Wikipedia'da Hutber Yasası ](https://en.wikipedia.org/wiki/Hutber%27s_law) 172 | 173 | > İyileştirme, bozulma anlamına da gelir. 174 | > ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber)) 175 | 176 | Bu yasa der ki; sistemde yapılan bir iyileştirme sistemin diğer taraflarında bozulmaya sebep olabilir ya da başka bozuklukları gizleyebilir, bu da sistemin mevcut durumunun daha da bozulmasına sebep olabilir. 177 | 178 | Örneğin, bir servisin cevap verme zamanında bir geliştirme yapılıp hızlandırılırsa bu durum süreçteki diğer aşamalarda kapasite ve çıktı artışına sebep olabilir. Bu da sistemin diğer taraflarını olumsuz etkileyebilir. 179 | 180 | ### Hype Döngüsü ve Amara Yasası 181 | 182 | [Wikipedia'da Hype Döngüsü](https://en.wikipedia.org/wiki/Hype_cycle) 183 | 184 | > Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz. 185 | > (Roy Amara) 186 | 187 | Hype Döngüsü bir teknolojinin zamanla yarattığı heyecan ve gelişiminin görsel olarak sunumudur ve Gartner tarafından ilk olarak oluşturulmuştur. En güzel anlatım aşağıdaki bir görsel ile yapılabilir: 188 | 189 | ![The Hype Cycle](../images/gartner_hype_cycle.png) 190 | 191 | *(Resmin Kaynağı: Jeremykemp tarafından İngilizce Wikipeda'da, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=10547051)* 192 | 193 | Kısaca anlatmak gerekirse, bu döngü her yeni teknolojinin ilk zamanlarında teknolojinin kendisi ve olası etkisi üzerinde bir heyecan dalgası oluştuğunu iddia ediyor. Ekipler yeni teknolojiler hemen kullanmaya çalışıyorlar ve genelde kendilerini sonuçtan memnun olmamış bir halde buluyorlar. Bu ya teknolojinin henüz olgunlaşmamış olmasından, ya da uygulamanın tam anlamıyla gerçekleşmemiş olmasından olabilir. Belirli bir süre geçtikten sonra, teknolojinin yeterliliği ve pratik kullanım alanları artar ve ekipler daha üretken olmaya başlar. Roy Amara'nın sözü bu durumu en özlü şekilde toparlıyor diyebiliriz - "Bir teknolojinin kısa vadede oluşacak etkisini abartıp, uzun vadede oluşacak etkisini hafife alıyoruz". 194 | 195 | ### Hyrum Yasası (Arabirimlerin Örtülü Hukuku) 196 | 197 | [Hyrum Yasası Web Sitesi](http://www.hyrumslaw.com/) 198 | 199 | > Belli sayıda kullanıcıya ulaştığında, servis sözleşmesinde ne demiş olduğunuzdan bağımsız olarak ürününüzün ya da sisteminizin bütün gözlemlenebilir davranışları artık üçüncü kişilere göre şekillenecektir. 200 | > (Hyrum Wright) 201 | 202 | Hyrum Yasası göre, eğer bir API'nin *oldukça büyük sayılabilecek sayıda kullanıcısı* olduğunda, artık bütün sonuçlar ve davranışlar (API sözleşmesinde belirtilmemiş olsalar bile) kullanıcılara göre şekillenecektir. Buna bir örnek olarak bir API'nin tepki süresi olabilir. Daha kapsamlı bir örnek olarak kullanıcıların bir regex ile dönen cevap metninin içinden hatanın *tipini* ayıkladıkları bir senaryoyu düşünelim. API sözleşmesinde bu cevap metinleri ile ilgili bir şey belirtilmemiş olmasına ve kullanıcıların hata kodunu kullanmalarını belirtilmesine rağmen, cevap metnini değiştirmeniz *bazı* kullanıcıların metni kullanmalarından dolayı hata ile karşılaşmalarına sebep olacaktır. 203 | 204 | Ek kaynaklar: 205 | 206 | - [The Law of Leaky Abstractions](#the-law-of-leaky-abstractions) 207 | - [XKCD 1172](https://xkcd.com/1172/) 208 | 209 | ### Moore Yasası 210 | 211 | [Wikipedia'da Moore Yasası](https://en.wikipedia.org/wiki/Moore%27s_law) 212 | 213 | > Entegre devre içerisindeki transistörlerin sayısı yaklaşık olarak iki yılda bir ikiye katlanır. 214 | 215 | Çoğu zaman yarı-iletken ve çip teknolojisinin gelişim hızını tahmin etmek için kullanılan Moore yasasının, 1970'lerden 2000'lerin sonlarına doğru oldukça doğru olduğu biliyoruz. Son yıllarda, [komponentlerin küçülmesinde fiziksel sınırlara](https://en.wikipedia.org/wiki/Quantum_tunnelling) ulaşıldığı için bu tahminlemenin tutmadığını da söyleyebiliriz. Ama paralelleştirmede uzmanlaşılması ve yarı-iletken teknolojilerindeki devrim potansiyelindeki değişiklikler Moore Yasası'nın yakın zamanda tekrar doğrulanacağını tahminler yapabileceğini düşünebiliriz. 216 | 217 | ### Murphy Yasası / Sod Yasası 218 | 219 | [Wikipedia'da Murphy Yasası](https://en.wikipedia.org/wiki/Murphy%27s_law) 220 | 221 | > Eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider. 222 | 223 | İsmini [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.)'dan alan *Murphy Yasası* der ki eğer bir işin kötü gitme ihtimali varsa mutlaka kötü gider. 224 | 225 | Bu programcılar arasında çok kullanılan bir atasözüdür. Geliştirme yaparken, test ederken ya da canlı sistemlerde çoğunlukla hep beklenmedik sorunlar olur. Bu durum (İngiltere'de yaygın kullanılan) *Sod Yasası* ile de ilişkilendirilebilir: 226 | 227 | > Eğer bir işin kötü gitme ihtimali varsa, olabilecek en kötü zamanda kötüye gidecektir. 228 | 229 | Bu iki 'yasa' daha çok espri amaçlı kullanılır. Bunun yanında, [*Doğrulama Önyargısı*](#TODO) ve [*Seçim Tarafgirliği*](#TODO) gibi olgular bu yasaların insanlar tarafında çok fazla vurgulanmasına sebep olabilir (işler yolundayken hiçbirşeye dikkat etmeyiz, ama bunun yanında sorunlar yaşanınca herşey göze batmaya başlar ve tartışılır). 230 | 231 | Ek kaynaklar: 232 | 233 | - [Doğrulama Önyargısı](#TODO) 234 | - [Seçim Tarafgirliği](#TODO) 235 | 236 | ### Parkinson Yasası 237 | 238 | [Wikipedia'da Parkinson Yasası](https://en.wikipedia.org/wiki/Parkinson%27s_law) 239 | 240 | > Bir iş, daima, bitirilmesi için kendisine ayrılan sürenin hepsini kapsayacak şekilde uzar. 241 | 242 | Orijinal bağlamında, bu kanun bürokrasi alanındaki çalışmalara dayanıyordu. Kötümser bir bakış açısıyla yazılım geliştirme girişimleri için de söylenebilir. Şöyle ki ekipler genelde proje bitiş tarihi yaklaşana kadar düşük verimde çalışırlar, bitiş tarihi yaklaştıkça bitirmek için yoğun bir çaba içine girerler ve sonuç olarak aslında bitiş tarihini tutturmuş olurlar. 243 | 244 | Bu yasa ile [Hofstadter Yasası](#hofstadters-law) birleştirilirse, daha kötümser bir yasaya ulaşılır. Bir iş bitirilmesi için harcanması gereken zamanı kapsar ve *her zaman gecikir*. 245 | 246 | Ek kaynaklar: 247 | 248 | - [Hofstadter Yasası](#hofstadters-law) 249 | 250 | ### Olgunlaşmamış Optimizasyon Etkisi 251 | 252 | [WikiWikiWeb'de Olgunlaşmamış Optimizasyon Etkisi](http://wiki.c2.com/?PrematureOptimization) 253 | 254 | > Vakti gelmeden gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır. 255 | > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en) 256 | 257 | Donald Knuth yazdığı [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements) isimli makalede, "Programcılar, programlarının kritik olmayan bölümlerinin hızını düşünerek veya endişelenerek çok fazla zaman harcarlar ve bu bakış açısı ile yaptıkları verimlilik geliştirmelerin hata ayıklama ve bakım yapma aşamalarına çok olumsuz etkileri olur. Kesinlikle bu tarz küçük geliştirmeleri (zamanımızın %97'sini harcadığımız) göz ardı etmeliyiz, **Vakti gelmeden yapılan optimizasyon bütün kötülüklerin anasıdır** gerçeğini unutmamalılıyız. Yine de, geride kalan % 3'teki kritik fırsatları kaçırmamalıyız." 258 | 259 | Aslında, *olgunlaşmamış optimizasyonu* ihtiyacımızın ne olduğunu bilmeden yapılan optimizasyon olarak tanımlayabiliriz (daha basit kelimelerle). 260 | 261 | ### Putt Yasası 262 | 263 | [Wikipedia'da Putt Yasası](https://en.wikipedia.org/wiki/Putt%27s_Law_and_the_Successful_Technocrat) 264 | 265 | > Teknolojide iki tür insan egemendir, yönetmedikleri şeyleri anlayanlar ve anlamadıkları şeyleri yönetenler. 266 | 267 | Putt yasasını çoğunlukla Putt sonucu takip eder: 268 | 269 | > Her teknik hiyerarşi, zaman içinde bir yetkinlik dönüşümü geliştirir. 270 | 271 | Bu iki cümle der ki grupların organiza olma şekillerindeki seçim kıstasları ve eğilimleri yüzünden bir zaman sonra teknik organizasyonun çalışma seviyelerinde bir grup yetenekli insan varken yönettikleri işin karmaşıklığından ve zorluklarından bihaber bir grup insan da yönetim kademelerini işgal edecektir. Bu durum [Peter Prensibi](#the-peter-principle) ya da [Dilbert Prensibi](#the-dilbert-principle) ile de açıklanabilir. 272 | 273 | Bununla birlikte, bunun gibi yasaların çok büyük genellemeler olduğu ve *bazı* organizasyon türleri için geçerli olabileceği gibi başkaları için geçerli olmayacağı unutulmamalıdır. 274 | 275 | Ek kaynaklar: 276 | 277 | - [Peter Prensibi](#the-peter-principle) 278 | - [Dilbert Prensibi](#the-dilbert-principle) 279 | 280 | ### Karmaşıklığın Korunması Yasası (Tesler Yasası) 281 | 282 | [Wikipedia'da Karmaşıklığın Korunması Yasası](https://en.wikipedia.org/wiki/Law_of_conservation_of_complexity) 283 | 284 | Bu yasa der ki, her sistemde kesinlikle ayıklanamayacak bir miktarda karmaşıklık vardır. 285 | 286 | Bir sistem ve yazılımdaki karmaşıklıkların bazıları dikkatsizlik veya yanlışlıktan ortaya çıkar. Bu kötü kurgulanmış yapının, herhangi bir dikkatsizliğin, ya da problemin kötü modellenmesinin sonucu olabilir. Bu tarz karmaşıklıklar giderilebilir ve sistemden ayıklanabilir. Bunun yanında, bazı karmaşıklıklar sistemin gerçekleridir yani sistemin çözmeye çalıştığı problemin doğası gereği ortaya çıkarlar. Bu tarz karmaşıklıklar sistem içinde farklı yerlere taşınabilirler ama sistemden ayıklanmazlar. 287 | 288 | O yasanın farklı bir yansıması olarak şöyle düşünülebilir, eğer bir karmaşıklık esastan geliyorsa ve sistem sadeleştirilerek bile ayıklanamıyorsa, daha karmaşık bir şekilde davranması beklenen *kullanıcının tarafına taşınabilir*. 289 | 290 | ### Sızdıran Soyutlamalar Yasası 291 | 292 | [Sızdıran Soyutlamalar Yasası, Joel on Software](https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/) 293 | 294 | > Önemsiz sayılmayacak bütün soyutlamar belli ölçüde sızıntı içerir. 295 | > ([Joel Spolsky](https://twitter.com/spolsky)) 296 | 297 | Bu yasa, karmaşık sistemleri sadeleştirmek için kullandığımız soyutlamaların bazı durumlarda soyutlamanın altındaki sistemin öğelerini sorunları ile birlikte sızdırır ve bu da beklenmedik davranışlar ortaya çıkması ile sonuçlanır. 298 | 299 | Dosya açma ve okuma işlemlerini örneklemek için kullanabiliriz. Dosya sistemi arayüzleri altta yeralan çekirdek sistemlerinin bir *soyutlamasıdır*, ki çekirdek sistemleri de aslında manyetik plakalardaki (fash disk ya da SDD) veriyi fiziksel olarak değiştiren işlemlerin soyutlamasıdır. Çoğu durumda, bir dosyayı ikili sistemdeki verilerin akışı olarak soyutlamak işe yarar. Manyetik sürücüler sıralı okuma yapıldığında rastgele erişimli sürücülere göre *daha* hızlıdır (sayfalama hatalarının artmasından dolayı) ama bu durum SDD sürücülerle karşılaştırmada geçerli değildir. Bu durumun üstesinden gelmek için, detayların altında yatan bilgileri (yani geliştiricinin bilmesi gereken uygulama detaylarını) soyutlamanın sızdırıyor olacağı dikkate alınmalıdır. 300 | 301 | Yukarıda verdiğimiz örnek *daha fazla* soyutlanma göz önünde bulundurulursa daha da karmaşıklaşabilir. Linux işletim sistemi dosyalara bir ağ üzerinden erişilmesine olanak sağlıyor ama bu dosyalar sanki yerel dosyalarmış gibi gösterilir. Bu soyutlama da eğer bir network sorunu olursa sızıntı oluşturur. Eğer bir uygulama geliştirici bu tür dosyaları normal dosyalarmış gibi düşünerek geliştirme yaparsa, ağızda oluşan herhangi bir gecikme ya da sorun çözümü sorunlu hale getirecektir. 302 | 303 | Yasa savunmaya çalıştığı durum, herhangi bir soyutlamaya çok fazla güvenmenin alta yatan işlemleri de tam anlamamayla birleşince çözülmeye çalışılan problemin çoğunlukla *daha da* karmaşıklaşması ile sonuçlanacağıdır. 304 | 305 | Ek kaynaklar: 306 | 307 | - [Hyrum Yasası](#hyrums-law-the-law-of-implicit-interfaces) 308 | 309 | Gerçek dünyadan örnekler: 310 | 311 | - [Photoshop'taki yavaş açılma problemi](https://forums.adobe.com/thread/376152): Photoshop bir zamanlar çok yavaş açılırdı, hatta bazen açılması dakikalar sürerdi. Sorunun sebebi program her başlangıçta ön tanımlı yazıcı ile ilgili belli bilgileri çekmeye çalışması olarak gözüküyordu. Eğer yazıcı bir ağ yazıcısıysa açılma daha da uzun sürüyordu. Ağ yazıcılarının yerel yazıcıları gibi *soyutlanması* kullanıcılara bu kötü deneyimi yaşatmış oldu. 312 | 313 | ### Önemsizlik Yasası 314 | 315 | [Wikipedia'da Önemsizlik Yasası](https://en.wikipedia.org/wiki/Law_of_triviality) 316 | 317 | Bu yasa diyor ki, ekipler önemsiz ve kozmetik sorunlara ciddi ve önemli sorunlara göre daha fazla zaman harcarlar. 318 | 319 | En çok kullanılan kurgu örnek nükleer enerji reaktörünü onaylayacak olan komitenin reaktörün genel tasarımını onaylama zamanından çok bisiklet parkının tasarımını onaylamak için zaman harcamasıdır. Çok büyük ve karmaşık konularla ilgili o alanda bir eğitime, tecrübeye ve hazırlığa sahip olmadan kayda değer yorum getirmek zordur. İnsanlar genelde değerli katkılar verdiklerinin görülmesini isterler. Dolayısıyla insanlar kolayca katkı verebilecekleri gerekli ve önemli olmasa bile küçük detaylara odaklanma eğilimi gösterirler. 320 | 321 | Bu kurgu örnek 'Bike Shedding' diye bir deyimin yaygınlaşmasına sebep olmuştur. Türkçe'deki 'pire için yorgan yakmak' ya da 'attığın taş ürküttüğün kurbağaya değsin' gibi deyimlere benzer. 322 | 323 | ### Unix Felsefesi 324 | 325 | [Wikipedia'da Unix Felsefesi](https://en.wikipedia.org/wiki/Unix_philosophy) 326 | 327 | Unix felsefesi şöyle özetlenebilir; bir yazılım parçası olabildiğince küçük olmalı ve sadece bir işi yapmaya odaklanmalıdır. Bu felsefeye uymak sistemleri büyük, karmaşık ve çok amaçlı programlarla oluşturmak yerine küçük, basit ve iyi tanımlanmış parçalardan daha kolayca oluşturmayı sağlar. 328 | 329 | Modern yaklaşımlardan biri olan 'Mikro-service Mimarisi' de bu felsefenin uygulaması olarak düşünülebilir. Çünkü bu mimari ile servislerin küçük, amaç odaklı ve tek bir iş yapacak şekilde geliştirilmesi ve karmaşık yapıların küçük basit bloklar halinde oluşturulması hedefleniyor. 330 | 331 | ### Spotify Modeli 332 | 333 | [Spotify Modeli, Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/) 334 | 335 | Spotify Modeli Spotify'daki uygulamasından dolayı popüler olmuş ekip ve organizasyon yapıları için yeni bir yaklaşımdır. Model basitçe ekiplerin teknolojilere göre değil de özellikler etrafında organize edilmesidir. 336 | 337 | Spotify Modeli kabileler (Tribes), birlikler (Guilds) ve kısımlar (Chapter) gibi organizasyon yapısında kullanılacak öğeleri de yaygın hale getirdi. 338 | 339 | ### Wadler Yasası 340 | 341 | [Wadler Yasası, wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law) 342 | 343 | > Herhangi bir programlama dilini tasarlarken, aşağıdaki listedeki herhangi bir özelliği tartışmak için harcanan zaman iki üzeri özelliğin listeki sırası ile doğru orantılıdır. 344 | > 1. Semantik 345 | > 2. Genel sözdizimi 346 | > 3. Sözcük sözdizimi 347 | > 4. Yorumlardaki sözcük sözdizimi(Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır.)(Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır.) 348 | > (Kısaca semantic için harcanan her bir saat için yorumlardaki sözcük sözdizimi için sekiz saat harcanacaktır.) 349 | 350 | [Önemsizlik Yasasında](#the-law-of-triviality) öne sürülene benzer olarak, Wadler Yasası yeni bir programlama dili tasarlanırken konunun önemi ile o konu için harcanan zaman ters orantılı olduğunu söylüyor. 351 | 352 | Ek kaynaklar: 353 | 354 | - [Önemsizlik Yasası](#the-law-of-triviality) 355 | 356 | ## Prensipler 357 | 358 | Prensiplerin genellikle tasarıma ilişkin rehberlerdir. 359 | 360 | ### Dilbert Prensibi 361 | 362 | [Wikipedia'da Dilbert Prensibi](https://en.wikipedia.org/wiki/Dilbert_principle) 363 | 364 | > Şirketler, yetersiz çalışanları, iş akışından uzaklaştırmak için sistematik olarak yönetici olmaya teşvik etme eğilimindedir. 365 | > *Scott Adams* 366 | 367 | Scot Adams (Dilbert çizgi dizisinin yazarı) [Peter prensibinden](#the-peter-principle) esinlenerek ortaya atılmış bir yönetim kavramıdır. Dilbert prensibine göre yetenekli olmayan çalışanlar yönetim kadorlarına dopru yükseltilirler ki üretime verecekleri zarar aza indirilsin. Adams bunu ilk olarak 1995'te Wall Street Journal'da yazdığı bir makalede açıkladı daha sonra ise 1996'da yazdığı [Dilbert Prensibi](#reading-list) adlı kitabında detaylandırdı. 368 | 369 | Ek kaynaklar: 370 | 371 | - [Peter Prensibi](#the-peter-principle) 372 | - [Putt Yasası](#putts-law) 373 | 374 | ### Pareto Prensibi (80/20 Kuralı) 375 | 376 | [Wikipedia'da Pareto Prensibi](https://en.wikipedia.org/wiki/Pareto_principle) 377 | 378 | > Hayattaki çoğu şey eşit dağılmaz. 379 | 380 | Pareto Prensibi der ki, çıktıların önemli bir çoğunluğu girdilerin çok azı tarafından oluşturulur: 381 | 382 | - Bir yazılımın 80%'i harcanan zamanın %20'sinde yazılır (bir başka deyişle, kodun en zor %20'lik bölümü haracanan zamanın %80'inde yazılır) 383 | - Harcanan eforun %20'si sonucun %80'ini oluşturur 384 | - Yapılan işin %20'si gelirin %80'ini oluşturur 385 | - Koddaki hataların %20'si sistem sorunlarının %80'ini oluşturur 386 | - Özelliklerin %20'si hizmetin %80'ini oluşturur 387 | 388 | 1940'lı yıllarda Romanya kökenli Amerikalı mühendis Dr. Joseph Juran, kendisi kalite kontrolün babası olarak nitelendirilir, [kalite kontrol sorunlarında Pareto Prensibini kullanmaya başladı](https://en.wikipedia.org/wiki/Joseph_M._Juran). 389 | 390 | Bu prensip aynı zamanda 80/20 Kuralı (The Law of the Vital Few and The Principle of Factor Sparsity) olarak da bilinir. 391 | 392 | Gerçek dünyadan örnekler: 393 | 394 | - 2002'de Microsoft en çok rapor edilen hataların üstten %20'sini çözünce kullanıcıların yaşadığı sorunların %80'inin çözüldüğünü gözlemlemiş ([Referans](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)). 395 | 396 | ### Peter Prensibi 397 | 398 | [Wikipedia'da Peter Prensibi](https://en.wikipedia.org/wiki/Peter_principle) 399 | 400 | > Hiyerarşideki insanlar “yetersizlik seviyelerine” göre yükselme eğilimindedir. 401 | > *Laurence J. Peter* 402 | 403 | Laurence J. Peter tarafından geliştirilen bir yönetim konsepti olan Peter Prensibi, işlerinde iyi olan kişilerin, artık başarılı olamadıkları bir seviyeye (kendi "yetersizlik seviyelerine") ulaşana kadar terfi ettiğini gözlemlemektedir. Bu durumda şirket içinde çok tecrübeli olduklarından organizasyondan (çok aykırı birşey yapmadıkları sürece) dışlanmazlar ve az sayıda temel beceriye sahip olacakları bir rolde kalmaya devam edecekler, çünkü onları başarılı kılan orijinal becerileri mutlaka bu yeni rolleri için gereken beceriler değildir. 404 | 405 | Bu, temelde farklı bir beceri kümesi gerektirdiğinden özellikle mühendislerle - kariyerine teknik rollerle başlayan ama sonra kariyer değiştirip diğer mühendisleri *yönetmeye* başlayan - alakalıdır. 406 | 407 | Ek kaynaklar: 408 | 409 | - [Dilbert Prensibi](#the-dilbert-principle) 410 | - [Putt Yasası](#putts-law) 411 | 412 | ### Dayanıklılık Prensibi (Postel Yasası) 413 | 414 | [Wikipedia'da Dayanıklılık Prensibi](https://en.wikipedia.org/wiki/Robustness_principle) 415 | 416 | > Yaptıklarınızda muhafazakar olun, başkalarından kabul ettiğiniz şeyler konusunda liberal olun. 417 | 418 | Genellikle sunucu uygulamaları geliştirirken uygulanabilir. Bu prensip der ki; kendi uygulamanızdan dışarıya veri gönderirken kılı kırk yararcasına dikkatli olun ama dışardan veri alırken mümkün olabilecek her durumda veriyi kabul etmeye çalışın. 419 | 420 | Bu prensibin amacı dayanıklı sistemlere geliştirmektir ve bu sistemler kötü yapılandırılmış girdileri bile anlayabildikleri durumda işleyebilmeliler. Bunun güvenlik açısından kötü amaçlı ve yeterince kontrol edilmemiş girdileri kabul etmek anlamına gelebileceği için riskli olduğu düşünülebilir. Tabiki bu riskin de göz önünde bulundurulması gerekir. 421 | 422 | ### SOLID 423 | 424 | SOLID aşağıdaki beş prensibin baş harflerinden oluşan bir kısaltmadır; 425 | 426 | - S: [Tek Sorumluluk Prensibi - The Single Responsibility Principle](#the-single-responsibility-principle) 427 | - O: [Açık/Kapalı Prensibi - The Open/Closed Principle](#the-openclosed-principle) 428 | - L: [Liskov Yerine Geçme Prensibi - The Liskov Substitution Principle](#the-liskov-substitution-principle) 429 | - I: [Arayüz Ayrım Prensibi - The Interface Segregation Principle](#the-interface-segregation-principle) 430 | - D: [Bağımlılığın Ters Çevrilmesi - The Dependency Inversion Principle](#the-dependency-inversion-principle) 431 | 432 | Bunları [Nesne Tabanlı Proglamlama'nın](#todo) temel prensipleri olarak değerlendirilebilir ve bu prensiplerin programcılara geliştirilebilir ve desteklenebilir sistemler geliştirmelerinde yardımcı oldukları kesindir. 433 | 434 | ### Tek Sorumluluk Prensibi 435 | 436 | [Wikipedia'da Tek Sorumluluk Prensibi](https://en.wikipedia.org/wiki/Single_responsibility_principle) 437 | 438 | > Her sistem parçasının ya da programlama sınıfının sadece bir sorumluluğu olmalı. 439 | 440 | Bu '[SOLID](#solid)' prensiplerinin ilkidir. Bu prensip der ki her bir sistem parçasının yada programlama sınıfının sadece ama sadece bir sorumluluğu olması gerekir. Daha sade anlatmak gerekirse, bir programdaki sadece bir özelliği etkileyen bir değişiklik sadece o özelliği ilgilendiren parça ya da sınıfta yapılmalı. Örneğin, şifrelerin doğruluğunun kontrolünde bir değiştirme yapılacaksa sadece programın o bölümünde değişiklik yapılmalı. 441 | 442 | Teorik olarak, bu prensibe uygun yazılmış kodlar daha sağlam ve değiştirilmesi kolaydır. Sadece tek bir parçanın değiştirildiğine emin olunduğunda değişimi *tesk etmek* de kolay olacaktır. Önceki şifre örneğini düşünürsek, şifrenin zorluk seviyesi değiştirildiğinde sadece şifre ilgili bölümlerin etkilenecektir. Birden fazla sorumluluğu olan bir bölümde olan değişikliğin nereleri etkileceğini hesaplamak daha zordur. 443 | 444 | Ek kaynaklar: 445 | 446 | - [Nesne Tabanlı Programlama](#todo) 447 | - [SOLID](#solid) 448 | 449 | ### Açık/Kapalı Prensibi 450 | 451 | [Wikipedia'da Açık/Kapalı Prensibi](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle) 452 | 453 | > Her sistem parçası (sınıf, modül, fonksiyon vs) genişletilmeye (türev alınmaya, miras alınma vs) açık olmalı ama değiştirilmeye (modifiye etme) kapalı olmalı. 454 | 455 | Bu '[SOLID](#solid)' prensiplerinin ikincisidir ve herhangi bir sistem parçasının *mevcut* davranışının değiştirilememesini ama kullanılarak/türetilerek *genişletilebilmesinin* gerekliliğini savunur. 456 | 457 | Örneğin Markdown formatındaki belgeleri HTML formatına çeviren bir modülü düşünelim. Eğer bu modül kendisi değiştirilmeden yeni bir Markdown formatını da işlemesi sağlanacak şekilde geliştirilebiliyorsa, bu modül genişletilmeye açık demektir. Eğer sonradan değiştirilip Markdown formatı işlemesi ile ilgili geliştirme *yapılamıyorsa*, bu modül değiştirilmeye *kapalı* demektir. 458 | 459 | Bu prensip nesne-tabanlı programlamaya tam uygundur. Şöyle ki, kendi nesne ve sınıflarımızı miras alınarak geliştirmeye uygun ve değiştirmeye ihtiyaç duymayacak şekilde tasarlarsak ve yazarsak nesne-tabanlı programlamaya tam uygun kod yazmış oluruz. 460 | 461 | Ek kaynaklar: 462 | 463 | - [Nesne Tabanlı Programlama](#todo) 464 | - [SOLID](#solid) 465 | 466 | ### Liskov Yerine Geçme Prensibi 467 | 468 | [Wikipedia'da Liskov Yerine Geçme Prensibi](https://en.wikipedia.org/wiki/Liskov_substitution_principle) 469 | 470 | > Bir sistemde var olan bir özellik kendinden türetilmiş türetilmiş bir özellikle herhangi bir sistemsel soruna sebep olmadan yer değiştirilebilmeli. 471 | 472 | '[SOLID](#solid)' prensiplerinin üçüncüsüdür. Bu prensibe göre herhangi bir bileşenin üzerine dayandığı bir özelliği (sınıf vs) o özelliklikten türetilmiş alt özellikle değiştirebilmeliyiz ve bu durumda bir sistem sorununa neden olunmaz ya da alt özelliğin bütün detaylarını bilmeye gerek kalmaz. 473 | 474 | 475 | Örneğin dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Eğer bu metod 'dosya' tipini kullanıyorsa, 'dosya' tipinden türeyen bütün tipleri de kullanabilmelidir. Eğer 'dosya' tipi geriye dönük aramayı destekliyorsa ama 'dosya' tipinden türetilmiş 'ağ dosyası' tipi bunu desteklemiyorsa o zaman 'ağ dosyası' tipi bu prensibi ihlal ediyor demektir. 476 | 477 | Bu prensip nesne-tabanlı programlamanın bağlı olduğu prensiplerden biridir ve geliştiricilerin kafasını karıştırmamak için sınıf hiyerarşisinin dikkatli tarasarlanması gerektiğini söyler. 478 | 479 | Ek kaynaklar: 480 | 481 | - [Nesne Tabanlı Programlama](#todo) 482 | - [SOLID](#solid) 483 | 484 | ### Arayüz Ayrım Prensibi 485 | 486 | [Wikipedia'da Arayüz Ayrım Prensibi](https://en.wikipedia.org/wiki/Interface_segregation_principle) 487 | 488 | > Hiçbir kullanıcı/müşteri/istemci, kullanmadığı yöntemlere bağlı kalmamalıdır. 489 | 490 | '[SOLID](#solid)' prensiplerinin dördüncüsüdür ve bir bileşenin kullanıcılarının, kullanmadığı bir bileşenin işlevlerine bağımlı olmaması gerektiğini belirtir. 491 | 492 | Örnek olarak dosyayı temsil eden bir yapıdan XML verisi okuyan bir metod düşünelim. Bu metod sadece dosyadan byte byte veri okumalı ve dosya içinde ileri ya da geri hareket etmeli. Eğer bu method dosya okuma dışında (dosya izinleri değişimi gibi) herhangi bir özellik değişiminden dolayı güncellenmek zorunda kalınıyorsa bu prensip ihlal edilmiş demektir. 493 | 494 | Bu prensip de nesne-tabanlı programlama ile direk ilişkilidir. 'interface' yapıları, sınıf hiyerarşileri ve soyut türler farklı bileşenler arası bağımlığı en aza indirmek için kullanılır. Duck typing de bu prensibi uygulamaya yardımcı olur. 495 | 496 | Ek kaynaklar: 497 | 498 | - [Nesne Tabanlı Programlama](#todo) 499 | - [SOLID](#solid) 500 | - [Duck Typing](#todo) 501 | - [Ayrışma](#todo) 502 | 503 | ### Bağımlılığın Ters Çevrilmesi 504 | 505 | [Wikipedia'da Bağımlılığın Ters Çevrilmesi](https://en.wikipedia.org/wiki/Dependency_inversion_principle) 506 | 507 | > Yüksek seviye modülleri, düşük seviye uygulamalarına bağlı olmamalıdır. 508 | 509 | '[SOLID](#solid)' prensiplerin beşincisidir. Bu ilke, daha üst seviye bileşenlerinin bağımlılıklarının ayrıntılarını bilmek zorunda olmadıklarını belirtir. 510 | 511 | Örnek olarak bir web sitesinden metadata okuyan bir program düşünelim. Bu programın ana bileşeninin web sitesinden içeriği indiren ve metadayı okuyan bileşenlerinden ne yaptığından haberdar olması gerekir. Eğer bu prensibe uyarsak ana bileşenin byte verisi okuyan ve byte verisinden metada çıkaran soyutlamalara bağımlı olması lazım. Ana bileşenin TCP/IP, HTTP ya da HTML hakında bir detaya hakim olmasına gerek yoktur. 512 | 513 | Bu prensip olması gereken bağımlığı tersine çevirdiği düşünebileceğinden (isminden dolayı) biraz karmaşık gelebilir. Pratikte, ayrı bir düzenleme bileşeninin, soyut türlerin doğru uygulamalarının kullanılmasını sağlaması gerektiği anlamına gelir (önceki örnekte, *bir şey* hala meta veri okuyucu bileşenine bir HTTP dosyası indiricisi ve HTML meta etiketi okuyucu sağlamalıdır). Bu prensip aynı zamanda [Kontrolün Ters Çevirilmesi](#todo) ve [Bağımlık Enjeksiyonu](#todo) gibi konularla da bağlantılıdır. 514 | 515 | Ek kaynaklar: 516 | 517 | - [Nesne Tabanlı Programlama](#todo) 518 | - [SOLID](#solid) 519 | - [Bağımlılığın Ters Çevrilmesi](#todo) 520 | - [Bağımlılık Enjeksiyonu](#todo) 521 | 522 | ### DRY Prensibi 523 | 524 | [Wikipedia'da DRY Prensibi](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) 525 | 526 | > Her bilgi parçasının bir sistem içinde tek, açık ve net bir temsiline sahip olması gerekir. 527 | 528 | *DRY Don't Repeat Yourself* yani Kendini Tekrar Etme deyimin kısaltılmasıdır. İlk olarak Andrew Hunt ve Dave Thomas tarafından [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) kitabında bahsedilmiştir. Bu ilke, geliştiricilere kod tekrarını azaltma ve bilgileri tek bir yerde tutmalarına yardımcı olmayı amaçlamaktadır. 529 | 530 | > DRY'nin tam tersi *WET* olacaktır (Write Everything Twice (Her Şeyi İki Kez Yaz) We Enjoy Typing (Yazmayı Seviyoruz)). 531 | 532 | Uygulamada, aynı bilgi parçasını iki (veya daha fazla) farklı yerde kullanıyorsanız, DRY'yi bunları tek bir tanede birleştirmek ve istediğiniz / ihtiyaç duyduğunuz yerde tekrar kullanmak için kullanabilirsiniz. 533 | 534 | Ek kaynaklar: 535 | 536 | - [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer) 537 | 538 | ### YAGNI 539 | 540 | [Wikipedia'da YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) 541 | 542 | ***Y**ou **A**ren't **G**onna **N**eed **I**t* (İhtiyacın olmayacak) deyiminin kısaltmasıdır. 543 | 544 | > İhtiyaç duyduğunuz şeyleri her zaman ihtiyaç duyduğunuzda geliştirin, onlara ihtiyacınız olacağını düşündüğünüzde değil. 545 | > ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP eş-kurucusu and "Extreme Programming Installed" kitabının yazarı) 546 | 547 | Bu *Aşırı Programlama* (XP) ilkesi, geliştiricilerin yalnızca acil gereksinimler için gerekli olan işlevleri yerine getirmeleri gerektiğini ve daha sonra ihtiyaç duyulabilecek işlevleri uygulayarak geleceği tahmin etme girişimlerinden kaçınmalarını önerir. 548 | 549 | Bu ilkeye bağlı kalmak, kod tabanındaki kullanılmayan kod miktarının ve hiçbir değer getirmeyen işlevlerde haracanan zamanın ve çabanın azalmasını sağlayacaktır. 550 | 551 | Ek kaynaklar: 552 | 553 | - [Reading List: Extreme Programming Installed](#reading-list) 554 | 555 | ## Ek Kaynaklar 556 | 557 | Bu kavramları ilginç bulduysanız, aşağıdaki kitapların keyfini çıkarabilirsiniz. 558 | 559 | - [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Extreme Programming kavramının temel prensiplerini içerir. 560 | - [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Yazılım mühendisliği klasiği sayılabilir. Brooks Yasası bu kitabın ana temasıdır. 561 | - [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Sınıflandırması zor bir kitap. Hofstadter Yasası bu kitaptan alıntıdır. 562 | - [Dilbert Prensibi - Adam Scott](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Amerikadaki kurumsal hayata mizahi bir yaklaşım, [Dilbert Prensibinin](#the-dilbert-principl) sahibinden. 563 | - [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle). 564 | 565 | ## TODO 566 | 567 | Selam!. Buraya ulaştıysanız, henüz yazmadığım bir konunun bağlantısını tıkladınız, bunun için üzgünüm - ve en kısa zamanda tamamlamaya çalışacağım! 568 | 569 | Soru ve önerileriniz için [issue](https://github.com/dwmkerr/hacker-laws/issues) açabilirsiniz, ya da katkıda bulunmak isterseniz [Pull Request](https://github.com/dwmkerr/hacker-laws/pulls) açabilirsiniz. 570 | --------------------------------------------------------------------------------