Infrastruktur sebagai Kod: bagaimana untuk mengatasi masalah menggunakan XP

Hello, Habr! Sebelum ini, saya mengadu tentang kehidupan dalam Infrastruktur sebagai paradigma kod dan tidak menawarkan apa-apa untuk menyelesaikan situasi semasa. Hari ini saya kembali untuk memberitahu anda pendekatan dan amalan yang akan membantu anda melarikan diri dari jurang keputusasaan dan mengarahkan situasi ke arah yang betul.

Dalam artikel sebelum ini "Infrastruktur sebagai kod: kenalan pertama" Saya berkongsi tanggapan saya tentang kawasan ini, cuba merenung keadaan semasa di kawasan ini, malah mencadangkan bahawa amalan standard yang diketahui oleh semua pembangun boleh membantu. Nampaknya terdapat banyak aduan tentang kehidupan, tetapi tidak ada cadangan untuk jalan keluar dari situasi semasa.

Siapa kita, di mana kita berada dan apa masalah yang kita hadapi

Kami kini berada dalam Pasukan Onboarding Sre, yang terdiri daripada enam pengaturcara dan tiga jurutera infrastruktur. Kita semua cuba menulis Infrastruktur sebagai kod (IaC). Kami melakukan ini kerana kami pada asasnya tahu cara menulis kod dan mempunyai sejarah menjadi pembangun "atas purata".

• Kami mempunyai satu set kelebihan: latar belakang tertentu, pengetahuan tentang amalan, keupayaan untuk menulis kod, keinginan untuk mempelajari perkara baharu.
• Dan terdapat bahagian yang kendur, yang juga merupakan tolak: kekurangan pengetahuan tentang perkakasan infrastruktur.

Tindanan teknologi yang kami gunakan dalam IaC kami.

• Terraform untuk mencipta sumber.
• Pembungkus untuk memasang imej. Ini ialah imej Windows, CentOS 7.
• Jsonnet untuk membuat binaan berkuasa dalam drone.io, serta menjana json pembungkus dan modul terraform kami.
• Azure.
• Ansible semasa menyediakan imej.
• Python untuk perkhidmatan tambahan dan skrip penyediaan.
• Dan semua ini dalam VSCode dengan pemalam yang dikongsi antara ahli pasukan.

Kesimpulan daripada saya artikel terakhir adalah seperti ini: Saya cuba menanamkan (pertama sekali dalam diri saya) keyakinan, saya ingin mengatakan bahawa kita akan mencuba pendekatan dan amalan yang kita ketahui untuk menangani kesukaran dan kerumitan yang wujud dalam bidang ini.

Kami sedang bergelut dengan isu IaC berikut:

• Ketidaksempurnaan alat dan cara untuk pembangunan kod.
• Pengerahan yang perlahan. Infrastruktur adalah sebahagian daripada dunia sebenar, dan ia boleh menjadi perlahan.
• Kurang pendekatan dan amalan.
• Kami baru dan tidak tahu banyak.

Pengaturcaraan Ekstrim (XP) untuk menyelamatkan

Semua pembangun sudah biasa dengan Extreme Programming (XP) dan amalan yang ada di belakangnya. Ramai daripada kita telah bekerja dengan pendekatan ini, dan ia telah berjaya. Jadi mengapa tidak menggunakan prinsip dan amalan yang ditetapkan di sana untuk mengatasi cabaran infrastruktur? Kami memutuskan untuk mengambil pendekatan ini dan melihat apa yang berlaku.

Menyemak kebolehgunaan pendekatan XP kepada industri andaBerikut ialah perihalan persekitaran yang sangat sesuai untuk XP, dan bagaimana ia berkaitan dengan kami:

