Mühəndis olmayanlara GitHub-ı Thread-də necə istifadə etməyi necə və niyə öyrədirik

Thread-də əsas inanclarımızdan biri də texnologiyanın böyük dəyişikliyə imkan yaratmasıdır. Bu məhsulumuz üçün, həm də daxili işimiz üçün vacibdir.

Bu iş üsulu sayəsində hər şeyi - məhsullar, ölçülər, üslublar, təchizatçılar, anbarımızdakı yerlər, dəstək biletləri üçün həllər və heç düşünmədiyiniz çox şeyi təqdim etməyə çalışırıq.

Bu məlumat modellərinin hamısı, şirkətdəki məlumatları qorumaq üçün istifadə edənlər üçün tələb olunan bir səylə əlaqələndirilir. Bu doğrulama, verilənlər bazası dizaynı və ön iş ilə düzəliş interfeysləri yaratmaq deməkdir. Çox vaxt sadəcə vaxtımız olmur - yeni xüsusiyyətlər daha yüksək bir prioritetə ​​sahibdir və bir mütəxəssis lazım olduqda bir neçə məlumat sənədini yeniləyə bilər, elədir?

Qısa müddətdə bu daha sürətli bir düzəliş olsa da, bir mühəndis işlərini kontekstdə dəyişdirməli, buraxılışa baxmalı və səhv bir şey olmadığından əmin olmalıdır - bunların hamısı məhsuldarlığa zərər verir. Bəlkə də daha vacibdir, lakin məlumatları yeniləməsi lazım olan şəxs artıq bütün prosesi özündə saxlamır və başqasının cədvəlinə etibar edir.

Nəticədə, bu proses bir xüsusiyyəti qapıdan tez çıxarmaq üçün faydalı ola bilər, lakin uzun müddət işləmək üçün çox sürtünmə yaradır.

Daha yaxşı bir həll

GitHub-un veb redaktorunu ilk dəfə işə saldığını xatırlayıram - təsirlənmədim. Niyə kimsə veb brauzerdə kodu düzəldə bilər? Nə üçün hər bir sənəddə yalnız bir sənəd dəyişə bilən bir redaktor istifadə etməliyəm? İllər sonra naşirin hədəf bazarı olmadığımı başa düşdüm.

Thread-də, inkişaf qrupundan kənar insanlar, artık səmərəli işləmələri üçün lazım olan məlumatların yenilənmələrini idarə edə bilmək üçün kod bazamıza töhfə vermək üçün GitHub veb interfeysindən necə istifadə etməyi öyrənirlər.

Artıq əsas kod bazamızda texniki rollarda olmayan, illər ərzində əməyi keçən mühəndis və podratçılardan daha çox insan var idi.

Bu nəticə verdi?

Məhsul komandasında mühəndis olaraq müştərilərimizə fayda gətirəcək xüsusiyyətlərin inkişafına və daha çox CRUD interfeysi yaratmaq əvəzinə dəyişən ölçümlərə diqqətimi yönəldə bilərəm. Əvvəlcə məlumat sənədlərindəki məlumatlar üzərində işləmək üçün sınaq üçün daxili alətləri tez-tez atladığımız üçün A / B testlərini daha sürətli verə bilərəm. Bir layihənin çatdırılma mərhələsinə çatdığımız zaman, xüsusiyyətin dəyəri barədə bir fikrə sahib olmağımızla yanaşı daxili istifadəçilərimizin də interfeyslərin necə işləməsini istədiklərini daha yaxşı düşündüyümüz üçün vaxtı tənzimləmə interfeyslərinə sərf edə bilərik.

Həm də məlumat sənədləri ilə məhdudlaşmır. Thread.com-dakı bir çox səhifə əslində statik HTML-dir, yəni göndərmə, geri qayıtma qaydaları və ya ümumi şərtlər haqqında tez-tez verilən suallarımız kimi səhifələr. Əməliyyat qrupumuz GitHub istifadə etməyi öyrənərək kömək istəmədən onu yeniləyə bilər. İstedad komandamız iş saytımızı da düzəldə bilər və gündəlik müraciət edənlərlə müsahibə zamanı ortaya çıxan suallara cavab verə bilər.

Bütün bunlar inkişaf qrupundan kənarda olan qrup üzvlərimizin işlərinə daha çox sahib olduqları və təcrübələrinin göstərəcəyi dəyişiklikləri etmək üçün daha az sürtünmə nöqtəsinə sahib olduqları mənasını verir.

Bunu necə edirik

Etdiyimiz ilk şey, öyrətməli olduğumuz yeni başlayanlar olduqda hərdən sonra GitHub dərslərinə başlamaqdır. Bir deposunun əsaslarını əhatə edirik və Google Sənədlərindəki sənəd reviziya jurnalları ilə müqayisə edirik, bir sənəd işlətmək nə deməkdir və budaq nədir. Bu barədə yalnız ümumi bir şəkildə danışacağıq, çünki hazırkı dərs formatımızda komanda xətti interfeysini ümumiyyətlə əhatə etmirik.

