Кофе-брейк №20. Мурдагы код деген эмне жана аны менен кантип иштөө керек. Техникалык документтерди жазууну жеңилдеткен куралдар

Мурдагы code деген эмне жана аны менен кантип иштөө керек

Булак: Доу Эрте жана кеч, программист, балким, эски codeго туш болушу мүмкүн. Бул таанышуунун кесепеттерин жеңилдетүү үчүн, мен өз тажрыйбамдан бир нече практикалык кеңештерди жана мисалдарды тандап алдым - атап айтканда, эски Java системасы менен иштөө.

Legacy Features

Легаси - бул башка бирөөнүн codeу, ал көбүнчө ушунчалык коркунучтуу болгондуктан, аны менен кантип иштөө керектиги түшүнүксүз. Эгер сиз эски codeдон тышкары, эски система менен иштешиңиз керек болсо, сиз дагы жолугасыз:

• эскирген технология менен;
• гетерогендүү архитектура;
• documentтердин жоктугу же ал тургай толук жоктугу.

Чындыгында, эски code анча деле коркунучтуу эмес жана бул жерде: эгерде система ушул он жыл бою жашап, дагы деле иштеп жатса, анда анын кандайдыр бир пайдасы бар. Балким, бул жакшы акча табат (акыркы стартапыңыздан айырмаланып). Кошумчалай кетсек, бул code өндүрүштө ушунча убакытка чейин жашай алса, салыштырмалуу ишенимдүү. Ошондуктан, ага өзгөртүүлөрдү этияттык менен жасоо керек. Биринчиден, сиз эки нерсени түшүнүшүбүз керек:

1. Миллиондогон же күнүнө миңдеген адамдар кирген системаны сыйлабай коё албайбыз. Канчалык начар жазылганына карабастан, бул жийиркеничтүү code өндүрүшкө чейин сакталып, 24/7 иштейт.

2. Бул система реалдуу акча алып келгендиктен, аны менен иштөө чоң жоопкерчorкти талап кылат. Бул стартап эмес, колдонуучулар эртең иштей турган нерсе. Бул ошондой эле катанын өтө чоң чыгымын билдирет жана бул жерде кеп кардардын дооматтарында эмес, иштин чыныгы абалында.

Тескери инженерия

Эски code менен ийгorктүү иштөө үчүн, тескери инженерия ыкмаларын колдонушуңуз керек болот. Биринчиден, анын кантип иштээрин так түшүнүү үчүн codeду кунт коюп окуп чыгышыңыз керек. Бул милдеттүү, анткени бизде documentтер жок болот. Эгерде биз автордун ой жүгүртүүсүн түшүнбөсөк, күтүлбөгөн кесепеттерге алып келген өзгөртүүлөрдү киргизебиз. Мындан өзүңүздү коргоо үчүн, сиз да чектеш codeду изилдешиңиз керек. Жана ошол эле учурда кеңдикте гана эмес, тереңдикте да жылат. Ката менен чакырылган ыкма кайда? Аны чакырган code кайдан келет? Мурдагы долбоордо "чалуу иерархиясы" жана "тип иерархиясы" баарынан көп колдонулат. Мүчүлүштүктөрдү оңдоочу менен көп убакыт коротушуңуз керек болот: биринчиден, каталарды табуу, экинчиден, бардыгы кантип иштээрин түшүнүү. Ал эми documentацияга келсек, өнөр жай археологиясына кайрылуу жаман болбойт. Эски documentтерди бир жерден казып алуу жана сиз мурастап калган code кандайча жазылганын эстегендер менен сүйлөшүү абдан пайдалуу болушу мүмкүн. Бул ыкмаларды колдонуп, эртеби-кечпи сиз codeду аздыр-көптүр түшүнө баштайсыз. Бирок аракетиңиз текке кетпеши үчүн, изилдөөңүздүн натыйжаларын дароо documentтештирүү керек. Бул үчүн мен блок схемаларды же ырааттуу диаграммаларды тартууну сунуш кылам. Албетте, сиз жалкоо болосуз, бирок сиз муну сөзсүз кылышыңыз керек, антпесе алты айдан кийин documentсиз бул codeду биринчи жолу көргөндөй казып чыгасыз.

