Абсурдните закони на софтуерния свят

Замисляли ли сте се защо умните хора като разработчиците на софтуер го прецакват толкова често? Има хора, които го направиха. В тази публикация правим преглед някои от неписаните закони, които описват поведението на професионалистите на изчисленията.

Първият ми компютър беше Commodore 64. Почти 30 kb RAM беше за системата, оставяйки 32 kb за текстообработка, игри, счетоводство на семейния бизнес и почти всичко, което правя с компютъра с 6 gb, който притежавам. Това оставя въпроса отворен Отговаря ли днешното оборудване на нуждите на софтуера или софтуерът използва повече хардуерни ресурси, тъй като те са налични?

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

Ето причините.

Законът на Завински

Разработчикът на Netscape Джейми Завински твърди това Всяка програма включва функции, докато не е в състояние да чете имейли. Ако не успее, той е заменен от друг, който е способен да го направи.

Когато го каза, шегата беше, че той се позовава на програми, които първоначално не са били предназначени за имейл клиенти. Той спря да бъде смешен, когато беше открито, че много приложения в Google Play искат разрешение за достъп до телефонни компоненти и потребителски данни, които не се нуждаят, за да си свършат работата.

Някои тълкуваха това като част от опитите за шпиониране на потребители. Но вероятно човешката природа е да направи нещо просто защото това може да се направи.

Принципът на Петър се прилага за софтуера

Лорънс Питър стана известен с това, че в йерархията човек се издига до позиция, за която е крайно некомпетентен. Но той също имаше време да каже нещо за сложни проекти:

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

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

Публикуван в IBM Systems Journal през 1984 г., този принцип гласи:

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

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

Жалко, че Shuttleworth не го взе предвид, когато стартира Unity.

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

Първата грешка в компютърната история беше истинска. Молец летя в едно от релетата на компютър MARK II, причинявайки неизправност.

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

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

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

Linux Adictos има инсталиран плъгин, за да гарантира, че ние, авторите, пишем по удобен за търсачката начин. Мразех го от първия ден. Всеки опит да се пише с малко литературен полет веднага се заклеймява с червено кръгче. С течение на времето свикнах и рядко се налага да правя корекции.

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

Следователно законът на Керниган гласи, че:

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

Правилото 90/90

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

Компютърният свят има своите варианти на този закон. Например, един Том Каргил каза:

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

Не беше ли ясно? Може би законът на Хофстадтер ще помогне:

„Винаги отнема повече време, отколкото очаквате, дори имайки предвид закона на Хофстадтер.“

Предполагам, че разработчиците на Ubuntu и Fedora трябва да знаят. Или поне да го запомните на всеки 6 месеца.

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

Софтуерните проекти с отворен код често имат два проблема; финансиране и липса на сътрудници. Освен ако второто не е проблем. Според Брук:

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

Разбираемо е, че не е нужно просто да актуализирате новите енкодери. Ще трябва да се документират повече, ще е необходима повече бюрокрация, за да се синхронизират всички и вероятно ще има битки.

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