Никой никога не ви учи как да създавате качествен софтуер
Оригиналът е на Florian Bellmann
Даниел Десподов преди 9 секунди 1 СподелиНай-четени
ПрепоръчаноЕмил Василев - 22:00 | 11.12.2023iOS 17.2 към този момент е налична с тези 18 нови функционалности
IT НовиниДаниел Маринов - 11:03 | 12.12.2023Ето по какъв начин Военноморски сили на Съединени американски щати възнамеряват да изведат от употреба нуклеарния самолетоносач USS Enterprise
IT НовиниДаниел Десподов - 8:05 | 11.12.2023Ето какво е основното условие за инсталирането на Windows 12
Даниел Десподовhttps://www.kaldata.com/Новинар. Увличам се от модерни технологии, осведомителна сигурност, спорт, просвета и изкуствен интелект.Увод
Случвало ли ви се е да участвате в план за създаване на програмен продукт, в който липсват жизненоважните ограничения за надзор и обезпечаване на качеството? Не сте сами в това отношение. Това се случва в зашеметяващо огромен % от фирмите и плановете. Дори и фирмите да знаят, че има такова нещо като QA (quality assurance – обезпечаване на качеството) и че то би трябвало да се прави, всички старания нормално водят единствено до един огромен QA спринт тъкмо преди стартирането на плана. Това е стресиращ интервал, в който се опитваме да накараме софтуера най-малко малко да работи. Разбира се, целият този безпорядък се повтаря при идващия цикъл на излизане без ни минимум усъвършенстване.
На какво ни учат в институтите
Проблемът е, че при проучването на информатиката не се преподава по какъв начин да се подсигуряват стандартите за качество на софтуера. По-голямата част от времето се отделя за проучване на логаритмите, компютърните правила, историята на някои езици и концепции и така нататък Освен това, най-малко в моето следване, имаше един учебен срок, отдаден на техниките за ръководство на планове и Scrum (рамката за ръководство на планове посредством тяхното делене на части). Всичко това е отлично, само че тук изцяло липсва обезпечаването на качеството. Пренебрегването на QA е голяма загуба, тъй като над 90% от всички студенти работят в изискванията на другите компании след довеждане докрай на образованието. Те ще би трябвало да основават нужния програмен продукт в точния момент и без неточности.
Защо фирмите едвам едва съумяват да дават софтуера си в точния момент
Сблъсквал съм се с това безчет пъти. Стандартите за обезпечаване на качеството и ограниченията за обезпечаване на качеството са измежду първите, които минават под ножа, тъй като за плановете най-съществен е бюджетът. Често те се залагат за в края на плана, само че в случай че създаването се проточи (което постоянно се случва) или има разгръщане на функционалностите (което постоянно се случва), към този момент няма време за QA. В последна сметка получаваме абсолютния най-малко неструктурирани проби и произвеждаме цифрова къщурка от карти с клатещи се стени.
Някои компании и екипи употребяват някакви QA стандарти. Обикновено някой чиновник на висше равнище дава отговор за тяхното използване. Най-често той или тя от личен горчив опит знае, че без обезпечаване на качеството работата последователно става все по-трудна и все по-сложна. За страдание даже съществуването на стандарти не е задоволително. Много постоянно екипите просто основават проби, с цел да удовлетворят критериите за оценка на плана.
Как да слезем от тази въртележка
Отне ми доста години опит, с цел да придобия увереността да стартира да приказвам за неналичието на ограничения за обезпечаване на качеството в плановете. Преди това ми се постановяваше да диспутирам с мениджърите, да дремя на работното място преди излизането на новите версии, да се оправям с разпадащите се системи в производството и да намирам изчезналия мониторинг. Всичко това въобще не бе занимателно. Тези обстановки са сходни на някои други усъвършенствания в базата данни или плана, които са невидими за мениджърите, като да вземем за пример рефакторинга. Но в тази ситуация с QA беше изключително мъчно, тъй като в случай че не прилагахме никакви ограничения за налагането му, в никакъв случай нямаше да се научим по какъв начин да го вършим вярно.
Само в случай че намерим сили да изразим мнението си и да го слагаме на разискване още веднъж и още веднъж, можем да създадем първите стъпки, с цел да излезем от този циничен кръг.
Да поговорим за парите
В един миг осъзнах, че употребявам несъответствуващи причини. Ако кажете, че софтуерът ще бъде „ по-стабилен “ или че ще „ опрости доста поддръжката “, тези причини няма да имат необикновен смисъл за тези, които не работят по самата кодова база. Трябва да поговорим за парите. Ние, разработчиците, би трябвало да приказваме за това какъв брой коства неналичието на QA. Това е езикът на бизнеса и на мениджмънта като цяло. Винаги се пробвам да обясня ограниченията за обезпечаване на качеството с образци като този: „ Ако не го създадем в този момент, напъните за разработка (и затова разходите) единствено след четири месеца те ще се усилят с 15% “ или „ Трябва да въведем unit проби за всички функционалности, другояче етапите на стабилизиране на версиите ни всякога ще се удължават. Това непосредствено се отнася за всички функционалности, които сътворяваме, тъй като всякога би трябвало ръчно да тестваме всички странични резултати. В резултат на това напредъкът ни ще бъде все по-малък с всяка последваща версия “.
Според моя опит преходът към сходни решения и образци оказва помощ да се разбере смисълът на тематиката. В последна сметка вашите старания ще подобрят живота на всички, просто те към момента не го осъзнават.
Минималната ефикасна доза
За да бъдем реалисти е значимо да не преекспонираме ограниченията за обезпечаване на качеството, като изразходваме авансово огромни суми за тях. Не бива да възпрепятстваме развиването на плана като цяло; също така не всички заинтригувани страни ще харесат този метод. Винаги поучавам да се акцентира на най-важните елементи на приложението. Обикновено има избран сюжет на потребление, присъща специфичност или нещо друго, върху което е построено цялото приложение. Това може да е някаква съществена функционалност, която би трябвало да работи вярно и устойчиво, с цел да може софтуерът да бъде потребен за клиента или потребителя. Именно това би трябвало да се тества. Измислете ограничения и способи да гарантирате, че тя работи по предопределение.
Харесва ми терминът „ минимална ефикасна доза “ (MED – minimum effective dose). Това е минималната мярка, която води до стремежи резултат. В региона на QA това може да бъде проект за ръчно тестване, автоматизирани проби в конвейер или нещо друго. Това е отправната точка. Ако функционалността на главните функционалности е подсигурена, можете последователно да разширите стабилността, да вземем за пример да добавите unit проби за всички нови функционалности. Също по този начин помислете за източниците на информация, които не можете да контролирате, като да вземем за пример външните API или въвежданите от потребителя данни. Намерете способи да валидирате и тях, тъй като това са явни места, в които софтуерът ви може да се провали заради неправилна приложимост. Итегрирайте и работете поетапно. Това се отнася и за обезпечаването на качеството.
Какво в действителност диря аз
Във всеки нов план, който стартирам или не преставам, диря концепцията за обезпечаване на качеството. Колкото и дребна да е тя, екипът би трябвало да намерения за нея.
Какво ще пускаме? От какво се нуждаем, с цел да работи? Как да го създадем работещо? Кои от ограниченията предумишлено ще изключим и за какво?Наличието на писмена документи плюс може би и проект за тестване са чудесни основи, върху които софтуерът може да се развива. Те демонстрират, че ние, екипът, сме обмислили по какъв начин да продължим напред. Мисъл от позиция на EDR. Освен това предлагам постоянно да преглеждате определените методологии, да речем един път на тримесечие.
Не употребявам TDD (Test-Driven Development – създаване, ръководено от проби, бел. прев.), когато пиша сорс код, само че мощно предлагам да се пишат проби редом с писането на софтуера. Това е най-подходящото време за писане на тест. Ако пишете проби, до момента в който реализирате дадена функционалност, ще получите в допълнение преимущество: кодът ще бъде структуриран по този начин, че фактически да може да бъде тестван. Когато пишете проби за към този момент подготвен програмен продукт, постоянно откривате, че в кода има прекалено много взаимни зависимости или че са нарушени правилата на едноличната отговорност. С помощта на тестванията показвате, че сте разбрали мечтаното държание и гарантирате, че всичко работи съгласно упованията. Можете даже да го наречете документи на кода.
Преимуществата за плана
Когато говорите за това, хората към вас схващат, че ви е грижа за плана. Като повдигате въпроса за качеството и оферирате вероятни решения, разширявате сферата си на въздействие като разработчик. Това може да бъде от изгода както за вас, по този начин и за плана. Качеството на живот на разработчиците и ръководителите ще се усъвършенства. Това несъмнено ще бъде видяно.
Само при съществуването на ограничения за обезпечаване на качеството един план може да се развива със здравословни темпове.
Промяна на плановете към по-добро
Използвате ли към този момент лични ограничения за обезпечаване на качеството във вашите планове или нещата са доста нестабилни? Искате да разширите уменията си като разработчик и да станете прочут като човек, който написа първокласен програмен продукт?
Започнете с малко. Помислете за MED (Minimum Edit Distance – минимално публицистично разстояние) на вашия план. Поемете отговорност и се превърнете в индивида от екипа си, който прави тази разлика. Не всеки би трябвало да бъде просветител на QA, само че можете да научите хората на тези техники, от които в действителност се нуждаят, като давате образец. Бъдете този, който ще стартира тази полемика.
