Təcrübəsiz proqramçıların tipik səhvlərinin təhlili: 1-ci hissə

Salam, dünya! Lazım olan hər şeyi öyrəndikdən və nəhayət təcrübəçi və ya kiçik işçi kimi işə qəbul olunduqdan sonra, yəqin ki, istirahət edə bilərsiniz, elə deyilmi? Necə olursa olsun! Hər şey yeni başlayır... Ətrafınızda çoxlu yeni və anlaşılmaz şeylər var və qapıdan kənarda necə fırıldaqçılıq etməmək olar? Bu gün danışacağımız şey budur. Bu yazıda mən yeni başlayanlar tərəfindən edilən ümumi səhvlərə baxmaq və onlardan qaçınmaq üçün öz təcrübəmdən bəzi məsləhətlər vermək istəyirəm. Beləliklə, uzatmadan başlayaq:

1. Daha təcrübəli həmkarlarından kömək istəmək qorxusu

Biz hamımız insanıq və hamımız axmaq görünməkdən qorxuruq, xüsusən də yeni çıxan, daha təcrübəli həmkarlarımızın gözündə. İlk işini əldə etdikdən sonra tərtibatçılar tez-tez bu qorxuya təslim olurlar və hər şeyi öz başlarına anlamağa çalışaraq, özlərinə təslim olurlar. Eyni zamanda, bir insan daha təcrübəli həmkarları ilə əhatə oluna bilər, onlar da öz növbəsində onu əvvəlcə ən düzgün yola yönəldə biləcəklər ki, bu da daha çox səhvlərdən və lazımsız "çarpmalardan" qaçınmağa kömək edəcəkdir. Buna görə də unutmayın: sual verməkdən qorxmayın: siz başlanğıcsınız və hamı bunu mükəmməl başa düşür. Soruşanda heç kim səni dəyənəklə döyməz. Bəlkə də əksinə, həmkarlarınızla daha tez dostlaşacaq və onlarla daha fəal ünsiyyət qurmağa başlayacaqsınız. Daha çox deyəcəyəm: müxtəlif texniki məsələləri nə qədər çox soruşsanız və müzakirə etsəniz, bir o qədər tez yaşıl bir başlanğıcın ayaqqabılarından qurtula və öz sahənizdə mütəxəssisə çevrilə bilərsiniz. Və daha bir məsləhət. StackOverFlow-u laqeyd yanaşmayın . Bu kontekstdə mən bu resursla bağlı suallar verməyi nəzərdə tuturam. Bir tərəfdən sualınıza cavab almaq üçün müəyyən vaxt lazımdır. Ancaq digər tərəfdən, siz dərhal mövcud problemin həlli üçün bir neçə yanaşma öyrənə və bir az fərqli perspektivdən baxa bilərsiniz. Onu da qeyd etmək istərdim ki, şərhlər-cavablar yazmaq, StackOverFlow-da suallara digər tərtibatçılardan gələn suallara aydınlıq gətirmək, karmadakı üstəgəl əlavə, praktiki faydaya malikdir: bu məsələni daha dərindən müzakirə etmək və anlamaq imkanınız var.

2. Özünüz məlumat axtarmağa çalışmayın

