Çevik zehniyyət vs Çevik mexanizmlər

https://flic.kr/p/bkcj5q

Dəfələrlə proqram komandalarının mexanizmlərə çox diqqət yetirdiyini və əsas prinsipi görməməzliyə vurduğunu görürəm. Bu, xüsusilə Çevik metodologiyalara aiddir. Scrum kimi üsulların o qədər mexanizmi var ki, sürətlə yenilənənlər tamamilə itirilir. Əvvəlcə Çevil haqqında düşüncəmin nə olduğunu aydınlaşdırmaq üçün komandama bir e-poçt olaraq yazdım, amma indi Scott Hanselman'ın tövsiyələrini nəzərə alaraq blog yazılarına çevirirəm.

Mən özümü bu anlayışı təmin etmək üçün bir qədər bacarıqlı hesab edirəm. Çevik inkişafın bir tornavida istifadə edərək başladığı günlərdən - öz kublarınızı sökmək və açıq oturma planı yaratmaq üçün çalışıram.

Karyeramın əvvəlində bir tibbi proqram şirkəti ilə işləmişəm. Xəstəxanalarda doktorun masaüstünə quraşdırılmış görüntü araşdırması üçün masaüstü proqram qurduq. Yerləşdirmə prosesi CD-lərlə başqa bir şəhərə səyahət və masaüstlərini və görüntü serverlərini quraşdırmağı əhatə edir. Biz FDA təsdiqinə məruz qaldıq, buna görə FDA təsdiqləməsindən keçən xüsusiyyətlərə qurmalı olduq. Bu, yuxarıdan aşağıya, şəlalə metodologiyası üçün ideal bir mühit yaratdı. Bütün spesifikasiyalar yazıldı, təsdiq edildi, imzalanmadı və yalnız o xüsusiyyətlərə və yalnız bu xüsusiyyətlərə tikildi. Quraşdırma qrupu ilə səyahətə başlamayan və həkimlərin proqram təminatından istifadə etdiyini seyr edənə qədər, dövrün əvvəlində müştəri ilə danışa bilsək daha yaxşı bir şey edə biləcəyimizi başa düşdük. Dəqiq spesifikasiyalara kod verdik və yenə də ola biləcəyi qədər faydalı olmayan bir şeyi çatdırdıq. Bu qrafik mənim təcrübələrimin bir hissəsini göstərir.

Proqram İnkişafı'nın necə https://blogs.perfmissions.com/perfceptsdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Bu zaman ətrafında komandam Çevik Manifesti və Ekstremal Proqramlaşdırma adlı bir təcrübə eşitdi. Kitabları fəal oxuduğumuz sənaye veteranları tərəfindən imzalandığını nəzərə alsaq, Martin Fowler və Kent Beck kimi insanlar bu təcrübəni çox qanuni qəbul etdilər. Beş nəfərlik komandam kubiklərimizi sökdü, yanımızda oturmaq, indeks kartları ilə bir lövhə qurmaq və yola davam etdiyimizdə XP təşkil etmək üçün baş nazirimizi (müştəri üçün etibarnamə) çəkdi. Həftəlik planlaşdırma və demolar, çox sayda cütləşmə və müzakirə dövrü keçirdik. Təxminən 15 il ərzində müxtəlif şirkətlərdə, müxtəlif dəyişikliklərdə və dəyişkənliklərdə işləmişəm. Bir komanda ümumiyyətlə heç bir metodologiyaya riayət etmirdi, amma bütün komanda üzvlərinin dərin çevik mənşəli olduqları, iterasiya və əməkdaşlıq onların işləmə vəziyyətidir və tətbiq olunan bir prosesə ehtiyac duymurdu.

Yəni Çevik açıq mərtəbə planları haqqında və ya çox danışmaq? Stendləriniz və retroslarınız varsa Çevik olmağınıza iddia edə bilərsinizmi? Scrum və ya TDD harada uyğun gəlir? Çox vaxt insanlar prosesin spesifikliyinə çox qarışırlar - Scrum və ya Kanban? İki həftə və ya bir həftə sprint? Geri bağlamanız yoxdursa, həqiqətən də çeviksiniz? Çevik metodlardan istifadə edərək aktiv inkişaf etməklə böyüdükdə, digər inkişaf etdiricilərlə bərabər məşğul olan, təcrübələri inkişaf etdirən və uyğunlaşdıran insanlar mənə yaxşı bir fikir verdi və bu yazı əsas prinsipləri müəyyənləşdirməkdir.

Çevik olmaq müştərilərin ehtiyaclarını tez bir zamanda ödəyə bilir. Daha sürətli kod yazmağımız deməkdir? Xeyr. Fizika qanunlarını döyə bilmərik və möhkəm çox funksiyalı bir tətbiq qurmaq üçün vaxt lazımdır.

Etməyimiz lazım olan şeydir

  1. Kodla həll etmək istədiyimiz əsas iş problemlərini müəyyənləşdirin
  2. Fərziyyəni sınamaq üçün tez bir nəzəri bir həll verin
  3. Ehtiyaclar dəyişdikcə təkrarlanır və uyğunlaşırıq və ya daha çox şey öyrənirik
  4. Müştəri ilə birlikdə komandanın məşğul bir hissəsi ilə birlikdə bunu edin

Başqa hər bir şey, 2 və 3-dən yuxarı olanları daha az ağrılı edir - ehtiyacı mümkün qədər tez ödədiyimizi və tez dəyişə bilməyəcəyimizi bilmək. Qurmaq (vs satmaq) qərarına gəlmişsinizsə, xüsusi proqram yazırsınız. Bu o deməkdir ki, onun ixtisaslaşdırılmış tələbləri və mühiti var.

