Lingkungan yang tidak tercela: tidak seorang pun boleh menulis kode kualitas

Di RIT ++, Nikita Sobolevn ( sobolevn ) menyampaikan, sebagaimana ia sendiri menyebutnya, sebuah khotbah tentang kualitas kode dan proses di perusahaan. Sangat sensitif, silakan tuangkan teh chamomile untuk diri sendiri, tetapi kami tidak menawarkan untuk menjauh dari layar. Anda dapat tidak setuju dengan salah satu tesis ini, bersikeras bahwa berbicara tentang acara TV adalah kunci untuk suasana yang sehat dalam tim, dan mengklaim bahwa Anda tidak memerlukan kerangka ketat linter dan CI untuk menulis kode yang baik. Tetapi jika Anda pernah menyalahkan orang lain atas kegagalan di tempat kerja, Anda harus membaca atau menonton cerita Nikita.

Pernahkah Anda bekerja di pekerjaan yang buruk?

Saya bekerja untuk waktu yang lama. Perusahaan saya sangat buruk. Semuanya sangat buruk, tanpa hasil, semuanya luar biasa. Kami memiliki proses yang menjijikkan, membenci pelanggan, dan pengembang yang tidak kompeten. Tidak ada yang bisa dilakukan tentang itu. Ketika semuanya begitu buruk, Anda tidak tahu harus mengambil apa, harus mulai dari mana. Anda merasa seperti roda gigi yang menyedihkan yang tidak dapat memengaruhi apa pun.



Ketika saya mengatakan semuanya buruk, maksud saya kami memiliki:

• kode buruk - tidak ada yang memikirkan kualitas kode, bahkan tidak ada yang bisa merumuskan kualitas kode itu.
• proses yang buruk.
• kami tidak bisa berkomunikasi secara normal,
• kami tidak melakukan apa yang diinginkan klien.

Ya, itu adalah pengembangan yang dilakukan oleh pihak luar, tapi itu tidak membuatnya buruk. Orang-orang membuatnya seperti itu.

"Orang-orang melakukan pekerjaan yang buruk, itu adalah orang-orang yang harus disalahkan atas fakta bahwa prosesnya buruk, kode itu buruk dan pelanggannya buruk" - pemikiran ini menyiksaku selama bertahun-tahun. Orang harus disalahkan karena fakta bahwa saya tidak menikmati pekerjaan saya.



Saya menghubungkan semua kemungkinan dosa kepada orang-orang dan berpikir bahwa itu adalah sumber utama masalah. Saya berharap bahwa suatu hari nanti mereka akan berubah, atau orang lain akan muncul, dan semuanya akan baik-baik saja.

Dalam semua keseriusan, saya memikirkan fakta bahwa perusahaan lain mempekerjakan orang yang berbeda secara fundamental yang berbeda dalam kualitas dan profesionalisme internal mereka, dan bahwa orang-orang ini berasal dari tes yang berbeda.

Tetapi pada titik tertentu saya mulai menebak bahwa mungkin orang tidak bisa disalahkan - mungkin kesalahan pada tingkat yang berbeda, di suatu tempat ada yang salah jauh sebelumnya. Dan kemudian jalan menuju koreksi muncul. Hanya dengan begitu Anda dapat menyelamatkan diri sebagai pengembang.

Saya menyadari bahwa kita membutuhkan revolusi, bahwa segala sesuatu perlu diubah: cara saya bekerja, bagaimana perasaan saya, bahwa pergi bekerja tidak menjadi ujian bagi saya. Saya ingin bekerja di tempat yang baik.

Hanya ada satu masalah - itu adalah perusahaan saya .



Saya orang yang memulai revolusi ini.

Saya menyadari bahwa Anda perlu mengubah segalanya untuk dapat menikmati bisnis favorit Anda lagi. Saya suka pemrograman, saya siap melakukannya 12 jam sehari dan menyebutnya istirahat dan pekerjaan saya.

