PHP ir Laravel: ką šis pasirinkimas reiškia įmonei, kuri užsako sistemą

Pasiūlyme parašyta „PHP 8.4, Laravel 13“ nėra techninė detalė: šios dvi eilutės nulemia, kiek ilgai sistema gaus saugumo pataisas, kas joje kainuos papildomai ir kiek kainuos perdavimas kitam programuotojui.

Pasiūlymas ateina penktadienio popietę, ir jo techninėje dalyje yra dvi eilutės, kurių susitikime niekas neskaito garsiai: „PHP 8.4“ ir „Laravel 13“. Kaina suprantama, terminas suprantamas, o šios dvi eilutės atrodo kaip tiekėjo vidaus virtuvė — maždaug tiek pat svarbios kaip tai, kokiu grąžtu bus išgręžta skylė sienoje, todėl jas paprastai praleidžia kaip techninę detalę, už kurią atsako kažkas kitas. Parašas vis dėlto stovi po visu dokumentu, ir būtent šios dvi eilutės nulemia, kiek ilgai sistema iš viso gaus saugumo pataisas, kas joje išrašys mėnesinę sąskaitą šalia kūrimo kainos ir kiek po trejų metų kainuos jos perdavimas kam nors kitam.

Šis straipsnis nėra apie tai, ar PHP yra gera kalba ir ar Laravel yra geras karkasas, nes į šį klausimą programuotojai atsako tarpusavyje ir pirkėjui iš to pokalbio nėra jokios praktinės naudos. Jis yra apie keturis dalykus, kuriuos pirkėjas gali patikrinti pats ir be techninių žinių: palaikymo kalendorių, licenciją, darbo rinką ir perdavimo sąlygas. Visi keturi yra vieši, trys iš jų yra datos arba pinigų sumos, ketvirtasis — tai, ką apie rinką galima ir ko negalima žinoti, ir nė vienas nepriklauso nuo to, kaip įtikinamai parašytas pasiūlymas — todėl juos verta tikrinti būtent tą savaitę, kol dėl kainos dar galima kalbėti.

Kas yra kalba, kas yra karkasas ir kodėl tai nėra vienas pasirinkimas

PHP yra programavimo kalba, kuria parašyta sistemos serverio pusė — ta dalis, kuri veikia pas tiekėją arba Jūsų talpinimo tiekėją ir kurios naudotojas niekada nemato. Laravel savo ruožtu yra karkasas, tai yra PHP kalba jau parašyta kodo bazė, kuri išsprendžia tai, kas kartojasi beveik kiekviename projekte: naudotojų prisijungimą, duomenų bazės užklausas, eiles, failų saugojimą, el. laiškų siuntimą. Pasiūlyme jie stovi greta kaip vienas pasirinkimas, tačiau tai du atskiri produktai, kuriuos prižiūri dvi skirtingos komandos su dviem skirtingais palaikymo kalendoriais, ir būtent todėl juos verta skaityti atskirai.

Kiek paplitusi kalba, pasirodo, pasakyti sunkiau, nei tikėtumėtės. W3Techs, kuris reguliariai skenuoja daugiau nei dvidešimt milijonų interneto svetainių, šių metų rugpjūtį rašo, kad PHP naudoja 70,2 % visų svetainių, kurių serverio pusės programavimo kalbą šis įrankis žino. Pastaroji sąlyga yra tai, kas paprastai dingsta, kai skaičių perrašo į prezentaciją: kalba eina ne apie 70 % visų pasaulio svetainių, o apie 70 % tų, kurias šis konkretus įrankis apskritai geba atpažinti, be to, dalį atpažinimo jis pats aprašo kaip išvestą netiesiogiai — jei puslapis yra WordPress, tai jis yra PHP.

Pirkėjui naudingesnis kitas skaičius iš to paties puslapio. Tarp svetainių, kurioms W3Techs nustato ir PHP versiją, 63,3 % veikia aštuntąja, 28,7 % septintąja ir 7,9 % vis dar penktąja, nors septintoji versija prarado net saugumo pataisas jau prieš ketverius metus. Tai reiškia, kad maždaug trečdalis išmatuojamo PHP interneto šiandien veikia su kodu, kuriam niekas nebedaro pataisų, ir tai įvyko ne todėl, kad kalba būtų bloga arba kad kas nors būtų padaręs klaidą kuriant. Tai įvyko todėl, kad niekas neužsakė ir neapmokėjo versijos keitimo, ir būtent šią rizikos dalį pirkėjas gali ir pamatyti, ir valdyti.

