Kofe fasiləsi №20. Köhnə kod nədir və onunla necə işləmək olar. Texniki sənədlərin yazılmasını asanlaşdıran alətlər

Köhnə kod nədir və onunla necə işləmək olar

Mənbə: Dou Gec-tez bir proqramçı yəqin ki, köhnə kodla qarşılaşmalı olacaq. Bu tanışlığın nəticələrini yüngülləşdirmək üçün mən öz təcrübəmdən bəzi praktiki məsləhətlər və nümunələr seçdim - xüsusən də köhnə Java sistemi ilə işləmək.

Köhnə Xüsusiyyətlər

Miras başqasının kodudur, çox vaxt o qədər dəhşətlidir ki, onunla necə işləmək ümumiyyətlə aydın deyil. Və köhnə bir sistemlə işləməlisinizsə, köhnə koddan əlavə, siz də qarşılaşacaqsınız:

• köhnəlmiş texnologiya ilə;
• heterojen memarlıq;
• sənədlərin olmaması və ya hətta tam olmaması.

Əslində, köhnə kod o qədər də qorxulu deyil və bunun səbəbi budur: sistem bütün bu on il yaşayıbsa və hələ də işləyirsə, deməli, onun müəyyən faydası var. Bəlkə də yaxşı pul qazanır (son başlanğıcınızdan fərqli olaraq). Bundan əlavə, bu kod istehsalda bu qədər uzun müddət yaşaya bilsəydi, nisbətən etibarlıdır. Buna görə də ona dəyişikliklər ehtiyatla edilməlidir. Əvvəlcə iki şeyi başa düşməlisiniz:

1. Milyonlar qazanan və ya gündə minlərlə insanın daxil olduğu sistemə hörmətsizlik edə bilmərik. Nə qədər pis yazılsa da, bu iyrənc kod istehsala qədər sağ qaldı və 24/7 işləyir.

2. Bu sistem real pul gətirdiyi üçün onunla işləmək böyük məsuliyyət daşıyır. Bu başlanğıc deyil, istifadəçilərin sabah işləyəcəyi bir şeydir. Bu, həm də səhvin çox yüksək qiymətini nəzərdə tutur və buradakı məqam müştərinin iddialarında deyil, işin real vəziyyətindədir.

Əks mühəndislik

Köhnə kodla uğurla işləmək üçün tərs mühəndislik üsullarından istifadə etməli olacaqsınız. Birincisi, tam olaraq necə işlədiyini başa düşmək üçün kodu diqqətlə oxumalısınız. Bu məcburidir, çünki çox güman ki, sənədlərimiz olmayacaq. Müəllifin düşüncə qatarını başa düşməsək, gözlənilməz nəticələrlə dəyişikliklər edəcəyik. Özünüzü bundan qorumaq üçün qonşu kodu da araşdırmaq lazımdır. Və eyni zamanda yalnız genişlikdə deyil, həm də dərinlikdə hərəkət edin. Səhvlə çağırılan metod haradadır? Onu çağıran kod haradan gəlir? Köhnə bir layihədə "zəng iyerarxiyası" və "tip iyerarxiyası" hər şeydən daha çox istifadə olunur. Sazlayıcı ilə çox vaxt sərf etməli olacaqsınız: birincisi, səhvləri tapmaq, ikincisi, hər şeyin necə işlədiyini başa düşmək. Sənədləşməyə gəlincə, sənaye arxeologiyasına müraciət etmək pis fikir olmazdı. Köhnə sənədləri hardasa qazmaq və miras aldığınız kodun necə yazıldığını xatırlayanlarla danışmaq çox faydalı ola bilər. Bu üsullardan istifadə edərək, gec-tez kodu az-çox başa düşməyə başlayacaqsınız. Ancaq səylərinizin boşa getməməsi üçün tədqiqatınızın nəticələrini dərhal sənədləşdirməlisiniz. Bunun üçün blok-sxemlər və ya ardıcıllıq diaqramları çəkməyi məsləhət görürəm. Əlbəttə ki, siz tənbəllik edəcəksiniz, amma bunu mütləq etməlisiniz, əks halda altı ay ərzində sənədləşmədən bu kodu ilk dəfə olduğu kimi qazacaqsınız.

Kodu yenidən yazmayın