Karena itu, saya merasakan semua kegagalan dengan sangat menyakitkan. Tidak hanya mereka terhubung dengan bisnis favorit saya, mereka juga terhubung dengan keuangan saya, dengan rasa diri saya dan hubungan saya dengan orang lain dan sangat tercermin dalam seluruh hidup saya. Ketika sesuatu tidak berhasil bagi saya, saya tidak bisa beristirahat, saya tidak bisa memikirkan hal lain.

Saya memutuskan bahwa hal terpenting yang dapat saya lakukan sekarang untuk meningkatkan kehidupan saya adalah melakukan pekerjaan dengan baik. Untuk ini, saya perlu memikirkan kembali semua kekacauan yang kami miliki dan menertibkannya.



Tetapi ketika Anda melihat ke dalam kekacauan, Anda tidak melihat pola - tidak ada yang menunjukkan bagaimana seharusnya.

Menciptakan keteraturan dari kekacauan adalah tindakan penciptaan yang sulit.

Anda harus mulai dari awal untuk memahami ketika semuanya berubah menjadi kekacauan. Anda perlu menentukan tatanan baru dan menjelaskan kepada diri sendiri apa yang harus dilakukan. Ini adalah kata-kata yang indah: "Ayo lakukan semuanya dengan baik!". Tetapi Anda datang untuk bekerja dan Anda tidak benar-benar memahami apa yang harus dilakukan untuk mengubah segalanya, tidak ada ide.

Pendidikan yang Anda dapatkan dan buku-buku yang Anda baca tidak membantu, karena semua yang Anda lakukan sebelumnya Anda pelajari dari buku-buku ini dan dari pendidikan ini.

Pernyataan masalah

Lalu saya berpikir - apa masalah terbesar? Di mana titik paling menyakitkan yang tidak memungkinkan untuk hidup dan bekerja? Saya menyadari bahwa ini adalah pernyataan masalah . Bagi saya, pengaturan tugas selalu sangat opsional.

Saya pikir banyak dari Anda telah melihat tugas dari satu judul "Perbaiki bug pada prod." Kami memiliki banyak ini, saya menulisnya dalam satu baris, dan kemudian orang melakukan kesalahan dan mencoba memperbaikinya. Saya berpikir: “Mengapa mereka tidak berpikir dengan kepala mereka sendiri? Apa yang sedang kamu lakukan? Anda perlu memperbaiki bug sederhana, dan tidak melakukan semua omong kosong ini. "

Lalu saya tidak menyadari bahwa saya benar-benar mengatur tugas dengan buruk. Tetapi pada titik tertentu saya masih menyadari bahwa saya perlu melakukan ini dengan cara yang sama sekali berbeda, dan saya mengembangkan beberapa prinsip.



Tugas harus singkat . Bukan dalam hal menjelaskan cara "memperbaiki bug pada prod," tetapi singkat. Pendek, tugas-tugas kecil nyaman dilakukan. Mereka dapat dimengerti oleh siapa saja: pemula, rata-rata, pengembang berpengalaman. Setiap orang dapat memahami tugas semacam itu dan melakukannya, misalnya, dalam setengah hari kerja. Anda bisa mulai dengan ini.

Tugas harus dipesan . Ketika mereka menetapkan tugas, mereka sering tidak berpikir dalam urutan apa mereka harus dilakukan. Tetapi tugas dapat memblokir satu sama lain, memparalelkan, atau menambah kompleksitas tambahan untuk tugas lain jika diselesaikan sebelumnya, dll.

Sangat sedikit yang dikatakan tentang urutan tugas: mereka dibawa ke Jira atau Trello, dan kemudian mereka dibawa dari sana. Tetapi hanya sedikit yang berpikir, dan dalam urutan apa, mengapa dan mengapa urutannya begini saja.

Semua tugas harus individual . Apa artinya ini? Tugas adalah entitas yang ada dalam suatu proyek dan selalu menjadi milik seseorang. Kadang-kadang tepat dalam uraian masalah Anda dapat menemukan: "Sergey, Masha, tolong perbaiki ini. Anda tahu bagaimana melakukannya. " Anda tidak dapat melakukan ini, Anda harus memberikan seluruh konteks sehingga tugas ini menjadi individual dalam dirinya sendiri, sehingga siapa pun yang membacanya dapat memenuhinya. Sehingga tidak ada ilmu yang tersebar bertebaran tentang proyek, dan tidak ada makna tersembunyi dalam kerangka tugas ini.