PHP palaikymo kalendorius yra pirmasis dokumentas, kurį verta atidaryti

PHP kūrėjų grupės taisyklė trumpa ir vieša: kiekviena versijos šaka gauna visą palaikymą dvejus metus nuo pirmojo stabilaus leidimo, paskui dar dvejus metus tik kritines saugumo pataisas (security-only support), ir po ketverių metų ateina end of life — ji visai nebeprižiūrima. Šioje taisyklėje yra viena detalė, kurią perpasakojimai beveik visada nupjauna: tikrosios pabaigos datos lentelėje priderintos prie paskutinės metų dienos, o ne prie išleidimo datos lapkritį, todėl „dveji metai nuo išleidimo“ ir tai, kas parašyta php.net lentelėje, skiriasi mėnesiu ar dviem.

Praktiškai tai reiškia štai ką. 8.2 versija šiuo metu yra tik security-only support, ir jos palaikymas baigiasi jau šių metų pabaigoje, taigi po maždaug keturių mėnesių. 8.3 versija visą palaikymą prarado pernai metų pabaigoje ir saugumo pataisas gaus iki 2027 m. pabaigos, taigi dar maždaug šešiolika mėnesių. 8.4 versija visą palaikymą turi iki šių metų galo ir paskui dar dvejus metus lieka security-only support, o naujausioji 8.5, išėjusi pernai lapkritį, visą palaikymą gauna dar visus kitus metus ir saugumo pataisas iki 2029 m. pabaigos.

8.1 versijos palaikymas baigėsi pernai metų paskutinę dieną, ir būtent šis atvejis vertas dėmesio, jei Jūs jau turite sistemą, o ne pasiūlymą. Jei tiekėjas prieš trejus metus ją parašė su 8.1 ir nuo to laiko niekas nieko nekeitė, šiandien ji veikia šakoje, kuriai saugumo pataisos nebeateina, ir apie tai neįspėja nei serveris, nei naršyklė, nei pati sistema. Puslapis atsiveria lygiai taip pat kaip vakar, klientai nieko nepastebi, ir vienintelė vieta, kur tai galima pamatyti, yra ta pati vieša lentelė, kurią atidaryti užtrunka mažiau laiko nei perskaityti pasiūlymo titulinį lapą.

Laravel kalendorius trumpesnis nei PHP kalendorius

Laravel savo politiką formuluoja dar trumpiau: klaidų taisymai aštuoniolika mėnesių, saugumo pataisos dvejus metus, ir nauja pagrindinė versija kasmet maždaug pirmąjį ketvirtį. Ilgalaikio palaikymo leidimo, kurį praktikai vadina LTS, šiandien jau nėra — senose versijose toks tikrai buvo, tačiau šių metų lentelėje tokios skilties iš viso nėra, todėl pasiūlymas, kuriame parašyta „LTS Laravel“, aprašo ką nors, ko šiuo metu niekas neparduoda. Tai trumpesnis pažadas, nei daugelis pirkėjų tikisi iš karkaso, ant kurio bus statoma sistema ateinantiems penkeriems metams.

Skaičiais, pagal pačią Laravel dokumentaciją, tvarka tokia. Laravel 13 išėjo šių metų kovą, klaidų taisymus gaus iki kitų metų trečiojo ketvirčio, o saugumo pataisas — iki 2028 m. kovo 17 d. Laravel 12 klaidų taisymų langas užsidarė šių metų rugpjūčio viduryje, tai yra septyniolika dienų prieš rašant šias eilutes, ir jos saugumo pataisos baigsis kitų metų vasarį. Laravel 11 saugumo palaikymas baigėsi šių metų pavasarį, taigi sistema, kuri šiandien veikia vienuoliktąja versija, jau veikia be pataisų, kad ir kaip gerai atrodytų iš išorės.

Atkreipkite dėmesį, kad Laravel 13 klaidų taisymų pabaiga nurodyta kaip ketvirtis, o ne kaip konkreti data. Tai pačių Laravel formulavimo netikslumas, ir tai nėra problema, kol perrašoma lygiai taip, kaip ten stovi; problema prasideda tada, kai tiekėjas ar pirkėjas apvalina iki konkrečios dienos ir paskui planuoja biudžetą pagal skaičių, kurio šaltinyje nėra. Dar viena riba, kurią reikia žinoti prieš renkantis versiją: Laravel 13 reikalauja bent PHP 8.3, todėl sistemos su tryliktąja versija negalima palikti su 8.2 net tada, jei pati 8.2 dar kurį laiką gautų saugumo pataisas.