Bundan sonra GitHub veb interfeysində bir dosyanın necə düzəldiləcəyini, bir öhdəlik mesajının necə yazılacağını, bir çəkilmə tələbinin nə olduğunu və Jenkins-in qurma vəziyyətinin nə demək olduğunu izah edəcəyik.

Nəhayət, texnoloji olmayan işçilərdən tikinti yaşıl olduqdan sonra birləşmə düyməsini vurmaq üçün Slack-də mövcud bir mühəndis seçmələrini xahiş edirik.

Problemlər baş verdi

Bütövlükdə bunun bütün komanda üçün böyük bir qələbə olduğunu düşünürük və böyüdükcə təlimlərə davam etmək və daha çox işçi motivasiya etməyi planlaşdırırıq, ancaq inkişaf etdikcə prosesimizi bir az dəyişdirdik.

Əvvəlcə, təsadüfi usta işlərin qarşısını almaq üçün GitHub rollarını və kilidli budaqları istifadə etdik. Versiya nəzarəti və filialları ilə çox tanış olmayan birisi üçün GitHub veb interfeysi, master filialın nə vaxt və ya yeni bir filialın nə vaxt verildiyi barədə xüsusilə aydın deyil. Thread olaraq, baş ofisimiz əl müdaxiləsi tələb olunmadan davamlı olaraq təmin edilir. Bu veb saytını zədələyən və fasilələrə səbəb olan bir çox öhdəliklə nəticələndi.

Bütün dayanma problemlərinə gəldikdə, 5 səbəb verdik və yerləşdirmə öncəsi vahid testləri ilə bu problemləri yaxından tuta biləcəyimizi gördük, lakin yəqin ki, problemi həll etmək üçün bütün yolları tuta bilməzdik.

İkincisi, bu problemə cavab olaraq, sadəcə məlumat sənədlərindəki məlumatların quruluşunu doğruluğunu yoxlayan və ya Django şablon sənədlərimizin hamısının etibarlı şablonlar olaraq təhlil edildiyini yoxlayacaq bəzi vahid testlərini yazmağa başladıq. Xüsusilə məlumat sənədləri ilə, normal olaraq onların sınaqdan keçirilməsini gözləməyəcəyik. Bununla birlikdə, faylları kodu bilməyən insanlar tərəfindən tənzimlənə biləcəyini istəyirik. Beləliklə, sadə səhvləri tapmaqda faydalı ola bilərlər.

Normalda məlumat fayllarımız üçün Python istifadə etdiyimiz üçün sintaksisin xüsusilə asan olmadığını və öyrəşdiyimizi gördük. Bunu düzəltmək üçün mühəndis üçün yazıldığından biraz daha təfərrüatlı sənədlər yazdıq. Bu sənədlər anbarda da mövcuddur və hər kəs tərəfindən redaktə edilə bilər. Beləliklə, mühəndis olmayan insanları təlimatları yeniləməyə, dəqiqləşdirməyə və saytın müəyyən hissələrində necə işləməyi öyrətməyə təşviq edirik.

İrəli get

Bu təcrübəni uğurlu hesab edirik və yaxın gələcəkdə davam edəcəyik. Veri fayllarını tənzimlənə bilən şəkildə tərtib etdikdə, sənədlərin içərisində, ehtimal ki, kopyalanabilir / yapışdırıla bilən nümunələr daxil olmaqla, ətraflı təlimatları daxil etməyə çalışacağıq.

Onsuz da test səhvlərimiz üçün səhvləri necə düzəldəcəyimiz barədə məlumatları olan məlumat xarakterli səhv mesajlarını göstərməyə çalışırıq, lakin test nəticəsini şərh etməyin mürəkkəbliyi səbəbindən, texniki cəhətdən mümkün olsa da, hazırda Jenkins'i qeyri-texniki qrup üzvlərinə məruz qoyuruq. Bu göndərmə təcrübəsini yaxşılaşdırmaq üçün növbəti fürsət və təlimdə irəliləyən yeni başlanğıcların növbəti sətirində sınaqdan keçirə biləcəyimiz bir şey ola bilər.

Nəhayət, bütün inkişaf etdiriciləri şirkətinizdə qeyri-texniki komanda üzvlərinin kod bazanıza töhfə vermə şansının olub olmadığını düşünməyə çağırıram. Hər iki tərəfdə də məhsuldarlığın faydaları, komandalar arasında empatiya və artıq inkişaf etdiricilərdən onlar üçün dəyişikliklər etməsi üçün işlərə sahib olma hissi var. Azaldılmış sürtünmə, eyni zamanda, işləmə səthlərində işlənmə vaxtının yüksək qiyməti olmadan başqalarının işlərində edə biləcəyi şeyləri təsir edə bilən daha qısa geribildirim dövrləri deməkdir.