2018 жылдың басынан бері мен командада жетекші/бастық/жетекші әзірлеуші лауазымын атқарып келемін - оны қалағаныңызша атаңыз, бірақ мәні мынада, мен модульдердің біріне және жұмыс істейтін барлық әзірлеушілерге толығымен жауаптымын. үстінде. Бұл позиция маған даму үдерісіне жаңа көзқарас береді, өйткені мен көбірек жобаларға қатысып, шешім қабылдауға белсендірек қатысамын. Жақында осы екі нәрсенің арқасында мен түсіну өлшемі код пен қолданбаға қаншалықты әсер ететінін кенет түсіндім.
Мен айтқым келетін мәселе, кодтың сапасы (және соңғы өнім) кодты құрастыратын және жазатын адамдардың не істеп жатқанын қаншалықты білетіндігімен тығыз байланысты.
Сіз дәл қазір ойлайтын шығарсыз: «Рахмет, кап. Әрине, жалпы не жазып жатқаныңызды түсінсеңіз жақсы болар еді. Әйтпесе, ерікті пернелерді басып, оны қалдыру үшін маймылдар тобын жалдауға болады. Және сіз мүлдем дұрыссыз. Тиісінше, мен сіз не істеп жатқаныңыз туралы жалпы түсінікке ие болу қажет екенін түсінетіндігіңізді кәдімгідей қабылдаймын. Мұны түсінудің нөлдік деңгейі деп атауға болады, біз оны егжей-тегжейлі талдамаймыз. Біз нақты нені түсінуіңіз керек екенін және оның күнделікті қабылдайтын шешімдеріңізге қалай әсер ететінін егжей-тегжейлі қарастырамыз. Егер мен бұл нәрселерді алдын ала білген болсам, бұл мені босқа кететін уақыт пен күмәнді кодты үнемдейтін еді.
Төменде кодтың бір жолын көрмесеңіз де, мен мұнда айтылғандардың бәрі жоғары сапалы, мәнерлі код жазу үшін өте маңызды деп ойлаймын.
Түсінудің бірінші деңгейі: Неліктен ол жұмыс істемейді?
Әзірлеушілер әдетте бұл деңгейге өздерінің мансабында өте ерте жетеді, кейде тіпті басқалардың көмегінсіз - кем дегенде менің тәжірибемде. Қате туралы есеп алдыңыз деп елестетіңіз: қолданбадағы кейбір функция жұмыс істемейді, оны түзету керек. Сіз қалай әрекет етесіз?
Стандартты схема келесідей көрінеді:
- Мәселені тудыратын код бөлігін табыңыз (мұны қалай жасау керек - бұл бөлек тақырып, мен оны бұрынғы код туралы кітабымда қарастырамын)
- Осы үзіндіге өзгерістер енгізіңіз
- Қате түзетілгеніне және ешқандай регрессия қателері орын алмағанына көз жеткізіңіз
Енді екінші тармаққа тоқталайық – кодқа өзгерістер енгізу. Бұл процеске екі көзқарас бар. Біріншісі - ағымдағы кодта не болып жатқанын анықтау, қатені анықтау және оны түзету. Екіншіден: сезіну арқылы жылжытыңыз - шартты мәлімдемеге немесе циклге +1 қосыңыз, айталық, функция қажетті сценарийде жұмыс істейтінін көріңіз, содан кейін басқа нәрсені көріңіз және т.с.с. ad infinitum.
Бірінші тәсіл дұрыс. Стив МакКоннелл өзінің Code Complete кітабында түсіндіргендей (айтпақшы, мен оны өте ұсынамын), біз кодтағы бір нәрсені өзгерткен сайын, оның қолданбаға қалай әсер ететінін сенімді түрде болжай білуіміз керек. Мен жадтан үзінді келтіріп отырмын, бірақ егер қатені түзету сіз күткендей жұмыс істемесе, сіз қатты алаңдап, бүкіл әрекет жоспарыңызға күмәндануыңыз керек.
Айтылғандарды қорытындылау үшін кодтың сапасын төмендетпейтін жақсы қатені түзету үшін кодтың бүкіл құрылымын да, нақты мәселенің көзін де түсінуіңіз керек.
Түсінудің екінші деңгейі: бұл не үшін жұмыс істейді?
Бұл деңгей алдыңғы деңгейге қарағанда интуитивті түрде азырақ түсініледі. Мен әлі де жаңадан әзірлеуші болған кезде, оны бастығымның арқасында білдім, содан кейін жаңадан келгендерге мәселенің мәнін бірнеше рет түсіндірдім.
Бұл жолы сіз бірден екі қате туралы есеп алдыңыз деп елестетейік: біріншісі А сценарийі туралы, екіншісі В сценарийі туралы. Екі сценарийде де бірдеңе дұрыс емес болады. Тиісінше, сіз бірінші қатені шешесіз. XNUMX-деңгейді түсіну үшін әзірлеген қағидаттарды пайдалана отырып, сіз мәселеге қатысты кодты тереңірек зерттейсіз, неге ол қолданбаның А сценарийіндегідей әрекет ететінін анықтайсыз және қалаған нәтижені беретін ақылға қонымды түзетулер жасайсыз. . Барлығы керемет өтіп жатыр.
Содан кейін сіз B сценарийіне өтесіз. Қателік тудыруға әрекеттеніп сценарийді қайталайсыз, бірақ — таң қалдырыңыз! — қазір бәрі өз қалауынша жұмыс істейді. Сіздің болжамыңызды растау үшін сіз A қатесінде жұмыс істеу кезінде жасалған өзгертулерді қайтарасыз және B қатесі қайта оралады. Түзетуіңіз екі мәселені де шешті. Бақытты!
Сіз мұны мүлде санаған жоқсыз. Сіз А сценарийіндегі қатені түзету жолын ойлап таптыңыз және оның неліктен В сценарийі үшін жұмыс істегенін білмейсіз. Бұл кезеңде екі тапсырма да сәтті орындалды деп ойлау өте қызықты. Бұл өте қисынды: мәселе қателерді жою болды, солай емес пе? Бірақ жұмыс әлі аяқталған жоқ: сіздің әрекеттеріңіз B сценарийіндегі қатені неге түзеткенін әлі де анықтауыңыз керек. Неліктен? Өйткені ол дұрыс емес принциптермен жұмыс істеуі мүмкін, содан кейін басқа жолды іздеу керек болады. Міне, осындай жағдайлардың бірнеше мысалы:
- Шешім барлық факторларды ескере отырып, B қатесіне бейімделмегендіктен, сізде C функциясы білмей бұзылған болуы мүмкін.
- Сондай-ақ, бір жерде сол функцияға қатысты үшінші қате жасырынып қалуы мүмкін және сіздің қатені түзету B сценарийінде жүйенің дұрыс жұмыс істеуіне байланысты. Қазір бәрі жақсы сияқты, бірақ бір күні бұл үшінші қатені байқап, түзетеді. Содан кейін В сценарийінде қате қайта пайда болады және тек сонда болғаны жақсы.
Мұның бәрі кодқа хаос қосады және бір күні сіздің басыңызға түседі - ең сәтсіз сәтте. Неліктен бәрі жұмыс істейтінін түсінуге уақыт бөлуге мәжбүрлеу үшін ерік-жігеріңізді жинауыңыз керек, бірақ бұл оған тұрарлық.
Түсінудің үшінші деңгейі: бұл не үшін жұмыс істейді?
Менің жақында түсінгенім дәл осы деңгейге қатысты және егер мен бұл идеяға ертерек келсем, маған ең көп пайдасын тигізер еді.
Чтобы было понятнее, разберем на примере: ваш модуль нужно сделать совместимым с функцией X. Вы не особенно близко знакомы с функцией X, но вам сказали, что для совместимости с ней нужно использовать фреймворк F. Другие модули, которые интегрируются с X, работают именно онымен.
Сіздің кодыңыз өмірінің бірінші күнінен бастап F шеңберімен мүлдем байланыста болған жоқ, сондықтан оны енгізу оңай болмайды. Бұл модульдің кейбір бөліктері үшін ауыр зардаптарға әкеледі. Дегенмен, сіз өзіңізді дамуға жібересіз: сіз апта бойы код жазуға, тестілеуге, пилоттық нұсқаларды шығаруға, кері байланыс алуға, регрессия қателерін түзетуге, күтпеген асқынуларды анықтауға, бастапқыда келісілген мерзімдерге сәйкес келмеуге, тағы бірнеше код жазуға, тестілеуге, кері байланыс алу, регрессия қателерін түзету – мұның бәрі F шеңберін жүзеге асыру үшін.
Және бір сәтте сіз кенеттен түсінесіз немесе біреуден естуіңіз мүмкін - мүмкін F жүйесі сізге X мүмкіндігімен үйлесімділік бермеуі мүмкін. Мүмкін, бұл уақыт пен күш-жігердің бәрі дұрыс емес.
Бірде мен жауапты жобада жұмыс істеп жүргенде осындай жағдай болды. Неліктен бұл болды? Себебі мен X функциясының не екенін және оның F шеңберімен қалай байланысты екенін түсінбедім. Не істеуім керек еді? Әзірлеу тапсырмасын тағайындаған адамнан басқа модульдер үшін жасалғанды жай ғана қайталаудың немесе X функциясының осыны орындауы керек деген сөзін қабылдаудың орнына, жоспарланған әрекет бағыты қалай қалаған нәтижеге әкелетінін нақты түсіндіруін сұраңыз.
Бұл жобаның тәжірибесі маған неліктен бізден белгілі бір нәрселерді орындауды сұрайтынын нақты түсінбейінше, әзірлеу процесін бастаудан бас тартуға үйретті. Тікелей бас тарту. Тапсырманы алған кезде бірінші серпін - уақытты босқа өткізбеу үшін оны бірден қабылдау. Бірақ «барлық егжей-тегжейлерге қол жеткізгенше жобаны тоқтатыңыз» саясаты уақытты үлкен көлемде азайтады.
Олар сізге қысым көрсетуге, жұмысқа кірісуге мәжбүрлеуге тырысса да, сіз мұның себебін түсінбесеңіз де, қарсы тұрыңыз. Алдымен, сізге неліктен мұндай тапсырма берілгенін анықтаңыз және бұл мақсатқа жетудің дұрыс жолы екенін шешіңіз. Мен мұның бәрін қиын жолмен үйренуге тура келді - менің үлгісім мұны оқығандардың өмірін жеңілдетеді деп сенемін.
Түсінудің төртінші деңгейі: ???
Бағдарламалауда әрқашан көп нәрсені үйренуге болады және мен түсіну тақырыбының бетін ғана сызып тастадым деп ойлаймын. Кодпен жұмыс істеген жылдар ішінде түсінудің тағы қандай деңгейлерін таптыңыз? Сіз код пен қолданбаның сапасына оң әсер еткен қандай шешімдер қабылдадыңыз? Қандай шешімдер дұрыс емес болып шықты және сізге құнды сабақ болды? Пікірлерде тәжірибеңізбен бөлісіңіз.
Ақпарат көзі: www.habr.com