İnkişaf prosesində ən vacib şey, özünüzü vaxtında döymək və bütün kodu sıfırdan yenidən yazmağa çalışmamaqdır. Bunun neçə adam-il tələb edəcəyini hesablayın. Müştərinin artıq işləyən bir şeyi yenidən düzəltmək üçün bu qədər pul xərcləmək istəməsi ehtimalı azdır. Bu, təkcə bütövlükdə sistemə deyil, həm də onun istənilən hissəsinə aiddir. Təbii ki, hər şeyi başa düşmək üçün sizə bir həftə, nəyisə düzəltmək üçün bir həftə vaxt verə bilərlər. Ancaq çətin ki, sizə sistemin bir hissəsini yenidən yazmaq üçün iki ay vaxt versinlər. Bunun əvəzinə, kodun qalan hissəsi ilə eyni üslubda yeni funksiyanı həyata keçirin. Başqa sözlə, əgər kod köhnədirsə, yeni gözəl texnologiyalardan istifadə etməyə tələsməməlisiniz: belə kodu oxumaq çox çətin olacaq. Məsələn, bizdə olduğu kimi bir vəziyyətlə qarşılaşa bilərsiniz: sistemin bir hissəsi Spring MVC-də, bir hissəsi isə çılpaq servletlərdə yazılmışdır. Servletlərdə yazılmış hissəyə başqa bir şey əlavə etmək lazımdırsa, biz onu eyni şəkildə - servletlərdə əlavə edirik.

Biznes maraqlarına hörmət edin

Yadda saxlamaq lazımdır ki, hər hansı bir vəzifə, ilk növbədə, biznesin dəyəri ilə müəyyən edilir. Müştəriyə biznes baxımından müəyyən dəyişikliklərə ehtiyac olduğunu sübut etməsəniz, bu dəyişikliklər baş verməyəcək. Və müştərini inandırmaq üçün onun yerində dayanmağa və maraqlarını başa düşməyə çalışmalısan. Xüsusilə, kodun oxunması çətin olduğu üçün refaktor etmək istəyirsinizsə, sizə bunu etməyə icazə verilməyəcək və onunla yaşamalı olacaqsınız. Əgər həqiqətən dözə bilmirsinizsə, işi biznes biletləri arasında yayaraq, kodu sakitcə və yavaş-yavaş yenidən təşkil edə bilərsiniz. Və ya müştərini inandırın ki, bu, məsələn, səhvləri tapmaq üçün tələb olunan vaxtı azaldacaq və nəticədə xərcləri azaldır.

Test

Aydındır ki, hər hansı bir layihədə test lazımdır. Ancaq köhnə sistemlərlə işləyərkən sınaqlara xüsusi diqqət yetirilməlidir, çünki edilən dəyişikliklərin təsiri həmişə proqnozlaşdırıla bilməz. Ən azı tərtibatçılar qədər çox testerə ehtiyacınız olacaq, əks halda avtomatlaşdırmada inanılmaz dərəcədə yaxşı olmalısınız. Layihəmizdə sınaq aşağıdakı mərhələlərdən ibarət idi:

1. Doğrulama, funksiyanın həyata keçirilən funksionallığı ayrı bir bölmədə yoxlanıldıqda.
2. Stabilizasiya, bütün xüsusiyyətlərin birləşdiyi buraxılış şöbəsi yoxlanıldıqda.
3. Sertifikatlaşdırma, eyni şey avadanlıq xüsusiyyətləri və konfiqurasiya baxımından istehsala mümkün qədər yaxın olan sertifikatlaşdırma mühitində bir qədər fərqli sınaq vəziyyətlərində yenidən işə salındıqda.

Və yalnız bütün bu üç mərhələdən keçdikdən sonra buraxılış edə bilərik. Kimsə yəqin ki, sertifikatlaşdırmanın əlavə bir mərhələ olduğunu düşünür, çünki sabitləşmə mərhələsində hər şey artıq aydınlaşdırılıb, lakin təcrübəmiz bunun belə olmadığını göstərir: bəzən başqa bir maşında ikinci tur üçün keçirilən reqressiya testi zamanı nəsə bir şey çıxacaq.

DevOps-u rəsmiləşdirin və buraxın

Buraxılış proseduru, məsələn, aşağıdakı kimi ola bilər. İnkişaf tamamlandıqda və iki və ya üç sınaq mərhələsi başa çatdıqda, gözlənilən buraxılış vaxtından 36 saat əvvəl DevOps komandasına e-poçt yazırıq. Bundan sonra biz devops komandasına zəng edirik və mühitlərdəki bütün dəyişiklikləri müzakirə edirik (biz onlara verilənlər bazası və konfiqurasiyadakı bütün dəyişikliklər barədə məlumat veririk). Hər dəyişiklik üçün əlimizdə bir sənəd var (Jira-da bilet). Daha sonra buraxılış zamanı bununla məşğul olan hər kəs bir araya gəlir və hər kəs indi nə etdiyini deyir: “Biz verilənlər bazasını yüklədik”, “Filan serverləri yenidən işə saldıq”, “İstehsal mühitində reqressiya testləri keçirməyə getdik. ” Bir şey səhv olarsa, orijinal buraxılış sənədində dəqiq təsvir olunan buraxılış geri qaytarma proseduru işə salınır - belə bir sənəd olmadan biz mütləq bir şeyi unutacağıq və ya çaşqınlaşacağıq.

Kodun keyfiyyətinə nəzarət