Ką abu kalendoriai kartu reiškia sistemai, kurią užsakote šiandien

Jei sistema perduodama su Laravel 13 kartu su PHP 8.4 arba 8.5, pirmoji data, kai kažkas būtinai turi pajudėti, yra 2028 m. kovas, kai baigiasi Laravel saugumo pataisos, ir tai maždaug aštuoniolika su puse mėnesio nuo šiandien. PHP šiame derinyje nėra ribojimas, nes abi šios šakos saugumo pataisas gauna ilgiau nei karkasas, todėl pirma sensta Laravel, o ne kalba. Tai ir vienintelis sąžiningas būdas atsakyti į klausimą „kiek ilgai ši sistema išsilaikys be papildomos investicijos“ — ne nuojauta, o ankstesniąja iš dviejų viešų datų.

Jei ta pati sistema perduodama su Laravel 13, bet PHP 8.3, tvarka apsiverčia ir pirmasis terminas ateina maždaug per šešiolika mėnesių, kai baigiasi šios PHP šakos saugumo pataisos. Jei tiekėjas rašo su Laravel 12, kas esamam projektui vis dar visiškai normalus pasirinkimas, saugumo pataisos baigiasi kitų metų vasarį, ir naujos sistemos gyvenimas prasideda su šešiais mėnesiais iki pirmojo privalomo versijos keitimo. Skirtumas tarp pirmojo ir trečiojo varianto yra metai, kuriuos galima laimėti viename pokalbyje prieš sutartį ir kurių po parašo jau nebepirksite.

Dvi klaidos šiame skaičiavime tokios paplitusios, kad jas verta įvardyti atskirai. Pirmoji — supainioti visą palaikymą su saugumo palaikymu, todėl išgirdus, kad „PHP 8.4 palaikymas baigiasi metų pabaigoje“, verta paklausti, kuris iš dviejų langų turimas omenyje: baigiasi įprastų klaidų taisymas, bet saugumo pataisos ateina dar dvejus metus. Antroji — patikėti pačių Laravel sakiniu, kad perėjimas prie naujos pagrindinės versijos paprastai užtrunkąs dieną ar mažiau; tai programuotojų suformuluotas tikslas, o ne išmatuotas vidurkis, ir sutartyje jo kaip termino įrašyti negalima.

Licencija kainuoja nulį, ir tai tiesa tik apie kalbą ir karkasą

Laravel karkasas platinamas su MIT licencija, kuri yra viena paprasčiausių atvirojo kodo licencijų ir leidžia kodą naudoti, keisti ir parduoti toliau, reikalaujant tik išsaugoti autoriaus teisių pranešimą. Su PHP šiek tiek sudėtingiau, ir šis sudėtingumas kaip tik dabar aktualus, nes licencija keičiasi: versijos iki 8.5 imtinai išeina su PHP licencijos 3.01 redakcija, o nuo 8.6 pereinama prie ketvirtosios redakcijos, kurią php.net pats aprašo kaip „Modified BSD“ licenciją ir kuri praktiškai sutampa su BSD-3-Clause. Nė viename iš šių variantų mokesčio nenumatyta.

Tai reiškia, kad už pačią kalbą ir patį karkasą įmonė nemoka nei už naudotoją, nei už procesoriaus core, nei už metus, ir šis nulis nėra akcija, kuri kada nors baigsis. Palyginimui tinka modelis, kurį naudoja Microsoft SQL Server: ten licencijuojama pagal core licence arba pagal serverį kartu su CAL, Standard leidimas ribojamas mažesniuoju iš keturių procesorių lizdų arba dvidešimt keturių cores, o nemokamas Express leidimas — vienu lizdu arba keturiais cores. Tikslių sumų čia nerašome, nes kainoraštis keičiasi ir jį reikia skaityti pas Microsoft; pirkėjui palyginamas modelis, o ne skaičius — vienas produktas skaičiuoja pagal aparatinę įrangą, kitas neskaičiuoja visai.