Mümkün qədər qısa müddətdə müştərinin qarşısında, funksionallığın kiçik bir hissəsi olsa da, görünən bir şey əldə etmək, rəyimizi daha sürətli əldə etməyə imkan verir. Buna görə hər zaman xüsusiyyətin kiçik bir dilimini hazırlamağı, sonu sona çatdırmağı və bunun hamısını istehsala yönəltməyin tərəfdarıyam. De, dəstək agentləriniz üçün bir müştəri haqqında bütün məlumatları görmək üçün bir səhifə qurursunuz. Bütün səhifə üçün məlumat mənbələrini araşdırmaq və əvvəlcə bütün API-ləri yazmaq üçün çox vaxt sərf etmək əvəzinə, bütün istehsal yolu boyu səhifədə bir alt məlumat əldə etməyə çalışın. İnteqrasiya və yerləşdirmə mexanizmlərinizi tətbiq edə biləcəksiniz, UI çərçivəsi ilə əlaqəli rəy almağa başlaya bilərsiniz, bu səhifə tətbiqinizin qalan hissəsi ilə necə uyğunlaşır və s. Bunlardan fərqli olaraq az miqdarda kod olduqda tənzimləmək daha asandır. bütün bir API çərçivəsini qurduğunuzda.

Çeviklik üçün vacib olan digər mexanizmlərdən bəziləri

Sprint: Zamanla işlənmiş dövrlərdə inkişaf etmək, hələ də müvafiq xüsusiyyətlər üzərində işləməyimizi təmin etmək üçün yeni məlumatları yoxlamağa və uyğunlaşdırmağa və müntəzəm olaraq daxil etməyə imkan verir. Proqram təminatı bir məsuliyyətdir. Yalnız ehtiyac duyduğumuzu qurmalıyıq və lazım olduqda lazım olanı əlavə edə bilməliyik. Buna görə mütəmadi olaraq bu günə qədər inşa etdiklərimizə və növbəti yola davam edəcəyimizə baxmaq lazımdır. Bu ikinci nöqtəyə gətirib çıxarır.

Daim qiymətləndirməyi və dəyişdirməyi planlaşdırdığımızı nəzərə alsaq, proqramımızın dəyişdirilməsi asan olmalıdır. Müştəri tətbiqdən istifadə etməyə başladıqdan sonra bəzi məlumatların əvvəlcədən hazırlanandan fərqli göstərilməsini istəsə nə olar? Səhifədəki hər şeyə toxunmadan bunu edə bilərdikmi? Yoxsa məlumat əldə etmək üçün başqa bir API çağırmalıyıq - bu dəyişikliyi etibarlı şəkildə edə bilərikmi? Budur yaxşı inkişaf təcrübələri və mexanizmləri

Vahid testi: Dəyişikliklər üçün təhlükəsizlik şəbəkəsi olduğu üçün müxtəlif səviyyələrdə avtomatlaşdırılmış testlərimiz var. Bölmənin əslində nə sınadığını da nəzərə almaq vacibdir. Vahid testləri məntiqi sınamalıdır. Yuxarıdakı nümunəni götürsəniz, məlumat almaq üçün fərqli bir API istifadə edərək, UI-yə məlumat verən API üçün vahid testlərində dəyişiklik tələb etməməlidir. Vahid testləri kodun refaktoruna inam vermək üçün mövcuddur, bu da öz növbəsində sizə yalnız indi lazım olanı yazmaq azadlığını verir və sonradan istirahət edə bilərsiniz, hər halda edə biləcəyiniz 100% əhatə metrikasını istehsal etməməlisiniz.

CI / CD: Bu, tapşırıq və çatdırılma arasındakı məsafəni qısaltmağa imkan verir. Bu çeviklik üçün vacibdir. Yerləşdirməyə maneələr aradan qaldırıldıqda və istehsaldakı kiçik dəyişiklikləri itələyə bilsək, dəyişiklik riski böyük dərəcədə azalır. Yerləşdirmələr yorucu olarsa, daha az olur. Daha az tez-tez yerləşdirilmələr böyük bir səth sahəsinə toxunaraq, bir ton dəyişikliyə səbəb olur və buna görə də risklidir. Proqram tədarükü performansının nə ilə əlaqəli olması və onu optimallaşdırmaq üçün hansı metrikadan istifadə etməyiniz barədə daha çox məlumat əldə etsəniz, bu kitabı Nicole Forsgren tərəfindən tövsiyə edirəm.

Narahatlıqların ayrılması: Sərbəst şəkildə birləşdirilmiş bir memarlıq dəyişdirmək asan olan bir proqram üçün vacibdir. Bir dəyişikliyin səthini azaldır. Mikroservislər və qablar narahatlıqların ayrılması üçün istifadə olunan bəzi mexanizmlərdir. Bunu xatırlamaq vacibdir və API, komponent və tətbiqlər qurarkən narahatlıqların ayrılmasını unutmayın.

Unutma
Yaxşı kod asanlıqla dəyişdirilə bilər

Daha yaxşı kod asanlıqla silinə bilər

Ən yaxşı kod, ümumiyyətlə yazılmayan şeydir

Yaratdığınız bitlərin gerçək dünyaya ən qısa müddətdə cavab verməsi vacibdir, buna görə yeni bitlərinizin nə kimi görünməli olduğunu bilirsiniz və lazımsız bit düzəltməyə vaxt itirmirsiniz.