Кодду кайра жазбаңыз

Иштеп чыгуу процессиндеги эң маанилүү нерсе - өз убагында өзүңүздү сабап, codeду нөлдөн баштап кайра жазууга аракет кылбоо. Буга канча адам-жыл керек болорун эсептеп көргүлө. Кардар буга чейин иштеп жаткан нерсени кайра жасоого мынчалык көп акча короткусу келери күмөн. Бул бүтүндөй системага гана эмес, анын каалаган бөлүгүнө да тиешелүү. Албетте, алар сизге баарын түшүнүү үчүн бир жума, бир нерсени оңдоо үчүн дагы бир жума бериши мүмкүн. Бирок алар сизге системанын бир бөлүгүн кайра жазууга эки ай бериши күмөн. Анын ордуна, жаңы функцияны codeдун калган стorнде ишке ашырыңыз. Башкача айтканда, эгер code эски болсо, анда сиз жаңы кооз технологияларды колдонууга азгырылбашыңыз керек: мындай codeду окуу абдан кыйын болот. Мисалы, сиз бизде болгон жагдайга туш болушуңуз мүмкүн: системанын бир бөлүгү Spring MVCде жазылган, ал эми бир бөлүгү жылаңач сервлеттерде жазылган. Ал эми сервлеттерде жазылган бөлүккө дагы бир нерсе кошуу керек болсо, биз аны ошол эле жол менен - ​​сервлеттерде кошобуз.

Бизнес кызыкчылыктарын урматтоо

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

Сыноо

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

1. Текшерүү, функциянын ишке ашырылган функционалдуулугу өзүнчө бөлүмдө текшерилгенде.
2. Турукташтыруу, релиз бутагы текшерилгенде, анда бардык функциялар бириктирилген.
3. Сертификатташуу, бир эле нерсе аппараттык мүнөздөмөлөрү жана конфигурациялары боюнча өндүрүшкө мүмкүн болушунча жакын болгон сертификация чөйрөсүндө бир аз башкача сыноо учурларында кайра иштетилгенде.

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

DevOps жана чыгарууну расмийлештирүү

Чыгаруу proceduresасы, мисалы, төмөнкүдөй болушу мүмкүн. Иштеп чыгуу аяктап, эки же үч тестирлөө этаптары аяктаганда, биз DevOps командасына күтүлгөн чыгаруу убактысына 36 саат калганда электрондук кат жазабыз. Андан кийин, биз devops командасын чакырып, чөйрөлөрдөгү бардык өзгөрүүлөрдү талкуулайбыз (биз аларга маалымат базасындагы жана конфигурациядагы бардык өзгөрүүлөр жөнүндө кабарлайбыз). Ар бир өзгөртүү үчүн бизде document бар (Жирадагы билет). Андан кийин, релиз учурунда, буга катышкандардын баары чогулуп, бардыгы азыр эмне кылып жатканын айтышат: "Биз маалымат базасын жүктөдүк", "Биз тигил же бул serverлерди кайра иштеттик", "Биз өндүрүш чөйрөсүндө регрессиялык тесттерди жүргүзүү үчүн бардык. ” Эгерде бир нерсе туура эмес болуп кетсе, релизди артка кайтаруу proceduresасы ишке киргизилет, ал баштапкы релиз documentинде так сүрөттөлгөн - мындай documentсиз биз сөзсүз түрдө бир нерсени унутуп калабыз же башаламан болобуз.

Коддун сапатын көзөмөлдөө

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

Техникалык documentтерди жазууну жеңилдеткен куралдар