Ketika tugas menjadi individual, pendek dan teratur, orang-orang mulai melakukannya seperti yang saya inginkan.

Hanya mengubah cara komunikasi, saya memastikan bahwa orang-orang yang telah melakukan omong kosong ini mulai melakukan apa yang saya inginkan - bukankah itu ajaib? Apakah ini bukan bukti bahwa banyak yang mudah diubah. Dan saya mulai mempelajari lebih jauh masalah ini.

Kami sering gagal pelanggan, tidak melakukan apa yang akan menguntungkannya. Saya pikir jika pengembang mulai memahami tugas kami dan melakukannya sebagaimana mestinya, dapatkah mereka memahami apa yang benar-benar diinginkan dan dilakukan pelanggan seperti yang diinginkan pelanggan?

Saya mencoba menggabungkan ini menjadi semacam sosok berwajah dua, yang di satu sisi berpikir seperti pengembang, di sisi lain - seperti klien.



Ini bukan tugas baru. Secara umum, pendekatan ini disebut Desain Domain-Driven dan telah berhasil diterapkan selama bertahun-tahun. Saya memutuskan untuk mengambil yang terbaik - cara komunikasi, alat, teknologi, dan mencoba membuat pengembang memahami apa yang perlu dilakukan untuk memuaskan keinginan klien.

Tugas itu sangat sulit, dan saya masih mengerjakan solusinya. Tetapi saya mengembangkan formula sederhana untuk diri saya sendiri.

Persyaratan Semuanya dimulai dengan mereka, pelanggan menyatakan keinginannya kepada kami, para pengembang, dalam bentuk persyaratan. Klien secara kondisional mengatakan: "Saya meminta halaman login berfungsi." Kesadaran mereka dimulai, menulis dalam bentuk tabel, daftar, grafik, dll. Persyaratan tetap bersama Anda sebagai bagian terpenting dari proyek Anda. Inilah yang Anda lakukan di level tertinggi.

Tetapi persyaratan ini tidak dapat dioperasikan untuk pengembang, mereka terlalu tinggi dan mentah. Untuk memulai, programmer membutuhkan dokumentasi.

Dokumentasi dan persyaratan adalah saudara kembar, ini adalah kesatuan ganda. Persyaratan - inilah yang perlu Anda lakukan, dan dokumentasi - cara melakukannya.

Ketika saya menyadari bahwa, pada prinsipnya, dokumentasi dapat dihasilkan dari persyaratan, ini menjadi bagian penting dari proses bisnis kami. Kami belajar cara merekam persyaratan dalam format khusus dan menghasilkan dokumentasi.

Tes . Langkah logis berikutnya adalah memverifikasi bahwa itu berfungsi. Kami mulai menguji persyaratan kami untuk memastikan bahwa kami benar-benar melakukan apa yang dibutuhkan.

Hal yang paling menarik adalah bahwa saya tidak menciptakan apa pun - saya tidak menulis satu baris kode pun agar ini berfungsi. Saya baru saja mengambil teknologi yang ada dan menerima: persyaratan, itu adalah dokumentasi, itu adalah tes.

Langkah logis berikutnya adalah menarik kode pada semuanya, karena kode itu adalah apa yang secara langsung kita terlibat.

Kode - demi yang semuanya sebenarnya dimulai. Agar pelanggan dan pengembang dapat terhubung, tampaknya, Anda harus masuk ke salah satu dari mereka di kepala dan memastikan bahwa mereka saling memahami. Tetapi untuk masuk ke kepala, Anda dapat mengambil alat yang sama dan menghubungkannya sehingga pengembang mulai memahami apa yang terjadi. Di sini Anda dapat membaca bagaimana saya melakukannya dalam praktik.

