Սկզբում միշտ դժվար է հասկանալ մեծ ու հին նախագիծը։ Ճարտարապետությունը ճարտարապետի գնահատման գործողություններից է: Սովորաբար պետք է աշխատել մեծ, հին նախագծերի հետ, իսկ արդյունքները պետք է հասցվեն մեկ շաբաթից։
Ինչպես գնահատել 100 հազար կամ ավելի տող կոդի նախագիծը մեկ շաբաթվա ընթացքում՝ միաժամանակ ապահովելով հաճախորդի համար իսկապես օգտակար արդյունքներ:
Ճարտարապետների և տեխնիկական առաջատարների մեծամասնությունը հանդիպել է նախագծի նմանատիպ գնահատականների: Սա կարող է թվալ որպես կիսաֆորմալ գործընթաց կամ որպես առանձին ծառայություն, ինչպես արվում է մեր ընկերությունում, այս կամ այն կերպ ձեզանից շատերը զբաղվել են դրանով:
Անգլերեն բնօրինակը ձեր ոչ ռուսախոս ընկերների համար այստեղ է. .
Մեր ընկերության մոտեցումը
Ես ձեզ կասեմ, թե ինչպես է այն աշխատում մեր ընկերությունում և ինչպես եմ ես գործում նմանատիպ իրավիճակներում, բայց դուք հեշտությամբ կարող եք փոխել այս մոտեցումը՝ ձեր նախագծի և ընկերության կարիքներին համապատասխան:
Ճարտարապետության գնահատման երկու տեսակ կա.
Ինտերիեր – մենք սովորաբար դա անում ենք ընկերության ներսում իրականացվող նախագծերի համար: Ցանկացած նախագիծ կարող է պահանջել ճարտարապետության գնահատում մի քանի պատճառներով.
- Թիմը կարծում է, որ իրենց նախագիծը կատարյալ է, և դա կասկածելի է: Մենք ունեցել ենք նման դեպքեր, և հաճախ նման նախագծերում ամեն ինչ հեռու է իդեալական լինելուց։
- Թիմը ցանկանում է փորձարկել իրենց նախագիծը և դրանց լուծումները:
- Թիմը գիտի, որ ամեն ինչ վատ է: Նրանք կարող են նույնիսկ թվարկել հիմնական խնդիրներն ու պատճառները, բայց ցանկանում են խնդիրների ամբողջական ցանկը և առաջարկությունները՝ ծրագրի բարելավման համար:
Արտաքին ավելի ֆորմալ գործընթաց է, քան ներքին գնահատումը: Հաճախորդը միշտ գալիս է միայն մի դեպքում, երբ ամեն ինչ վատ է՝ շատ վատ։ Սովորաբար հաճախորդը հասկանում է, որ կան գլոբալ խնդիրներ, բայց չի կարող ճիշտ բացահայտել պատճառները և դրանք բաժանել բաղադրիչների:
Արտաքին հաճախորդի համար ճարտարապետության գնահատումն ավելի բարդ դեպք է: Գործընթացը պետք է լինի ավելի պաշտոնական. Նախագծերը միշտ մեծ են ու հին։ Նրանք ունեն բազմաթիվ խնդիրներ, սխալներ և ծուռ կոդ: Կատարված աշխատանքների վերաբերյալ հաշվետվությունը պետք է պատրաստ լինի առավելագույնը մի քանի շաբաթվա ընթացքում, որը պետք է ներառի հիմնական խնդիրներն ու բարելավման առաջարկությունները։ Ուստի, եթե գործ ունենանք նախագծի արտաքին գնահատման հետ, ապա ներքին գնահատականը կարկանդակ կլինի։ Դիտարկենք ամենադժվար դեպքը.
Ձեռնարկությունների նախագծի ճարտարապետության գնահատում
Գնահատելու տիպիկ նախագիծը մեծ, հին, ձեռնարկատիրական նախագիծ է՝ բազմաթիվ խնդիրներով: Հաճախորդը գալիս է մեզ մոտ և խնդրում շտկել իր նախագիծը: Դա նման է այսբերգի հետ, հաճախորդը տեսնում է իր խնդիրների միայն ծայրը և չի պատկերացնում, թե ինչ կա ջրի տակ (կոդի խորքում):
Խնդիրներ, որոնց մասին հաճախորդը կարող է բողոքել և կարող է տեղյակ լինել.
- Կատարողական խնդիրներ
- Օգտագործելիության խնդիրներ
- Երկարաժամկետ տեղակայում
- Միավորի և այլ թեստերի բացակայություն
Խնդիրներ, որոնց մասին հաճախորդը, ամենայն հավանականությամբ, տեղյակ չէ, բայց դրանք կարող են առկա լինել նախագծում.
- Անվտանգության խնդիրներ
- Դիզայնի խնդիրներ
- Սխալ ճարտարապետություն
- Ալգորիթմական սխալներ
- Անհամապատասխան տեխնոլոգիաներ
- Տեխնիկական պարտք
- Սխալ զարգացման գործընթաց
Պաշտոնական ճարտարապետության վերանայման գործընթաց
Սա պաշտոնական գործընթաց է, որին մենք հետևում ենք որպես ընկերություն, բայց դուք կարող եք այն հարմարեցնել՝ կախված ձեր ընկերությունից և նախագծից:
Հայց հաճախորդից
Հաճախորդը խնդրում է գնահատել ընթացիկ նախագծի ճարտարապետությունը: Մեր կողմից պատասխանատու անձը հավաքում է հիմնական տեղեկատվություն ծրագրի մասին և ընտրում անհրաժեշտ փորձագետներին: Կախված նախագծից, դրանք կարող են լինել տարբեր փորձագետներ:
Լուծման ճարտարապետ – գնահատման և համակարգման հիմնական պատասխանատու անձը (և հաճախ միակը):
Հավաքեք հատուկ փորձագետներ – .Net, Java, Python և այլ տեխնիկական մասնագետներ՝ կախված նախագծից և տեխնոլոգիաներից
Ամպային փորձագետներ – դրանք կարող են լինել Azure, GCP կամ AWS ամպային ճարտարապետներ:
Ենթակառուցվածքներ – DevOps, համակարգի ադմինիստրատոր և այլն:
Այլ փորձագետներ – ինչպիսիք են մեծ տվյալները, մեքենայական ուսուցումը, կատարողականի ինժեները, անվտանգության փորձագետը, QA առաջատարը:
Ծրագրի մասին տեղեկատվության հավաքագրում
Դուք պետք է հնարավորինս շատ տեղեկատվություն հավաքեք նախագծի վերաբերյալ: Կախված իրավիճակից, կարող եք օգտագործել տարբեր տեխնիկա.
- Հարցաթերթիկներ և փոստով հաղորդակցվելու այլ եղանակներ: Ամենաանարդյունավետ միջոցը.
- Առցանց հանդիպումներ.
- Տեղեկատվության փոխանակման հատուկ գործիքներ, ինչպիսիք են՝ Google doc, Confluence, շտեմարաններ և այլն:
- «Ուղիղ եթեր» հանդիպումներ տեղում։ Ամենաարդյունավետ և ամենաթանկ միջոցը.
Ի՞նչ պետք է ստանաք հաճախորդից:
Հիմնական տեղեկություններ. Ինչի՞ մասին է նախագիծը։ Դրա նպատակն ու արժեքը. Ապագայի հիմնական նպատակներն ու ծրագրերը. Բիզնեսի նպատակներն ու ռազմավարությունները. Հիմնական խնդիրները և ցանկալի արդյունքները.
Ծրագրի տեղեկատվություն. Տեխնոլոգիաների փաթեթ, շրջանակներ, ծրագրավորման լեզուներ: Ներքին կամ ամպի տեղակայում: Եթե նախագիծը ամպի մեջ է, ինչ ծառայություններ են օգտագործվում: Ինչ ճարտարապետական և դիզայներական նախշեր են օգտագործվել:
Ոչ ֆունկցիոնալ պահանջներ. Բոլոր պահանջները՝ կապված համակարգի կատարման, հասանելիության և օգտագործման հեշտության հետ: Անվտանգության պահանջներ և այլն:
Հիմնական օգտագործման դեպքեր և տվյալների հոսքեր:
Մուտք դեպի աղբյուրի կոդը. Ամենակարևոր մասը! Դուք անպայման պետք է մուտք ստանաք շտեմարաններ և փաստաթղթեր, թե ինչպես կառուցել նախագիծը:
Ենթակառուցվածքների հասանելիություն. Լավ կլիներ մուտք ունենալ դեպի բեմ կամ արտադրական ենթակառուցվածք՝ կենդանի համակարգի հետ աշխատելու համար: Դա մեծ հաջողություն է, եթե հաճախորդն ունի ենթակառուցվածքների և կատարողականի մոնիտորինգի գործիքներ: Այս գործիքների մասին մենք կխոսենք հաջորդ բաժնում:
Փաստաթղթերով հիմնավորում. Եթե հաճախորդն ունի փաստաթղթեր, սա լավ սկիզբ է: Այն կարող է հնացած լինել, բայց դեռ լավ սկիզբ է: Երբեք մի վստահեք փաստաթղթերին. փորձարկեք այն հաճախորդի հետ, իրական ենթակառուցվածքի վրա և սկզբնական կոդով:
Ճարտարապետության գնահատման գործընթաց
Ինչպե՞ս կարելի է այդքան կարճ ժամանակում մշակել այդքան մեծ քանակությամբ տեղեկատվություն: Նախևառաջ զուգահեռեք աշխատանքը։
DevOps-ը պետք է դիտարկի ենթակառուցվածքը: Տեխնիկական մուտքը կոդի մեջ: Կատարողականության ինժեներ՝ կատարողականության ցուցանիշները դիտելու համար: Տվյալների բազայի մասնագետը պետք է ավելի խորը ուսումնասիրի տվյալների կառուցվածքները:
Բայց սա իդեալական դեպք է, երբ ունես շատ ռեսուրսներ։ Սովորաբար, մեկից երեք հոգի գնահատում են նախագիծը: Դուք կարող եք նույնիսկ ինքներդ կատարել գնահատումը, ինչը հաճախ տեղի է ունենում, եթե ունեք համապատասխան գիտելիքներ և փորձ ծրագրի բոլոր ոլորտներում: Այս դեպքում անհրաժեշտ է հնարավորինս ավտոմատացնել բոլոր գործընթացները:
Ցավոք, դուք ստիպված կլինեք ձեռքով կարդալ փաստաթղթերը: Ճիշտ չափով փորձի շնորհիվ դուք կարող եք արագ հասկանալ փաստաթղթերի որակը: Ինչն է ճիշտ և ինչը ակնհայտորեն չի համընկնում իրականության հետ։ Երբեմն դուք կարող եք տեսնել ճարտարապետություն փաստաթղթերում, որոնք երբեք չեն աշխատի իրական կյանքում: Սա ձեզ համար մղիչ է մտածելու, թե ինչպես է դա իրականում կատարվել նախագծում:
Ծրագրի գնահատման ավտոմատացման օգտակար գործիքներ
Կոդի գնահատումը պարզ վարժություն է: Դուք կարող եք օգտագործել ստատիկ կոդի անալիզատորներ, որոնք ձեզ ցույց կտան դիզայնի, կատարողականի և անվտանգության խնդիրները: Ահա դրանցից մի քանիսը.
հիանալի գործիք է ճարտարապետի համար: Այն ցույց կտա ձեզ մեծ պատկերը, կախվածությունը մոդուլների և պոտենցիալ վերամշակման տարածքների միջև: Ինչպես բոլոր լավ գործիքները, այն լավ գումար արժե, բայց դուք կարող եք օգտվել 30-օրյա փորձնական տարբերակից:
- լավ հին գործիք: Ստատիկ կոդի վերլուծության գործիք: Թույլ է տալիս բացահայտել վատ կոդը, սխալները և անվտանգության խնդիրները ավելի քան 20 ծրագրավորման լեզուների համար:
Ամպային բոլոր մատակարարներն ունեն ենթակառուցվածքի մոնիտորինգի գործիքներ: Սա թույլ կտա ճիշտ գնահատել ձեր ենթակառուցվածքի արդյունավետությունը ծախսերի և կատարողականի առումով: AWS-ի համար սա է . Azure-ի համար հեշտ է .
Լրացուցիչ կատարողականի մոնիտորինգը և գրանցումը կօգնի գտնել կատարողականի խնդիրները բոլոր մակարդակներում: Սկսած անարդյունավետ հարցումներով տվյալների բազայից, հետնամասից և վերջացրած ճակատային մասով: Նույնիսկ եթե հաճախորդը նախկինում չի տեղադրել այս գործիքները, դուք կարող եք դրանք բավականին արագ ինտեգրել գործող համակարգին՝ աշխատանքի հետ կապված խնդիրները բացահայտելու համար:
Ինչպես միշտ, լավ գործիքներն արժե այն: Ես կարող եմ խորհուրդ տալ մի քանի վճարովի գործիք: Իհարկե, դուք կարող եք օգտագործել բաց կոդով, բայց դա ձեզ ավելի շատ ժամանակ կխլի: Եվ դա պետք է արվի նախապես, այլ ոչ թե ճարտարապետական գնահատման գործընթացում:
– հայտի կատարողականը գնահատելու գործիք
- ամպային համակարգի մոնիտորինգի ծառայություն
Անվտանգության փորձարկման համար մատչելի բազմաթիվ գործիքներ կան: Այս անգամ ես ձեզ խորհուրդ կտամ համակարգի սկանավորման անվճար գործիք:
– վեբ հավելվածների սկանավորման գործիք՝ անվտանգության չափանիշներին համապատասխանելու համար:
Եկեք ամեն ինչ հավաքենք մեկ ամբողջության մեջ:
Զեկույցի պատրաստում
Սկսեք ձեր հաշվետվությունը հաճախորդից հավաքած տվյալների հետ: Նկարագրեք ծրագրի նպատակները, սահմանափակումները, ոչ ֆունկցիոնալ պահանջները: Դրանից հետո պետք է նշվեն բոլոր մուտքային տվյալները՝ սկզբնաղբյուր, փաստաթղթեր, ենթակառուցվածք:
Հաջորդ քայլը. Թվարկեք բոլոր խնդիրները, որոնք գտել եք ձեռքով կամ ավտոմատացված գործիքների միջոցով: Տեղադրեք մեծ ավտոմատ ստեղծվող հաշվետվություններ վերջում` հավելվածների բաժնում: Գտնված խնդիրների մասին պետք է լինեն կարճ և հակիրճ ապացույցներ:
Առաջնահերթություն տվեք սխալի, նախազգուշացման, տեղեկատվական սանդղակի վրա հայտնաբերված խնդիրների վրա: Դուք կարող եք ընտրել ձեր սեփական սանդղակը, բայց սա ընդհանուր ընդունվածն է:
Որպես իսկական ճարտարապետ՝ ձեր պարտականությունն է առաջարկություններ տրամադրել՝ հայտնաբերված խնդիրները շտկելու համար: Նկարագրեք բարելավումները և բիզնեսի արժեքը, որը հաճախորդը կստանա: Ինչպես ցույց տալ բիզնեսի արժեքը մենք ավելի վաղ քննարկել ենք.
Փոքր կրկնություններով ճանապարհային քարտեզ պատրաստեք: Յուրաքանչյուր կրկնություն պետք է պարունակի ավարտելու ժամանակը, նկարագրությունը, բարելավման համար անհրաժեշտ ռեսուրսների քանակը, տեխնիկական արժեքը և բիզնեսի արժեքը:
Մենք ավարտում ենք ճարտարապետության գնահատումը և հաճախորդին տրամադրում հաշվետվություն
Երբեք պարզապես հաշվետվություն մի ուղարկեք փոստով: Այն կարող է ընդհանրապես չկարդալ, կամ կարող է չկարդալ ու չհասկանալ առանց պատշաճ բացատրության: Մի խոսքով, կենդանի շփումը օգնում է վերացնել մարդկանց միջև թյուրիմացությունները: Դուք պետք է հանդիպեք հաճախորդի հետ և խոսեք հայտնաբերված խնդիրների մասին՝ կենտրոնանալով ամենակարևորների վրա: Արժե հաճախորդի ուշադրությունը հրավիրել այն խնդիրների վրա, որոնց մասին նա կարող է նույնիսկ տեղյակ չլինել: Օրինակ՝ անվտանգության խնդիրները և բացատրել, թե դրանք ինչպես կարող են ազդել բիզնեսի վրա: Ցույց տվեք ձեր ճանապարհային քարտեզը բարելավումներով և քննարկեք տարբեր տարբերակներ, որոնք ավելի հարմար են հաճախորդի համար: Սա կարող է լինել ժամանակը, ռեսուրսները, աշխատանքի ծավալը:
Որպես ձեր հանդիպման ամփոփում, ուղարկեք ձեր զեկույցը հաճախորդին:
Վերջում
Ճարտարապետության գնահատումը բարդ գործընթաց է: Գնահատումը ճիշտ իրականացնելու համար անհրաժեշտ է ունենալ բավարար փորձ և գիտելիքներ:
Ընդամենը մեկ շաբաթվա ընթացքում հաճախորդին հնարավոր է ապահովել իր և իր բիզնեսի համար օգտակար արդյունքներ։ Նույնիսկ եթե դուք դա անում եք միայնակ:
Իմ փորձից ելնելով, շատ բարելավումներ ներբեռնվեցին կեսին, և երբեմն երբեք չսկսվեցին: Նրանք, ովքեր իրենց համար ընտրեցին ոսկե միջինը և աշխատուժի նվազագույն ծախսերով կատարեցին բիզնեսի համար առավել օգտակար բարելավումների միայն մի մասը, զգալիորեն բարելավեցին իրենց արտադրանքի որակը: Նրանք, ովքեր ոչինչ չեն արել, կարող էին մի երկու տարի հետո ընդհանրապես փակել նախագիծը։
Ձեր նպատակն է ցույց տալ հաճախորդին առավելագույն բարելավումներ նվազագույն գնով:
Այլ հոդվածներ բաժնից դուք կարող եք կարդալ ձեր ազատ ժամանակ:
Մաղթում եմ ձեզ մաքուր կոդ և լավ ճարտարապետական որոշումներ։
Մեր ֆեյսբուքյան խումբը - .
Source: www.habr.com