Жаңы баштаган программисттердин типтүү каталарын талдоо: 1-бөлүк

Салам дүйнө! Керектүү нерселердин баарын үйрөнүп, акыры стажер же кенже катары жумушка орношкондон кийин, балким, эс ала аласыз, туурабы? Кандай болбосун! Баардыгы жаңыдан башталып жатат... Айланаңызда көптөгөн жаңы жана түшүнүксүз нерселер бар, жана дарбазадан чыгып эле ушинтип шылдыңдап калбаш үчүн? Бул тууралуу бүгүн сүйлөшөбүз. Бул макалада мен башталгычтар кетирген жалпы каталарды карап чыгып, алардан кантип сактануу боюнча өз тажрыйбамдан бир нече кеңеш бергим келет. Андыктан, келгиле, андан ары созсуз баштайлы:

1. Тажрыйбалуу кесиптештерден жардам суроодон коркуу

Биз баарыбыз пендебиз жана баарыбыз, айрыкча, жаңы ачылган, тажрыйбалуу кесиптештерибиздин көзүнө келесоо көрүнүүдөн коркобуз. Биринчи жумушка орношкондон кийин, иштеп чыгуучулар көбүнчө бул коркуу сезимине берorп, баарын өз алдынча чечүүгө аракет кылышат. Ошол эле учурда, адамды тажрыйбалуу кесиптештери курчап алса болот, алар, өз кезегинде, алгач аны эң туура жолго багыттай алышат, бул көбүрөөк каталардан жана керексиз "бүтүрүктөрдөн" качууга жардам берет. Ошондуктан, эсиңизде болсун: суроо берүүдөн коркпоңуз: сиз башталгычсыз жана муну баары жакшы түшүнөт. Сурасаң эч ким таяк менен урbyte. Балким, тескерисинче, сиз кесиптештериңиз менен тезирээк достошуп, алар менен активдүү баарлаша баштайсыз. Мен дагы айтам: сиз канчалык көп сурап, ар кандай техникалык маселелерди талкууласаңыз, ошончолук тезирээк жашыл башталгычтын бут кийиминен чыгып, өз тармагында адис болуп өсө аласыз. Жана дагы бир кеңеш. StackOverFlow га көңүл бурбаңыз . Бул контекстте мен бул ресурс боюнча суроолорду бергим келет. Бир жагынан сурооңузга жооп алуу үчүн бир аз убакыт керек. Бирок, экинчи жагынан, сиз дароо эле учурдагы көйгөйдү чечүү үчүн бир нече ыкмалар жөнүндө биле алабыз жана бир аз башкача көз караш менен карап көрөлү. Башка иштеп чыгуучулардын StackOverFlow боюнча суроолоруна комментарий-жоопторду жазуу, кармадагы плюскадан тышкары, практикалык пайдага ээ экенин белгилегим келет: сизде бул маселени тереңирээк талкуулап, түшүнүүгө мүмкүнчүлүк бар.

2. Өз алдынча маалымат издөөгө аракет кылбаңыз

Балким, бул ката мурункунун тескери жагы. Сиз кесиптештериңизди жана тааныштарыңызды ар бир көйгөй же көйгөй менен тарта баштаганда айткым келет. Суроо жакшы, бирок суроолор менен алыска барбаш керек, антпесе тажап калышың мүмкүн. Эгер кандайдыр бир түшүнүксүз жагдай пайда болсо, биринчи кезекте издөө жөндөмүңүздү эң мыкты издөө системасында колдонуу керек - Google. Кимдир бирөө түшүнүксүз каталардын жана башка маселелердин басымдуу көпчүлүгүнө туш болгон. Эгер сиз аны Google'да издесеңиз жана ушул сыяктуу көйгөй менен тааныш болгон жана өз ишинде колдонууга ылайыктуу ар тараптуу жоопторду алган адамдардын санын көрсөңүз, таң каласыз. Мунун негизинде сиз кесиптешиңиздин суроого жооп бергенин уга аласыз - "Google аны." Бул жооп сизди таарынтпашыңыз керек, анткени сиздин кесиптешиңиз сиздин иш тармагыңыздын бардык татаал жактарын жеткире турган жеке мугалим эмес. Интернеттин чексиз кеңдиги сизге ушундай насаатчылык менен жардам берет. Кээде программист Google издөөдө кара курлуу адам деп да аталат . Ошондуктан, тыгылып калганда, биз адегенде Google'да көйгөйдү издейбиз, эгер эч кандай чечим табылбаса (сейрек, бирок мындай болот), анда биз кесиптештерибизден сурай баштайбыз. Кандайдыр бир мүчүлүштүктөр же түшүнүксүз каталар болгондо эмес, көйгөйдү чечүүнүн жолун тандап жатканда дароо сурап алуу керек. Анткени, алар сиздикинен ары көрө алышат жана тигил же бул мамиле узак мөөнөттүү келечекте кандай болоорун дароо айтып беришет.