Segera setelah kami menggabungkan (Kode adalah satu!) Pengembang dan pelanggan dengan bantuan jalinan entitas yang berbeda, kami mencapai sangat penting: pengembang kami akhirnya mulai melakukan apa yang dibutuhkan bisnis . Mereka berhenti memperkenalkan sesuatu seperti itu, karena mereka melihat persyaratan dan memahaminya, mengerti apa yang perlu dilakukan.

Untuk memastikan bahwa kami mengeksekusi, kami memiliki tes yang ditulis dalam bentuk persyaratan, dan persyaratan ini cukup jelas untuk diimplementasikan dalam bahasa yang dapat dimengerti dalam kode, dan menulis kode yang baik sesuai dengan persyaratan ini.

Komunikasi

Saya sudah menyebutkan "komunikasi" berkali-kali. Saya suka berbicara dengan teman dan keluarga saya, tetapi tidak di tempat kerja. Di tempat kerja, saya harus berkomunikasi dengan orang-orang - saya tidak memilih mereka berdasarkan ini. Sangat sering, komunikasi di tempat kerja tidak membantu .

Kita semua berkomunikasi dengan rekan kerja tentang topik yang tidak bekerja (mendiskusikan acara TV, dll.), Karena kita adalah orang-orang. Untungnya, cacat ini bisa diperbaiki. Untuk memahami bagaimana komunikasi yang sangat merusak bagi kami, Anda dapat melihat berbagai contoh.

Pertama-tama, orang saling mengalihkan perhatian dan merobek dari keadaan mengalir. Pria itu baru saja datang dan mengatakan sesuatu - apa yang harus saya lakukan dengan ini sekarang? Mengapa dia mengatakan kepada saya bahwa dia ingin menyampaikan ini?

Atau aksi unjuk rasa. Aku benci mereka, aku selalu merasa seperti orang idiot ketika duduk di pertemuan. Semua orang tampaknya memahami sesuatu, mereka memiliki wajah yang cerdas, dan saya kehilangan satu dan berpikir kapan itu akan berakhir. Saya ingin pergi karena semua yang kita diskusikan dapat didiskusikan lebih cepat.

Demonstrasi mencuri banyak waktu dan tidak berguna.

Ada beberapa masalah penting lainnya, misalnya, orang-orang mulai bersumpah pada rapat umum ini. Bayangkan Anda ditempatkan di sebuah ruangan kecil yang penuh dengan orang-orang yang tidak ingin Anda lihat. Anda ingin pergi, dan orang-orang ini membuat Anda membuat beberapa keputusan serius. Secara wajar, pelecehan dimulai - agresi pasif pertama, kemudian penghinaan yang jelas. Sayangnya, tidak ada yang bisa dilakukan dengan ini, karena manusia adalah makhluk yang saling bertentangan. Tidak peduli bagaimana Anda mencoba memoderasi situasi, tidak peduli bagaimana Anda menjemput orang baik yang tidak bersumpah - orang akan bersumpah, dan ini normal .

Ada masalah lain dalam bisnis kami - orang menghilang . Front-end atau devops Anda dapat dengan mudah berhenti merespons suatu hari. Terutama orang yang bekerja dari jarak jauh cukup mematikan telepon dan mengakhiri percakapan secara sepihak.

Ini dan beberapa masalah lain tampaknya tidak terpecahkan. Anda tidak dapat mengajar semua orang untuk menjadi baik, tidak konflik, bertanggung jawab - itu tidak mungkin.

Tapi Anda bisa hidup dengannya. Menjadi seorang realis, Anda dapat memahami bahwa hidup adalah seperti ini: orang-orang akan menghilang, mengutuk, tidak ingin berkomunikasi dengan Anda - ini normal. Saya memecahkan masalah ini sebagai berikut - komunikasi terstruktur.



Untuk menyusun komunikasi, cukup untuk mengambil dua langkah:

• Pergi ke Telegram sekarang dan hapus. Setelah Anda menghapus semua halaman Anda di jejaring sosial, orang tidak akan bisa menulis kepada Anda.
• Setelah itu, mulailah satu saluran dan katakan bahwa Anda hanya dapat berkomunikasi dengan cara ini.

