Anlamadığınız bir şeyi inkişaf etdirməyə razı olmayın

Anlamadığınız bir şeyi inkişaf etdirməyə razı olmayın

2018-ci ilin əvvəlindən mən komandada aparıcı/bos/aparıcı inkişaf etdirici vəzifəsini tuturam - bunu istədiyiniz adlandırın, amma məsələ ondadır ki, modullardan biri və işləyən bütün tərtibatçılar üçün tamamilə cavabdehəm. onun üzərində. Bu mövqe mənə daha çox layihələrdə iştirak etdiyim və qərarların qəbulunda daha fəal iştirak etdiyim üçün inkişaf prosesinə yeni perspektivlər açır. Bu yaxınlarda, bu iki şey sayəsində birdən başa düşdüm ki, anlayış ölçüsü koda və tətbiqə nə qədər təsir edir.

Qeyd etmək istədiyim məsələ odur ki, kodun (və son məhsulun) keyfiyyəti kodu tərtib edən və yazan insanların etdikləri işdən nə dərəcədə xəbərdar olması ilə sıx bağlıdır.

Ola bilər ki, indi düşünürsən: “Sağ ol, Kap. Təbii ki, ümumiyyətlə, nə yazdığını başa düşmək yaxşı olardı. Əks təqdirdə, ixtiyari düymələri vurmaq üçün bir qrup meymunu işə götürə və onu tərk edə bilərsiniz." Və siz tamamilə haqlısınız. Müvafiq olaraq, nə etdiyinizə dair ümumi bir fikrə sahib olmağın zəruri olduğunu başa düşməyinizi təbii hesab edirəm. Bunu anlayışın sıfır səviyyəsi adlandırmaq olar və biz bunu ətraflı təhlil etməyəcəyik. Tam olaraq nəyi başa düşməli olduğunuzu və bunun hər gün verdiyiniz qərarlara necə təsir etdiyini ətraflı nəzərdən keçirəcəyik. Əgər bunları əvvəlcədən bilsəydim, bu, mənə çox vaxt itirdiyim vaxtdan və şübhəli koddan xilas olardı.

Aşağıda tək bir kod sətirini görməsəniz də, yenə də inanıram ki, burada deyilən hər şey yüksək keyfiyyətli, ifadəli kod yazmaq üçün böyük əhəmiyyət kəsb edir.

Birinci səviyyə anlayışı: Niyə işləmir?

Tərtibatçılar adətən bu səviyyəyə karyeralarında çox erkən çatırlar, bəzən hətta başqalarının köməyi olmadan - ən azı mənim təcrübəmdə. Təsəvvür edin ki, səhv hesabatı aldınız: proqramdakı bəzi funksiyalar işləmir, onu düzəltmək lazımdır. Necə davam edəcəksiniz?

Standart sxem belə görünür:

  1. Problemə səbəb olan kod parçasını tapın (bunu necə etmək ayrı bir mövzudur, mən onu köhnə kod haqqında kitabımda əhatə edirəm)
  2. Bu parçaya dəyişikliklər edin
  3. Səhvin düzəldildiyinə və heç bir reqressiya səhvinin olmadığına əmin olun

İndi ikinci məqama diqqət yetirək - kodda dəyişikliklərin edilməsi. Bu prosesə iki yanaşma var. Birincisi, mövcud kodda dəqiq nə baş verdiyini araşdırmaq, səhvi müəyyən etmək və onu düzəltməkdir. İkincisi: hisslə hərəkət edin - şərti ifadəyə və ya döngəyə +1 əlavə edin, deyək ki, funksiyanın istədiyiniz ssenaridə işlədiyini yoxlayın, sonra başqa bir şey sınayın və s. ad sonsuz.

Birinci yanaşma düzgündür. Steve McConnell özünün Code Complete kitabında izah etdiyi kimi (yeri gəlmişkən, bunu çox tövsiyə edirəm), biz hər dəfə kodda nəyisə dəyişdirəndə bunun tətbiqə necə təsir edəcəyini əminliklə proqnozlaşdıra bilməliyik. Yaddaşdan sitat gətirirəm, lakin səhv düzəlişi gözlədiyiniz kimi işləməsə, çox narahat olmalı və bütün fəaliyyət planınızı şübhə altına almalısınız.