3. Сокур көчүрүү

Бирок көйгөйдү издөө жана ага жараша аны чечүүнүн өз тузактары бар. Мисалы, сокур көчүрүү-паста . Бул, адатта, окшош көйгөйдү тапканыңызда болот (бирок, балким, так ошондой эмес) жана анын астында, мисалы, StackOverFlowдо чечим бар. Сиз бул чечимди кабыл алып, көп майда-чүйдөсүнө чейин айтпастан, аны өзүңүз көчүрүп, чаптаңыз. Ошондо сиз же сиздин кесиптештериңиз кээ бир кызыктай мүчүлүштүктөрдү же функцияңыздын туура эмес жүрүм-турумун таба аласыз. Анан ошол замат буттар кайдан келгенин эч ким билбейт. Анан, албетте, бул code менен орун табылат, жана бул чечим үчүн, албетте, мактоого болбойт. Ошондуктан, сиз StackOverFlow (же башка жерде) боюнча даяр чечимди тапканыңызда, биринчи кезекте аны деталдуу талдап чыгышыңыз керек, бул эмне, кантип жана эмне үчүн. Балким, бул функцияны Google'да издеп, анын documentтерин караңыз. Ошондон кийин гана аны долбооруңузга киргизиңиз.

4. Туура эмес чечимди ыргытуу

Чечимди жазып жатканда, кээде ал барган сайын татаалдашып, акыры туюк абалга келип калат. Ал эми сиз башка, ишке жарамдуу альтернатива издөөнүн ордуна ушул ыкманы колдонуу менен бул маселени кандайдыр бир жол менен чечүү үчүн аны барган сайын татаалдаштырып жатасыз. Мүмкүн, сиз жөн гана сарптаган энергияңызга жана убакытыңызга өкүнүп жаткандырсыз, ошондуктан сиз чечесиз: эмне болсо да, багынбаңыз, бирок маселени ушундай жол менен чечиңиз. Бул таптакыр туура мамиле эмес. Жок дегенде программалоодо. Башка ыкманы канчалык эртерээк аракет кылсаңыз, ошончолук көп убакытты үнөмдөйсүз. Андыктан, буга канча убакыт жумшаганыңызга карабастан, эксперимент жана башка ыкмаларды сынап көрүүдөн коркпоңуз. Мындан тышкары, бул сиздин тажрыйбаңыз үчүн упайлар болот, анткени сиз бир нече ыкмаларды колдонуп, бул аймакты жакшыраак изилдейсиз.

5. Учурдагы тапшырма боюнча суроо берүүдөн коркуу

Долбоордун үстүндө иштөө, адатта, кээ бир тапшырмаларды (Тапшырмаларды) аткарууга туура келет. Мисалы, Жирада . Ал эми бул милдеттер дайыма эле майда-чүйдөсүнө чейин жана так сүрөттөлбөйт. Алар, адатта, команда лидерлери тарабынан жазылат, булар да адамдар, эгер бир нерсе болсо. Алар ошондой эле бир нерсе кошууну унутуп коюшу мүмкүн же тигил же бул функция менен анча тааныш эмес экениңизди эске алышпайт. Ооба, же сизде долбоорго кирүү мүмкүнчүлүгү жок (мисалы, маалымат базасына, журнал serverине ж.б.у.с.). Эми, тапшырманы алып, аны бир-эки сааттан ашык изилдеп, сиз дагы эле таң калып экранды карап отурасыз. Жана муну эч кандай майнапсыз түшүнүүнү улантуунун ордуна, сиз бул тапшырманы жаратуучуга жетектөөчү/тактоочу суроолорду бере башташыңыз керек. Айталы, сиз командада баарлашуу үчүн колдонгон тиркемеде (мисалы, Microsoft Teams) же түздөн-түз ушул тапшырманын астында комментарий катары. Бир жагынан, эгер сиз жеке билдирүүгө суроо жазсаңыз, жооп тезирээк болот, анткени адам суроону дароо көрөт. Башка жагынан алып караганда, Жирада суроо берүү менен сиз бир нерсе кылып жатканыңыздын, тактап айтканда, маселени талдап жатканыңыздын далилдерине ээ болосуз. Бул процессти тездетүүнүн бир жолу бар: Жирада комментарий катары суроо бериңиз жана бул комментарийге шилтемени карап көрүү өтүнүчү менен жеке билдирүүгө жөнөтүңүз.

