Kofe tanaffusi №20. Eski kod nima va u bilan qanday ishlash kerak. Texnik hujjatlarni yozishni osonlashtiradigan vositalar

Eski kod nima va u bilan qanday ishlash kerak

Manba: Dou Erta va kech dasturchi, ehtimol, eski kodga duch kelishi kerak. Ushbu tanishuvning oqibatlarini engillashtirish uchun men o'z tajribamdan ba'zi amaliy maslahatlar va misollarni tanladim - xususan, eski Java tizimi bilan ishlash.

Eski xususiyatlar

Legacy - bu boshqa birovning kodi, u ko'pincha shunchalik dahshatliki, u bilan qanday ishlashni umuman tushunib bo'lmaydi. Va agar siz eski tizim bilan ishlashingiz kerak bo'lsa, eski kodga qo'shimcha ravishda siz ham duch kelasiz:

• eskirgan texnologiya bilan;
• heterojen arxitektura;
• hujjatlarning yo'qligi yoki hatto to'liq yo'qligi.

Darhaqiqat, eski kod unchalik qo'rqinchli emas va shuning uchun: agar tizim o'n yil davomida yashagan bo'lsa va hali ham ishlayotgan bo'lsa, unda biroz foyda bor. Balki u yaxshi pul topadi (oxirgi startapingizdan farqli o'laroq). Bundan tashqari, agar u ishlab chiqarishda shu qadar uzoq davom etsa, ushbu kod nisbatan ishonchli hisoblanadi. Shuning uchun unga o'zgartirishlar ehtiyotkorlik bilan kiritilishi kerak. Avvalo, siz ikkita narsani tushunishingiz kerak:

1. Biz millionlab daromad keltiradigan yoki kuniga minglab odamlar tomonidan foydalaniladigan tizimga hurmatsizlik qila olmaymiz. Qanchalik yomon yozilgan bo'lmasin, bu jirkanch kod ishlab chiqarishgacha saqlanib qoldi va 24/7 ishlaydi.

2. Ushbu tizim haqiqiy pul olib kelganligi sababli, u bilan ishlash katta mas'uliyatni talab qiladi. Bu startap emas, balki foydalanuvchilar ertaga ishlaydi. Bu, shuningdek, xatoning juda yuqori narxini nazarda tutadi va bu erda nuqta mijozning da'volarida emas, balki ishlarning haqiqiy holatida.

Teskari muhandislik

Eski kod bilan muvaffaqiyatli ishlash uchun siz teskari muhandislik texnikasidan foydalanishingiz kerak bo'ladi. Birinchidan, uning qanday ishlashini tushunish uchun kodni diqqat bilan o'qib chiqishingiz kerak. Bu majburiy, chunki bizda hujjatlar bo'lmasligi mumkin. Agar biz muallifning fikrini tushunmasak, biz oldindan aytib bo'lmaydigan oqibatlarga olib keladigan o'zgarishlar qilamiz. O'zingizni bundan himoya qilish uchun siz qo'shni kodni ham o'rganishingiz kerak. Va ayni paytda nafaqat kenglikda, balki chuqurlikda ham harakat qiling. Xato bilan chaqirilgan usul qayerda? Uni chaqiradigan kod qayerdan keladi? Eski loyihada "qo'ng'iroqlar ierarxiyasi" va "tur ierarxiyasi" hamma narsadan ko'ra tez-tez ishlatiladi. Tuzatish vositasi bilan ko'p vaqt sarflashingiz kerak bo'ladi: birinchidan, xatolarni topish, ikkinchidan, hamma narsa qanday ishlashini tushunish. Hujjatlarga kelsak, sanoat arxeologiyasiga murojaat qilish yomon fikr bo'lmaydi. Qaerdadir eski hujjatlarni qazib olish va siz meros qilib olgan kod qanday yozilganini eslayotganlar bilan suhbatlashish juda foydali bo'lishi mumkin. Ushbu usullardan foydalanib, ertami-kechmi siz kodni ko'proq yoki kamroq tushuna boshlaysiz. Ammo sa'y-harakatlaringiz behuda ketishining oldini olish uchun tadqiqot natijalarini darhol hujjatlashtirishingiz kerak. Buning uchun blok-sxema yoki ketma-ketlik sxemalarini chizishni tavsiya qilaman. Albatta, siz dangasa bo'lasiz, lekin buni albatta qilishingiz kerak, aks holda olti oy ichida hujjatsiz ushbu kodni birinchi marta bo'lgani kabi qazib olasiz.

Kodni qayta yozmang

Rivojlanish jarayonida eng muhim narsa o'z vaqtida o'zingizni mag'lub qilish va butun kodni noldan qayta yozishga urinmaslikdir. Buning uchun qancha odam-yil talab qilinishini hisoblang. Xaridor allaqachon ishlayotgan narsani qayta tiklash uchun juda ko'p pul sarflashni xohlashi dargumon. Bu nafaqat butun tizimga, balki uning istalgan qismiga ham tegishli. Albatta, ular sizga hamma narsani aniqlash uchun bir hafta, biror narsani tuzatish uchun yana bir hafta berishlari mumkin. Ammo ular sizga tizimning bir qismini qayta yozish uchun ikki oy berishlari dargumon. Buning o'rniga, yangi funksiyani kodning qolgan qismi bilan bir xil uslubda amalga oshiring. Boshqacha qilib aytganda, agar kod eski bo'lsa, siz yangi chiroyli texnologiyalardan foydalanishga vasvasaga tushmasligingiz kerak: bunday kodni o'qish juda qiyin bo'ladi. Misol uchun, siz bizda bo'lgan vaziyatga duch kelishingiz mumkin: tizimning bir qismi Spring MVC-da, bir qismi esa yalang'och servletlarda yozilgan. Va agar servletlarda yozilgan qismga boshqa biror narsa qo'shilishi kerak bo'lsa, biz uni xuddi shu tarzda - servletlarda qo'shamiz.

Biznes manfaatlarini hurmat qiling

Shuni esda tutish kerakki, har qanday vazifa, birinchi navbatda, biznes uchun qiymat bilan belgilanadi. Agar siz mijozga biznes nuqtai nazaridan ma'lum o'zgarishlar zarurligini isbotlamasangiz, bu o'zgarishlar sodir bo'lmaydi. Va mijozni ishontirish uchun siz uning o'rnida turishga va uning manfaatlarini tushunishga harakat qilishingiz kerak. Xususan, agar siz kodni o'qish qiyin bo'lganligi sababli qayta tiklashni xohlasangiz, sizga ruxsat berilmaydi va siz u bilan yashashingiz kerak. Agar chindan ham chiday olmasangiz, ishni biznes chiptalari bo'ylab tarqatib, kodni asta-sekin va asta-sekin qayta tashkil qilishingiz mumkin. Yoki mijozni bu, masalan, xatolarni topish uchun zarur bo'lgan vaqtni qisqartirishiga va natijada xarajatlarni kamaytirishiga ishontiring.

Sinov

Har qanday loyihada test zarurligi aniq. Ammo eski tizimlar bilan ishlashda sinovga alohida e'tibor berilishi kerak, chunki kiritilgan o'zgarishlarning ta'siri har doim ham oldindan aytib bo'lmaydi. Sizga ishlab chiquvchilar kabi kamida ko'p tester kerak bo'ladi, aks holda siz avtomatlashtirishda ajoyib darajada yaxshi bo'lishingiz kerak. Bizning loyihamizda test quyidagi bosqichlardan iborat edi:

1. Tasdiqlash, funksiyaning amalga oshirilgan funksionalligi alohida bo'limda tekshirilganda.
2. Stabilizatsiya, barcha xususiyatlar birlashtirilgan bo'lgan reliz filiali tekshirilganda.
3. Sertifikatlash, xuddi shu narsa apparat xususiyatlari va konfiguratsiyasi bo'yicha ishlab chiqarishga imkon qadar yaqin bo'lgan sertifikatlashtirish muhitida biroz boshqacha sinov holatlarida qayta ishga tushirilganda.

Va faqat ushbu uch bosqichdan o'tganimizdan keyingina biz reliz qilishimiz mumkin. Kimdir sertifikatlashni qo'shimcha bosqich deb o'ylaydi, chunki hamma narsa barqarorlashtirish bosqichida aniqlangan, ammo bizning tajribamiz shuni ko'rsatadiki, bu unday emas: ba'zida boshqa mashinada ikkinchi bosqichda o'tkaziladigan regressiya testi paytida, qandaydir tarzda nimadir. chiqadi.

DevOps-ni rasmiylashtiring va chiqaring

Chiqarish tartibi, masalan, quyidagicha bo'lishi mumkin. Ishlab chiqish tugallangach va ikki yoki uchta sinov bosqichi tugallangandan so'ng, kutilgan vaqtdan 36 soat oldin DevOps jamoasiga elektron pochta xabarini yozamiz. Shundan so'ng, biz devops jamoasini chaqiramiz va muhitdagi barcha o'zgarishlarni muhokama qilamiz (biz ularga ma'lumotlar bazasi va konfiguratsiyadagi barcha o'zgarishlar haqida xabar beramiz). Har bir o'zgarish uchun bizda hujjat bor (Jiradagi chipta). Keyin, reliz paytida, bu bilan shug'ullanadigan har bir kishi yig'iladi va hamma hozir nima qilayotganini aytadi: "Biz ma'lumotlar bazasini yukladik", "Biz falon serverlarni qayta ishga tushirdik", "Biz ishlab chiqarish muhitida regressiya testlarini o'tkazish uchun bordik. ” Agar biror narsa noto'g'ri bo'lsa, relizning asl hujjatida aniq tasvirlangan relizni orqaga qaytarish protsedurasi ishga tushiriladi - bunday hujjatsiz biz albatta nimanidir unutamiz yoki chalkashib ketamiz.

Kod sifatini nazorat qilish

Va nihoyat, kodni ko'rib chiqish - bu ba'zi sabablarga ko'ra barcha loyihalarda ishlatilmaydigan amaliyot. Har bir kod bir nechta odam tomonidan ko'rib chiqilsa, bu juda yaxshi. Hatto juda kuchli jamoada ham kodni ko'rib chiqish jarayonida ba'zi xatolar doimo topiladi va agar bir necha kishi unga qarasa, aniqlangan xatolar soni ortadi. Bundan tashqari, ba'zida uchinchi yoki to'rtinchi sharhlovchi eng yomon narsani topadi.

Texnik hujjatlarni yozishni osonlashtiradigan vositalar

Manba: Dzone Ko'pchilik dasturchilar texnik hujjatlar yozishni yoqtirmaydilar. Psixolog Jerald Vaynberg hatto hujjatlarni "dasturlashning kastor yog'i" deb atagan: ishlab chiquvchilar uni o'qishni yaxshi ko'radilar, lekin ular o'zlari yozishni yomon ko'radilar. Yo'l-yo'riq yoki bo'sh yo'l xaritasining etishmasligi dasturiy ta'minotning turli qismlari qanday ishlashi haqida ma'lumot etishmasligiga olib keladi. Bu oxir-oqibat kodning oxirgi foydalanuvchilari tajribasini yomonlashtiradi, chunki hujjatlar yo'q bo'lganda, ular mahsulotning aniqligi va foydaliligiga tayana olmaydi. Dasturchilarga hujjatlar yozish odatini shakllantirishni osonlashtirish uchun men deyarli hamma uchun mavjud bo'lgan to'rtta ajoyib vositaga e'tibor berishni tavsiya qilaman.

GitHub sahifalari

Ehtimol, bugungi kunda GitHub’da ishlash tajribasiga ega bo‘lmagan bironta dasturchi yo‘q. Bu, shuningdek, hujjatlarni saqlash uchun biror joyga muhtoj bo'lgan dasturchilar uchun ajoyib joy. Ko'p odamlar foydalanuvchiga oddiy qo'llanmani taqdim etish uchun o'zlarining kod bazasida standart Readme-dan foydalanadilar, ammo bu GitHub-da hujjatlarni yaratishning yagona usuli emas. GitHub sahifalari yordamida siz loyihangiz sahifalari, jumladan, hujjatlar va oʻquv qoʻllanmalari uchun xostingdan koʻproq narsani olasiz. Siz barcha GitHub omborlari bilan to'g'ridan-to'g'ri o'zaro aloqada bo'lish imkoniyatiga ega bo'lasiz, bu esa ishlab chiquvchilarga o'z kodlarini yangilagani kabi hujjatlarni yangilash imkonini beradi. Bundan tashqari, siz Jekyll-dan bu erda foydalanishingiz mumkin - bu sizning belgilaringizni oddiy matnga yoki to'liq huquqli veb-sahifalarga aylantirishga yordam beradi.

Hujjatlarni o'qing

Nomidan ko'rinib turibdiki, Read the Docs dasturchilarga hujjatlarni saqlash va o'qish uchun platformani taqdim etadi. Xizmat GitHub Pages kabi ishlaydi: dasturchilar Git, Bazaar, Mercurial va boshqalarni o'z ichiga olgan sevimli versiyalarni boshqarish tizimlaridan hujjatlarga o'zgartirishlar kiritishlari mumkin. Avtomatik versiya yaratish va sahifa yaratish ham qo'llab-quvvatlanadi. Read Docs-ning eng yaxshi tomoni uning moslashuvchanligidir. Hujjat yaratish jarayonining ko'p qismini avtomatlashtirishingiz uchun u veb-huklarni qo'llab-quvvatlaydi. Bu ko'pchilik dasturchilar hech narsa qilishni xohlamaydigan vazifani bajarishda juda katta vaqtni tejaydi. Bundan tashqari, platformada joylashtirilgan hamma narsa keng omma uchun turli formatlarda, jumladan PDF, bir sahifali HTML va hatto elektron kitob formatida mavjud. Xizmat hujjatlarni yangilab turish uchun muntazam ishlarning muhim qismini o'z zimmasiga oladi.

Tettra

Tettra nafaqat dasturiy hujjatlarni saqlash uchun platforma, balki to'liq bilimlar bazasi. Bu, ayniqsa, loyiha turli xil dasturiy ta'minot bo'laklarida ishlaydigan koderlarning katta guruhini o'z ichiga olganida yaxshi ishlaydi. Tettra umumiy savollarga javoblarni hujjatlashtirish uchun ishlatilishi mumkin.

Asalarizor

Apiary-ni ishlab chiquvchilar uchun juda foydali qiladigan narsa shundaki, u API hujjatlari bilan yordam berishda juda yaxshi ish qiladi. Platforma foydalanuvchilarga o'z hujjatlarini Markdown da , jumladan soxta API qo'ng'iroqlarini yozish imkonini beradi. Apiary shuningdek, API elementlarini sinab ko'rish va prototip qilish imkonini beradi. Boshqacha qilib aytganda, bu bir joyda hujjatlashtirish vositasi va sinov platformasi.