Common - Question 1 (Quality in development)

Question 1

Co je kvalita ve vyvoji SW

Answer 1

Kombinace metod za ucelem dosazenim vydefinovane urovne kvality. Tyto metody jsou treba testovani, detekce chyb, definice pozadavku atp. Kvalita SW dost zavisi na uhlu pohledu - Uzivatel bude mit jiny pozadavky na kvalitu oprodi vyvojari. Obvykle se hleda nejlepsi kompromis mezi jednotlivymy uhly. Nektere kvality jdou proti sobe - (napr rychlost/bezpecnost). Nejcasteji kvalitu a jeji vlastnosti urci zakaznik.

Question 2

Co je SOLID

Answer 2

SOLID je seznam doporucenych principu pro kvalitnejsi kod. Principy jsou: Single responsibility principle, Open-Close, Liskov substitution principle, Interface Segregation, Dependency Inversion

Question 3

Co znaci Single Responsibility Principle

Answer 3

Kazda trida/metoda by mela mit pouze jeden ucel (delat jednu vec).

Question 4

Co znaci Open-Close principle

Answer 4

Trida ma byt otevrene k rozsirovani, ale uzavrena k modifikaci stavajici funkcionality.

Question 5

Co znaci Liskov substitution principle

Answer 5

Jakkykoli podtrida muze nahradit sveho rodice - podtrida by nemela rozbit chovani nebo invariant

Question 6

Co znaci Interface Segregation principle

Answer 6

Znaci mit radsi vice interfacu nez par, ktere pak maji vice funkci - souvisi se single responsibility.

Question 7

Co znaci Dependency Inversion principle

Answer 7

Trida by mela zaviset na definici interfacu a ne na konkretni implementaci tridy.

Question 8

Mereni SW

Answer 8

Snazime se merit vlastnosti SW abychom meli prehled, jestli je napr kod citelny, spolehlivy. Muzeme merit, kolik procest radku kodu je otestovano,

Question 9

Technicky dluh

Answer 9

Podobne jako penezni. Snizime kvalitu SW na ukor rychlejsimu vyvoji

Question 10

Co si pod kvalitou SW muze predstavit Uzivatel

Answer 10

Kvality, ktere muze pocitit vizualne/ uzivanim. Tedy: uzivatelska pouzitelnost (jak se vyzna v rozhrani), jestli sluzba jede bez vypadku, rychlost sluzby, presnost sluzeb

Question 11

Co si pod kvalitou SW muze predstavit programator

Answer 11

Kvality, ktere citi pri psani sluzby. Tedy: komplexita kodu, testovatelnost, modularnost, pochopitelnost kodu.

Question 12

Co si pod kvalitou SW muze predstavit manazer?

Answer 12

Kvality, ktere cili prevazne na dlouhodoby vyvoj sluzby. Tedy: skalovatelnost, znovupouzitelnost, schopnost adaptace na nove okolnosti (novy zakon treba vejde v platnost)

Question 13

SW metriky

Answer 13

Lines of Code
Number of methods
Number of Classes
Number of packages
Code coverage
Statement coverage
Function coverage
Branch Coverage
Cyclomatic complexity

Question 14

Metody pro zlepseni performance?

Answer 14

Profiling procesu - zkoumani complexity a bottlenecku vypoctu
paralelni zpracovani - (nutne pohlidat kriticke sekce - muze naopak i ublizit)
kontrolovane vyuziti vice zdroju - vyuzit cachovani, load balancer a repliky

Question 15

Metody pro zlepseni udrzitelnosti

Answer 15

Psat cisty kod (Solid, DRY, KISS)
Byt pripraven na zmeny (lide se vyvyji a pozadavky s nemi, zakony se meni/vytvari)
vhodny vyber knihoven (vybirat aktivni knihovny, aby se nestalo, ze za pul roku uz ji nikdo nebude spravovat a bude nutny prepis)

Question 16

Metody pro zlepseni spolehlivosti

Answer 16

Monitorovat produkci - sbirat informace o behu a o chybach hlavne.
Tvorit system, ktery pocita s chybami

Question 17

Test-ability code smells

Answer 17

Globalni promene
Dependency injection
Hardcodovany vytvareni trid pres new (od toho jsou factory) - jde o to, kdyz pak potrebujem rozsirit tridu o metody pro testy

Question 18

SW Quality Management, o co se snazi

Answer 18

Snazi se pomoci vydefinovanych procesu zajistit vydefinovanou uroven kvality SW.

Question 19

Jake jsou kategorie procesu SW Quality Managment

Answer 19

SQP - Software Quality planning (risk analysis, cost benefit analysis, naplanovani ukolu, vydefinovani quality management scope)
SQA - Software Quality Assurance (monitorovani vyvoje aby vedli k vydefinovane kvalite)
SQC - Software Quality Control (monitorovani procesu a produktu, jestli splnuje aplikovane standardy/kvality)
SPI - Software process improvement (zlepseni efektivity procesu, aby pripadne zlepsili kvalitu SW)

Question 20

K cemu je Clean Code?

Answer 20

Aby se programator lepe vyznal v kodu

Question 21

Clean code, jake jsou zakladni principy?

Answer 21

