Բարեւ Ձեզ! Ես Դմիտրի Պավլովն եմ, աշխատում եմ , և նաև Apache Ignite-ի կատարող և PMC մասնակից եմ և Apache Training-ի մասնակից: Վերջերս ես ներկայացրեցի Սբերբանկի բաց կոդով հանդիպման ժամանակ կոմիտերի աշխատանքի մասին: Բաց կոդով համայնքի զարգացման հետ մեկտեղ շատ մարդիկ սկսեցին ավելի ու ավելի շատ հարցեր ունենալ՝ ինչպես դառնալ հանձնակատար, ինչ առաջադրանքներ ստանձնել, և քանի տող կոդ պետք է գրվի այս դերը ստանալու համար: Երբ մտածում ենք կատարողների մասին, անմիջապես պատկերացնում ենք ամենակարող և ամենագետ մարդկանց՝ գավազանի փոխարեն թագ ու «Մաքուր օրենսգիրք» հատորով: Այդպե՞ս է։ Իմ գրառման մեջ ես կփորձեմ պատասխանել կոմիտերների մասին բոլոր կարևոր հարցերին, որպեսզի հասկանաք, արդյոք դա ձեզ իսկապես անհրաժեշտ է։
Opensource համայնքի բոլոր նորեկները մտքեր ունեն, որ նրանք երբեք չեն դառնա պարտավորություններ: Ի վերջո, շատերի համար սա հեղինակավոր դեր է, որը կարելի է ձեռք բերել միայն հատուկ արժանիքների համար՝ մի տոննա կոդ գրելով: Բայց դա այնքան էլ պարզ չէ: Եկեք նայենք կատարողին համայնքի տեսանկյունից:
Ո՞վ է հանձնակատարը և ինչո՞ւ է անհրաժեշտ:
Երբ մենք ստեղծում ենք նոր բաց կոդով արտադրանք, մենք միշտ թույլ ենք տալիս օգտվողներին օգտագործել և ուսումնասիրել այն, ինչպես նաև փոփոխել և տարածել փոփոխված պատճենները: Բայց երբ տեղի է ունենում փոփոխություններով ծրագրային պատճենների անվերահսկելի բաշխում, մենք չենք ստանում ներդրումներ հիմնական կոդի բազայում, և նախագիծը չի զարգանում: Հենց այստեղ է անհրաժեշտ կոմիտերը, ով իրավունք ունի հավաքել օգտատերերի ներդրումները նախագծին:
Ինչու՞ դառնալ հանձնակատար:
Սկսենք նրանից, որ պարտավորվելը ռեզյումեի համար պլյուս է, իսկ ծրագրավորման ոլորտում սկսնակների համար դա էլ ավելի մեծ պլյուս է, քանի որ հաճախ աշխատանքի դիմելիս խնդրում են կոդի օրինակներ։
Պարտավորվելու երկրորդ անկասկած առավելությունը լավագույն մասնագետների հետ շփվելու և բաց կոդով որոշ հետաքրքիր գաղափարներ ձեր նախագծի մեջ ներգրավելու հնարավորությունն է: Բացի այդ, եթե լավ գիտեք որոշակի բաց կոդով արտադրանք, կարող եք աշխատանք ստանալ այն ընկերությունում, որն աջակցում կամ օգտագործում է այն: Նույնիսկ կարծիք կա, որ եթե չմասնակցես բաց կոդով, ապա բարձր կարիերայի պաշտոնների չես հասնի։
Բացի կարիերայի և աշխատանքի առումով օգուտներից, պարտավորվելն ինքնին հաճելի է։ Դուք ճանաչված եք մասնագիտական հանրության կողմից, հստակ տեսնում եք ձեր աշխատանքի արդյունքը։ Ոչ թե ինչ-որ կորպորատիվ զարգացման դեպքում, որտեղ երբեմն նույնիսկ չեք հասկանում, թե ինչու եք դաշտերը հետ ու առաջ տեղափոխում XML-ով:
Բաց կոդով համայնքներում դուք կարող եք հանդիպել առաջատար մասնագետների, ինչպիսիք են Լինուս Տորվալդսը: Բայց եթե դուք այդպիսին չեք, չպետք է մտածեք, որ այնտեղ ձեզ համար անելիք չկա, կան տարբեր մակարդակների առաջադրանքներ։
Դե, կան նաև հավելյալ բոնուսներ. Apache կոմիտերները, օրինակ, ստանում են անվճար IntelliJ Idea Ultimate լիցենզիա (թեև որոշ սահմանափակումներով):
Ի՞նչ անել, որպեսզի դառնաք հանձնակատար:
Դա պարզ է, դուք պարզապես պետք է պարտավորվեք:
Եթե կարծում եք, որ նախագծերում ձեզ համար առաջադրանքներ չկան, ապա սխալվում եք։ Պարզապես միացեք ձեզ հետաքրքրող համայնքին և արեք այն, ինչ անհրաժեշտ է: Apache Software Foundation-ն ունի առանձին կոմիտերներին ներկայացվող պահանջներով։
Ի՞նչ խնդիրներ կունենաք լուծելու։
Ամենատարբերը` մշակումից մինչև թեստեր և փաստաթղթեր գրելը: Այո, այո, համայնքում փորձարկողների և վավերագրողների ներդրումը գնահատվում է մշակողների ներդրման հետ հավասար հիմունքներով: Կան ոչ ստանդարտ առաջադրանքներ, օրինակ՝ գործարկել YouTube ալիք և պատմել այլ օգտվողներին, թե ինչպես եք օգտագործում բաց կոդով արտադրանքը: Օրինակ, Apache Software Foundation-ն ունի առանձին , որտեղ նշված է, թե ինչ օգնություն է պահանջվում։
Արդյո՞ք ես պետք է մեծ հատկանիշ գրեմ, որպեսզի դառնամ կոմիտեր:
Ոչ Սա ամենևին էլ անհրաժեշտ չէ։ Կոմիտերը պարտավոր չէ տոննա կոդ գրել: Բայց եթե դուք գրել եք մեծ հատկանիշ, ծրագրի կառավարման հանձնաժողովի համար ավելի հեշտ կլինի ձեզ գնահատել: Համայնքին նպաստելը միայն հնարավորությունների, ծրագրավորման և թեստավորման հետ կապված չէ: Եթե նամակ եք գրում և խոսում խնդրի մասին, առաջարկեք հիմնավորված լուծում՝ սա նույնպես ներդրում է:
Կարևոր է հասկանալ, որ պարտավորվելը վստահության հետ է կապված: Անկախ նրանից, թե ձեզ հանձնառու դարձնելը, թե ոչ, որոշում են հենց ձեզ նման մարդիկ՝ հիմնվելով ձեր՝ որպես ապրանքին օգուտ բերող մարդու տեսակետների վրա: Հետևաբար, դուք, համայնքում ձեր գործողություններով և արարքներով, պետք է շահեք հենց այս վստահությունը:
Ինչպե՞ս վարվել:
Եղեք կառուցողական, դրական, քաղաքավարի և համբերատար: Հիշեք, որ բաց կոդով բոլորը կամավոր են, և ոչ ոք ոչ ոքի ոչինչ պարտական չէ: Նրանք ձեզ չեն պատասխանում. սպասեք և հիշեցրեք ձեր հարցի մասին 3-4 օրվա ընթացքում: Նրանք միշտ չէ, որ պատասխանում են ձեզ. լավ, բաց կոդով կամավոր է:
Մի խնդրեք ինչ-որ մեկին ինչ-որ բան անել ձեզ համար կամ ձեզ համար: Համայնքի փորձառու անդամները նման «մուրացկանների» բնազդ ունեն և անմիջապես ալերգիա են ունենում նրանց նկատմամբ, ովքեր ցանկանում են իրենց աշխատանքը մղել դեպի իրենց:
Եթե օգնություն եք ստանում, դա հիանալի է, բայց մի չարաշահեք այն: Դուք չպետք է գրեք. «Տղաներ, շտկեք սա, հակառակ դեպքում ես կորցնում եմ իմ տարեկան բոնուսը»: Ավելի լավ է հարցնել, թե ուր պետք է գնաք հաջորդը, և ասեք, թե ինչ եք արդեն փորել այս վրիպակի վերաբերյալ: Իսկ եթե խնդրի լուծման արդյունքներից ելնելով խոստանաք թարմացնել վիքին, ապա հավանականությունը, որ ձեզ կպատասխանեն, զգալիորեն կմեծանա։
Վերջապես կարդացեք և սովորել .
Ինչպե՞ս նպաստել, եթե պարտավորված չես:
Նախագծերը հաճախ օգտագործում են RTC սխեմա, որտեղ նախ ամեն ինչ անցնում է վերանայման, այնուհետև փոփոխությունները միաձուլվում են հիմնականի մեջ: Այս սխեմայով բացարձակապես բոլորը ենթարկվում են վերանայման, նույնիսկ հանձնակատարները: Հետևաբար, դուք կարող եք հաջողությամբ նպաստել նախագծին` առանց հանձնակատար լինելու: Եվ որպեսզի ավելի հեշտ լինի ընտրվել որպես նոր հանձնողներ, դուք կարող եք մենթոր անել նոր մասնակիցներին, կիսվել գիտելիքներով և ստեղծել նոր նյութեր:
Բազմազանություն՝ օգուտ, թե վնաս.
Բազմազանություն - Apache Software Foundation-ի ընկալմամբ, սա, ի թիվս այլ բաների, մի քանի ընկերությունների կողմից բաց կոդով նախագծի մասնակիցների պատկանելությունն է: Եթե բոլորը կապված են միայն մեկ կազմակերպության հետ, ապա նախագծի նկատմամբ հետաքրքրության կորստով բոլոր մասնակիցները արագ փախչում են դրանից: Բազմազանությունը ապահովում է երկարաժամկետ, կայուն նախագիծ, բազմազան փորձ և մասնակիցների կարծիքների լայն շրջանակ:
Սիրո՞ համար, թե՞ հարմարության համար:
Opensource նախագծերում կան երկու տեսակի մարդիկ՝ նրանք, ովքեր աշխատում են կազմակերպությունում, որը նպաստում է այս արտադրանքին, և նրանք, ովքեր աշխատում են այստեղ սիրո համար, այսինքն՝ կամավորներ: Ո՞րն է ավելի արդյունավետ: Որպես կանոն, մասնակիցներ, ովքեր աջակցում են արտադրանքը ներդրող կազմակերպությունից: Նրանք պարզապես ունեն ավելի շատ ժամանակ և հստակ մոտիվացիա՝ հասնելու ճշմարտությանը, նրանք կենտրոնացած են առաջադրանքի վրա և ավելի մոտ են օգտատիրոջը:
Նրանք, ովքեր դա անում են «սիրուց դրդված», նույնպես մոտիվացված են, բայց այլ կերպ՝ նրանք ցանկանում են ուսումնասիրել նախագիծը, աշխարհն ավելի լավը դարձնել: Եվ հենց այդպիսի մասնակիցներն են ավելի կայուն ու երկարաժամկետ կողմնորոշված, քանի որ սեփական նախաձեռնությամբ համայնք եկածները դժվար թե մեկ օրում լքեն այն։
Ինչպե՞ս գտնել հավասարակշռություն արտադրողականության և կայունության միջև: Երկու տարբերակ կա. Առաջին տարբերակը. երբ մասնակիցն աշխատում է մի ընկերությունում, որը պաշտոնապես ներգրավված է այս opensource նախագծում, և դրանում ինչ-որ լրացուցիչ բան է անում՝ ելնելով իր շահերից, օրինակ՝ աջակցելով նորեկներին: Երկրորդ տարբերակն այն ընկերությունն է, որը ենթարկվել է opensource տրանսֆորմացիայի: Օրինակ, երբ աշխատողները աշխատում են հիմնական բիզնես նախագծի վրա շաբաթը չորս օր, իսկ մնացած ժամանակ նրանք աշխատում են բաց կոդով:
Հանձնարար - լինել, թե չլինել.
Պարտավորելը լավ և օգտակար թեմա է, բայց պետք չէ հատուկ ձգտել հանձնակատար դառնալ։ Այս դերը կոդի վրա հիմնված դեր չէ և չի ցուցադրում ձեր գիտելիքները: Միակ բանը, որ կարևոր է, փորձաքննությունն է, այսինքն՝ գիտելիքն ու փորձը, որ ձեռք ես բերում՝ ուսումնասիրելով նախագիծը, խորանալով դրա մեջ և օգնելով ուրիշներին լուծել խնդիրները:
Source: www.habr.com