Deyilənləri ümumiləşdirmək üçün kodun keyfiyyətini aşağı salmayan yaxşı bir səhv düzəliş etmək üçün həm kodun bütün strukturunu, həm də konkret problemin mənbəyini başa düşməlisiniz.

İkinci anlayış səviyyəsi: Niyə işləyir?

Bu səviyyə əvvəlki ilə müqayisədə daha az intuitiv şəkildə dərk edilir. Mən hələ naşı tərtibatçı ikən müdirim sayəsində bunu öyrəndim və sonradan dəfələrlə yeni gələnlərə məsələnin mahiyyətini izah etdim.

Bu dəfə təsəvvür edək ki, siz eyni anda iki səhv hesabatı aldınız: birincisi A ssenarisi, ikincisi B ssenarisi haqqındadır. Hər iki ssenaridə səhv bir şey baş verir. Müvafiq olaraq, ilk olaraq ilk səhvi həll edirsiniz. Səviyyə XNUMX başa düşmək üçün hazırladığımız prinsiplərdən istifadə edərək, siz problemə aid olan kodu dərindən öyrənirsiniz, bunun niyə tətbiqin A Ssenarisində olduğu kimi davranmasına səbəb olduğunu anlayır və istədiyiniz nəticəni verən ağlabatan düzəlişlər edirsiniz. . Hər şey əla gedir.

Sonra B ssenarisinə keçirsiniz. Siz səhvi təhrik etmək üçün ssenarini təkrarlayırsınız, amma sürpriz! - indi hər şey lazım olduğu kimi işləyir. Təxmininizi təsdiqləmək üçün səhv A üzərində işləyərkən etdiyiniz dəyişiklikləri geri qaytarırsınız və səhv B geri qayıdır. Səhv düzəlişiniz hər iki problemi həll etdi. Xoşbəxt!

Siz heç buna inanmadınız. Siz A ssenarisindəki səhvi düzəltmək üçün bir yol tapdınız və bunun niyə B ssenarisi üçün işlədiyini bilmirsiniz. Bu mərhələdə hər iki tapşırığın uğurla tamamlandığını düşünmək çox cəlbedicidir. Bu olduqca məntiqlidir: məsələ səhvləri aradan qaldırmaq idi, elə deyilmi? Lakin iş hələ başa çatmayıb: siz hələ də hərəkətlərinizin B ssenarisindəki səhvi niyə düzəltdiyini anlamalısınız. Niyə? Çünki o, yanlış prinsiplər üzərində işləyə bilər və sonra başqa çıxış yolu axtarmaq lazım gələcək. Bu cür halların bir neçə nümunəsi:

  • Həll bütün amilləri nəzərə alaraq B səhvinə uyğunlaşdırılmadığı üçün siz bilmədən C funksiyasını pozmuş ola bilərsiniz.
  • Mümkündür ki, eyni funksiya ilə əlaqəli bir yerdə gizlənən üçüncü bir səhv də var və B ssenarisində sistemin düzgün işləməsi üçün düzəlişiniz ondan asılıdır. İndi hər şey yaxşı görünür, amma bir gün bu üçüncü səhv fərq ediləcək və düzəldiləcək. Sonra B ssenarisində səhv yenidən baş verəcək və yalnız orada olsa yaxşıdır.

Bütün bunlar koda xaos əlavə edir və nə vaxtsa başınıza düşəcək - çox güman ki, ən uyğun olmayan anda. Özünüzü hər şeyin niyə işlədiyini başa düşməyə vaxt sərf etməyə məcbur etmək üçün iradənizi toplamalı olacaqsınız, amma buna dəyər.

Üçüncü anlayış səviyyəsi: Niyə işləyir?

Mənim son fikirlərim məhz bu səviyyəyə aiddir və bu fikrə əvvəllər gəlsəydim, yəqin ki, mənə ən çox fayda verərdi.