Bəlkə də bu səhv əvvəlkinin əks tərəfidir. Hər bir problem və ya problemlə həmkarlarınızı və tanışlarınızı çəkməyə başladığınızı nəzərdə tuturam. Soruşmaq yaxşıdır, amma suallarla çox uzağa getməməlisən, əks halda cansıxıcı ola bilərsən. Hər hansı anlaşılmaz məqam ortaya çıxarsa, ilk iş axtarış bacarıqlarınızı ən yaxşı axtarış sistemində - Google-da tətbiq etməkdir. Kimsə artıq anlaşılmaz səhvlərin və digər problemlərin böyük əksəriyyəti ilə qarşılaşıb. Google-da axtarsanız və oxşar problemlə tanış olan və işlərində istifadə üçün uyğun hərtərəfli cavablar almış insanların sayını görsəniz, çox təəccüblənəcəksiniz. Buna əsaslanaraq, tez-tez bir həmkarınızın bir suala cavab verdiyini eşidə bilərsiniz - "Google onu." Bu cavabdan inciməməlisiniz, çünki sizin həmkarınız iş sahənizin bütün incəliklərini çatdırmalı olan şəxsi müəllim deyil. İnternetin sonsuz genişlikləri bu cür mentorluqda sizə kömək edəcəkdir. Bəzən proqramçıya Google axtarışında qara kəmərli şəxs də deyilir . Buna görə də, ilişib qalanda əvvəlcə problemi Google-da araşdırırıq və heç bir həll tapılmadıqda (nadir hallarda, amma olur), sonra həmkarlarımızdan soruşmağa başlayırıq. Bir növ nasazlıq və ya anlaşılmaz səhv olduqda deyil, problemi həll etmək üçün bir yanaşma seçərkən dərhal onlardan soruşmağa dəyər. Axı, onlar sizinkilərdən kənarı görə bilirlər və bu və ya digər yanaşmanın uzunmüddətli perspektivdə necə nəticələnəcəyini dərhal söyləyə bilərlər.

3. Blind copy-paste

Ancaq problemi araşdırmaq və buna uyğun olaraq onun həlli də öz tələlərinə malikdir. Məsələn, kor kopyala-yapışdır . Bu, adətən oxşar problem tapdığınız zaman baş verir (lakin bəlkə də tam eyni deyil) və onun altında, məsələn, StackOverFlow-da həll yolu var. Bu həlli özünüz götürün, çox təfərrüata varmadan kopyalayın və yapışdırın. Və sonra siz və ya layihə həmkarlarınız bəzi qəribə səhvlər və ya funksionallığınızın yanlış davranışı aşkar edirsiniz. Və dərhal heç kim ayaqların haradan gəldiyini bilmir. Sonra təbii ki, bu kodun olduğu yer tapılacaq və bu qərara görə mütləq təriflənməyəcəksiniz. Buna görə də, StackOverFlow-da (və ya başqa yerdə) hazır həll tapdığınız zaman ilk növbədə onun nə olduğunu, necə və niyə olduğunu ətraflı təhlil etməlisiniz. Yəqin ki, bu funksiyanı google-da axtarın və bunun üçün sənədlərə baxın. Və yalnız bundan sonra onu layihənizdə tətbiq edin.

4. Səhv həllin atılması

Həll yazarkən bəzən elə olur ki, o, getdikcə mürəkkəbləşir və sonda dalana dirənir. Və siz başqa, daha işlək alternativ axtarmaq əvəzinə bu yanaşmadan istifadə edərək bu problemi birtəhər həll etmək üçün onu getdikcə daha da çətinləşdirməyə çalışırsınız. Ola bilsin ki, sadəcə olaraq sərf etdiyiniz enerji və vaxta görə təəssüflənirsiniz və buna görə də qərar verirsiniz: nə olursa olsun, təslim olmayın, problemi bu şəkildə həll edin. Bu tamamilə düzgün yanaşma deyil. Ən azından proqramlaşdırmada. Fərqli yanaşmanı nə qədər tez sınasanız, bir o qədər çox vaxta qənaət etmiş olarsınız. Buna görə də, buna sərf etdiyiniz vaxta baxmayaraq, təcrübə etməkdən və digər yanaşmaları sınamaqdan qorxmayın. Üstəlik, bunlar təcrübəniz üçün məqamlar olacaq, çünki siz bir neçə yanaşmanı sınayacaqsınız və bu sahəni daha yaxşı öyrənəcəksiniz.

5. Cari tapşırıqla bağlı suallar vermək qorxusu