6. Команданын лидеринен өтө көп нерсени күтүү

Дагы, бул мурунку пункттун экинчи жагы. Команда лидери - бул өнүктүрүү тобунун башчысы болгон адам. Эреже катары, команданын мындай мүчөсүнүн убактысынын көбү байланыштын ар кандай түрлөрүнө жумшалат. Ошол эле учурда ал эмне экенин унутпоо үчүн code жазат. Ооба, сиз түшүнгөндөй, бул абдан бош каарман. Ал эми ар бир чүчкүргөндө ашыкча чыйрыгуу аны бактылуу кылбай турганы анык. Ар бир команданын мүчөсү ага бир топ суроолорду берип жатканын элестетиңиз. Демек, сиз жинди боло аласыз, туурабы? Жана сиз тараптан көптөгөн суроолор менен ал сизге узак убакыт бою жооп берери таң калыштуу эмес. Топтун лидерине суроолордун санын азайтуу үчүн эмне кылсаңыз болот:

• Сокур тактардын санын азайтуу үчүн бул долбоордун documentтерин тереңирээк изилдеңиз.
• Башка команда мүчөлөрүнө суроолорду бериңиз. Алар бул функцияны жетектей эле бorши мүмкүн, же андан да көп, анткени алардын бири ошол функцияны жазган.

Же болбосо, IDEде annotationларды карай аласыз: ким жана качан кайсы бир сапта codeду акыркы жолу өзгөрткөн. Мына ушундай жол менен биз бул суроону ким эң туура берерин билебиз. Сиз буга чейин эле түшүнгөнүңүздөй, команданын лидерине суроо берип жатканда, ошондой эле кесиптештерге суроо берип жатканда, сиз алтын ортону сактоого аракет кылышыңыз керек - суроо берүүдөн коркпоңуз, ошондой эле аларды ашыкча сан менен капалантпаңыз.

7. Кодду карап чыгуудан коркуу

Кодду карап чыгуу же codeду карап чыгуу - бул жалпы тиркемеге (жалпы фorалга, мисалы, мастер же иштеп чыгуучуга) codeду жүктөөдөн мурунку этап. Бул текшерүүнү бул тапшырмага тиешеси жок иштеп чыгуучу ишке ашырат, ал жаңы көз караш менен иштеп чыгуунун баштапкы этабында байкалбай калган code стorндеги каталарды, так эместиктерди же кемчorктерди таба алат. Эгерде комментарийлер болсо, алар codeдун айрым бөлүмдөрүнө комментарий катары калтырылат. Бул учурда, бул тапшырманы аткарган иштеп чыгуучу рецензияга ылайык каталарды оңдоого тийиш (же өзүнүн чечимдерин рецензент менен талкуулап, балким аны өзүнүн чечиминин тууралыгына ынандырат). Андан кийин, аны кайра карап чыгууга жөнөтүңүз ж.б.у.с. кароочу эч кандай комментарий калмайынча. Кодду жүктөөдөн мурун кароочу "фильтр" катары кызмат кылат. Ошентип, көптөгөн жаңы программисттер codeду карап чыгууну сын жана айыптоо катары кабыл алышат. Алар аны баалабай, андан коркушат, бул туура эмес. Бул codeду карап чыгуу бизге codeубузду жакшыртууга мүмкүндүк берет. Анткени, биз эмнени туура эмес кылып жатканыбыз жана эмнеге көңүл бурушубуз керектиги тууралуу маанилүү маалыматтарды алабыз. Ар бир codeду карап чыгууну окуунун бир бөлүгү катары караш керек, бул сизге жакшыртууга жардам берет. Адам сиздин codeуңузга комментарий калтырганда, ал сиз менен өзүнүн тажрыйбасын, эң мыкты тажрыйбасын бөлүшөт. Мага келсек, сиз codeду карап чыкпастан жакшы программист боло албайсыз. Анткени сиз codeуңуздун канчалык жакшы экенин жана сырттан тажрыйбалуу адамдын көз карашында каталар бар-жогун билбейсиз.

8. Абструстук чечимдерге тенденция