1. Keperluan perisian yang berubah secara dinamik. Ia jelas kepada kami apa matlamat akhirnya. Tetapi butiran boleh berbeza-beza. Kami sendiri memutuskan di mana kami perlu teksi, jadi keperluan berubah secara berkala (terutamanya oleh kami sendiri). Jika kita mengambil pasukan SRE, yang melakukan automasi itu sendiri, dan dengan sendirinya mengehadkan keperluan dan skop kerja, maka perkara ini sesuai dengan baik.

2. Risiko yang disebabkan oleh projek masa tetap menggunakan teknologi baharu. Kita mungkin menghadapi risiko apabila menggunakan beberapa perkara yang tidak kita ketahui. Dan ini adalah 100% kes kami. Keseluruhan projek kami adalah penggunaan teknologi yang kami tidak tahu sepenuhnya. Secara umum, ini adalah masalah yang berterusan, kerana... Terdapat banyak teknologi baharu yang muncul dalam sektor infrastruktur sepanjang masa.

3,4. Pasukan pembangunan lanjutan yang kecil dan ditempatkan bersama. Teknologi automatik yang anda gunakan membenarkan ujian unit dan kefungsian. Dua perkara ini tidak sesuai dengan kita. Pertama, kami bukan pasukan yang diselaraskan, dan kedua, terdapat sembilan daripada kami, yang boleh dianggap sebagai pasukan yang besar. Walaupun, menurut beberapa takrifan pasukan "besar", ramai ialah 14+ orang.

Mari lihat beberapa amalan XP dan cara ia mempengaruhi kelajuan dan kualiti maklum balas.

Prinsip Gelung Maklum Balas XP

Pada pemahaman saya, maklum balas adalah jawapan kepada soalan, adakah saya melakukan perkara yang betul, adakah kita akan ke sana? XP mempunyai skema ketuhanan untuk ini: gelung maklum balas masa. Perkara yang menarik ialah semakin rendah kita, semakin cepat kita dapat mendapatkan OS untuk menjawab soalan yang diperlukan.

Ini adalah topik yang agak menarik untuk perbincangan, bahawa dalam industri IT kami adalah mungkin untuk mendapatkan OS dengan cepat. Bayangkan betapa peritnya membuat projek selama enam bulan dan barulah tahu ada kesilapan pada awal-awal lagi. Ini berlaku dalam reka bentuk dan dalam mana-mana pembinaan sistem yang kompleks.

Dalam kes IaC kami, maklum balas membantu kami. Saya akan segera membuat pelarasan kecil pada rajah di atas: pelan keluaran tidak mempunyai kitaran bulanan, tetapi berlaku beberapa kali sehari. Terdapat beberapa amalan yang terikat dengan kitaran OS ini yang akan kita lihat dengan lebih terperinci.

Penting: maklum balas boleh menjadi penyelesaian kepada semua masalah yang dinyatakan di atas. Digabungkan dengan amalan XP, ia boleh menarik anda keluar dari jurang keputusasaan.

Bagaimana untuk menarik diri keluar dari jurang keputusasaan: tiga amalan

Ujian

Ujian disebut dua kali dalam gelung maklum balas XP. Ia bukan begitu sahaja. Mereka amat penting untuk keseluruhan teknik Pengaturcaraan Extreme.

Diandaikan bahawa anda mempunyai ujian Unit dan Penerimaan. Sesetengah memberi anda maklum balas dalam beberapa minit, yang lain dalam beberapa hari, jadi mereka mengambil masa yang lebih lama untuk menulis dan disemak kurang kerap.

Terdapat piramid ujian klasik, yang menunjukkan bahawa perlu ada lebih banyak ujian.

Bagaimanakah rangka kerja ini digunakan kepada kami dalam projek IaC? Sebenarnya... tidak sama sekali.