Ketika Anda berada dalam posisi untuk mendikte keinginan Anda kepada orang lain, Anda mengajar mereka untuk berkomunikasi. Anda menunjukkan bahwa komunikasi harus terstruktur dan bermanfaat bagi semua peserta .

Kami memilih komunikasi melalui GitLab. Jika Anda memiliki pertanyaan, tanyakan di GitLab. Jika Anda ingin mengajukan beberapa pertanyaan aneh, tanyakan di sana. Jika Anda mengerti bahwa tidak ada tempat di mana Anda dapat mengajukan pertanyaan seperti itu, mungkin itu tidak perlu ditanyakan.

Kami hanya berkomunikasi tentang topik yang sedang dikerjakan . Jika seseorang ingin mendiskusikan Game of Thrones - maaf, kami sedang bekerja, dan diskusikan Game of Thrones dengan teman-teman Anda. Jika Anda ingin membahas teknologi baru, membuat tiket, mari kita bahas: mungkin itu akan menguntungkan proyek. Tapi "Game of Thrones" tentu tidak akan membawa manfaat bagi proyek.

Komunikasi terstruktur membuat orang yang berbeda sama. GitLab bahkan memiliki avatar yang hampir sama - yang satu memiliki huruf K, yang lain C, dan saya tidak tahu siapa orang-orang ini. Saya tidak peduli mereka itu apa, yang utama mereka berkomunikasi dalam struktur.

Setelah kami menyusun komunikasi, menjalin kerja sama dengan pelanggan, belajar bagaimana menulis tiket yang dapat dimengerti, saatnya untuk membahas kode.

Kode

Dan di sini masalah baru terletak pada menunggu - orang tidak tahu cara menulis kode, dan ini normal . Saya dulu berpikir bahwa orang lain menulis kode yang buruk, dan saya baik. Tetapi kemudian saya menyadari bahwa saya sendiri sedang menulis kode yang buruk. Dan setelah beberapa saat saya sadar bahwa semua orang menulis kode yang buruk , dan itu tidak masalah.

Orang tidak dibuat untuk menulis kode. Pemrograman adalah lingkungan yang agresif di mana seseorang tidak memiliki kecenderungan. Kode ini memiliki banyak kompleksitas: arsitektur dan sejumlah besar informasi. Dalam sistem terdistribusi, secara umum mengerikan. Sulit bagi seseorang untuk mengatasi arus informasi. Dan ini normal.

Tetapi jika demikian, Anda dapat melakukan sesuatu dengan ini dan belajar bagaimana bekerja dalam kondisi ini.



Agar dapat bekerja dengan ini, Anda memerlukan ketelitian - CI dan tes yang seketat mungkin pada apa yang Anda lakukan. Itu harus menjadi Penghakiman Terakhir - alat yang menjawab pertanyaan, kode yang baik atau buruk. Hanya dengan melihatnya, mata CI yang melihat semua akan tahu apakah pekerjaan Anda akan dikuasai atau akan tetap di suatu tempat di atas panggung.

CI seperti itu, tentu saja, tidak bisa dihindari. Segera setelah seseorang mendapatkan hak eksklusif untuk berkomitmen untuk menguasai, semua upaya untuk membangun proses berantakan, karena seseorang ini mulai melakukan segala macam omong kosong.

CI yang tak terhindarkan dan teliti menyediakan beberapa fitur yang lebih keren. Ini adalah peluang untuk dikembangkan, karena sekarang ada bilah dasar tempat Anda dapat membangun: setiap potongan kode selanjutnya lebih baik daripada yang sebelumnya. Setiap potongan kode selanjutnya menambah nilai proyek dan meningkatkan CI. Setiap potongan kode selanjutnya adalah langkah menuju pengembangan.

Setelah fondasi siap, Anda dapat melanjutkan.

Tetapi orang-orang masih akan membuat kesalahan, karena tidak ada CI, bahkan yang dikonfigurasi dengan cara paling keras, dapat menangkap semua kesalahan . Dan mereka akan muncul di tempat-tempat yang tidak akan dipikirkan orang lain.