Layihə üzərində işləmək adətən bəzi tapşırıqların (Tapşırıqlar) yerinə yetirilməsi ilə nəticələnir. Məsələn, Jirada . Və bu vəzifələr həmişə ətraflı və aydın şəkildə təsvir edilmir. Bunlar adətən komanda rəhbərləri tərəfindən yazılır və bu baş verərsə, bunlar da insanlardır. Onlar həmçinin nəsə əlavə etməyi unuda bilərlər və ya sizin bu və ya digər funksionallıqla o qədər də tanış olmadığınız nəzərə alınmaya bilər. Yaxşı və ya layihəyə girişiniz yoxdur (məsələn, verilənlər bazasına, log serverinə və s.). İndi tapşırığı aldıqdan sonra bir neçə saatdan çox öyrəndikdən sonra hələ də oturub çaşqınlıqla ekrana baxırsınız. Və bunu heç bir nəticə vermədən başa düşmək əvəzinə, bu tapşırığın yaradıcısına aparıcı/aydınlaşdırıcı suallar verməyə başlamalısınız. Deyək ki, komandada ünsiyyət üçün istifadə etdiyiniz proqramda (məsələn, Microsoft Teams) və ya birbaşa bu tapşırıq altında şərh olaraq. Bir tərəfdən, şəxsi mesajda sual yazsanız, çox güman ki, cavab daha sürətli olacaq, çünki şəxs sualı dərhal görəcək. Digər tərəfdən, Jira-da sual verməklə, bir şey etdiyinizə, yəni problemi təhlil etdiyinizə dair sübutunuz var. Bu prosesi sürətləndirməyin bir yolu var: Jira-da şərh olaraq sual verin və baxmaq istəyi ilə şəxsi mesajda bu şərhə keçid göndərin.

6. Komanda rəhbərindən çox şey gözləmək

Yenə də bu, əvvəlki nöqtənin əks tərəfidir. Komanda rəhbəri inkişaf qrupunun rəhbəri olan şəxsdir. Bir qayda olaraq, belə bir komanda üzvünün vaxtının çox hissəsi müxtəlif növ kommunikasiyalara sərf olunur. Və eyni zamanda, bütün bunların nə olduğunu unutmamaq üçün kod da yazır. Yaxşı, başa düşdüyünüz kimi, bu çox məşğul bir xarakterdir. Və hər asqırma üçün həddindən artıq seğirmə onu xoşbəxt etməyəcəkdir. Təsəvvür edin ki, hər bir komanda üzvü onu bir dəstə sualla bombalayıb. Deməli, dəli ola bilərsiniz, elə deyilmi? Və sizin tərəfinizdən çoxlu suallarla uzun müddət sizə cavab verməsi təəccüblü olmayacaq. Komanda rəhbərinə sualların sayını azaltmaq üçün nə edə bilərsiniz:

• Kor nöqtələrin sayını azaltmaq üçün bu layihənin sənədlərini daha dərindən öyrənin.
• Digər komanda üzvlərinə suallar verin. Tamamilə mümkündür ki, onlar bu funksionallıqla aparıcı kimi və ya daha çox tanışdırlar, çünki çox güman ki, onlardan biri həmin funksionallığı yazıb.

Alternativ olaraq, IDE-də siz annotasiyalara baxa bilərsiniz: müəyyən bir sətirdəki kodu kim və nə vaxt dəyişdirdi. Beləliklə, bu sualı kimin verməsinin daha düzgün olacağını öyrənəcəyik. Yəqin ki, artıq başa düşdüyünüz kimi, komanda rəhbərinə sual verərkən, eləcə də həmkarlarına sual verərkən qızıl ortanı saxlamağa çalışmalısan - sual verməkdən qorxma, həm də onları həddindən artıq rəqəmlə incitmə.

7. Kodun nəzərdən keçirilməsi qorxusu