Užsakant tai turi dvi pasekmes, kurias verta užsirašyti iš karto. Pirmoji yra maloni: nėra licencių audito, nėra metinio perskaičiavimo už naudotojus, kurių per metus padaugėjo, ir nėra situacijos, kai programinės įrangos tiekėjas po trejų metų ateina su sąskaita už viršytą limitą. Antroji yra ta, kurią linkstama pamiršti: atvirasis kodas nuima priklausomybę nuo karkaso savininko, bet priklausomybės kaip tokios nenuima. Priklausomybė pereina kitur — prie agentūros, kuri vienintelė žino, kaip projektas sudėtas, prie mokamų produktų, stovinčių šalia kodo, prie abandoned package, kurio prižiūrėtojai sustojo, ir prie pagrindinės versijos, kuriai palaikymas pasibaigęs. Šios keturios vietos yra tos, kurias pirkėjas turi patikrinti, nes licencijos eilutė apie jas nieko nesako.

Kur Laravel vis dėlto pradeda kainuoti: produktai, kurie nėra karkasas

Ta pati komanda, kuri prižiūri Laravel, parduoda ir keletą produktų, ir pasiūlyme jie dažnai stovi vienoje eilutėje su karkasu, tarsi būtų jo sudedamoji dalis. Laravel savo svetainėje šiuos du dalykus atskiria pats: paketai — Horizon, Telescope, Pulse, Scout, Sanctum, Octane ir kiti — yra MIT licencijuoti ir nemokami, o produktai yra Cloud, Forge, Nightwatch, Vapor ir Nova, ir jie kainuoja pinigus kas mėnesį arba kas metus. Envoyer vis dar parduodamas atskirai. Nė vienas iš šių produktų nėra reikalingas, kad Laravel sistema veiktų, ir būtent todėl jų buvimas pasiūlyme yra pasirinkimas, o ne būtinybė.

Kainos šių metų rugpjūtį atrodė taip. Forge, kuriuo valdomi serveriai, kainuoja 12, 19 arba 39 JAV dolerius per mėnesį priklausomai nuo plano. Nova, kuri yra administravimo skydelis, kainuoja 99 dolerius vieną kartą už vieną projektą kartu su metų atnaujinimais ir 79 dolerius per metus už atnaujinimų tęsimą, o neribota licencija kainuoja atitinkamai 299 ir 249 dolerius, be to, ji dengia Jūsų pačių projektus, o ne Jūsų klientų projektus. Nightwatch, kuris surenka sistemos įvykius, prasideda nemokamu planu ir kyla iki 20, 60 ir 300 dolerių per mėnesį, pridedant priemoką už įvykius virš įskaičiuoto limito. Laravel Cloud prasideda nuo 5 dolerių per mėnesį plius suvartojimas, o Envoyer kainuoja nuo 10 iki 50 dolerių per mėnesį.

Klausimas pirkėjui nėra, ar šie produktai geri, nes paprastai jie geri ir programuotojui sutaupo kelias dienas per mėnesį. Klausimas yra, kurie iš jų įtraukti į įvardytą kainą, kurioje paskyroje jie registruoti ir kas su jais nutiks, jei Jūs po dvejų metų pakeisite tiekėją. Prenumerata, kuri yra agentūros paskyroje ir sutartyje neminima, yra būtent ta priklausomybė, kurios MIT licencija nenuima, nes MIT kalba apie kodą, o ne apie paskyrą, kurioje jis diegiamas ir prižiūrimas.

Kas nutinka, jei programuotojas dingsta

„Kodą gali perimti bet kuris Laravel programuotojas“ yra sakinys, kuris teisiškai teisingas ir praktiškai nepilnas, ir mes jį esame rašę ir patys. MIT licencija tikrai leidžia kitai įmonei su šiuo kodu dirbti, neprašant leidimo nei mūsų, nei Laravel komandos. Ar naujasis programuotojas bus naudingas jau pirmąją savaitę, nulemia keturi visai kiti dalykai, ir visus keturis galima patikrinti dar prieš pasirašant sutartį.

Pirmasis yra pagrindinė versija. Perdavimas iš Laravel 11 naujai komandai nėra perdavimas, o versijos keitimo projektas, nes saugumo palaikymas ten jau pasibaigęs ir pirmasis darbas bus ne nauja funkcija, o pavėluotas versijos keitimas iki palaikomo leidimo. Antrasis yra atstumas nuo karkaso įprastos tvarkos: Laravel dokumentacija numato tam tikrą katalogų ir klasių išdėstymą, ir kuo toliau projektas nuo jo nuėjęs, tuo brangesnis susipažinimas. Skaičiaus čia nėra ir jokiame šaltinyje tokio nėra, yra tik kryptis; užtat pirkėjas gali visai konkrečiai paklausti, kas projekte parašyta priešingai numatytajam ir kokio poreikio tam reikėjo.

