O'zbekcha (✅)
English
Eng kam hayratlanish tamoyili - Wikipedia
Odamlar tizimning bir qismidir. Dizayn foydalanuvchi tajribasi, taxminlari va aqliy modellariga mos kelishi kerak.
Frans Kaashoek
Ushbu tamoyil tizimlar va interfeyslarni xususiyatlar va funksionallik osongina topiladigan va foydalanuvchi kutganlariga mos keladigan tarzda ishlab chiqilishini taklif qiladi. Foydalanuvchilarni "hayratlantiruvchi" xususiyatlardan intuitiv ravishda mavjud naqsh va amaliyotlarga asoslanib fikr yuritish mumkin bo'lgan xususiyatlar foydasiga to'sqinlik qilish kerak.
Ko'pgina misollar foydalanuvchi interfeyslarida mavjud, masalan, kontentni yangilash uchun mobil ilovada "pastga tortish" ishorasi. Boshqa bir misol buyruq qatori vositalari bo'lishi mumkin, bu erda parametrlar qanday nomlanishi, mavjud bo'lishi kerak bo'lgan umumiy parametrlar va boshqalar uchun ko'plab standartlar mavjud.
Shuningdek qarang:
The Principle of Least Astonishment on Wikipedia
People are part of the system. The design should match the user's experience, expectations, and mental models.
Frans Kaashoek
This principle proposes that systems and interfaces should be designed in a way that features and functionality is easily discovered and matches users expectations. Features that 'surprise' users should be discouraged in favour of features that can be intuitively reasoned about based on existing patterns and practices.
Many examples are present in user interfaces, such as a 'pull down' gesture on a mobile appliation to refresh content. Another example would be command line tools, where many standards exist for how parameters are named, common parameters that should be available and so on.
See also:
Taqsimlangan hisoblash xatolari - Wikipedia
Tarmoqli hisoblash xatolari nomi bilan ham tanilgan, xatoliklar tarqatilgan hisoblashlar haqidagi taxminlar (yoki eʼtiqodlar) roʻyxati boʻlib, bu dasturiy taʼminotni ishlab chiqishda nosozliklarga olib kelishi mumkin. Taxminlar quyidagilardan iborat:
- Tarmoq ishonchli
- Kechikish nolga teng
- Tarmoqli kengligi cheksizdir
- Tarmoq xavfsiz
- Topologiya o'zgarmaydi
- Bitta administrator bor
- Transport narxi nolga teng
- Tarmoq bir hil
Dastlabki to'rtta element Bill Joy va Tom Lyon tomonidan 1991 yilda ro'yxatga olingan va birinchi bo'lib Jeyms Gosling tomonidan "Tarmoqli hisoblash xatolari" sifatida tasniflangan. L. Peter Deutsch 5, 6 va 7-noto'g'rilarni qo'shib qo'ydi. 90-yillarning oxirida Gosling 8-chi xatoni qo'shdi.
Guruh o'sha paytda Sun Microsystems ichida sodir bo'layotgan voqealardan ilhomlangan.
Bardoshli kodni loyihalashda ushbu xatolarni diqqat bilan ko'rib chiqish kerak; Agar ushbu noto'g'ri tushunchalarning har biri tarqalgan tizimlarning haqiqatlari va murakkabliklari bilan shug'ullana olmaydigan noto'g'ri mantiqqa olib kelishi mumkin.
Shuningdek qarang: Taqsimllangan hisoblash xatolarini qidirish (1-qism) - Vaidehi Joshi Medium
The Fallacies of Distributed Computing on Wikipedia
Also known as Fallacies of Networked Computing, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
- The network is reliable
- Latency is zero
- Bandwidth is infinite
- The network is secure
- Topology doesn't change
- There is one administrator
- Transport cost is zero
- The network is homogeneous
The first four items were listed by Bill Joy and Tom Lyon around 1991 and first classified by James Gosling as the "Fallacies of Networked Computing". L. Peter Deutsch added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
The group was inspired by what was happening at the time inside Sun Microsystems.
These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
See also:
Bu "You Ain't Gonna Need It" (Sizga kerak bo'lmaydi) so'zining qisqartmasi.
Har doim narsalarni sizga haqiqatan ham kerak bo'lganda amalga oshiring, hech qachon ularga muhtojligingizni oldindan bilganingizda.
(Ron Jeffries) (XP hammuassisi va "O'rnatilgan ekstremal dasturlash" kitobining muallifi)
Ushbu Extreme Programming (XP) tamoyilini ishlab chiquvchilarga faqat bevosita talablar uchun zarur bo'lgan funksionallikni amalga oshirishi va keyinchalik kerak bo'lishi mumkin bo'lgan funksiyalarni amalga oshirish orqali kelajakni bashorat qilishga urinishlardan qochish kerakligini taklif qiladi.
Ushbu tamoyilga rioya qilish kodlar bazasida foydalanilmagan kod miqdorini kamaytirishi va hech qanday qiymat keltirmaydigan funksionallikka vaqt va kuch sarflanishiga yo'l qo'ymaslik kerak.
Shuningdek qarang: O`qishingiz kerak: Exstrimal Dasturlash o`rnatilgan
This is an acronym for You Ain't Gonna Need It.
Always implement things when you actually need them, never when you just foresee that you need them.
(Ron Jeffries) (XP co-founder and author of the book "Extreme Programming Installed")
This Extreme Programming (XP) principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later.
Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value.
Oddiy tuting, ahmoq.
KISS tamoyili shuni ko'rsatadiki, ko'pchilik tizimlar, agar ularni murakkablashtirgandan ko'ra oddiy bo'lsa, yaxshi ishlaydi; shuning uchun dizaynda soddalik asosiy maqsad bo'lishi kerak va keraksiz murakkablikdan qochish kerak. 1960 yilda AQSh dengiz flotida paydo bo'lgan bu ibora samolyot muhandisi Kelli Jonson bilan bog'langan.
Bu tamoyilini Jonsonning dizaynerlar guruhiga bir nechta asboblarni topshirganligi haqidagi hikoya eng yaxshi misol qilib ko'rsatadi, chunki ular loyihalashtirgan reaktiv samolyotni jangovar sharoitlarda faqat shu asboblar bilan ta'mirlash mumkin bo'lishi kerak. Demak, "ahmoq" muhandislarning o'z imkoniyatlarini emas, balki narsalarni buzish usuli va ularni ta'mirlash uchun mavjud vositalarning murakkabligi o'rtasidagi munosabatni anglatadi.
Shuningdek qarang: Gall qonuni
Keep it simple, stupid
The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided. Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves.
See also: Gall's Law
Bog'liqlik Inversiyasi tamoyili - Wikipedia
Yuqori darajadagi modullar past darajadagi ilovalarga bog'liq bo'lmasligi kerak.
"SOLID" tamoyillarining beshinchisi. Ushbu tamoyil yuqori darajadagi orkestrlash komponentlari o'zlarining bog'liqliklari tafsilotlarini bilishlari shart emasligini bildiradi.
Misol tariqasida, bizda veb-saytdagi metama'lumotlarni o'qiydigan dastur borligini tasavvur qiling. Biz asosiy komponent veb-sahifa tarkibini yuklab olish uchun komponent, so'ngra metama'lumotlarni o'qiy oladigan komponent haqida bilishi kerak deb taxmin qilamiz. Agar biz qaramlik inversiyasini hisobga oladigan bo'lsak, asosiy komponent faqat bayt ma'lumotlarini oladigan mavhum komponentga, keyin esa bayt oqimidan metama'lumotlarni o'qiy oladigan mavhum komponentga bog'liq bo'ladi. Asosiy komponent TCP/IP, HTTP, HTML va boshqalar haqida bilmaydi.
Bu tamoyil murakkab, chunki u tizimning kutilayotgan bog'liqliklarini (shuning uchun nomini) «invertatsiya qilish» kabi ko'rinishi mumkin. Amalda, bu, shuningdek, alohida orkestrlash komponenti mavhum turlarning to'g'ri bajarilishini ta'minlashi kerakligini anglatadi (masalan, oldingi misolda, metadata o'quvchi komponentini hali ham HTTP faylni yuklab oluvchi va HTML meta tegini o'quvchi bilan ta'minlashi kerak). Keyin bu Boshqaruvning Inversiyasi va Qaramlik in'ektsiyasi kabi naqshlarga to'g'ri keladi.
Shuningdek qarang:
The Dependency Inversion Principle on Wikipedia
High-level modules should not be dependent on low-level implementations.
The fifth of the 'SOLID' principles. This principle states that higher-level orchestrating components should not have to know the details of their dependencies.
As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, something must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as Inversion of Control and Dependency Injection.
See also:
Interfeyslarga bo`lish tamoyili - Wikipedia
Hech bir mijoz o'zi ishlatmaydigan usullarga qaram bo'lishga majburlanmasligi kerak.
"SOLID" tamoyillarining to'rtinchisi. Ushbu printsip komponentning iste'molchilari aslida foydalanmayotgan komponentning funktsiyalariga bog'liq bo'lmasligi kerakligini bildiradi.
Misol tariqasida, bizda faylni ifodalovchi tuzilmadan XML hujjatini o'qish usuli borligini tasavvur qiling. U faqat baytlarni o'qishi, faylda oldinga yoki orqaga siljishi kerak. Agar fayl tuzilmasining bog'liq bo'lmagan xususiyati o'zgarganligi sababli ushbu usulni yangilash kerak bo'lsa (masalan, fayl xavfsizligini ifodalash uchun foydalaniladigan ruxsatlar modelining yangilanishi), u holda printsip bekor qilingan. Fayl uchun "seekable-stream" interfeysini amalga oshirish va XML o'quvchi uchun undan foydalanish yaxshiroq bo'lar edi.
Ushbu tamoyil ob'ektga yo'naltirilgan dasturlash uchun alohida ahamiyatga ega, bu erda interfeyslar, ierarxiyalar va mavhum turlar turli komponentlar orasidagi bog'lanishni minimallashtirish uchun ishlatiladi. Duck typing - bu aniq interfeyslarni yo'q qilish orqali ushbu printsipni amalga oshiradigan metodologiya.
Shuningdek qarang:
The Interface Segregation Principle on Wikipedia
No client should be forced to depend on methods it does not use.
The fourth of the 'SOLID' principles. This principle states that consumers of a component should not depend on functions of that component which it doesn't actually use.
As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a 'seekable-stream' interface, and for the XML reader to use that.
This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to minimise the coupling between different components. Duck typing is a methodology which enforces this principle by eliminating explicit interfaces.
See also:
Liskovning o'rin almashish tamoyili on Wikipedia
Tizimni buzmasdan turni pastki turga almashtirish mumkin bo'lishi kerak.
"SOLID" tamoyillarining uchinchisi. Ushbu tamoyil shuni ko'rsatadiki, agar komponent bir turga tayansa, u tizimning ishlamay qolishi yoki ushbu kichik turning tafsilotlarini bilmasdan turib, ushbu turdagi kichik turlardan foydalanish imkoniyatiga ega bo'lishi kerak.
Misol tariqasida, bizda faylni ifodalovchi tuzilmadan XML hujjatini o'qish usuli borligini tasavvur qiling. Agar usul asosiy turdagi "fayl" dan foydalansa, u holda "fayl" dan kelib chiqadigan har qanday narsa funktsiyada ishlatilishi kerak. Agar "fayl" teskari qidirishni qo'llab-quvvatlasa va XML tahlilchisi bu funktsiyadan foydalansa, lekin teskari qidirishga urinishda olingan "tarmoq fayli" turi muvaffaqiyatsiz bo'lsa, "tarmoq fayli" printsipni buzgan bo'ladi.
Ushbu tamoyil ob'ektga yo'naltirilgan dasturlash uchun alohida ahamiyatga ega, bunda tizim foydalanuvchilarini chalkashtirib yubormaslik uchun tip ierarxiyasini diqqat bilan modellashtirish kerak.
Shuningdek qarang:
The Liskov Substitution Principle on Wikipedia
It should be possible to replace a type with a subtype, without breaking the system.
The third of the 'SOLID' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be usable in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
See also:
Ochiq yopiqlik tamoyili Wikipedia
Ob'ektlar uzaytirish uchun ochiq va o'zgartirish uchun yopiq bo'lishi kerak.
"SOLID" tamoyillarining ikkinchisi. Ushbu tamoyil ob'ektlar (sinflar, modullar, funktsiyalar va boshqalar bo'lishi mumkin) o'zlarining xatti-harakatlarini kengaytirish imkoniyatiga ega bo'lishlari kerakligini, lekin ularning mavjud xatti-harakatlarini o'zgartirib bo'lmasligini bildiradi.
Gipotetik misol sifatida Markdown hujjatini HTMLga aylantira oladigan modulni tasavvur qiling. Endi tasavvur qiling-a, Markdown spetsifikatsiyasiga matematik tenglamalarni qo'llab-quvvatlaydigan yangi sintaksis qo'shildi. Yangi matematik sintaksisni amalga oshirish uchun modul kengaytmalarga ochiq bo'lishi kerak. Biroq, mavjud sintaksis ilovalari (masalan, paragraflar, o'qlar va boshqalar) o'zgartirish uchun yopilishi kerak. Ular allaqachon ishlaydi, biz odamlar ularni o'zgartirishini xohlamaymiz.
Ushbu printsip ob'ektga yo'naltirilgan dasturlash uchun alohida ahamiyatga ega, bunda biz osongina kengaytiriladigan ob'ektlarni loyihalashimiz mumkin, lekin ularning mavjud xatti-harakatlari kutilmagan tarzda o'zgarishi mumkin bo'lgan ob'ektlarni loyihalashdan qochamiz.
Shuningdek qarang:
The Open/Closed Principle on Wikipedia
Entities should be open for extension and closed for modification.
The second of the 'SOLID' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour extended, but that their existing behaviour should not be able to be modified.
As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. Now imagine there is a new syntax added to the Markdown specification, which adds support for mathematical equations. The module should be open to extension to implement the new mathematics syntax. However, existing syntax implementations (like paragraphs, bullets, etc) should be closed for modification. They already work, we don't want people to change them.
This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.
See also:
Yagona javobgarlik tamoyili - Wikipedia
Har bir modul yoki sinf faqat bitta mas'uliyatga ega bo'lishi kerak.
"SOLID" tamoyillarining birinchisi. Ushbu tamoyil modullar yoki sinflar bir narsani va faqat bitta narsani bajarishi kerakligini ko'rsatadi. Amaliy ma'noda, bu dasturning xususiyatiga bitta, kichik o'zgartirish faqat bitta komponentni o'zgartirishni talab qilishini anglatadi. Masalan, parolni murakkablik uchun tekshirish usulini o'zgartirish dasturning faqat bitta qismini o'zgartirishni talab qilishi kerak.
Nazariy jihatdan, bu kodni yanada mustahkam va o'zgartirishni osonlashtirishi kerak. O'zgartirilayotgan komponentning yagona mas'uliyati borligini bilish, bu o'zgarishni sinab ko'rish osonroq bo'lishi kerakligini anglatadi. Oldingi misoldan foydalanib, parol murakkabligi komponentini o'zgartirish faqat parol murakkabligi bilan bog'liq xususiyatlarga ta'sir qilishi mumkin. Ko'p mas'uliyatli tarkibiy qismga o'zgartirishning ta'siri haqida fikr yuritish ancha qiyin bo'lishi mumkin.
Shuningdek qarang:
The Single Responsibility Principle on Wikipedia
Every module or class should have a single responsibility only.
The first of the "SOLID" principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
Theoretically, this should make the code more robust, and easier to change. Knowing that a component being changed has a single responsibility only means that testing that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
See also:
Bu qisqartma bo'lib, u quyidagilarga ishora qiladi:
- S: Yagona javobgarlik tamoyili
- O: Ochiq/Yopiqlik tamoyili
- L: Liskovning o`rin almashtirish tamoyili
- I: Interfeyslarga bo`lish tamoyili
- D: Bog’liqlik Inversiyasi tamoyili
Bular Ob'ektga yo'naltirilgan dasturlashning asosiy tamoyillari. Bu kabi dizayn tamoyillari ishlab chiquvchilarga yanada barqaror tizimlarni yaratishga yordam berishi kerak.
This is an acronym, which refers to:
- S: The Single Responsibility Principle
- O: The Open/Closed Principle
- L: The Liskov Substitution Principle
- I: The Interface Segregation Principle
- D: The Dependency Inversion Principle
These are key principles in Object-Oriented Programming. Design principles such as these should be able to aid developers build more maintainable systems.
Barqarorlik tamoyili Wikipedia
Qilayotgan ishlaringizda konservativ bo'ling, boshqalardan qabul qilgan narsada liberal bo'ling.
Ko'pincha server ilovalarini ishlab chiqishda qo'llaniladigan ushbu tamoyil siz boshqalarga yuborgan narsangiz imkon qadar minimal va mos bo'lishi kerakligini ta'kidlaydi, lekin agar uni qayta ishlash mumkin bo'lsa, mos kelmaydigan kiritishga ruxsat berishni maqsad qilishingiz kerak.
Ushbu tamoyilning maqsadi mustahkam tizimlarni yaratishdir, chunki agar niyat hali ham tushunilsa, ular noto'g'ri shakllangan ma'lumotlarni boshqarishi mumkin. Biroq, noto'g'ri kiritilgan ma'lumotlarni qabul qilish, ayniqsa, bunday kirishni qayta ishlash yaxshi sinovdan o'tkazilmagan bo'lsa, xavfsizlikka ta'sir qilishi mumkin. Ushbu ta'sirlar va boshqa masalalar Erik Allman tomonidan "Qayta ko'rib chiqilgan mustahkamlik printsipi" kitobida tasvirlangan.
Vaqt o'tishi bilan mos kelmaydigan kiritishga ruxsat berish, protokollarning rivojlanish qobiliyatini buzishi mumkin, chunki amalga oshiruvchilar oxir-oqibat o'z xususiyatlarini yaratish uchun ushbu liberallikka tayanadilar.
Shuningdek qarang: Hyrum qonuni
The Robustness Principle on Wikipedia
Be conservative in what you do, be liberal in what you accept from others.
Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should aim to allow non-conformant input if it can be processed.
The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested. These implications and other issues are described by Eric Allman in The Robustness Principle Reconsidered.
Allowing non-conformant input, in time, may undermine the ability of protocols to evolve as implementors will eventually rely on this liberality to build their features.
See Also: Hyrum's Law
The Peter Principle on Wikipedia
Ierarxiyadagi odamlar odatda o'zlarining "qobiliyatsizlik darajasi" ga ko'tarilishadi.
Laurence J. Peter
Lorens J. Piter tomonidan ishlab chiqilgan boshqaruv kontseptsiyasi, Piter printsipi, o'z ishlarida yaxshi bo'lgan odamlar, ular endi muvaffaqiyatga erisha olmaydigan darajaga (ularning "qobiliyatsizlik darajasi") yetguncha ko'tarilishini kuzatadi. Ayni paytda, ular kattaroq bo'lganligi sababli, ular tashkilotdan chetlatilish ehtimoli kamroq (agar ular juda yomon ishlamasa) va o'zlarining ichki ko'nikmalariga ega bo'lmagan rolda yashashda davom etadilar, chunki ularni yaratgan asl qobiliyatlari Muvaffaqiyatli bo'lish ularning yangi ishlari uchun zarur bo'lgan ko'nikmalar emas.
Bu muhandislar uchun alohida qiziqish uyg'otadi - ular dastlab chuqur texnik rollarda boshlanadi, lekin ko'pincha boshqa muhandislarni boshqarishga olib keladigan martaba yo'liga ega - bu mutlaqo boshqacha mahorat to'plamini talab qiladi.
Shuningdek qarang:
The Peter Principle on Wikipedia
People in a hierarchy tend to rise to their "level of incompetence".
Laurence J. Peter
A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to managing other engineers - which requires a fundamentally different skill set.
See Also:
The Shirky Principle explained
Institutlar o'zlari hal qiladigan muammoni saqlab qolishga harakat qiladilar.
Clay Shirky
Shirkiy printsipi shuni ko'rsatadiki, murakkab echimlar - kompaniya, sanoat yoki texnologiya - ular hal qilayotgan muammoga shunchalik e'tibor qaratishlari mumkinki, ular beixtiyor muammoning o'zini davom ettirishi mumkin. Bu qasddan bo'lishi mumkin (muammoning yangi nuanslarini topishga intilayotgan kompaniya, bu muammoni hal qilishni davom ettirishni asoslaydi) yoki beixtiyor (muammoni to'liq hal qiladigan yoki uni bartaraf etadigan echimni qabul qila olmasligi yoki qurishni xohlamasligi).
Bog'liq bo'lgan:
- Apton Sinklerning mashhur satri: "Odamning maoshi uning tushunmasligiga bog'liq bo'lsa, biror narsani tushunishga majbur qilish qiyin!"
- Kley Kristensenning “Innovatorning dilemmasi”
Shuningdek qarang:
The Shirky Principle explained
Institutions will try to preserve the problem to which they are the solution.
Clay Shirky
The Shirky Principle suggests that complex solutions - a company, an industry, or a technology - can become so focused on the problem that they are solving, that they can inadvertently perpetuate the problem itself. This may be deliberate (a company striving to find new nuances to a problem which justify continued development of a solution), or inadvertent (being unable or unwilling to accept or build a solution which solves the problem completely or obviates it).
Related to:
- Upton Sinclair's famous line, "It is difficult to get a man to understand something, when his salary depends upon his not understanding it!"
- Clay Christensen's The Innovator's Dilemma
See also:
Hayotdagi ko'p narsalar bir tekis taqsimlanmagan.
Pareto tamoyili shuni ko'rsatadiki, ba'zi hollarda natijalarning aksariyati ozchilikdan kelib chiqadi:
- Muayyan dasturiy ta'minotning 80% umumiy ajratilgan vaqtning 20% da yozilishi mumkin (aksincha, kodning eng qiyin 20% 80% vaqtni oladi)
- Harakatning 20 foizi natijaning 80 foizini beradi
- Ishning 20 foizi daromadning 80 foizini tashkil qiladi
- 20% xatolar 80% buzilishlarga olib keladi
- Xususiyatlarning 20 foizi foydalanishning 80 foizini tashkil qiladi
1940-yillarda amerikalik-ruminiyalik muhandis doktor Jozef Juran sifat nazoratining otasi sifatida tanilgan, Pareto tamoyilini sifat masalalariga qo'llay boshladi.
Ushbu tamoyil, shuningdek, 80/20 qoidasi, Hayotiy Ozchilik Qonuni va Omillarning kamligi tamoyili sifatida ham tanilgan.
Haqiqiy dunyo misollari:
- 2002 yilda Microsoft eng ko'p xabar qilingan xatolarning 20 foizini tuzatib, Windows va ofisdagi tegishli xatolar va ishdan chiqishlarning 80 foizini yo'q qilishini xabar qildi (Ma'lumotnoma).
The Pareto Principle on Wikipedia
Most things in life are not distributed evenly.
The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
- 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time)
- 20% of the effort produces 80% of the result
- 20% of the work creates 80% of the revenue
- 20% of the bugs cause 80% of the crashes
- 20% of the features cause 80% of the usage
In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, began to apply the Pareto principle to quality issues.
This principle is also known as: The 80/20 Rule, The Law of the Vital Few, and The Principle of Factor Sparsity.
Real-world examples:
- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated (Reference).
The Dilbert Principle on Wikipedia
Kompaniyalar layoqatsiz xodimlarni ish jarayonidan olib tashlash uchun boshqaruvga muntazam ravishda ko'tarishga moyildirlar.
Scott Adams
Skott Adams (Dilbert komiks yaratuvchisi) tomonidan ishlab chiqilgan boshqaruv konsepsiyasi, Dilbert printsipi Piter printsipidan ilhomlangan. Dilbert printsipiga ko'ra, hech qachon malakali bo'lmagan xodimlar etkazilishi mumkin bo'lgan zararni cheklash uchun rahbarlikka ko'tariladi. Adams birinchi marta 1995 yilda Wall Street Journal maqolasida printsipni tushuntirgan va uni 1996 yilda "Dilbert printsipi" biznes kitobida kengaytirgan.
Shuningdek qarang:
The Dilbert Principle on Wikipedia
Companies tend to systematically promote incompetent employees to management to get them out of the workflow.
Scott Adams
A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by The Peter Principle. Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, The Dilbert Principle.
See Also:
O'lik dengiz effekti Bruce F. Webster
"... [T] ko'proq iqtidorli va samarali IT muhandislari ketishlari mumkin bo'lganlar - bug'lanish uchun ... [qolganlar] ortda qoladiganlar [qoldiqlar] - eng kam qobiliyatli va samarali IT muhandislari. ."
Bryus F. Webster
"O'lik dengiz effekti" har qanday tashkilotda muhandislarning ko'nikmalari / iste'dodlari / samaradorligi ko'pincha ularning kompaniyadagi vaqtiga teskari proportsional ekanligini ko'rsatadi.
Odatda, yuqori malakali muhandislar boshqa joyda ish topishni oson topadilar va birinchi bo'lib buni amalga oshiradilar. Eskirgan yoki zaif ko'nikmalarga ega muhandislar kompaniyada qolishga moyil bo'ladi, chunki boshqa joyda ish topish qiyin. Bu, ayniqsa, agar ular kompaniyada ishlagan vaqtlari davomida qo'shimcha maoshni oshirgan bo'lsalar, yaqqol namoyon bo'ladi, chunki boshqa joylarda ekvivalent ish haqi olish qiyin bo'lishi mumkin.
The Dead Sea Effect on Bruce F. Webster
"... [T]he more talented and effective IT engineers are the ones most likely to leave - to evaporate ... [those who tend to] remain behind [are] the 'residue' — the least talented and effective IT engineers."
Bruce F. Webster
The "Dead Sea Effect" suggests that in any organisation, the skills/talent/efficacy of engineers is often inversely proportional to their time in the company.
Typically, highly skilled engineers find it easy to gain employment elsewhere and are the first to do so. Engineers who have obsolete or weak skills will tend to remain with the company, as finding employment elsewhere is difficult. This is particularly pronounced if they have gained incremental pay rises over their time in the company, as it can be challenging to get equivalent remuneration elsewhere.
Mavjud vaziyatning sabablari tushunilmaguncha islohotlar o'tkazilmasligi kerak.
Ushbu tamoyil texnik qarzni bartaraf etishda dasturiy ta'minot muhandisligida dolzarbdir. Dasturning har bir satri dastlab kimdir tomonidan negadir yozilgan. Chesterton's Fence, birinchi qarashda ortiqcha yoki noto'g'ri ko'rinsa ham, kodni o'zgartirish yoki olib tashlashdan oldin uning konteksti va ma'nosini to'liq tushunishga harakat qilish kerakligini taklif qiladi.
Bu tamoyilning nomi G.K.Chestertonning hikoyasidan kelib chiqqan. . Bir kishi yo'lning o'rtasidan o'tib ketayotgan panjaraga duch keldi. Bu befoyda panjara to‘siq bo‘layotganidan hokimga shikoyat qiladi va uni olib tashlashni so‘raydi. Hokim birinchi navbatda nega panjara borligini so'raydi. Erkak bilmayman desa, shahar hokimi: "Agar uning maqsadini bilmasangiz, men uni olib tashlashingizga albatta ruxsat bermayman. Boring va undan foydalanishni bilib oling, keyin yo'q qilishingizga ruxsat beraman", deydi. u."
Chesterton's Fence on Wikipedia
Reforms should not be made until the reasoning behind the existing state of affairs is understood.
This principle is relevant in software engineering when removing technical debt. Each line of a program was originally written by someone for some reason. Chesterton's Fence suggests that one should try to understand the context and meaning of the code fully, before changing or removing it, even if at first glance it seems redundant or incorrect.
The name of this principle comes from a story by G.K. Chesterton. A man comes across a fence crossing the middle of the road. He complains to the mayor that this useless fence is getting in the way, and asks to remove it. The mayor asks why the fence is there in the first place. When the man says he doesn't know, the mayor says, "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."
Barcha modellar no'tg'ri WikiMedia
Barcha modellar noto'g'ri, lekin ba'zilari foydali.
George Box
Ushbu tamoyil tizimlarning barcha modellari nuqsonli ekanligini ko'rsatadi, ammo ular juda nuqsonli bo'lmasa, ular foydali bo'lishi mumkin. Ushbu tamoyil statistikada ildiz otgan, ammo ilmiy va hisoblash modellariga ham tegishli.
Ko'pgina dasturiy ta'minotning asosiy talabi qandaydir tizimni modellashtirishdir. Modellashtirilayotgan tizim kompyuter tarmog'i, kutubxona, ijtimoiy aloqalar grafigi yoki boshqa turdagi tizim bo'lishidan qat'i nazar, dizayner modellashtirish uchun tegishli tafsilotlar darajasini tanlashi kerak. Haddan tashqari tafsilotlar haddan tashqari murakkablikka olib kelishi mumkin, juda kam tafsilot modelning ishlashiga xalaqit berishi mumkin.
Shuningdek qarang: The Law of Leaky Abstractions
All models are wrong, but some are useful.
George Box
This principle suggests that all models of systems are flawed, but that as long as they are not too flawed they may be useful. This principle has its roots in statistics but applies to scientific and computing models as well.
A fundamental requirement of most software is to model a system of some kind. Regardless of whether the system being modeled is a computer network, a library, a graph of social connections or any other kind of system, the designer will have to decide an appropriate level of detail to model. Excessive detail may lead to too much complexity, too little detail may prevent the model from being functional.
See also: The Law of Leaky Abstractions