Kodun nəzərdən keçirilməsi və ya kodun nəzərdən keçirilməsi kodu ümumi tətbiqə (ümumi filiala, məsələn, master və ya inkişaf etdirməyə) yükləməzdən əvvəlki mərhələdir. Bu yoxlama bu vəzifəyə aidiyyatı olmayan, inkişafın ilkin mərhələsində nəzərə alınmayan kod üslubunda səhvləri, qeyri-dəqiqlikləri və ya çatışmazlıqları yeni bir görünüşlə aşkar edə bilən bir tərtibatçı tərəfindən həyata keçirilir. Şərhlər varsa, kodun müəyyən bölmələrinə şərh kimi qalır. Bu halda, bu tapşırığı yerinə yetirən tərtibatçı baxışa uyğun olaraq səhvləri düzəltməlidir (yaxud öz qərarlarını rəyçi ilə müzakirə etməli, bəlkə də onu qərarının düzgünlüyünə inandırmalıdır). Daha sonra onu nəzərdən keçirmək üçün geri göndərin və rəyçinin heç bir şərhi olmayana qədər davam edin. Rəyçi kodu yükləməzdən əvvəl "filtr" rolunu oynayır. Beləliklə, bir çox təcrübəsiz proqramçılar kodun nəzərdən keçirilməsini tənqid və qınama kimi qəbul edirlər. Onun qədrini bilmirlər və ondan qorxurlar və bu yanlışdır. Kodumuzu təkmilləşdirməyə imkan verən kodun nəzərdən keçirilməsidir. Axı nəyi səhv etdiyimiz və nələrə diqqət etməli olduğumuz barədə vacib məlumatlar alırıq. Hər bir kodun nəzərdən keçirilməsinə öyrənmənin bir hissəsi kimi baxmaq lazımdır, bu sizə təkmilləşdirməyə kömək edə bilər. Bir şəxs kodunuza şərh yazdıqda, öz təcrübəsini, ən yaxşı təcrübələrini sizinlə bölüşür. Mənə gəlincə, kodu nəzərdən keçirmədən yaxşı proqramçı ola bilməzsiniz. Çünki siz hətta kodunuzun nə qədər yaxşı olduğunu və orada kənardan təcrübəli bir adamın nöqteyi-nəzərindən səhvlərin olub-olmadığını bilmirsiniz.

8. Mücərrəd həllərə meyl

Çox vaxt müxtəlif tapşırıqların/problemlərin bir neçə fərqli həlli ola bilər. Və bütün mövcud həllər arasında, yeni başlayanlar adətən ən mürəkkəb və "abstrus" olanlardan istifadə edirlər. Və bu doğrudur: əgər təcrübəsiz bir proqramçı dünən bir çox müxtəlif alqoritmləri, nümunələri, məlumat strukturlarını öyrənibsə, əlləri onlardan birini həyata keçirmək üçün qaşınır. Bəli və mən, belə deyək, özümü bəyan etmək istəyirəm. İnanın, mən özüm də belə idim və nə danışdığımı bilirəm :) Elə bir vəziyyət yaranmışdı ki, uzun müddət bir funksionallıq yazmağa sərf etmişəm ki, onun çox, çox mürəkkəb olduğu ortaya çıxdı. Sonra Senior+ səviyyəli tərtibatçı tərəfindən yenidən yazılmışdır. Təbii ki, onun nəyi və necə dəyişdiyini görmək mənə maraqlı idi. Mən onun həyata keçirilməsinə baxdım və bunun nə qədər sadə olduğuna heyran oldum. Və kod üç dəfə az oldu. Və eyni zamanda, bu funksionallıq üçün testlər dəyişmədi və uğursuz olmadı! Yəni ümumi məntiq olduğu kimi qalır. Buradan belə bir nəticəyə gəldim ki, ən dahiyanə həllər həmişə sadədir . Bu həyata keçirildikdən sonra kodun yazılması xeyli asanlaşdı və nəzərəçarpacaq dərəcədə yüksək səviyyəli oldu. Yaxşı, onda nümunələrdən və alqoritmlərdən nə vaxt istifadə etməyə dəyər, soruşursan? Sonra, onlardan istifadə edərkən ən sadə və ən yığcam yol olacaq.