Trečiasis yra priklausomybės, tai yra svetimi paketai, kuriais sistema pasikliauja. Composer, kuris Laravel pasaulyje juos valdo, saugo failą su tiksliomis versijomis, ir jis vertingas būtent todėl, kad naujas programuotojas gali įdiegti lygiai tą patį, ką matė ankstesnis, o ne tai, kas šiandien naujausia. Ko šis failas negarantuoja, yra du dalykai: kad paketas vis dar bus prieinamas atsisiųsti, ir kad jame nuo to laiko nerasta pažeidžiamumų. Komanda composer audit abu parodo vienu iškvietimu, ir tai trumpiausia klausimo forma, kokią apskritai galima užduoti apie svetimą kodo bazę.

Ketvirtasis yra abandoned package, ir čia žodžiai klaidina. Packagist, viešas Composer katalogas, pažymi, kad prižiūrėtojai sustojo, tačiau tai nereiškia, kad paketas dingsta ar nustoja veikti: swiftmailer vis dar tiekiamas, jam užfiksuoti 449 milijonai registruotų įdiegimų, paskutinis leidimas yra iš 2021 m., ir kartu jam yra trys žinomi pažeidžiamumai. Mūsų pačių šios svetainės kodo bazėje, kuri yra Laravel 13 kartu su Filament administravimo skydeliu, yra 109 gamybiniai paketai ir nė vieno abandoned package — tai mūsų skaičius apie mūsų projektą, o ne sektoriaus vidurkis, nes paskelbto sektoriaus vidurkio nėra niekur.

Kokia didelė darbo rinka ir kodėl tikslaus skaičiaus niekas nepasakys

Į klausimą, ar Latvijoje lengva rasti žmogų, kuris sistemą perims, sąžiningas atsakymas toks: viešos statistikos apie PHP ar Laravel programuotojus Latvijoje nėra. Yra netiesioginiai duomenys, ir jie vertingi lygiai tiek, kiek tiksliai aprašomi. JetBrains pernykštėje PHP apklausoje tarp 1720 žmonių, kuriems PHP yra pagrindinė kalba, 64 % dirba su Laravel, 25 % su WordPress ir 23 % su Symfony; duomenys rinkti pavasarį, apklausa šališka JetBrains įrankių naudotojų naudai, ką įmonė pripažįsta pati, ir didžiausios respondentų grupės ateina iš Japonijos, JAV, Rusijos, Kinijos ir Prancūzijos, o ne iš Baltijos.

Europos lygiu Eurostat šių metų gegužę praneša, kad pernai Europos Sąjungoje dirbo 10,45 milijono informacinių ir ryšių technologijų specialistų, tai yra 5,0 % visų užimtųjų ir 2,6 % daugiau nei metais anksčiau. Apie Latviją to paties šaltinio ankstesnėje suvestinėje yra kitas skaičius, pirkėjui naudingesnis už bendrą prieaugį: 2023 m. tik 4,48 % Latvijos įmonių ieškojo ar bandė įdarbinti tokius specialistus, ir tai buvo žemiausias rodiklis visoje Sąjungoje, o tarp tų Europos įmonių, kurios ieškojo, 57,5 % vakansijos užpildyti nesugebėjo.

Šie skaičiai yra apie srities specialistus apskritai, o ne apie PHP, ir jų negalima perrašyti kaip teiginio apie Laravel darbo rinką Latvijoje — nei mums, nei tiekėjui, kuris juos cituoja Jūsų pasiūlyme. Mes patys savo paslaugų puslapyje esame rašę, kad programuotojų, kurie perima darbą, rasti lengva; ruošdami šį straipsnį šiam teiginiui šaltinio neradome, todėl čia jo nekartojame. Pirkėjui praktinė seka vis tiek kita: ne tikėti rinkos dydžiu, o pasiekti, kad kodo bazė būtų tokia, į kurią naujas žmogus įeina pigiai nepriklausomai nuo to, kiek tokių žmonių yra.

Kur mes patys brėžiame ribą pasiūlyme

Mes rašome Laravel nuo 2013 m., kai išėjo jo ketvirtoji versija, ir tai praktiškai reiškia, kad esame ne kartą perėję būtent tai, apie ką šis straipsnis įspėja — pagrindinės versijos keitimą, kuris nėra vienos dienos darbas ir kurio negalima padaryti tarp kitų užduočių. Mūsų Laravel sistemų kūrimo puslapyje yra kaina ir terminai, ir tai atskiras pokalbis; šiame straipsnyje yra tik tai, ką pasiūlyme galima patikrinti nepriklausomai nuo to, kas jį parašė ir kaip gerai jis parašytas.