• Ujian unit, walaupun pada hakikatnya perlu ada banyak, tidak boleh terlalu banyak. Atau mereka sedang menguji sesuatu secara tidak langsung. Malah, kita boleh mengatakan bahawa kita tidak menulisnya sama sekali. Tetapi berikut adalah beberapa aplikasi untuk ujian sedemikian yang dapat kami lakukan:
  1. Menguji kod jsonnet. Ini, sebagai contoh, adalah saluran paip pemasangan dron kami, yang agak rumit. Kod jsonnet dilindungi dengan baik oleh ujian.
     Kami menggunakan ini Rangka kerja ujian unit untuk Jsonnet.
  2. Ujian untuk skrip yang dilaksanakan apabila sumber bermula. Skrip ditulis dalam Python, dan oleh itu ujian boleh ditulis padanya.
• Ia berkemungkinan untuk menyemak konfigurasi dalam ujian, tetapi kami tidak melakukannya. Ia juga mungkin untuk mengkonfigurasi peraturan konfigurasi sumber menyemak melalui tflint. Walau bagaimanapun, semakan di sana terlalu asas untuk terraform, tetapi banyak skrip ujian ditulis untuk AWS. Dan kami menggunakan Azure, jadi ini sekali lagi tidak terpakai.
• Ujian penyepaduan komponen: ia bergantung pada cara anda mengklasifikasikannya dan di mana anda meletakkannya. Tetapi mereka pada dasarnya berfungsi.

  Beginilah rupa ujian integrasi.

  
  
  Ini adalah contoh semasa membina imej dalam Drone CI. Untuk menghubungi mereka, anda perlu menunggu 30 minit untuk imej Packer terbentuk, kemudian tunggu 15 minit lagi untuk imej itu berlalu. Tetapi mereka wujud!

  Algoritma pengesahan imej

  1. Pembungkus mesti terlebih dahulu menyediakan imej sepenuhnya.
  2. Di sebelah ujian terdapat terraform dengan keadaan setempat, yang kami gunakan untuk menggunakan imej ini.
  3. Apabila dibuka, modul kecil yang terletak berdekatan digunakan untuk memudahkan kerja dengan imej.
  4. Setelah VM digunakan daripada imej, semakan boleh bermula. Pada asasnya, pemeriksaan dijalankan dengan kereta. Ia menyemak cara skrip berfungsi pada permulaan dan cara daemon berfungsi. Untuk melakukan ini, melalui ssh atau winrm kami log masuk ke mesin yang baru dibangkitkan dan menyemak status konfigurasi atau sama ada perkhidmatan sudah siap.

• Keadaannya serupa dengan ujian penyepaduan dalam modul untuk terraform. Berikut ialah jadual pendek yang menerangkan ciri-ciri ujian tersebut.

  
  
  Maklum balas mengenai saluran paip adalah sekitar 40 minit. Semuanya berlaku untuk masa yang sangat lama. Ia boleh digunakan untuk regresi, tetapi untuk pembangunan baharu ia biasanya tidak realistik. Jika anda sangat bersedia untuk ini, sediakan skrip berjalan, kemudian anda boleh mengurangkannya kepada 10 minit. Tetapi ini masih bukan ujian Unit, yang melakukan 5 keping dalam 100 saat.

Ketiadaan ujian Unit semasa memasang imej atau modul terraform menggalakkan pengalihan kerja kepada perkhidmatan berasingan yang hanya boleh dijalankan melalui REST atau skrip Python.

Sebagai contoh, kami perlu memastikan bahawa apabila mesin maya dimulakan, ia mendaftarkan dirinya dalam perkhidmatan ScaleFT, dan apabila mesin maya dimusnahkan, ia memadam sendiri.

Memandangkan kami mempunyai ScaleFT sebagai perkhidmatan, kami terpaksa bekerja dengannya melalui API. Terdapat pembungkus yang ditulis di sana yang boleh anda tarik dan berkata: "Masuk dan padam ini dan itu." Ia menyimpan semua tetapan dan akses yang diperlukan.

Kami sudah boleh menulis ujian biasa untuk ini, kerana ia tidak berbeza daripada perisian biasa: beberapa jenis apiha diejek, anda tariknya, dan lihat apa yang berlaku.

