Кодыңызды таза және әдемі ету - белгіленген мерзімге жетудің тамаша тәсілі. Роберт Мартин өзінің қысқаша мәлімдемелерінің бірімен басын қағып: «Код сапасының жалғыз шынайы өлшемі - What-The-F**ks/Minute бірлігі. .” " түпнұсқада). Бұл нені білдіретінін түсіндірейін. Мен codeты қарап шыққан сайын менің миым үш эмоцияның бірімен өтеді:
«WTF?! Бұл не пәле?!» (жиренішпен) - олай емес... бәрі өте нашар....
«WTF?! Бұл не пәле?!» (таңданып) - мм, ақылды жігіт жасады!
«WTF?! Бұл не пәле?!» (тітіркеніп) – әлдебір абыржу, тіпті не айтып отырмыз?!
Сонымен, ең бастысы не және кейбір codeты көргенде біз нені бағалаймыз? Міне, оның тазалығы мен сұлулығы. Таза және әдемі code жазу мүмкіндігі жоғары кәсіби әзірлеушінің көрсеткіші болып табылады. Бұл дағдыға оқыту екі құрамдас – білім мен еңбекке негізделген. Білім сізге үлгілерді, принциптерді, тәжірибелерді, эвристиканы үйретеді. Олар кәсіби өсу үшін қажет. Тек сіз бұл білімді тынымсыз жаттығулар мен тынымсыз еңбек арқылы губка сияқты сіңіруіңіз керек. Қысқасы, таза code жазу оңай емес. Бұл қиын, қажырлы жұмыс, оған көп күш салу керек. Сынақ және қате арқылы сіз өзіңіз қалаған шешімді тапқанша бірдей қадамдарды қайта-қайта қайталау арқылы жақсартасыз. Қарапайым жол жоқ. Төменде таза code жазуды үйренуге көмектесетін бірнеше кеңестер берілген.
Есімде не бар
Кендрик Ламар (американдық хип-хоп әртісі – редактордың ескертпесі) бірде: «Егер мен шынайы оқиғаны айтайын десем, мен өз атымнан бастауым керек», - деп дәл айтқан. Бағдарламалық жасақтаманы әзірлеудегі атаулар барлық жерде. Біз функцияларды, сыныптарды, аргументтерді, пакеттерді, бағдарламаларды - барлығын атаймыз. Біз бастапқы файлдарды және анықтамалық кітаптарды және онымен байланысты барлық нәрселерді атаймыз. Біз заттарды шексіз атаймыз және бұл таза codeты жасау жұмысының маңызды бөлігі болады. Сіз берген атау ниетті көрсетуі керек. Жақсы атауды табу оңай емес, уақытты қажет етеді, бірақ codeпен күресу керек болғанда және жағдай күрделене түскенде көп уақытты үнемдейді. Сондықтан бұл процесте абай болыңыз және қолайлырақ нәрсені тапсаңыз, кейін атауларды өзгертуден қорықпаңыз. Сіздің codeыңызбен айналысатын әрбір адам сізге өте риза болады.
Есіңізде болсын, кез келген айнымалының, класстың, функцияның атауы үш негізгі сұраққа жауап беруі керек: ол (айнымалы, функция және т.б.) неліктен бар, ол не істейді және не үшін қолданылады.
Бұл жақсы суреттеу дағдыларын ғана емес, сонымен қатар жалпы эрудиция мен кең дүниетанымды қажет етеді. Және мұны сізге өзіңізден артық ешкім үйрете алмайды.
«Бір функция» - бір нәрсе
Луи Генри Салливан (американдық рационалист және модернист сәулетші) бір кездері әйгілі: «функция пішінді анықтайды » . Ол бұл туралы үйлердің архитектурасы туралы айтты, бірақ бұл оның мәнін өзгертпейді. Әрбір жүйе бағдарламашылар оны дәл сипаттау үшін жасайтын кейбір домендік тілге негізделген. Функциялар тілдің етістіктерінің қызметін атқарады, ал класстар зат есімдер болып табылады. Көбінесе функциялар бағдарламалау тілін ұйымдастыруда маңызды орын алады және оларды дұрыс жазу жақсы codeты құрудың мәні болып табылады. Сапа функцияларын жазудың екі алтын ережесі бар:
Олар кішкентай болуы керек
Олар бір нәрсені, бір тапсырманы орындауы керек және оны жақсы орындауы керек
Яғни, сіздің функцияңыз шағын болуы керек және кірістірілген құрылымдар болмауы керек. Осылайша, функция шегініс деңгейлері бір немесе екіден көп болмауы керек. Бұл тәсіл codeты оқуды, түсінуді және түсінуді айтарлықтай жеңілдетеді. Сонымен қатар, функция ішіндегі өрнектер абстракцияның бірдей деңгейінде екеніне сенімді болуымыз керек. Функциядағы абстракция деңгейлерін араластыру әрқашан көп шатасуларды тудырады және сайып келгенде, басқарылмайтын codeқа әкеледі. Үздік бағдарламашылар функцияларды жай жазу үшін code емес, әңгімелейтін әңгімелер ретінде қарастырады. Олар тамаша әңгімеші ретінде әрекет ете алатын бай, мәнерлі және таза code блогын жасау үшін таңдаған бағдарламалау тілінің құралдарын пайдаланады.
«Пікірлер нашар codeты толтырмайды»
Винус Уильямс, американдық теннисші және бес дүркін Уимблдон чемпионы: «Әркім өз пікірлерін қалдырады. Осылайша қауесеттер пайда болады » . Пікір екі жүзді қылыш сияқты.Жақсы қойылған пікір өте пайдалы нәрсе. Екінші жағынан, бос орынды бос, пайдасыз пікірлерден артық ештеңе босата алмайды. Бірақ ең зиянды пікірлер – жалған ақпарат пен өтірік тарататын пікірлер. Бір сөзбен айтқанда, түсініктеме - қажетті зұлымдықтың бір түрі. Әрқашан емес, бірақ көп жағдайда. Неліктен? Бұл қарапайым, түсініктеме неғұрлым ескі болса, соғұрлым оны сақтау қиынға соғады және көптеген бағдарламашылар, өздеріңіз білетіндей, әрқашан codeтағы өзгерістермен бірге түсініктемелерді өзгертпейді. Код қозғалады және дамиды. Код бөліктері алға және артқа жылжытылады, бірақ түсініктемелер жоқ. Және бұл проблемаға айналады!
Есіңізде болсын: аз түсініктемелері бар таза, түсінікті code күрделі, ретсіз codeқа қарағанда әлдеқайда жақсы. Түсініктемелерде жасаған хаосты түсіндіруге күшіңізді жұмсамаңыз. Сол уақытты сол ластануды тазалауға жұмсаған дұрыс.
«Кодты пішімдеу әрқашан басымдылық болып табылады»
Мұны Роберт Си Мартин (Роберт Сесил Мартин) басқа ешкім айтқан емес, ака Боб ағай, әзірлеуші , бағдарламалық жасақтаманы әзірлеу бойынша көптеген кітаптардың авторы, кеңесші, Agile манифестінің бірлескен авторы және т.б. Және ол былай деп қосты: «Кодты пішімдеу - бұл коммуникацияның бір түрі. Ал коммуникация кез келген кәсіби әзірлеуші үшін басты басымдық болып табылады». Жоғарыда айтылған мәлімдемені елемеуге болмайды, өйткені ол тамаша әзірлеушінің маңызды сипаттамаларының бірі туралы айтады. Пішімделген code сіздің ойыңызға терең қарауға мүмкіндік береді. Біз адамдарды ұқыптылығымызбен, егжей-тегжейге ұқыптылығымызбен, ойымызды жүйелеп, анық жеткізе білуімізбен таң қалдырғымыз келеді. Бірақ егер адамдар codeты қараған кезде, олар винегретті еске түсіретін, басы да, аяғы да жоқ қандай да бір шатасуды көрсе, бұл сіздің күш-жігеріңізді жоққа шығарады және әзірлеушінің беделін төмендетеді. Оған тіпті күмәнданбаңыз! Егер сіз бұл бизнестегі ең бастысы «code жұмыс істейді» деп ойласаңыз, сіз шындықтан өте алыссыз. Бүгін жасаған функционалдылық келесі шығарылымда өзгертілуі мүмкін, бірақ codeтың оқылу мүмкіндігі өзгермейді. Кодтың стилі және оның жақсы оқылымдылығы бастапқы code танылмастай өзгертілгеннен кейін де codeты ұзақ уақыт сақтауды жеңілдетеді.
Болашақта есте қалатын нәрсе codeтың өзі емес, сіздің стильіңіз бен дәйектілігіңіз екенін ешқашан ұмытпаңыз. Сондықтан codeтың жақсы пішімделгеніне және команданың барлық мүшелеріне түсінікті қарапайым ережелерге сәйкес келетініне көз жеткізіңіз.
Алдымен «try-catch-finally» блогын жасаңыз
Джордж Кангилем (ғылым тарихшысы, философ): «Адам үшін қателік жасау табиғи нәрсе, бірақ қателесуді талап ету - шайтаннан », - деп дұрыс айтқан . Ақауларды жою - бұл барлық бағдарламашылар жасайтын нәрсе. Жарамсыз деректер кіріске енуі мүмкін және құрылғылар істен шығуы мүмкін. Әзірлеушілер ретінде біз codeтың өзі істеу керек нәрсені жасайтынына көз жеткізуіміз керек. Мәселе қателерді өңдеу ғана емес, сонымен қатар «таза және оқуға оңай» қателерді өңдеу. Көптеген бағдарламалар қателерді өңдеуге бейімделеді. Егер сіз мұны жасасаңыз, бәрі хаосқа түседі, негізгі codeтың мақсаты мен логикасы жойылады. Бұл дұрыс емес, олай болмауы керек. Код таза және сенімді болуы керек және қателерді өңдеу codeқа біркелкі және табиғи түрде тоқылған болуы керек. Бұл жоғары деңгейдегі бағдарламашының көрсеткіші. Бұған қол жеткізудің бір жолы - дұрыс орналастыру және try-catch блоктарындағы барлық қателерді қамту. Бұл блоктар сіздің codeыңыздың ауқымын анықтайды. try-catch-finally блогының try бөлігінде codeты орындаған кезде, орындау кез келген уақытта тоқтатылып, одан кейін ұстауда жалғасуы мүмкін екенін айтасыз. Сондықтан codeты жазғанда try-catch-finally арқылы бастауды ұсынамыз. Бұл әрекет ету кезінде codeта ненің дұрыс еместігіне қарамастан, пайдаланушы codeтан не күте алатынын анықтауға көмектеседі.
Сіз шығарған әрбір ерекшелік қатенің орнын және көзін анықтау үшін жеткілікті мәтінмәнді қамтуы керек екенін әрқашан есте сақтаңыз. Шығармашылық және ақпараттық қате туралы хабарлар code жазылғаннан кейін көп уақыт өткен соң, тіпті бағдарламашы мүлдем басқа тапсырмалармен айналысса да, есте сақталады.
Жинақтау
Бір ерекше сөз тіркесі жоғарыда айтылғандардың барлығын қорытындылауға көмектеседі. Бұл code-сезім немесе «жалпы code сезімі», қарапайым мағынаның бағдарламашы баламасы. Роберт Мартиннің сөзімен айтқанда: «Таза codeты жазу «тазалық» деген мұқият және аздап ауыр сезімнің нәтижесінде қолданылатын көптеген шағын әдістерді жүйелі пайдалануды талап етеді. Бұл кішігірім әдістер жалпы codeты сезіну деп аталады » . Кейбіреулерімізде бұл «дыбыстық code сезімі» басынан бері бар, ал басқалары оны тұрақты тәжірибе арқылы дамыту керек. Бұл инстинкт жаман және жақсы code арасындағы айырмашылықты тануға ғана емес, сонымен қатар жаман codeты жақсыға айналдыруға бағытталған стратегияларды қалыптастыруға көмектеседі. Нашар code бәрін бұзады. Бейнелеп айтсақ, ең дәмді тортты ит боқымен тоңазытып алсаңыз, онда... у... ешкімге ұнамауы екіталай. Кодты сезіну бағдарламашыға таза code жасау мақсатына жету үшін дұрыс құралдарды пайдалануға көмектеседі. Код-сезім дегеннің не екенін түсінетін программист – бос экранда көп жылдар бойы есте қалатын өнер туындысын жасай алатын суретші. Мит университетінің информатика профессоры және Creative Commons және Free Software Foundation қорының негізін қалаушы директоры Гарольд «Хал» Абельсон былай деп түйіндеді: «Бағдарламалар алдымен адамдар оқи алатындай етіп жазылуы керек, содан кейін олар оқи алатындай етіп жазылуы керек. орындалды.» машинасы» . Тақырып бойынша не оқуға болады: «Agile Software Craftsmanship анықтамалығы» - Роберт Мартин. «Agile estimation анықтамалығы» - Майк Кон Author туралы: Рави Шанкар Раджан – Мумбайдан (Үндістан) жаһандық IT бағдарламасының менеджері. Танымал блогер, хайку ақыны, археология мен тарихқа құмар. Сіз онымен Twitter , Medium , LinkedIn арқылы байланыса аласыз
GO TO FULL VERSION