Apa arti posisi arsitek QA? Dan apa arti posisi meme wrangler yang sepenuhnya tidak bisa dipahami? Sejak kapan penguji harus terhubung saat bekerja pada arsitektur? Bagaimana mengubah proses dalam organisasi sehingga orang-orang di pertemuan dengan kompleksitas pertama tidak kembali ke yang lama?
Neil Ford menyajikan tiga opsi di situs webnya: ThoughtWorker (seorang karyawan ThoughtWorks, yang banyak orang ketahui karena Martin Fowler), Arsitek Perangkat Lunak dan Meme Wrangler. Segera, di konferensi Heisenbug kami, ia akan berbicara tentang menciptakan "arsitektur evolusi," yang dapat diubah dengan perubahan keadaan eksternal. Sementara itu,
Mikhail xomyakus Druzhinin (anggota komite program Heisenbug) bertanya kepada Neal: bagaimana pidatonya bersinggungan dengan pengujian, dan banyak lagi.
- Bisakah Anda mulai dengan menceritakan tentang diri Anda dan karier Anda?- tentu saja Saya telah berada di ThoughtWorks selama hampir 14 tahun. Sebelum itu, dia adalah CTO di sebuah perusahaan konsultan dan pelatihan kecil yang beranggotakan sekitar 25 orang, dan di sana dia mulai mencoba tangannya di teknologi seperti Jawa. Tiga buku pertama yang saya tulis sebelum bergabung dengan ThoughtWorks. Yang pertama adalah tentang Delphi, pada waktu itu cukup populer di Rusia dan di Eropa.
Ketika saya masih CTO, saya bosan menjadi geek alfa. Ketika Anda tahu lebih banyak dari orang-orang di sekitar Anda tidak benar-benar berkembang. Saya mulai berbicara di berbagai konferensi, dan saya benar-benar menikmati berada di antara pembicara lain karena mereka orang yang sangat cerdas dan tertarik. Dan saya mulai secara tidak sadar mencari perusahaan di mana orang-orang yang benar-benar cerdas dan tertarik akan bekerja. Dan secara harfiah tersandung ThoughtWorks, seperti banyak orang, di situs web Martin Fowler. Pada hal-hal seperti CruiseControl dan pustaka pengujian NUnit, saya perhatikan bahwa mereka memberikan kontribusi besar untuk open source dan melakukan banyak hal yang sangat menarik. Maka saya secara tidak sengaja memulai proses wawancara dengan ThoughtWorks, yang pada akhirnya saya menerima tawaran pekerjaan. Ini adalah langkah yang baik bagi saya, karena mereka adalah pengembang yang sangat cerdas dan sangat antusias.
Saya bisa menjadi konsultan independen, tetapi dalam peran ini saya tidak suka dua hal. Pertama, Anda harus melakukan semua bisnis sendiri: penagihan, mengejar orang demi uang, mengatur arus kas dan semua itu. Saya mampu melakukan ini, tetapi itu tidak menarik bagi saya. Gairah saya adalah perangkat lunak dan pengembangan.
Dan yang kedua: jika Anda seorang konsultan independen, maka Anda jarang berhasil bekerja dalam kolaborasi dengan seseorang, sebagai sebuah tim. Anda hampir selalu mandiri, dan saya sangat suka pengembangan tim. Saya bahkan menulis beberapa buku bersama dengan penulis lain, termasuk buku terbaru saya, Evolutionary Architecture. Tampak bagi saya bahwa ketika bekerja bersama, hasilnya lebih besar daripada jumlah masing-masing komponen. Ketika Anda berkolaborasi dalam karya kreatif, baik itu proyek menulis atau program, Anda bisa mendapatkan lebih banyak sudut pandang dan ide yang lebih umum, sehingga hasilnya akan lebih baik.
Jadi pada bulan April ini sudah 14 tahun sejak saya di ThoughtWorks. Saya tahu ini dengan sangat baik, karena salah satu keuntungan menarik dari bekerja di ThoughtWorks adalah bahwa jika Anda telah bersama perusahaan selama 10 tahun, Anda mendapatkan waktu liburan 12 minggu yang dibayar ketika Anda dapat melakukan apa pun yang Anda inginkan. Dan setelah itu, setiap 5 tahun Anda mendapat cuti kreatif 6 minggu, jadi saya punya satu tahun tersisa sampai 6 minggu pertama. Saya sangat menyukai yang 12 minggu dan saya menantikan yang berikutnya. Jadi, Anda selalu ingat apa yang telah Anda lakukan selama satu dekade: mereka diukur dengan liburan yang menyenangkan.
- Ini adalah liburan yang sangat nyata, keren."Saya disewa oleh ThoughtWorks sebagai arsitek dan memainkan peran itu untuk sementara waktu sampai saya mencapai tingkat direktur." Sebagian besar pekerjaan saya sekarang berhubungan dengan bidang arsitektur perangkat lunak, saya menghabiskan banyak waktu di persimpangan praktik arsitektur dan rekayasa (misalnya, pengiriman terus-menerus) - Saya menduga bahwa di sini minat saya bersinggungan dengan minat audiens Heisenbug.
Secara khusus, yang sering saya bicarakan belakangan ini adalah topik buku terbaru saya, konstruksi arsitektur evolusioner. Jika Anda dapat mencegah bug, maka orang yang menguji aplikasi akan lebih mudah. Arsitektur evolusi mencakup teknik keamanan untuk fitur arsitektur kritis - seperti penyebaran, pengujian, skalabilitas, kinerja, dan sebagainya.
"Apa arti Meme Wrangler?"- Menurut aturan ThoughtWorks, Anda dapat memilih jabatan apa pun, kecuali untuk beberapa orang yang dipesan seperti "CEO". Jika Anda datang dengan posisi yang menarik untuk diri sendiri, maka silakan. Dan ketika set kartu nama berakhir, Anda dapat membuat yang baru.
Pekerjaan pertama saya adalah seorang arsitek aplikasi. Posisi ini mencerminkan esensi pekerjaan, tetapi sangat sering di perusahaan besar itu menyiratkan bahwa Anda tidak lagi membawa banyak manfaat, bahwa Anda menghabiskan lebih banyak waktu menggambar daripada membuat sesuatu.
Dan salah satu keuntungan dari pengembangan kustom adalah Anda dapat berkenalan dengan sejumlah besar proyek yang berbeda. Arsitek perangkat lunak, saya pikir, adalah “pencocokan pola” secara alami: kami mencoba menerapkan pola pada semua yang kami lihat, bahkan untuk hal-hal dari dunia nyata. Jadi, jika Anda seorang arsitek dalam pengembangan kustom, Anda harus melihat banyak proyek berbeda, Anda melihat pola berulang di dalamnya, Anda melihat mana yang berhasil. Dan saya menyadari bahwa, pada kenyataannya, pekerjaan saya sedikit mengumpulkan ide-ide menarik dari ekosistem perangkat lunak. Dari sini datang Meme Wrangler.
Meme adalah istilah yang diciptakan oleh penulis Richard Dawkins, itu adalah unit luas untuk menunjuk ide. Semua orang tahu meme dari Internet - ini adalah beberapa hal jenaka yang menangkap dan menyebar seperti virus. Dan kata "bertengkar" memiliki dua arti yang bermanfaat, yang pertama adalah bertindak sebagai hakim dalam perselisihan, dan yang kedua adalah mengemudi menjadi kawanan. Dan saya memilih posisi Meme Wrangler, karena lebih akurat mencerminkan apa yang saya lakukan sekarang. Terlebih lagi, sekarang setelah saya merilis buku lain, saya menulis di Twitter bahwa saya "memasang meme lain" dan memasukkannya ke dalam buku ini.
- Dapatkah Anda menjelaskan apa yang harus dilakukan oleh arsitek perangkat lunak, apa yang Anda lakukan sebagai arsitek perangkat lunak?"Tentu saja aku bisa mencoba, tetapi tidak ada yang benar-benar berhasil memberikan definisi ini." Martin Fowler - seorang pria yang sangat keren dalam memberikan definisi untuk segala sesuatu di bidang pemrograman - telah secara terbuka menolak untuk mendefinisikan istilah "arsitek perangkat lunak" dalam teksnya
"Siapa yang butuh arsitek?" .
Tetapi jika Anda melihat peran seorang arsitek perangkat lunak, salah satu hal adalah bahwa mereka bertanggung jawab atas segala sesuatu yang kemudian sulit diubah. Ini semua terkait dengan struktur sistem perangkat lunak Anda: pola dasar apa yang akan Anda gunakan, bahasa apa atau kerangka mana. Karena semua keputusan ini memiliki konsekuensi yang luas.
Salah satu hal yang sangat diperhatikan oleh arsitek adalah apa yang kita sebut "parameter arsitektur," yang juga disebut "persyaratan non-fungsional," tetapi kami tidak suka nama ini. Ini adalah hal-hal seperti kinerja, skalabilitas, elastisitas, penerapan - semua ini adalah tanggung jawab arsitek. Seorang arsitek dapat membuat struktur yang akan memperhitungkan persyaratan untuk program itu sendiri, dan semua parameter arsitektur yang harus disediakan di dalamnya.
Misalkan Anda seorang arsitek dan Anda perlu membuat struktur sistem perangkat lunak untuk mendaftarkan siswa di universitas. Misalkan kita memiliki seribu siswa dan 10 kursus yang harus mereka daftarkan. Dan sekarang, berdasarkan pengetahuan kami tentang bagaimana universitas diselenggarakan, menurut Anda apa yang akan terjadi: siswa akan didistribusikan secara merata sepanjang semester sehingga kami mendapatkan jumlah siswa yang sama di setiap kursus, atau mereka semua akan bertahan hingga satu jam terakhir, dan lalu buru-buru merekam sekaligus?
Dan ini elastisitas, ini adalah parameter arsitektur yang harus Anda pastikan ketika Anda membuat sistem seperti itu. Kemungkinan besar, ini tidak ditunjukkan di mana pun, tetapi Anda tahu itu, hanya berdasarkan pada bidang subjek. Inilah yang membuat arsitektur sistem perangkat lunak begitu rumit: Anda perlu memahami area subjek, serta kemampuan teknis dan keterbatasan perusahaan Anda. Anda dapat dibatasi, misalnya, oleh kenyataan bahwa basis data relasional ini sudah dipilih untuk standar perusahaan kami, dan kami perlu meningkatkan produktivitas. Bagaimana kita bisa mencapai hasil ini?
Ini adalah pekerjaan arsitek perangkat lunak - untuk mengatasi semua keputusan penting yang terkait dengan fakta bahwa ia memiliki konsekuensi jangka panjang dan sangat sulit untuk mengubahnya nanti. Banyak elemen struktur, seperti antarmuka pengguna, cukup mudah untuk dikembangkan, karena Anda baru saja mengubah satu lapisan aplikasi. Dan arsitektur lebih tentang bagaimana semua lapisan ini disandingkan, dan biasanya lebih sulit untuk diubah.
Mereka mengatakan bahwa layanan microser sekarang cukup populer, dan arsitektur seperti itu dibuat khusus dengan harapan akan adanya perubahan yang konstan. Jadi untuk membuat perubahan besar pada struktur layanan-mikro jauh lebih mudah, tetapi mereka diciptakan sejak awal. Dan ini adalah topik yang sangat menarik untuk penelitian - bagaimana merancang arsitektur yang mudah diubah, karena untuk industri inilah yang paling sulit untuk waktu yang sangat lama.
- Mengenai masalah arsitektur dan posting: Saya melihat "Arsitek QA" pada kartu nama dan LinkedIn semakin banyak.- Ini adalah salah satu masalah dari istilah "arsitek": setiap perusahaan harus menemukan namanya sendiri untuk ini. Saya bertemu "arsitek QA" dan "arsitek data", "arsitek sistem", "arsitek solusi", "arsitek teknis" - Saya bertemu arsitek dari semua garis yang mungkin. Dan ini adalah masalah, karena tidak ada yang bisa memberikan definisi yang jelas, dan memberikan apa yang Anda inginkan.
Apa "arsitek QA" dapat berarti bagi perusahaan tertentu, saya bahkan tidak tahu pasti. Apakah orang tersebut mengembangkan struktur QA? Bagi saya, ini lebih dekat dengan fungsi seorang arsitek sebagai ahli teknis, karena seringkali seorang arsitek juga seorang manajer proyek teknis. Tetapi arsitek juga menangani presentasi dan dokumentasi. Jadi, jika saya seorang arsitek dan saya memiliki ide cemerlang untuk arsitektur baru, tetapi saya tidak dapat membuat presentasi dan meyakinkan orang-orang dengan uang bahwa kita harus melakukannya, maka kita tidak akan memiliki kesempatan untuk mewujudkan ide keren saya. Ini berarti keterampilan komunikasi.
Keterampilan ini berlaku untuk QA, dan siapa pun yang melakukan ini juga bisa disebut "arsitek." Anda lihat, ini adalah pos yang tidak jelas. Banyak organisasi sampai-sampai menyebut insinyur senior itu seorang arsitek, karena kedengarannya keren dan mereka tidak tahu apa lagi untuk menyebutnya. Seperti, Anda tahu, pengembang senior-senior-senior - oke, arsitek. Dan saya bertemu perusahaan di mana ada satu jenis arsitek, dan saya bertemu perusahaan di mana ada puluhan jenis arsitek. Bahkan, ini adalah posting fiktif. "Meme wrangler" saya lebih baik dalam hal ini karena jelas dibuat-buat.
- Mari bicara tentang pidato Anda di Heisenbug. Anda akan berbicara pada konferensi pengujian - bagaimana dengan kualitas perangkat lunak untuk Anda?- Saya pribadi mempertimbangkan kualitas komponen arsitektur sistem. Saya tahu bahwa dunia QA melihat perangkat lunak lebih sebagai kotak hitam, yaitu, terlihat dari perspektif pengguna apakah ada kesalahan dan kegagalan, apakah berfungsi dengan benar. Tentu saja, saya juga tertarik dengan ini, tetapi saya lebih khawatir tentang akar penyebab kesalahan: mengapa aplikasi tidak dapat diandalkan, mengapa crash secara berkala? Di sini saya harus menjadi garis pertahanan terakhir, mencari tahu mengapa ini terjadi. Dan ada hal-hal seperti kinerja dan responsif. Ada banyak pembicaraan tentang mereka di dunia UI sekarang, mereka memiliki indikator yang jelas: jika situs seluler Anda memuat konten yang terlihat lebih dari 3 detik, pengguna akan pergi dan pergi ke tempat lain.
Perhatian besar diberikan pada kinerja web: berapa waktu sebelum memuat konten yang terlihat pertama, berapa total waktu pemuatan halaman. Dan semua ini adalah parameter kualitas, yang tentu terlihat dari sudut pandang pengamat luar, dan saya adalah orang yang harus mencari tahu bagaimana kita akan membangun sebuah sistem di mana indikator tersebut tercapai. Dan ini dapat menyebabkan perubahan di frontend mengenai teknologi web mana yang akan digunakan, tetapi juga dapat menyebabkan perubahan di backend. Mungkin, untuk mengirimkan informasi bukan secara real time, tetapi dalam sebuah paket, dan di tengah membuat mekanisme caching? Bagi saya, kualitas terlihat seperti ini: menentukan apa persyaratannya, dan kemudian menghasilkan implementasi teknis yang akan mewujudkannya.
- Dapatkan Anda memberikan studi kasus paling menarik dari praktik terkait dengan kualitas?- Sulit dikatakan, semua proyek berbeda, jadi yang terbaik selalu yang terakhir yang saya kerjakan!
Yah, entah bagaimana saya bekerja pada sistem di mana persyaratannya mirip dengan Lotus Notes. Ingat program kuno seperti itu? Dia adalah program yang mengerikan, tetapi dia melakukan satu hal dengan sangat, sangat bagus. Program ini disinkronkan dengan sangat baik: Anda dapat mengunduh surat dan catatan Anda, lalu naik taksi, pergi ke suatu tempat, menjawab semua surat pada saat itu, dan saat berikutnya Anda terhubung ke jaringan, semuanya akan secara otomatis membongkar, menyinkronkan, dan bekerja secara ajaib cara.
Dan kami memiliki klien dengan sistem penjualan yang menginginkan prinsip kerja yang sama. Karena tenaga penjualan selalu bergerak, dan perlu mereka memesan tanpa koneksi Internet, dan kemudian semuanya akan disinkronkan dan menjadi sebagaimana mestinya.
Dan kami menyadari betapa sulitnya ini, karena banyak kasus batas dan skenario yang perlu disediakan. Pertama, kami mengembangkan sistem yang berfungsi tanpa koneksi internet sama sekali, kemudian kami mulai sinkronisasi. Dan ada banyak sakit kepala - misalnya, kinerja aplikasi online dibandingkan dengan offline, penundaan nyata muncul saat menyambungkan, karena sinkronisasi sedang berlangsung pada waktu itu. Jadi, dalam kasus ini, QA adalah pecahan besar bagi kami, karena mereka menemukan kasus batas yang menghancurkan seluruh sistem.
Dan dari luar, ini sepertinya tugas yang sederhana. Aplikasi seperti Dropbox dan Google Drive memecahkan masalah ini sehingga menjadi tidak terlihat. Dan sepertinya itu mudah. Tetapi ketika kami mencoba menyelesaikannya, ternyata ada sejuta kasus perbatasan. Jadi tanpa QA yang andal, sulit untuk menemukan semuanya, yang masing-masing harus dikembalikan agar sejajar dengan struktur aplikasi untuk memastikan bahwa keseluruhan struktur masih berfungsi.
Sebenarnya, ketika kami sedang mengembangkan sistem ini, membuat perubahan mendasar pada struktur, kami menyadari bahwa kasus perbatasan akan sering dan tidak dapat diterima. Dan ini adalah ilustrasi yang bagus tentang betapa pentingnya memiliki lingkaran umpan balik yang sangat mapan antara desain arsitektur dan bagian-bagian seperti QA. Terlalu banyak perusahaan menunda ini pada saat-saat terakhir, tetapi jika Anda melakukannya, pada akhirnya banyak hal akan dilakukan dengan salah, dan Anda harus kembali dan menghabiskan banyak waktu untuk mengulanginya. Jika Anda menjalin kontak dekat antara pengembangan arsitektur dan pengujian, Anda dapat menemukan kasus batas ini dan mengubah struktur lebih cepat. Untungnya, kami sangat fleksibel dalam proyek ini - karena ini adalah proyek ThoughtWorks, kami memiliki siklus yang sangat cepat. Dan kami memiliki tim penguji yang sangat kuat.
- Banyak orang dalam pengujian bertanya bagaimana mereka dapat mempengaruhi arsitektur. Bagi mereka, arsitektur adalah sesuatu di menara gading. Apa yang bisa dilakukan dengan ini?- Tampaknya bagi saya bahwa akan bermanfaat bagi penguji untuk datang ke arsitek dan menjelaskan kepada mereka bahwa mereka melakukan pekerjaan mereka dengan buruk, dan lebih baik bagi penguji untuk mengetahui bagaimana melakukannya. Orang-orang suka ketika mereka diberitahu ini! Sebenarnya, tidak, mereka tidak menyukainya, tidak ada hal baik yang akan terjadi.
Saya punya mantra favorit untuk kasus-kasus seperti itu: "lebih baik untuk ditampilkan daripada berdiskusi." Anda perlu menunjukkan betapa berbedanya dunia Anda dari dunia mereka. Jika Anda seorang insinyur pengujian, Anda perlu membawa case pengguna yang akan menunjukkan dengan jelas cacat desain. Jika Anda menunjukkan skenario ini kepada seorang arsitek, maka ini bukan hanya keluhan tentang sesuatu, tetapi demonstrasi nyata: "Sekarang, proyek Anda tidak akan berfungsi dalam skenario seperti itu, jadi itu perlu diubah." Jika mereka tidak setuju dengan ini, maka ini berarti mereka kehilangan kontak dengan kenyataan. Dan arsitek harus peka terhadap hal-hal yang terjadi di dunia nyata.
Ada sedikit besar, seperti saya menyebutnya,
puisi dari mantan Sekretaris Pertahanan Donald Rumsfeld, yang berbicara tentang "terkenal terkenal" dan "tidak diketahui tidak dikenal". Jadi, dalam setiap proyek perangkat lunak ada "tidak diketahui tidak diketahui", sehingga pengembangan arsitektur apapun harus berulang. Karena tidak masalah seberapa banyak Anda memikirkannya, hal-hal yang tidak dapat Anda ramalkan dengan cara apa pun hanya akan muncul tiba-tiba saat Anda mencoba membangun struktur ini.
, , Docker. , , . , , .
. , , , — , .
, , ?
— .— ! ! , , , . (QA). , , , .
, , QA , . , , , . -, . -, .
, — . , QA , . , . , .
— , ?— . , , , - QA-, -, , data science, . , .
, . , , . - : « ». - : «, , , , , ». , , , . .
, ThoughtWorks, « » . , , deployment pipeline. , , , , , . , QA, , , , , , , . , -.
— . , «-», «QA» - ?— . ThoughtWorks , , , . , , . , , -, . , . , .
— QA ?— , , . — . , .
- , . , , , . - , . , , . , , , . , .
, . , — , 1975 , .
— 1975-?— « -» , . , . ( ), « ». , . , , - , . , . , .
, , , — , QA . , . , , . , , .
— .— , , Apple , . Wi-Fi , , . . UI, . QA, .
— , . , ThoughtWorks — ?— , , « , ». , , , .
, . ? UI, , , — , . , , , : «! !» , , 50 Jira, .
. , : , , , : , , , . , .
. , . , , , .
, — « , ». , . , , . , , . , , — , . , .
. HR, . . — , , . , - ? , , -, , , ? , - :
— ! , - ? ?
- Ya.
— .
15- Jira, , , . , , , , . , , - Slack, , , , Slack.
, , . , 30 . ? , . , , , . -. , . , .
: , , , , . - QA: , , email Slack, , . , , , .
— . . , -, , . .— , . , , . , , : , .
Slack! Slack — , . , , . « » , Slack. , « ». , , , , . - Slack, , , - .
, , .
-. , . — , , , . , . , - ?
— .— ! , . , . Slack, , . , Slack, , , , , , , .
— -. - , , .
. , IT-, , , , . . , , - - ?— . . - , , , -, . - , .
: - , . «, ». . , .
, . , , . ThoughtWorks, , , , . . , ThoughtWorks , .
, , , , , . « , ». , , - , — , . , - , . «»: , , , . . , , , .
, . -, . : «, , agile-, 1,3 , «», 30% ». , . : « , , , , ».
— , ?— : ? ? , . , - — . ? - — , , .
, , . , , , . , -, QA , , , , . , . , , , — , , , .
— , , , - ?— . , : , , -, , , , .
— , , , . , : « », , , .
— «architecture is abstract until operationalized», . , , ?- tentu saja , , meme wrangler.
, DevOps-. , , . DevOps , , — , , .
, — , « » . . , . , : , , . , , ?
— .— , , ! , , . — , , , , , . , , , , : Docker -, - . , , .
, , — , , .
— . !Heisenbug , 17-18 , «Building evolutionary architectures: Fitness functions». , : , — .