Keputusan ujian: Ujian unit, yang sepatutnya memberikan OS dalam satu minit, tidak memberikannya. Dan jenis ujian yang lebih tinggi dalam piramid adalah berkesan, tetapi hanya meliputi sebahagian daripada masalah.

Pengaturcaraan pasangan

Ujian, tentu saja, bagus. Anda boleh menulis banyak daripada mereka, mereka boleh menjadi pelbagai jenis. Mereka akan bekerja pada tahap mereka dan memberi kami maklum balas. Tetapi masalah dengan ujian Unit yang buruk, yang memberikan OS terpantas, kekal. Pada masa yang sama, saya masih mahukan OS pantas yang mudah dan menyenangkan untuk digunakan. Apatah lagi kualiti penyelesaian yang terhasil. Nasib baik, terdapat teknik yang boleh memberikan maklum balas yang lebih pantas daripada ujian unit. Ini adalah pengaturcaraan pasangan.

Apabila menulis kod, anda ingin mendapatkan maklum balas tentang kualitinya secepat mungkin. Ya, anda boleh menulis segala-galanya dalam cawangan ciri (supaya tidak memecahkan apa-apa untuk sesiapa sahaja), buat permintaan tarik dalam Github, berikannya kepada seseorang yang pendapatnya mempunyai berat, dan tunggu jawapan.

Tetapi anda boleh menunggu lama. Orang ramai sibuk, dan jawapannya, walaupun ada, mungkin tidak berkualiti tinggi. Katakan bahawa jawapan datang serta-merta, penyemak serta-merta memahami keseluruhan idea, tetapi jawapannya masih datang lewat, selepas fakta. Saya harap ia lebih awal. Inilah yang disasarkan pengaturcaraan pasangan – serta-merta, pada masa penulisan.

Di bawah ialah gaya pengaturcaraan pasangan dan kebolehgunaannya dalam mengusahakan IaC:

1. Klasik, Berpengalaman+Berpengalaman, anjakan mengikut pemasa. Dua peranan - pemandu dan pelayar. Dua orang. Mereka bekerja pada kod yang sama dan bertukar peranan selepas tempoh masa tertentu yang telah ditetapkan.

Mari kita pertimbangkan keserasian masalah kita dengan gaya:

• Masalah: ketidaksempurnaan alatan dan alatan untuk pembangunan kod.
  Kesan negatif: ia mengambil masa yang lebih lama untuk berkembang, kita memperlahankan, rentak/irama kerja menjadi hilang.
  Cara kami melawan: kami menggunakan alatan yang berbeza, IDE biasa dan juga mempelajari pintasan.
• Masalah: Penggunaan yang perlahan.
  Kesan negatif: meningkatkan masa yang diperlukan untuk membuat sekeping kod yang berfungsi. Kami bosan semasa menunggu, tangan kami menghulurkan untuk melakukan sesuatu yang lain sementara kami menunggu.
  Bagaimana kami berjuang: kami tidak mengatasinya.
• Masalah: kekurangan pendekatan dan amalan.
  Kesan negatif: tidak ada pengetahuan tentang cara melakukannya dengan baik dan cara melakukannya dengan buruk. Memanjangkan penerimaan maklum balas.
  Bagaimana kita berjuang: saling bertukar pendapat dan amalan dalam kerja berpasangan hampir menyelesaikan masalah.

Masalah utama menggunakan gaya ini dalam IaC ialah kadar kerja yang tidak sekata. Dalam pembangunan perisian tradisional, anda mempunyai pergerakan yang sangat seragam. Anda boleh meluangkan masa lima minit dan menulis N. Luangkan masa 10 minit dan tulis 2N, 15 minit - 3N. Di sini anda boleh menghabiskan lima minit dan menulis N, dan kemudian menghabiskan 30 minit lagi dan menulis sepersepuluh daripada N. Di sini anda tidak tahu apa-apa, anda terperangkap, bodoh. Siasatan mengambil masa dan mengalihkan perhatian daripada pengaturcaraan itu sendiri.