9. Velosipedlərin ixtirası

Bu konsepsiya həm də təkərin ixtirası kimi tanınır. Onun mahiyyəti ondan ibarətdir ki, tərtibatçı həlli artıq mövcud olan problemə öz həllini tətbiq edir və proqramçı tərəfindən icad edilənlərdən dəfələrlə daha yaxşıdır. Bir qayda olaraq, öz velosipedinizi ixtira etmək vaxt itkisinə və tərtibatçının işinin səmərəliliyinin azalmasına səbəb olacaq, çünki ən yaxşıdan uzaq olan bir həll tapılmaya bilər və ya ümumiyyətlə tapılmaya bilər. Eyni zamanda, müstəqil qərar vermək imkanından imtina etmək olmaz. Proqramçı, hazır həllərdən istifadə edərək və ya özünün icad edərək, bacarıqlı və vaxtında həll etmək üçün qarşısında görünə biləcək vəzifələri düzgün şəkildə idarə etməlidir. Bir tərəfdən, universitetlərdə və kurslarda bizə velosiped yaratmaqda əlimizdən gələni etməli olan müxtəlif növ tapşırıqlarla bombardman olunur. Ancaq bu, yalnız ilk baxışdan görünür. Əslində bunun məqsədi alqoritmik təfəkkürün inkişafı və dilin sintaksisinə daha dərindən yiyələnməkdir. Və bu cür tapşırıqlar həm də alqoritmləri/strukturları daha yaxşı başa düşməyə kömək edir və lazım gələrsə, onlara qabaqcıl analoqlarını həyata keçirmək üçün bacarıqlar verir (lakin bu çox nadir hallarda tələb olunur). Real həyatda, əksər hallarda, öz təkərinizi icad etməyə ehtiyac yoxdur, çünki ehtiyaclarımızı ödəyən analoqlar çoxdan mövcuddur. Ola bilsin ki, təcrübəniz sayəsində sizə lazım olan bu və ya digər funksionallığın tətbiqinin mövcudluğu barədə məlumatınız olmayacaq. Bu məqalənin ilk bəndindən istifadə etməli olduğunuz yer budur, yəni daha təcrübəli həmkarlarınızdan kömək istəyin. Onlar sizə yol göstərə biləcəklər (məsələn, Google-a hansı istiqamətdə məsləhət verin) və ya xüsusi bir tətbiq (müəyyən kitabxana) təklif edə bilərlər.

10. Testlər yazmayın

Bütün yeni başlayanlar yazı testlərini sevmirlər. Yeni başlayanlar haqqında nə demək olar: yeni başlayanlar da test yazmağı sevmirlər, lakin bunun nə üçün lazım olduğunu daha yaxşı başa düşürlər. Tamamilə yaşıl olanda düşünürsən: bunları niyə yazmaq olar? Hamısı işləyir və heç bir səhv ola bilməz. Bəs dəyişikliklərinizin sistemin başqa bir hissəsində nəyisə pozmayacağına necə əmin ola bilərsiniz? Həmkarlarınız faydalarından daha çoxunu pozan dəyişikliklərə əl atsanız, bunu qiymətləndirməyəcəklər. Sınaqların xilasetməyə gəldiyi yer budur. Tətbiq testlərlə nə qədər çox əhatə olunsa, bir o qədər yaxşıdır (əhatə faizi də deyilir). Tətbiq testlərlə yaxşı əhatə olunubsa, onların hamısını işlətməklə siz dəyişikliklərinizlə pozula biləcək yerləri tapa bilərsiniz. Yuxarıdakı misalda dediyim kimi, funksionallığı refaktorlaşdırarkən testlər uğursuz olmadı və hamısı ümumi məntiqin dəyişmədiyi üçün. Bu o deməkdir ki, testlər müəyyən funksionallığın məntiqinin dəyişib-dəyişmədiyini də göstərə bilər. Beləliklə, test yazmağı sevməsəniz belə, onların şübhəsiz faydaları var və onlar onlara sərf olunan vaxta dəyər.