Dodrzovani vydefinovanych konvenci pro projekt - tyka se pojmenovanani trid/metod/promenych.
Pokud projekt nema vydefinovane konvence, snazime se ridit zazitymi obecnymi konvencemi (konkretni pro jazyk, nebo obecne)
Cisty kod by mel dodrzovat SOLID principy a DRY (Don’t Repeat Yourself - zadny copy paste)
GRASP - General Responsibility Assigment SW principles - tipy pro obecne rozrazeni tridy na ruzne kategorie (je to podobne i single responsibility principle). Muzem mit tridy, ktere pouze drzi data, tridy pro vytvareni trid (factories), tridy pro transformaci dat, tridy pro abstrakci programu (facade)

Question 22

Priznaky ze se porusuje clean code (Bad code smells)

Answer 22

Circular dependency
Long parametr list
Long methods
Wrong abstraction levels (spatne dedeni trid)

Question 23

Co je refactoring? Co je cilem? Kdy refaktorujem?

Answer 23

Cilem refactoringu je snaha o zlepseni kodu v zavislosti na vydefinovanych kvalitach. Kod se casto refaktoruje, kdyz je potreba opravit chybu, zmenit/pridat feature ve sluzbe (refactoring probiha pred/po), narazime na spatne citelny kod. Refactor samotny by nemel rozbit nebo zmenit chovani sluzby.

Question 24

Co je obsahem refactoringu?

Answer 24

Extrakce method/trid
inlining method/trid (mit separatni metodu nedava smysl)
Prejmenovani
Vytvareni konstant pro magicke cisla/stringy
Zjednoduseni podminek
Nahrazeni arraye/vectoru tridou

Question 25

Co je Code Coverage?

Answer 25

% pokryti radku, ktere jsou hitnute behem testu (100% Code Coverage != bug free => div(x, y) => ret x/y, test div(6, 3) == 100% Code Coverage ale bug by byl div(6, 0))

Question 26

Co je Cyclomatic Complexity

Answer 26

a measurement to determine the stability and level of confidence in a program. It measures the number of linearly-independent paths through a program module. Pocita se jako graf (N - vrcholy, E - hrany) Cyclomatic Complexity = |E| - |N| + P (P = number of entry and exit locations)

Question 27

Uznavane Rozsahy Cyclomatic Complexity?

Answer 27

1 - 4 - low 5 - 7 - medium 8 - 10 - high 11+ - very high

Question 28

Maintainability index, co to je? Vyhody/Nevyhody

Answer 28

Index, ktery se snazi vyjadrit obtiznost udrzby kodu. Vyhoda je, ze diky tomu mame alespon naky prehled, nevyhoda je, ze hodne zavisi na delce kodu (LOC se pouziva v HV, CC - tedy tri promene v rovnici ktere zavisi na LOC)

Question 29

Maintability index rovnice

Answer 29

orig: MI=171 - 5.2*ln(HV) - 0.23*CC - 16.2*ln(LOC) LOC = Lines of code CC = Cyclomatic Complexity HV=Halstead volume (pocet unikatnich operatoru a promenych v koldu v pomeru delky kodu) HV= ProgramLength*log_2(ProgramVocabulary) Microsoft upravil formuli, aby sedela do rozsahu 1-100 (upravil: MAX(0, MI * 100/171) )

Question 30

Uznavane rozsahy Maintability index

Answer 30

Hodnoty jsou v rozsahu (-inf, 171) Cim nizsi hodnota, tim hur citelny. >= 85 - vysoce udrzovatelne 65-85 - relativne dobre udrzovatelne <=65 - spatne udrzovatelne

Question 31

Testovani - popis

Answer 31

Testovani je process, pri kterem se system/kod/komponenta evaluuje, jestli splnuje vydefinovane pozadavky. Pouziva se oracle, ktery se snazi urcit, jestli vysledek pro dany vstup je spravny (tedy chovani funkce je pravdepodobne spravne) Testovat se muze kod (viz urovne testovani kodu), ale i system (stress test, load test, endurace)

Question 32

TDD - popis

Answer 32

Test Driven Development je technika zalozena na psani testu pri vyvoji. Doporucene (dle uncle boba) zacit s testem, dokud nefailne a pak pridat kod, dokud test neprojde. Az projde, zacit zase psat test, dokud nefailne a tak dokola.

Question 33

Urovne testovani kodu

Answer 33

Unit tests - testuje jednotlive prvky kodu (metoda/funkce/trida), White box testing Integration tests - oproti unit testum testuje komponenty dohromady (unit testy nemusi odhalit dobrou spolupraci komponent - jedna metoda muze ocekavat centimetry, druha ale metry), White box a Black box Acceptance test - Replikuje chovani uzivatele (klika jako uzivatel), pro test web sluzeb je SeleniumHQ, Blackbox System testing - testuje cely system/SW, Blackbox

Question 34

Metody programovani zalozene na testovani

Answer 34

BDD - Behavior-driven development TDD - Test-driver development Maji vyhodu, ze pri refaktoru by testy meli overit, ze nebyla rozbita funkcnost. Na druhou stranu pri zmene featury se musi krom kodu zmenit i vsechny testy.

Question 35

Testovani systemu/vykonu

Answer 35

Load testing - simulace pouzivani - Simuluje se pouzivani X uzivatelu, Jak rychle se nacte/pouziva atp. Stress testing - hleda se maximalni vykon appky (kolik treba max uzivatelu muze byt pripojenych) Soak/Endurance testing - testuje se na delsim obdobi (similuje se nejlepe realne chovani na ocekavanem/vydefinovany trafiku - jaky byl ocekavan) Profiling nasledne muze odhalit bottleneck a zajistit stabilitu/robustnost/efektivnejsi praci se zdroji.