Apa yang bisa dilakukan tentang ini? Anda dapat kembali ke taktik yang biasa dan mengatakan: "Anda membuat kesalahan, perbaiki. Anda menulis kode yang buruk - belajarlah menulis kode. " Ini adalah jalan yang buruk yang tidak mengarah pada pembangunan.

Untuk benar-benar menulis dengan benar dan mengembangkan produk Anda, Anda memerlukan pendekatan dan mentalitas baru.

Lingkungan yang tidak bersalah

Saya menyebut pendekatan ini sebagai lingkungan yang tidak bercela - ini berarti bahwa saya tidak pernah menyalahkan orang atas apa pun . Jika bug masuk ke proyek Anda, ini adalah masalah proyek. Bug ini harus diperbaiki agar tidak pernah terjadi lagi. Jika ini adalah bug dalam kode, Anda harus menulis tes regresi. Jika ini adalah bug dalam infrastruktur proyek, Anda perlu menulis alat yang akan mencegah bug ini.



Ketika Anda mulai tidak hanya memperbaiki bug dan berharap bahwa semuanya tidak akan berantakan pada produksi, tetapi memperbaikinya di tingkat sistem, Anda mulai membuat dan menciptakan - menciptakan alat baru, mengembangkan pendekatan baru dan pola arsitektur. Anda mulai berpikir dengan kepala Anda dan memastikan bahwa bug tidak muncul kembali.

Pekerjaan terus-menerus pada kesalahan membawa pengembang ke tingkat yang berbeda secara mendasar. Anda mulai menciptakan alat untuk pengembang, menerapkannya, mempromosikan, dll.

Ciptaan yang saya bicarakan sekarang sangat besar. Ketika Anda mencoba menggunakan pendekatan ini, Anda akan menemukan fakta bahwa semua yang ada sekarang, terutama untuk beberapa bahasa pemrograman, tidak cukup ketat.

Suatu kali saya bertanya-tanya apakah saya bisa menulis linter yang akan membuat semua orang menulis kode yang sama. Saya sangat ketat dan memasukkan semua aturan yang mungkin bisa saya buat. Tetapi orang masih menulis kode yang berbeda . Ini sangat mirip, tetapi saya selalu dapat memahami bahwa kode ini ditulis oleh orang yang berbeda. Jadi, linter saya masih belum cukup ketat - tunggu rilis baru.

Pendekatannya tetap, kami menunggu mesin untuk merespons, programnya dilakukan dengan baik atau tidak. Dan itu berhasil, karena alat seperti itu membantu dalam pekerjaan.

Tetapi kita tidak boleh lupa bahwa orang adalah peserta yang diperlukan dalam proses tersebut . Tidak peduli apa pun pengaturan teknis yang Anda buat, jika penampilan orang tersebut tidak melalui kode Anda, masih ada sesuatu yang membuat rambut Anda berdiri, meskipun CI lulus.

Di satu sisi, kami telah menangani masalah kami dan kami telah menolak kode yang sangat buruk. Tetapi, bagaimanapun, kita tidak sepenuhnya terisolasi darinya. Diperlukan proses peninjauan kode . Jika kode tidak lulus tinjauan kode, maka semua yang Anda lakukan sebelumnya tidak ada gunanya.

Setiap langkah selanjutnya hanya masuk akal jika ada dasar untuk yang sebelumnya.

, , , - CI . , , . - — .



— .

— . . : « , ?!» , , .

: , . , , , — : . , .

- — . , , , : « ? . , - ». — , - , - . .

— , — .

— , . , .

, , . . . , .

, , , , . , , , .

, , , , , , , .

— . , — , , , .

, . , , . open source , .

. , , , — .

. , , , , . , — , — . , .

. , . : — , — . .

. , , — ? , , , . .

. , , — , . - , , . , . open source.

. , , , , , . , , , .. !

. : . - , . , , . . , , . .

. , , - , . -, .

. , . - — , . , .

, . , . , .

Agile , . QualityConf , ++, — . , , .