Көп учурда ар кандай тапшырмалар/көйгөйлөр бир нече ар кандай чечимдерге ээ болушу мүмкүн. Жана бардык жеткorктүү чечимдердин ичинен башталгычтар, адатта, эң татаал жана “абструкциялууларды” колдонушат. Жана бул чындык: эгерде башталгыч программист кечээ эле көптөгөн ар кандай алгоритмдерди, схемаларды, маалымат структураларын изилдеген болсо, анда анын колу алардын бирин ишке ашыруу үчүн кычышып жатат. Ооба, мен, мындайча айтканда, өзүмдү билдиргим келет. Мага ишенип коюңуз, мен өзүм да ошондой болчумун жана эмне жөнүндө айтып жатканымды билем :) Менде бир функцияны жазууга көп убакыт короткон жагдай болду, ал абдан татаал болуп чыкты. Андан кийин ал Senior+ деңгээлиндеги иштеп чыгуучу тарабынан кайра жазылган. Албетте, анын эмнени, кандайча өзгөрткөнүнө кызыктым. Мен анын ишке ашырылышын карап, анын канчалык жөнөкөй болуп калганына таң калдым. Ал эми code үч эсе аз болуп калды. Ошол эле учурда, бул функция үчүн тесттер өзгөргөн жок жана ийгorкке жеткен жок! Башкача айтканда, жалпы логика ошол эле бойдон калууда. Мындан мен мындай жыйынтыкка келдим: эң гениалдуу чечимдер ар дайым жөнөкөй . Бул ишке ашкандан кийин, code жазуу бир топ жеңилдеди жана ал кыйла жогорку деңгээлде болуп калды. Анда, үлгүлөрдү жана алгоритмдерди качан колдонуу керек, деп сурайсыңбы? Андан кийин, аларды колдонууда эң жөнөкөй жана эң компакттуу жол болот.

9. Велосипедди ойлоп табуу