Daha aydın olması üçün bir misala baxaq: modulunuz X funksiyası ilə uyğunlaşdırılmalıdır. Siz X funksiyası ilə o qədər də tanış deyilsiniz, lakin sizə dedilər ki, onunla uyğun olmaq üçün F çərçivəsindən istifadə etməlisiniz. X ilə inteqrasiya edən modullar tam olaraq onunla işləyir.

Kodunuz ömrünün ilk günündən F çərçivəsi ilə heç bir əlaqə saxlamayıb, ona görə də onu həyata keçirmək o qədər də asan olmayacaq. Bu modulun bəzi hissələri üçün ciddi nəticələrə səbəb olacaq. Bununla belə, özünüzü inkişafa atırsınız: kod yazmaq, sınaqdan keçirmək, pilot versiyaları yaymaq, rəy almaq, reqressiya səhvlərini düzəltmək, gözlənilməz fəsadları aşkar etmək, ilkin razılaşdırılmış son tarixlərə uyğun gəlməmək, daha çox kod yazmaq, sınaqdan keçirmək, rəy əlaqəsi əldə etmək, həftələrlə vaxt sərf edirsiniz. reqressiya səhvlərinin düzəldilməsi - bütün bunlar F çərçivəsini həyata keçirmək üçün.

Və bir anda siz birdən başa düşürsünüz - və ya bəlkə də kimdənsə eşidirsiniz - ola bilsin ki, F çərçivəsi sizə X xüsusiyyəti ilə heç bir uyğunluq verməyəcək.Bəlkə bütün bu vaxt və səy buna tamamilə yanlış xərclənib.

Bir dəfə cavabdeh olduğum bir layihə üzərində işləyərkən oxşar hadisə baş verdi. Niyə bu baş verdi? Çünki mən X funksiyasının nə olduğunu və onun F çərçivəsi ilə necə əlaqəli olduğunu çox az başa düşürdüm. Nə etməli idim? İnkişaf tapşırığını təyin edən şəxsdən digər modullar üçün görülənləri təkrarlamaq və ya X funksiyasının bunu etməli olduğu barədə sözünü qəbul etmək əvəzinə, nəzərdə tutulan fəaliyyət kursunun istənilən nəticəyə necə gətirib çıxardığını aydın şəkildə izah etməsini xahiş edin.

Bu layihənin təcrübəsi mənə nə üçün bizdən müəyyən şeylər tələb olunduğunu aydın başa düşməyənə qədər inkişaf prosesinə başlamaqdan imtina etməyi öyrətdi. Birbaşa imtina edin. Bir tapşırığı aldıqda, ilk impuls vaxt itirməmək üçün dərhal onu qəbul etməkdir. Lakin “biz bütün təfərrüatları öyrənənə qədər layihəni dondurun” siyasəti miqyaslı sifarişlərlə sərf olunan vaxtı azalda bilər.

Sizə təzyiq göstərməyə, işə başlamağa məcbur etməyə çalışsalar da, bunun səbəbini anlamasanız da, müqavimət göstərin. Birincisi, niyə sizə belə bir tapşırığın verildiyini anlayın və bunun məqsədə doğru yol olub-olmadığına qərar verin. Bütün bunları çətin yoldan öyrənməli oldum - ümid edirəm ki, mənim nümunəm bunu oxuyanların həyatını asanlaşdıracaq.

Dördüncü anlayış səviyyəsi: ???

Proqramlaşdırmada öyrənmək üçün həmişə daha çox şey var və mən inanıram ki, başa düşmək mövzusunun yalnız səthini cızmışam. Kodla işlədiyiniz illər ərzində başqa hansı anlayış səviyyələrini kəşf etmisiniz? Kodun və tətbiqin keyfiyyətinə müsbət təsir göstərən hansı qərarları qəbul etdiniz? Hansı qərarların səhv olduğu ortaya çıxdı və sizə dəyərli dərs verdi? Təcrübənizi şərhlərdə paylaşın.

Mənbə: www.habr.com

Добавить комментарий