Kesimpulan: dalam bentuk tulen ia tidak sesuai untuk kita.

2. Ping-pong. Pendekatan ini melibatkan seorang menulis ujian dan seorang lagi melakukan pelaksanaan untuknya. Mengambil kira hakikat bahawa segala-galanya adalah rumit dengan ujian Unit, dan anda perlu menulis ujian integrasi yang mengambil masa yang lama untuk memprogram, semua kemudahan ping-pong hilang.

Saya boleh katakan bahawa kami cuba mengasingkan tanggungjawab untuk mereka bentuk skrip ujian dan melaksanakan kod untuknya. Seorang peserta datang dengan skrip, dalam bahagian kerja ini dia bertanggungjawab, dia mempunyai kata terakhir. Dan yang lain bertanggungjawab untuk pelaksanaan. Ia berjaya dengan baik. Kualiti skrip dengan pendekatan ini meningkat.

Kesimpulan: malangnya, kadar kerja tidak membenarkan penggunaan ping-pong sebagai amalan pengaturcaraan pasangan dalam IaC.

3. Gaya Kuat. Amalan yang sukar. Ideanya ialah seorang peserta menjadi navigator arahan, dan yang kedua mengambil peranan sebagai pemandu pelaksanaan. Dalam kes ini, hak untuk membuat keputusan terletak sepenuhnya pada pelayar. Pemandu hanya mencetak dan boleh mempengaruhi apa yang berlaku dengan perkataan. Peranan tidak berubah untuk masa yang lama.

Baik untuk belajar, tetapi memerlukan kemahiran insaniah yang kuat. Di sinilah kita goyah. Teknik itu sukar. Dan ia bukan tentang infrastruktur.

Kesimpulan: ia berpotensi digunakan, kami tidak berputus asa mencuba.

4. Mobbing, swarming dan semua gaya yang diketahui tetapi tidak disenaraikan Kami tidak menganggapnya, kerana Kami belum mencubanya dan mustahil untuk membincangkannya dalam konteks kerja kami.

Keputusan umum menggunakan pengaturcaraan pasangan:

• Kami mempunyai kadar kerja yang tidak sekata, yang mengelirukan.
• Kami menghadapi kemahiran insaniah yang tidak cukup baik. Dan bidang subjek tidak membantu mengatasi kelemahan kita ini.
• Ujian panjang dan masalah dengan alatan menyukarkan pembangunan berpasangan.

5. Walaupun begitu, terdapat kejayaan. Kami menghasilkan kaedah kami sendiri "Convergence - Divergence". Saya akan menerangkan secara ringkas bagaimana ia berfungsi.

Kami mempunyai rakan kongsi tetap selama beberapa hari (kurang dari seminggu). Kami melakukan satu tugas bersama-sama. Kami duduk bersama untuk seketika: seorang menulis, yang lain duduk dan menonton pasukan sokongan. Kemudian kami bersurai untuk beberapa waktu, masing-masing melakukan beberapa perkara bebas, kemudian kami berkumpul semula, menyegerakkan dengan cepat, melakukan sesuatu bersama-sama dan bersurai lagi.

Perancangan dan komunikasi

Blok amalan terakhir yang melaluinya masalah OS diselesaikan ialah organisasi kerja dengan tugas itu sendiri. Ini juga termasuk pertukaran pengalaman yang di luar kerja berpasangan. Mari kita lihat tiga amalan:

1. Objektif melalui pokok gol. Kami mengatur pengurusan keseluruhan projek melalui pokok yang tidak berkesudahan ke masa hadapan. Secara teknikal, penjejakan dilakukan di Miro. Terdapat satu tugas - ia adalah matlamat perantaraan. Daripadanya pergi sama ada matlamat yang lebih kecil atau kumpulan tugas. Tugas itu sendiri datang daripada mereka. Semua tugas dibuat dan diselenggara di papan ini.