Бул концепция дөңгөлөктүн ойлоп табуусу катары да белгилүү. Анын маңызы иштеп чыгуучу өзүнүн чечимдери бар болгон маселенин өз чечимин ишке ашыргандыгында жана программист ойлоп тапкандарынан бир нече эсе жакшыраак экендигинде. Эреже катары, өзүңүздүн велосипедиңизди ойлоп табуу убакытты жоготууга жана иштеп чыгуучунун ишинин натыйжалуулугунун төмөндөшүнө алып келет, анткени эң жакшыдан алыс болгон чечим табылбай калышы мүмкүн же такыр табылбай калышы мүмкүн. Ошол эле учурда көз карандысыз чечим кабыл алуу мүмкүнчүлүгүн жокко чыгарууга болбойт. Программист даяр чечимдерди колдонуу менен же өз алдынча ойлоп табуу менен, компетенттүү жана өз убагында чечүү үчүн анын алдында пайда болушу мүмкүн болгон милдеттерди туура багыттоо керек. Бир жагынан, университеттерде жана курстарда бизге велосипеддерди жасоого жардам бере турган ар кандай тапшырмалар берилет. Бирок бул биринчи караганда гана. Чындыгында мунун максаты – алгоритмдик ой жүгүртүүнү өнүктүрүү жана тилдин синтаксисин терең өздөштүрүү. Жана мындай тапшырмалар ошондой эле алгоритмдерди/структураларды жакшыраак түшүнүүгө жардам берет жана зарыл болсо, аларга алдыңкы аналогдорун ишке ашыруу үчүн көндүмдөрдү берет (бирок бул өтө сейрек керек). Чыныгы жашоодо, көпчүлүк учурларда, өз дөңгөлөктү ойлоп табуунун кереги жок, анткени биздин муктаждыктарыбызды канааттандырган аналогдор көптөн бери бар. Балким, сиздин тажрыйбаңыздан улам, сизге керектүү тигил же бул функцияны ишке ашыруунун бар экендигин билбей каласыз. Бул жерде сиз ушул макаланын биринчи пунктун колдонушуңуз керек, тактап айтканда, тажрыйбалуу кесиптештерден жардам сураңыз. Алар сизге жетекчorк бере алат (мисалы, Google'га кайсы багытта кеңеш бере аласыз) же белгилүү бир ишке ашырууну сунуштай алат (белгилүү бир китепкана).

10. Тесттерди жазбаңыз

Бардык башталгычтар жазуу тесттерин жактырышпайт. Жаңы келгендер жөнүндө эмне айтууга болот: жаңы эмес адамдар да тест жазууну жактырышпайт, бирок алар эмне үчүн керек экенин жакшыраак түшүнүшөт. Сиз толугу менен жашыл болгондо, ойлонуп: эмне үчүн аларды жазып? Мунун баары иштейт, жана эч кандай ката болушу мүмкүн эмес. Бирок сиздин өзгөртүүлөрүңүз системанын башка бөлүгүндө бир нерсени бузуп албасына кантип ишене аласыз? Кесиптештериңиз аларга пайдасынан көбүрөөк зыян келтирген өзгөрүүлөрдү баалаbyte. Бул жерде сыноолор жардамга келет. Канчалык көп өтүнмө тесттер менен камтылса, ошончолук жакшы (камтуу пайызы деп да аталат). Эгерде тиркеме тесттер менен жакшы камтылган болсо, алардын баарын иштетүү менен сиз өзгөртүүлөрүңүз менен бузула турган жерлерди таба аласыз. Жогорудагы мисалда айткандай, функцияны рефакторингде тесттер ийгorксиз болгон жок жана бардыгы жалпы логика өзгөргөн жок. Бул тесттер белгилүү бир функциянын логикасы өзгөргөн же өзгөрбөгөнүн да көрсөтө алат дегенди билдирет. Демек, тест жазууну жактырбасаңыз да, алардан шексиз пайдалар бар жана алар аларга сарпталган убакытка татыктуу.

11. Ашыкча комментарий берүү

Көптөгөн иштеп чыгуучулар перфекционизмден жапа чегип, башталгычтар да четте калbyte. Бирок кээде бул каалоонун терс таасири, алар ар бир нерсеге жана бардык нерсеге комментарий бере башташат. Ал тургай, эмне кереги жок, анткени бул абдан ачык:

Cat cat = new Cat(); // cat Object

Бардык эле башталгыч программисттер codeун комментарийлөө дайыма эле жакшы нерсе эмес экенин дароо түшүнүшпөйт, анткени code бир топ башаламан жана окуу кыйын болуп калат. Эгер code өзгөртүлүп, бирок ага эч кандай комментарий болбосочу? Көрсө, ал бизди алдап, башыбызды айландырат экен. Анда эмне үчүн мындай комментарий? Адатта, жакшы жазылган code комментарий берүүнүн кереги жок , анткени андагы бардыгы ачык-айкын жана окула турган. Эгерде сиз комментарий жазсаңыз, бул сиз codeдун окулушун бузуп, кандайдыр бир жол менен кырдаалды жөнгө салууга аракет кылып жатканыңызды билдирет. Эң жакшы ыкма алгач комментарийлер менен толукталбаган окула турган codeду жазуу болот. Мен ошондой эле методдордун, өзгөрмөлөрдүн жана класстардын туура аталышын, тактап айтканда, мен карманган эрежени айтпай коё алган жокмун: Эң жакшы комментарий – бул комментарийдин жоктугу, анын ордуна – тигил же бул нерсени так сүрөттөгөн туура атоо. колдонмоңуздагы функция.

12. Жаман ат коюу

Көбүнчө башталгычтар класстардын, өзгөрмөлөрдүн, методдордун ж.б. аталыштарын бурмалашат. Мисалы, аты анын максатын такыр сүрөттөбөгөн классты түзгөндө. Же өзгөрмө кыска аталыш менен түзүлөт, х сыяктуу бир нерсе жана n жана y аттуу дагы эки өзгөрмө түзүлгөндө, x эмне кылганын эстеп калуу абдан кыйын болуп калат . Мындай учурларда, сиз codeду жакшылап ойлонуп, ал жерде эмне болуп жатканын түшүнүү үчүн микроскоптун астында (балким, мүчүлүштүктөрдү оңдоочу) бул функцияны изилдешиңиз керек. Бул жерде мен жогоруда айткан codeдогу туура атоо жардамга келет. Туура аталыштар codeдун окулушун жакшыртат, ошого жараша таанышууга убакытты үнөмдөйт, анткени аты болжолдуу түрдө анын функционалдуулугун сүрөттөгөн ыкманы колдонуу алда канча оңой. Коддо баары аталыштардан турат (өзгөрмөлөр, методдор, класстар, файл an objectилери ж.б.), бул пункт туура, таза codeду түзүүдө абдан маанилүү болуп калат. Бул ысым маанисин билдириши керек экенин эстен чыгарбоо керек: мисалы, өзгөрмө эмне үчүн бар, ал эмне кылат жана кантип колдонулат. Жана мен кайра-кайра белгилей кетейин, өзгөрмөнү сүрөттөө үчүн эң жакшы комментарий анын туура аталышы. Комментарийлерди тереңирээк изилдөө жана туура ат коюу үчүн мен сизге эски классиканы окууну сунуштайм: “Таза code. Түзүү, анализдөө жана рефакторинг”, Роберт Мартин . Ушуну менен бул макаланын биринчи бөлүгү (ой жүгүртүү) аяктады. Уландысы бар…