Най-странните програмни принципи, за които никога не сте чували

реклама

Вече ви преведохме през най-съществените принципи на програмиране 10 основни принципа на програмиране, всеки програмист трябва да следваВинаги пишете код, който може да се поддържа от всеки, който може да свърши работа с вашия софтуер. За тази цел ето няколко програмни принципа, които ще ви помогнат да изчистите постъпката си. Прочетете още за което трябва да знаете, но има друг клас принципи на програмиране, които могат да се докажат още по-изгодно от тези.

Докато гореспоменатите принципи ви учат как да бъдете умен със своя код следните принципи ще ви научат да бъдете мъдър с вашия код. Някои от тях са странни и много от тях са хумористични, но всички са еднакво практични и важни. Внимавайте!

1. Принципът на Блуат

Този има толкова много вариации, че е трудно да се избере един като основен. Може би най-официалната версия е Законът за софтуерното разгръщане, по-често наричан Законът на Завински, кръстен на Джейми Завински и споменат през Изкуството на програмирането UNIX:

„Всяка програма се опитва да се разшири, докато не може да чете поща. Онези програми, които не могат да се разширят, се заменят с тези, които могат. “

instagram viewer

Говори се за тенденцията на програмите да привличат все повече и повече функции във времето и неизбежно се насочват към увеличаване на сложността. Може да знаете това като функция пълзене, което е непрекъснатото добавяне на нови функции, които нямат нищо общо с основната цел на програмата. Изпълзяването на характеристиките води до подуване, а подуването често е нежелателно.

Това може да важи и за производителността на софтуера:

„Софтуерът се разширява, за да консумира всички налични ресурси.“

През 90-те години твърдите дискове и процесори и RAM бяха далеч по-рестриктивни, отколкото днес, а програмистите работиха усилено, за да се поберат, доколкото могат. Но сега, когато имаме по-големи дискове и по-бързи процесори и повече RAM памет, все още се борим да спазваме ограниченията. Всичко се раздува с течение на времето. Ваша работа е да държите това под контрол.

2. Манталитетът "По-лошото е по-добро"

Почти така, сякаш в отговор на принципа на Блут, ние имаме По-лошо е по-добрият манталитет, създаден за първи път от Ричард П. Габриел в есе той написа за качеството на софтуера:

„Софтуерът, който е ограничен, но лесен за използване, може да бъде по-привлекателен за потребителя и пазара, отколкото обратното.“

С други думи, разумно е да разберете това един проблем вашият софтуер има за цел да реши и след това да бъде много добре в това едно нещо. Не го усложнявай. Колкото повече се разнасяте тънки, толкова по-неуправляем става проектът и толкова по-нежелан става за потребителите.

Какво се случва, когато пренебрегнете това? Вие завършвате с Принтер за софтуер на Питър:

„Свръх сложният проект в крайна сметка ще стане твърде сложен, за да бъде разбран дори от собствените му разработчици.“

Той идва от по-широкия принцип на Петър, който гласи, че когато служителите се повишават въз основа на техния момент компетентност, а не очакваната им компетентност на следващата им позиция, всички служители в крайна сметка се оказват на позиция некомпетентност. Вземете този принцип и го приложете към софтуера и ще видите защо по-лошият софтуер често може да бъде по-добър.

3. Законът на Оръл

„Всеки свой собствен код, който не сте гледали в продължение на шест или повече месеца, може да е написан и от друг.“

Тази на пръв поглед демотивационна поговорка всъщност е нещо, което трябва да се възприеме. Факт е, че никой не е перфектен. Може да си мислите, че сте гениален програмист в момента, но има винаги нещо повече, което можете да научите, винаги повече място за отглеждане. Ако някога погледнете назад към стария код и рейтинг, това вероятно означава оттогава научихте нещо ново.

Казано по друг начин: ако погледнете назад към стар проект и не можете да видите нещо, което можете да подобрите или бихте направили различно следващия път, вероятно ще сте в застой като програмист.