Ko mes neteigame, yra tai, kad bet kuris programuotojas perima bet kurią kodo bazę vienodai lengvai, nes ankstesnis skyrius sako priešingai. Ką mes teigiame, yra konkretiau ir patikrinamiau: saugykla yra kliento nuo pirmos dienos, joje yra ir priklausomybių failas, ir dokumentacija, ir diegimo konfigūracija, ir perdavimo metu versija yra ta, kuri tuo metu dar gauna saugumo pataisas. Jei Jums atrodo, kad pasirinkimas iš tikrųjų yra tarp standartinio produkto ir individualios sistemos, tai yra kitas pokalbis, kurį esame parašę atskirai, o jei klausimas būtent apie el. parduotuvę, WooCommerce ir Laravel palyginimas atsako tiksliau nei šis straipsnis.

Praktiškai į perdavimo rinkinį įeina saugykla su visa istorija, priklausomybių failas su tiksliomis versijomis, README su paleidimo žingsniais, diegimo konfigūracija ir prieiga prie visų paskyrų, kuriose sistema veikia. Tai yra tai, ką galima pažadėti ir patikrinti. Ko pažadėti negalima, yra rinka: kiek žmonių Latvijoje šį darbą paims ir už kokią kainą, nėra mūsų rankose ir nėra jokioje viešoje statistikoje, todėl šio klausimo neatsakome įtikinamu skaičiumi. Vienintelis dalykas, kuris čia iš tikrųjų veikia pirkėjo naudai, yra tai, kad kodo bazė įprasta, versija palaikoma ir dokumentacija parašyta tuo metu, o ne atidėta perdavimo savaitei.

Ko paklausti prieš pasirašant

Pirmasis klausimas apie datas: kuri Laravel pagrindinė versija ir kuri PHP šaka bus sistemoje būtent perdavimo dieną ir kada baigiasi jų saugumo pataisos. Atsakymas yra dvi datos, abi galima patikrinti dviejuose viešuose puslapiuose per penkias minutes, ir jas reikia įrašyti arba į sutartį, arba bent į susirašinėjimą. Jei tiekėjas įvardija versiją, kurios palaikymas baigiasi anksčiau nei garantijos terminas, tai nėra uždrausta ir kartais net pagrįsta, bet tada tai turi žinoti abi pusės, ir kainoje turi būti aišku, kas mokės už perėjimą.

Antrasis klausimas apie prenumeratas: kurie mokami produktai — Forge, Cloud, Nova, Nightwatch, Vapor ar Envoyer — sistemos veikimui reikalingi, kiek jie kartu kainuoja per mėnesį ir kurioje paskyroje jie yra. Trečiasis apie saugyklą: nuo kurios dienos ji Jūsų, ar joje yra priklausomybių failas ir ar į automatinį tikrinimą įtraukta composer audit komanda. Ketvirtasis yra pinigų klausimas, kurį paprastai atideda vėlesniam laikui ir paskui nustebę randa biudžete: kas mokės už pagrindinės versijos keitimą po pusantrų metų ir ar tai įeina į priežiūros sutartį, ar bus naujas užsakymas.

Nė vienas iš šių keturių klausimų nereikalauja, kad Jūs suprastumėte kodą, ir nė vieno nereikia laikyti nepasitikėjimu tiekėju. Visi jie apie tai, kas nutiks po to, kai projektas bus baigtas ir sąskaita apmokėta, ir geras tiekėjas į juos atsako iš karto, nes pats šias datas žino mintinai. Jei atsakymas į kurį nors užtrunka savaitę arba virsta paaiškinimu, kodėl klausimas nesvarbus, tai jau ir yra atsakymas.

Šie keturi klausimai nepakeičia techninio vertinimo ir neatsako, ar siūloma architektūra gera, bet jie pašalina didžiąją dalį nemalonių staigmenų, kurios paprastai ateina antraisiais ar trečiaisiais metais, kai pradinis entuziazmas pasibaigęs ir sistema paprasčiausiai veikia. Jei turite pasiūlymą rankose ir nesate tikri, ką jame parašytos versijos reiškia Jūsų terminams ir biudžetui, parašykite mums — atsakymą į šiuos keturis klausimus galima paruošti neatidarius kodo.