Skim ini juga memberikan maklum balas, yang berlaku sekali sehari apabila kami menyegerakkan di perhimpunan. Mempunyai rancangan bersama di hadapan semua orang, tetapi tersusun dan terbuka sepenuhnya, membolehkan semua orang menyedari apa yang sedang berlaku dan sejauh mana kami telah maju.

Kelebihan penglihatan visual tugas:

• Kausalitas. Setiap tugas membawa kepada beberapa matlamat global. Tugasan dikumpulkan kepada matlamat yang lebih kecil. Domain infrastruktur itu sendiri agak teknikal. Ia tidak selalu jelas apa kesan khusus, contohnya, menulis buku panduan tentang berhijrah ke nginx lain terhadap perniagaan. Mempunyai kad sasaran berdekatan menjadikannya lebih jelas.
  
  Kausalitas adalah sifat penting masalah. Ia secara langsung menjawab soalan: "Adakah saya melakukan perkara yang betul?"
• Paralelisme. Terdapat sembilan daripada kami, dan secara fizikalnya mustahil untuk melemparkan semua orang pada satu tugas. Tugasan dari satu kawasan mungkin juga tidak mencukupi. Kami terpaksa menyamakan kerja antara kumpulan kerja kecil. Pada masa yang sama, kumpulan itu duduk di atas tugas mereka untuk beberapa waktu, mereka boleh diperkuatkan oleh orang lain. Kadang-kadang orang jatuh dari kumpulan kerja ini. Seseorang pergi bercuti, seseorang membuat laporan untuk conf DevOps, seseorang menulis artikel tentang Habr. Mengetahui matlamat dan tugas yang boleh dilakukan secara selari menjadi sangat penting.

2. Penggantian pembentang mesyuarat pagi. Pada pendirian kami menghadapi masalah ini - orang melakukan banyak tugas secara selari. Kadang-kadang tugas saling berkaitan dan tidak ada pemahaman tentang siapa yang melakukan apa. Dan pendapat ahli pasukan yang lain sangat penting. Ini adalah maklumat tambahan yang boleh mengubah jalan penyelesaian masalah. Sudah tentu, biasanya ada seseorang dengan anda, tetapi nasihat dan petua sentiasa berguna.

Untuk memperbaiki keadaan ini, kami menggunakan teknik "Menukar Pendirian Terkemuka". Sekarang mereka diputar mengikut senarai tertentu, dan ini mempunyai kesannya. Apabila tiba giliran anda, anda terpaksa menyelam dan memahami perkara yang berlaku untuk menjalankan mesyuarat Scrum yang baik.

3. Demo dalaman. Bantuan dalam menyelesaikan masalah daripada pengaturcaraan pasangan, visualisasi pada pokok masalah dan bantuan pada mesyuarat scrum pada waktu pagi adalah baik, tetapi tidak sesuai. Sebagai pasangan, anda hanya terhad oleh pengetahuan anda. Pepohon tugas membantu memahami secara global siapa yang melakukan apa. Dan penyampai dan rakan sekerja pada mesyuarat pagi tidak akan menyelami masalah anda. Mereka pasti mungkin terlepas sesuatu.

Penyelesaiannya didapati dengan menunjukkan kerja yang dilakukan antara satu sama lain dan kemudian membincangkannya. Kami bertemu sekali seminggu selama sejam dan menunjukkan butiran penyelesaian kepada tugasan yang telah kami lakukan sepanjang minggu lalu.

Semasa demonstrasi, adalah perlu untuk mendedahkan butiran tugas dan pastikan untuk menunjukkan operasinya.

Laporan boleh dijalankan menggunakan senarai semak.1. Masukkan ke dalam konteks. Dari mana datangnya tugas itu, kenapa perlu?