4. Принцип на най-малкото учудване

"Ако една необходима функция има висок фактор на учудване, може да се наложи да я препроектирате."

Първо публикувано в IBM Systems Journal още през 1984 г. този принцип все още е учудващо важен днес - може би повече от всякога.

По същество се докосва до деликатния баланс между иновации и познания: ако е част от софтуера твърде различен от други по рода си и не съответства на очакванията на потребителите, тогава те вероятно няма да го приемат. По-добре е да се стремите към постепенни подобрения, които са достатъчно големи, за да бъдат впечатляващи, но достатъчно малки, за да сте запознати.

5. Закон за кибернетичната ентомология

„Винаги има още една грешка.“

Често се обажда Законът на Любарски за кибернетичната ентомология, не е ясно кой всъщност е този Любарски. Принципът му обаче важи за всички програмисти: колкото и чисто да напишете кода си, независимо как стабилно тествате модулите си, без значение колко често рефакторирате класовете си, винаги ще има друга грешка.

В известен смисъл това е принцип на освобождаване. Макар че определено трябва стремя се за код без грешки също е важно да запомните, че перфекционизмът е враг на доброто. Потърсете грешки, поправете ги, когато възникнат, и след това продължете напред.

6. Законът на Керниган

„Отстраняването на грешки е два пъти по-трудно от писането на кода на първо място. Следователно, ако напишете кода възможно най-умело, по дефиниция не сте достатъчно умен, за да го отстраните.

Брайън Керниган, същият този, който е съавтор библията на езика за програмиране на С Защо програмирането на C все още си заслужава да се учиC не е мъртъв език. Всъщност списание IEEE Spectrum го класира като №2 на топ език през 2017 г. Ето пет причини защо. Прочетете още , е известен с този проницателен закон. Същността на това е: пишете добре код, пишете четлив код, пишете прост код, нищо, стига да не е така умен код.

Опитът да огънете програмиращите си мускули със сложност на слонова кост е точно обратното на това, което означава напишете чист и по-добър код 10 съвета за писане на по-чист и по-добър кодПисането на чист код изглежда по-лесно, отколкото всъщност е, но ползите си заслужават. Ето как можете да започнете да пишете по-чист код днес. Прочетете още . Колкото по-трудно е вашият код да се разбере, толкова по-трудно ще бъде да се отстрани грешката, когато неизбежно се счупи.

И като Робърт С. Мартин обяснява, че не става въпрос само за отстраняване на грешки:

„Всъщност съотношението време, прекарано в четене, в сравнение с писане, е много над 10 към 1. Ние постоянно четем стар код като част от усилията да напишем нов код... [Следователно] улесняването на четенето улеснява писането. "

7. Отстраняване на грешки от каучукова патица

Този не е толкова принцип, колкото техника, но е толкова полезен и странен, че ще ни отхвърлят да го изоставим.

Първо казано в Прагматичният програмист, отстраняване на грешки от гумена патица е, когато отстранявате грешката на счупен софтуер, като обяснявате кода си на неодушевен обект (напр. гумена патица) един ред по един. Той работи, защото актът на обяснение задейства различни части от мозъка ви и е по-вероятно да забележите несъответствия и да разберете къде сте сбъркали.

По тази причина гумената патица може да бъде а изненадващо изящен подарък за програмисти Най-добрите Geek подаръци за програмисти: 20 идеи за кодери и нервиТърсите подарък за програмист? Тук са най-добрите подаръци за мотиви, вариращи от механични клавиатури до стоящи бюра и други. Прочетете още , независимо дали го купувате за себе си или за ваш приятел по програмиране.

8. Правилото деветдесет и деветдесет

„Първите 90 процента от кода представляват първите 90 процента от времето за разработка. Останалите 10 процента от кода представляват останалите 90 процента от времето за разработка. “