Булак: Dzone Көпчүлүк программисттер техникалык documentтерди жазганды жактырышпайт. Психология боюнча эксперт Джеральд Вайнберг documentацияны “программалоонун кастор майы” деп да атаган: иштеп чыгуучулар аны окуганды жакшы көрүшөт, бирок алар өздөрү жазганды жек көрүшөт. Жетекчorктин жоктугу же бош жол картасы программалык камсыздоонун ар кандай бөлүктөрү кандайча иштээри жөнүндө маалыматтын жетишсиздигине алып келет. Бул акыр аягында codeдун акыркы колдонуучуларынын тажрыйбасын начарлатат, анткени documentтер жок болгон учурда алар буюмдун тактыгына жана пайдалуулугуна ишене алышпайт. Программисттерге document жазуу адатын калыптандырууну жеңилдетүү үчүн, мен азыр дээрлик бардыгына жеткorктүү болгон төрт мыкты куралга көңүл бурууну сунуштайм.

GitHub баракчалары

Бүгүнкү күндө GitHubда иштөө тажрыйбасы жок бир дагы иштеп чыгуучу жок болсо керек. Бул ошондой эле documentтерди сактоо үчүн бир жерге муктаж болгон программисттер үчүн сонун жер. Көптөгөн адамдар колдонуучуну жөнөкөй жол менен камсыз кылуу үчүн code базасында стандарттык Readme колдонушат, бирок бул GitHubда documentтерди түзүүнүн жалгыз жолу эмес. GitHub баракчалары менен сиз проектиңиздин барактарына, анын ичинде documentтерге жана окуу куралдарына хостингден көбүрөөк аласыз. Сиз бардык GitHub репозиторийлери менен түздөн-түз иштешүү мүмкүнчүлүгүнө ээ болуп, иштеп чыгуучуларга codeду жаңырткандай эле documentтерди жаңыртуу мүмкүнчүлүгүн аласыз. Мындан тышкары, сиз Jekyllди бул жерден колдонсоңуз болот - бул сиздин белгилөөңүздү жөнөкөй текстке же толук кандуу веб-баракчаларга өзгөртүүгө жардам берет.

Документтерди окуңуз

Аты айтып тургандай, Read the Docs иштеп чыгуучуларга documentтерди сактоо жана окуу үчүн платформаны камсыз кылат. Кызмат GitHub Pages сыяктуу иштейт: программисттер Git, Bazaar, Mercurial жана башкалар сыяктуу сүйүктүү versionсын башкаруу тутумдарынан documentтерге өзгөртүүлөрдү киргизе алышат. Автоматтык түрдө versionлоо жана баракты түзүү да колдоого алынат. Read Docs программасынын эң жакшы жагы анын ийкемдүүлүгү. Ал вебхуктарды колдойт, ошондуктан сиз document түзүү процессинин көбүн автоматташтыра аласыз. Бул көпчүлүк программисттер эч нерсе кылгысы келбеген тапшырманы аткарууда убакытты үнөмдөйт. Кошумчалай кетсек, платформада жайгаштырылган нерселердин бардыгы жалпы коомчулукка ар кандай форматтарда, анын ичинде PDF, бир беттик HTML жана ал тургай электрондук китеп форматында жеткorктүү. Кызмат documentацияны жаңыртуу үчүн күнүмдүк иштердин олуттуу бөлүгүн алат.

Tettra

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

Apiary

Apiaryди иштеп чыгуучулар үчүн абдан пайдалуу кылган нерсе - бул API documentтерине жардам берүү боюнча эң сонун иш. Платформа колдонуучуларга өздөрүнүн documentтерин Markdown ичинде , анын ичинде жасалма API чалууларын жазууга мүмкүнчүлүк берет. Apiary ошондой эле API элементтерин сынап көрүүгө жана прототип кылууга мүмкүндүк берет. Башкача айтканда, бул бир жерде documentтештирүү куралы жана тестирлөө платформасы.