Və nəhayət, kodun nəzərdən keçirilməsi nədənsə bütün layihələrdə istifadə olunmayan bir təcrübədir. Hər bir kod parçası birdən çox şəxs tərəfindən nəzərdən keçirilirsə, əladır. Çox güclü komandada belə, kodun nəzərdən keçirilməsi prosesində həmişə bəzi səhvlər aşkar edilir və bir neçə nəfər ona baxarsa, müəyyən edilən səhvlərin sayı artır. Üstəlik, bəzən üçüncü və ya dördüncü rəyçi ən pis şeyi tapır.

Texniki sənədlərin yazılmasını asanlaşdıran alətlər

Mənbə: Dzone Əksər proqramçılar texniki sənədlər yazmağı sevmirlər. Psixologiya eksperti Gerald Weinberg hətta sənədləri "proqramlaşdırmanın kastor yağı" adlandırdı: tərtibatçılar onu oxumağı sevirlər, lakin özləri yazmağa nifrət edirlər. Rəhbərliyin olmaması və ya boş yol xəritəsi proqram təminatının müxtəlif hissələrinin necə işlədiyi barədə məlumatın olmaması ilə nəticələnir. Bu, son nəticədə kodun son istifadəçiləri üçün təcrübəni pisləşdirir, çünki sənədlər olmadıqda, onlar məhsulun düzgünlüyünə və faydalılığına etibar edə bilməzlər. Proqramçıların sənədləri yazmaq vərdişini formalaşdırmasını asanlaşdırmaq üçün indi demək olar ki, hər kəs üçün əlçatan olan dörd əla alətə diqqət yetirməyi məsləhət görürəm.

GitHub Səhifələri

Yəqin ki, bu gün GitHub-da işləmək təcrübəsi olmayan tək bir tərtibatçı yoxdur. Sənədləri saxlamaq üçün bir yerə ehtiyacı olan proqramçılar üçün də əla yerdir. Bir çox insanlar istifadəçiyə sadə bir təlimat təqdim etmək üçün kod bazasında standart Readme-dən istifadə edirlər, lakin bu, GitHub-da sənədlər yaratmağın yeganə yolu deyil. GitHub Səhifələri ilə siz sənədləşdirmə və dərsliklər daxil olmaqla, layihənizin səhifələri üçün hostinqdən daha çox şey əldə edirsiniz. Siz bütün GitHub repozitoriyaları ilə birbaşa qarşılıqlı əlaqədə olmaq imkanı əldə edirsiniz ki, bu da tərtibatçılara sənədləri kodlarını yenilədikləri kimi yeniləməyə imkan verir. Bundan əlavə, burada Jekyll-dən istifadə edə bilərsiniz - bu, işarələmənizi düz mətnə ​​və ya tam hüquqlu veb səhifələrə çevirməyə kömək edir.

Sənədləri oxuyun

Adından da göründüyü kimi, Read the Docs tərtibatçılara sənədləri saxlamaq və oxumaq üçün platforma təqdim edir. Xidmət GitHub Səhifələri kimi işləyir: proqramçılar Git, Bazaar, Mercurial və digərləri daxil olmaqla sevimli versiya idarəetmə sistemlərindən sənədlərə dəyişiklik edə bilərlər. Avtomatik versiya və səhifə yaradılması da dəstəklənir. Read Docs-un ən yaxşı hissəsi onun çevikliyidir. O, veb-qançları dəstəkləyir, beləliklə, siz sənəd yaratma prosesinin çox hissəsini avtomatlaşdıra bilərsiniz. Bu, əksər proqramçıların heç bir şey etmək istəmədiyi bir tapşırıq üçün böyük vaxta qənaətdir. Bundan əlavə, platformada yerləşdirilən hər şey geniş ictimaiyyət üçün müxtəlif formatlarda, o cümlədən PDF, tək səhifəli HTML və hətta e-kitab formatında mövcuddur. Xidmət sənədləri yeni saxlamaq üçün gündəlik işin əhəmiyyətli hissəsini öz üzərinə götürür.

Tettra

Tettra sadəcə proqram sənədlərinin saxlanması üçün platforma deyil, tam bilik bazasıdır. Layihə müxtəlif proqram təminatı üzərində işləyən böyük bir koder qrupunu əhatə etdikdə xüsusilə yaxşı işləyir. Tettra ümumi suallara cavabları sənədləşdirmək üçün istifadə edilə bilər.

Arıxana

Apiary-ni tərtibatçılar üçün bu qədər faydalı edən şey , onun API sənədlərinə kömək etmək üçün əla iş görməsidir. Platforma istifadəçilərə saxta API zəngləri də daxil olmaqla sənədlərini Markdown -da yazmağa imkan verir . Apiary həmçinin API elementlərini sınamağa və prototip etməyə imkan verir. Başqa sözlə, bir yerdə sənədləşdirmə vasitəsi və sınaq platformasıdır.