Тази нахална малка поговорка на Том Каргил е в основата на това, защо програмирането може да бъде толкова разочароващо: колкото и близо да смятате, че сте готови, вие сте много по-далеч отколкото дори най-добрите ви оценки. Когато мислите, че сте готови, вие сте само на половината път.

Това върви ръка за ръка със закона на Хофщадтер:

„Винаги отнема повече време, отколкото очаквате, дори когато вземете предвид Закона на Hofstadter.“

9. Закон на Паркинсън

„Работата се разширява така, че да се запълни времето, достъпно за нейното приключване.“

Този един принцип, създаден от Кирил Нордкот Паркинсън, е по-широк принцип, който абсолютно важи за програмирането и се прилага ръка за ръка с Правилото за деветдесет и деветдесет по-горе: колкото и време да имате, за да завършите проект, е точно колко време ще продължи предприеме. В разработването на софтуер „довършването рано“ е доста мит.

Законът на Паркинсън е причината правилните срокове да са от решаващо значение, ако искате да завършите и изпратите софтуера си. Ето защо съвременните професионални програмисти често препоръчват гъвкави принципи за управление на проекти Как да използвате принципите на Agile Project Management, за да организирате живота сиAgile, най-известният като метод за управление на проекти, е чудесна рамка за управление на личния ви живот. Ще ви покажем кои принципи можете да заемете - включено е безплатно изтегляне на работния лист! Прочетете още и инструменти за управление на проекти като Асана Trello vs. Асана: Най-добрият безплатен инструмент за управление на проекти е ...Изборът между Трело и Асана е труден. Тук сравняваме безплатните планове и ви помагаме да решите кой инструмент за управление на проекти е най-подходящ за вашия екип. Прочетете още .

10. Законът на Брук

„Добавянето на работна ръка към късен софтуерен проект го прави по-късно.“

Следващия път, когато закъснявате с проект, който е вероятно, тъй като повечето програми за програмиране се нуждаят от повече време, отколкото е отделено, не забравяйте, че добавянето на кодери няма да го реши по-бързо.

Всъщност вероятно ще отнеме повече време да завърши. Не само, че трябва да приведете новите кодиращи устройства до скорост, те вероятно ще се сблъскат със съществуващите кодери. Ще трябва да бъдат документирани повече неща, ще е необходима повече бюрокрация, за да се запазят всички на една и съща страница, и повече търкания ще излязат от цялото време на пресичане.

Напред като програмист

Сега, когато знаете тези принципи, всъщност сте по-подходящи за реалния свят на програмиране, а не само на това, което сте срещнали в училище, в уеб курс или в bootcamp. Тези принципи идват от години и години опит и неуспехи.

С тази новооткрита мъдрост вече можете да се насочите към a кариера на програмиране с голямо търсене 10 работни програми за компютърно програмиране, които са в търсенето в моментаТъй като задаването на задание за програмиране може да бъде трудно в сегашния пейзаж, помислете за фокусиране върху една от следните концентрации, за да подобрите шансовете си за успех. Прочетете още с по-реалистични очаквания. За това научете как да увеличете възможностите си за кариерно програмиране Как да подобрите възможностите си за програмиране в кариератаАко се надявате да започнете, рестартирате или подобрите по друг начин кариерата си по програмиране, това не е лесно. Ако сте в колеж, сега е моментът. Ето няколко съвета, които могат да ви отнемат далеч. Прочетете още . И ако решите, че програмирането не е за вас, не се притеснявайте - помислете за едно от тях вместо това некодиращи технологични задачи Кодирането не е за всеки: 9 Технически работни места, които можете да получите без негоНе се обезкуражавайте, ако искате да сте част от областта на технологиите. Има много работни места за хора без умения за кодиране! Прочетете още .

Кой от тези принципи е най-доверен за вас? Знаете ли за други странни програмни принципи, които сме пропуснали? Кажете ни долу в коментарите по-долу!