11. Həddindən artıq şərh

Bir çox tərtibatçı mükəmməllikdən əziyyət çəkir və yeni başlayanlar da istisna deyil. Amma bəzən bu istəyin bir yan təsiri hər kəsə və hər şeyə şərh verməyə başlayırlar. Hətta nəyə ehtiyac yoxdur, çünki o qədər aydındır:

Cat cat = new Cat(); // cat Object

Bütün təcrübəsiz proqramçılar dərhal başa düşmürlər ki, kodu şərh etmək həmişə yaxşı bir şey deyil, çünki kod daha dağınıq və oxunması çətin olacaq. Bəs kod dəyişdirilsə, lakin onun üçün heç bir şərh olmasaydı? Belə çıxır ki, o, bizi aldadacaq və ancaq çaşdıracaq. Niyə belə bir şərh? Adətən, yaxşı yazılmış kodun şərhə ehtiyacı yoxdur , çünki içindəki hər şey artıq aydın və oxunaqlıdır. Şərh yazırsınızsa, bu o deməkdir ki, kodun oxunuşunu artıq pozmusunuz və vəziyyəti birtəhər düzəltməyə çalışırsınız. Ən yaxşı yanaşma əvvəlcə şərhlərlə əlavə edilməli olmayan oxunaqlı kodu yazmaq olardı. Metodların, dəyişənlərin və siniflərin düzgün adlandırılmasını, yəni mənim əməl etdiyim bir qaydanı qeyd etməyə kömək edə bilmədim: Ən yaxşı şərh şərhin olmamasıdır və bunun əvəzinə - bu və ya digərini aydın şəkildə təsvir edən düzgün adlandırma tətbiqinizdə funksionallıq.

12. Səhv ad

Çox vaxt yeni başlayanlar siniflərin, dəyişənlərin, metodların və s. adlarını saxtalaşdırırlar. Məsələn, adı ümumiyyətlə məqsədini təsvir etməyən bir sinif yaratdıqda. Və ya x kimi qısa adla dəyişən yaradılır və n və y adlı daha iki dəyişən yaradıldıqda x- in nə etdiyini xatırlamaq çox çətin olur . Belə hallarda, kodu diqqətlə düşünməli və orada nə baş verdiyini sadəcə başa düşmək üçün bu funksiyanı mikroskop altında (bəlkə də sazlayıcıdan istifadə etməklə) öyrənməlisiniz. Burada yuxarıda qeyd etdiyim koddakı düzgün adlandırma bizə kömək edir. Düzgün adlar kodun oxunuşunu yaxşılaşdırır, müvafiq olaraq tanışlığa vaxta qənaət edir, çünki adın onun funksionallığını təxminən təsvir etdiyi bir üsuldan istifadə etmək daha asandır. Kodda hər şey adlardan ibarətdir (dəyişənlər, metodlar, siniflər, fayl obyektləri və s.), bu məqam düzgün, təmiz kod yaratarkən çox vacib olur. Yadda saxlamaq lazımdır ki, adın mənasını çatdırmaq lazımdır: məsələn, dəyişən niyə mövcuddur, nə edir və necə istifadə olunur. Mən dönə-dönə qeyd edəcəm ki, dəyişəni təsvir etmək üçün ən yaxşı şərh onun düzgün adıdır. Şərhləri daha dərindən öyrənmək və düzgün adlandırmaq üçün sizə əbədi klassikanı oxumağı məsləhət görürəm: “Təmiz kod. Yaratma, təhlil və refaktorinq”, Robert Martin . Bu qeydlə bu məqalənin birinci hissəsi (fikirlər) başa çatdı. Ardı var…