2. Bagaimanakah masalah itu diselesaikan sebelum ini? Contohnya, klik tetikus secara besar-besaran diperlukan, atau mustahil untuk melakukan apa-apa sama sekali.

3. Bagaimana kita memperbaikinya. Contohnya: "Lihat, sekarang ada scriptosik, inilah readme."

4. Tunjukkan cara ia berfungsi. Adalah dinasihatkan untuk melaksanakan secara langsung beberapa senario pengguna. Saya mahu X, saya buat Y, saya nampak Y (atau Z). Sebagai contoh, saya menggunakan NGINX, merokok url, dan mendapat 200 OK. Jika tindakan itu panjang, sediakannya lebih awal supaya anda boleh menunjukkannya kemudian. Adalah dinasihatkan untuk tidak memecahkannya terlalu lama sejam sebelum demo, jika ia rapuh.

5. Terangkan sejauh mana kejayaan masalah itu diselesaikan, apakah kesukaran yang masih ada, apa yang tidak diselesaikan, apakah penambahbaikan yang boleh dilakukan pada masa hadapan. Contohnya, sekarang CLI, maka akan ada automasi penuh dalam CI.

Adalah dinasihatkan bagi setiap pembesar suara untuk mengekalkannya selama 5-10 minit. Jika ucapan anda jelas penting dan akan mengambil masa yang lebih lama, selaraskan ini terlebih dahulu dalam saluran sre-takeover.

Selepas bahagian bersemuka sentiasa ada perbincangan dalam benang. Di sinilah maklum balas yang kami perlukan tentang tugas kami muncul.

Hasilnya, tinjauan dijalankan untuk menentukan kegunaan apa yang berlaku. Ini adalah maklum balas mengenai intipati ucapan dan kepentingan tugas.

Kesimpulan yang panjang dan apa yang seterusnya

Ia mungkin kelihatan bahawa nada artikel itu agak pesimis. Ini adalah salah. Dua tahap maklum balas yang lebih rendah, iaitu ujian dan pengaturcaraan pasangan, berfungsi. Tidak sesempurna pembangunan tradisional, tetapi ada kesan positif daripadanya.

Ujian, dalam bentuk semasa mereka, hanya menyediakan liputan kod separa. Banyak fungsi konfigurasi akhirnya tidak diuji. Pengaruh mereka terhadap kerja sebenar semasa menulis kod adalah rendah. Walau bagaimanapun, terdapat kesan daripada ujian penyepaduan, dan ia membolehkan anda melakukan pemfaktoran semula tanpa rasa takut. Ini adalah satu pencapaian yang hebat. Selain itu, dengan peralihan tumpuan kepada pembangunan dalam bahasa peringkat tinggi (kami mempunyai python, pergi), masalah itu hilang. Dan anda tidak memerlukan banyak semakan untuk "gam"; semakan integrasi am sudah memadai.

Bekerja secara berpasangan lebih bergantung pada orang tertentu. Terdapat faktor tugas dan kemahiran insaniah kita. Bagi sesetengah orang ia berfungsi dengan baik, dengan yang lain ia lebih teruk. Pasti ada faedah daripada ini. Adalah jelas bahawa walaupun peraturan kerja berpasangan tidak dipatuhi dengan secukupnya, hakikat melaksanakan tugas bersama-sama mempunyai kesan positif terhadap kualiti hasil. Secara peribadi, saya dapati bekerja secara berpasangan lebih mudah dan menyeronokkan.

Cara peringkat lebih tinggi untuk mempengaruhi OS - merancang dan bekerja dengan tugas dengan tepat menghasilkan kesan: pertukaran pengetahuan berkualiti tinggi dan kualiti pembangunan yang lebih baik.

Kesimpulan ringkas dalam satu baris

• Pengamal HR bekerja di IaC, tetapi dengan kecekapan yang kurang.
• Kuatkan apa yang berkesan.
• Buat mekanisme dan amalan pampasan anda sendiri.

Sumber: www.habr.com