Benar, selama ini, ada sesuatu yang tidak berubah. Yaitu, kode dikirim ke milis (atau beberapa daftar), dan di sana ia ditinjau dan didiskusikan sampai dianggap siap untuk dimasukkan ke dalam kernel Linux. Tetapi terlepas dari kenyataan bahwa proses bekerja dengan kode ini telah digunakan dengan sukses selama bertahun-tahun, hal itu terus-menerus dikritik. Misalnya, ini
Artikel terbaru dari Microsoft Sara Novotny membuat banyak gangguan di Internet. Artikel tersebut mengatakan bahwa teknik kolaborasi kode yang digunakan dalam mengembangkan kernel Linux sudah ketinggalan zaman. Dikatakan bahwa jika komunitas pengembang Linux ingin menarik profesional muda ke jajarannya, metode ini akan baik untuk diganti dengan sesuatu yang lebih modern. Dalam perdebatan seputar ide-ide ini, pembela dan penentang mereka bentrok.
Saya percaya bahwa posisi saya memungkinkan saya untuk memberikan beberapa ide tentang pengembangan kernel Linux. Selama hampir sepuluh tahun sekarang, saya telah menulis kode untuk Linux dan proyek lain yang diatur dengan cara yang sama. Ketika saya masih di Red Hat, saya berkontribusi pada kode infrastruktur kernel x86, kode hypervisor KVM dan emulator QEMU, dan kode Xen Hypervisor. Saya berpartisipasi dalam pengembangan proyek lain juga. Saya tidak melakukan banyak Linux selama sekitar 7 tahun, tetapi hanya karena saya mencurahkan waktu saya untuk mengerjakan kerangka C ++ Seastar dan pada database ScyllaDB... Kedua proyek ini dikembangkan menggunakan metodologi yang sangat mirip dengan yang digunakan dalam pengembangan Linux. Sekarang saya bekerja sebagai insinyur utama di Datadog, sebuah perusahaan di mana proses pengembangan perangkat lunak hampir berlawanan dengan yang digunakan di Linux. Ini lebih mirip dengan bagaimana pengembangan diatur di perusahaan web lain.
Jadi di sisi mana saya berada? Izinkan saya segera menjelaskan bahwa saya tidak menyukai proses pengembangan Linux. Saya cukup yakin ini bukan hanya penghalang bagi pengembang baru, tetapi juga penghalang produktivitas tinggi pada kode Anda (dan ini bukan tentang email). Inilah sumber perasaan negatif yang dialami developer. Dan saya tidak akan mengikuti model itu untuk proyek apa pun di mana saya memiliki hak eksklusif untuk membuat keputusan tentang bagaimana pekerjaan akan diatur.
Tetapi pada saat yang sama, nampaknya banyak kritikus terhadap proses pengembangan Linux percaya bahwa fakta bahwa para pembelanya memperjuangkannya dengan begitu sengit hanyalah konsekuensi dari fakta bahwa komunitas Linux penuh dengan orang-orang tua yang memiliki cengkeraman pada tradisi dan tradisi. tidak mau berubah dengan dalih apapun. Ini tidak terjadi (walaupun saya yakin ada orang-orang seperti itu di komunitas Linux). Proses pengembangan kernel Linux membawa beberapa manfaat unik dan penting bagi penggunanya. Jika Anda menerapkan prinsip yang sama pada proyek lain, proyek semacam itu hanya akan mendapat manfaat darinya.
Alat lain apa pun, selain email, menentukan mereka yang menggunakannya dengan skema kerja yang agak kaku, sehingga membuat Linux tidak mendapatkan keuntungan seperti itu. Dan milis hanyalah mekanisme nyata yang menarik perhatian debat. Kami membutuhkan alat yang dapat menurunkan hambatan masuk bagi pengembang Linux. Alat yang dapat memperbaiki kekurangan dalam proses pengembangan. Yang memungkinkan organisasi yang berbeda untuk mengenali kekuatan dari organisasi pengembangan Linux. Alat seperti ini benar-benar dapat membuat perbedaan untuk seluruh industri pengembangan perangkat lunak.
Ada banyak dari mekanisme ini yang sangat bermanfaat. Agar tidak memperpanjang percakapan kita, saya akan fokus pada salah satunya, yang menurut saya paling penting. Saya akan melakukan yang terbaik untuk mengungkapkan esensinya dan berbicara tentang mengapa, terlepas dari kekuatannya, hal itu menyebabkan begitu banyak emosi negatif pada pengembang. Saya juga akan memberi tahu Anda mengapa, di satu sisi, dapat bermanfaat bagi proyek lain, dan di sisi lain, mengapa ini sangat penting untuk Linux.
Pesan komit dan tambalan
Dalam dunia pengembangan kernel Linux, terdapat aturan: kode yang dimaksudkan untuk dimasukkan ke dalam kernel harus dipecah menjadi beberapa patch terpisah. Masing-masing harus menyelesaikan satu dan hanya satu masalah. Pesan komit yang berarti harus disiapkan untuk setiap tambalan. Seringkali terjadi bahwa pesan seperti itu lebih panjang dari kode yang mereka gambarkan.
Ini adalah contoh utama dari apa yang umumnya kurang dalam proyek lain. Sebagian besar pesan komit yang pernah saya lihat dalam proyek modern di GitHub terlihat seperti "perubahan per 25 Agustus", atau sedikit (tetapi hanya sedikit) lebih baik, seperti "implementasi fungsi X". Jika ada yang perlu melihat kode seperti ini di masa mendatang, tidak akan mudah bagi mereka untuk mengetahui mengapa perubahan tersebut dilakukan pada kode. Beberapa bug yang diperbaiki komit ini mungkin tidak kentara. Jika Anda tidak tahu bagaimana tepatnya kesalahan tersebut diperbaiki, mereka dapat dengan mudah kembali ke proyek. Saat saya membaca pesan komit yang singkat dan tidak berarti, saya mungkin tidak menyadari keadaan di mana bug ditemukan.
Berikut contoh kecilnya. Lihat komit ke kernel Linuxdibuat oleh teman baik saya Johann Weiner. Mudah bagi saya untuk membayangkan bagaimana, di proyek lain, pesan ke commit serupa akan terlihat seperti "menghapus peringatan". Dan ketika saya membaca pesan dari komit yang dibahas di sini, saya belajar tentang mengapa mungkin, tanpa membahayakan proyek, untuk menyingkirkan peringatan ini, tentang keadaan di mana ini, memang, tidak akan mengarah pada hal buruk, dan tentang apa aturan harus diikuti jika suatu saat diputuskan untuk mengubah kode ini.
Saya yakin ada orang di banyak organisasi yang melakukan ini. Tetapi ketika mengerjakan kernel Linux, setiap orang yang terlibat dalam bisnis ini harus melakukan ini. Oleh karena itu, saya cukup yakin bahwa dengan membaca pesan komit, saya akan memahami segala sesuatu yang perlu dipahami tentang perubahan kode yang sesuai. Jika kita berbicara tentang kesalahan, maka saya akan belajar tentang di sistem mana kesalahan itu terwujud, dalam kondisi apa itu terjadi, mengapa itu tidak mempengaruhi sistem lain dengan cara apa pun, dan apa yang harus diperhatikan agar kesalahan ini tidak kembali ke proyek.
Pekerjaan semacam ini sangat diinginkan di organisasi mana pun. Hal ini mempermudah orang lain (dan pengembang itu sendiri, ketika dia beralih ke kodenya setelah beberapa saat) untuk memahami alasan membuat perubahan pada kode, untuk memahami mengapa kode tersebut berfungsi seperti itu. Hal ini memudahkan programmer baru untuk mengetahui proyek tersebut. Ini memecahkan masalah mengembalikan kesalahan lama, mengurangi bahaya bahwa beberapa kode, yang tampaknya tidak terkait dengan yang dipermasalahkan, dapat merusak sesuatu di dalamnya.
Di proyek lain, hal ini "sangat diinginkan". Tetapi di Linux itu mutlak diperlukan karena dua alasan:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
Backport biasanya tidak menjadi masalah bagi perusahaan online modern yang tidak perlu mempertahankan beberapa lini produk paralel. Mereka menciptakan sesuatu, menyebarkannya kepada pengguna, dan di situlah akhirnya. Tapi ketika backport ikut bermain, segalanya menjadi lebih rumit. Pengembang (mungkin bukan pembuat program) mungkin perlu memutuskan bagaimana sedikit mengadaptasi kode ke basis kode lama yang sedikit berbeda dari yang modern. Dan solusi yang meminimalkan risiko sering kali (dan sering kali) adalah salah satu yang terdiri dari membuat tambalan hanya untuk menerapkan bagian tertentu dari sekumpulan besar perubahan. Bayangkan komit 2000 baris yang berisi 5 baris kode untuk memperbaiki bug. Selain itu, bayangkan bahwa kesalahan ini terjadi setelah pemfaktoran ulang API. Apa yang akan Anda pilih:menyiapkan backport berdasarkan sekumpulan besar perubahan, atau berdasarkan patch yang terdokumentasi dengan baik, terdokumentasi dengan baik, dan rusak? Sebagai orang yang telah membuat backport yang tak terhitung jumlahnya, saya sudah tahu bagaimana saya akan menjawab pertanyaan seperti itu.
Nah, dengan atau tanpa backport, proyek harus membayar mahal untuk mendapatkan keuntungan dari pengorganisasian seperti ini ketika ada penekanan besar pada pendokumentasian perubahan dengan hati-hati. Sekarang programmer perlu menjaga tidak hanya kodenya, tetapi juga bagaimana mengaturnya kembali dan membuatnya sejalan dengan aturan kerja pada proyek.
Beberapa pemfaktoran ulang kode ini sederhana. Katakanlah kita berbicara tentang menggunakan perintah git add -p dan memilih apa yang akan menjadi kumpulan perubahan. Hal-hal menjadi sedikit lebih rumit ketika seorang programmer dihadapkan pada dependensi melingkar antara fragmen kode individual. Bayangkan sebuah fungsi yang mengembalikan sebuah objek dari tipe yang akan ditambahkan ke proyek setelah menambahkan fungsi ini padanya. Untuk mengatasi situasi ini, Anda harus menggunakan kode, yang, akibatnya, tidak akan masuk ke proyek yang sudah selesai, tetapi hanya akan memainkan peran sebagai solusi sementara.
Semua ini menambah sakit kepala bagi programmer, tetapi seseorang tidak dapat mengatakan bahwa tugas-tugas seperti itu sama sekali tidak dapat diselesaikan. Misalkan Anda telah, dengan presisi pembedahan, membagi semua yang Anda lakukan menjadi fragmen yang mudah dan nyaman digunakan. Masalah sebenarnya dimulai setelah programmer lain mulai melihat kode Anda. Peninjauan kode di organisasi mana pun sangat penting. Para ahli membaca kode orang lain dan menyarankan (atau menuntut) perubahan padanya.
Misalkan seorang programmer diminta untuk menambahkan parameter baru ke metode tertentu yang ada di patch pertama dari satu set perbaikan. Dan mari kita asumsikan juga bahwa metode ini digunakan di semua patch berikutnya.
Ini berarti programmer harus kembali ke patch pertama dan menambahkan parameter baru ke metode tersebut. Setelah itu, tambalan berikutnya tidak dapat lagi diterapkan. Oleh karena itu, programmer tidak hanya perlu memikirkan mengapa ini terjadi, tetapi juga perlu memperbaiki semua kesalahan secara manual. Jika semua tambalan individu sebelumnya telah diuji, maka sekarang hasil dari pengujian ini sudah kedaluwarsa dan tambalan harus diuji lagi.
Menata ulang pekerjaan adalah masalah kecil. Tapi mengerjakan ulang apa yang telah dilakukan adalah masalah yang jauh lebih serius.
Inilah yang ingin saya sampaikan kepada komunitas pengembang Linux dan yang terkait dengan komunitas ini: semua ini, tentu saja, cukup bisa dilakukan. Tetapi jika ini bukan penghalang masuk bagi para profesional muda, maka saya bahkan tidak tahu apa yang bisa disebut sebagai "penghalang masuk". Kebutuhan untuk menghabiskan waktu, tenaga, saraf, dan sumber daya komputer Anda untuk mengatur ulang, menulis ulang, mengerjakan ulang apa yang telah dilakukan jelas bukan yang diperjuangkan oleh programmer. Dalam hal ini, saya menemukan satu ide yang secara berkala muncul dalam bentuk ini: "... tetapi programmer yang baik tidak akan mengalami masalah dengan ini." Ini juga disuarakan seperti ini: "tetapi ini mengajarkan pemrogram gaya berpikir tertentu, persis seperti yang harus dimiliki oleh pemrogram yang baik." Penalaran semacam ini tampaknya tidak tulus bagi saya dan tidak membawa manfaat apa pun. Memang:Saya baru saja mencantumkan semua kekuatan metode ini, tetapi saya juga menemukan bahwa semua pemfaktoran ulang kode ini adalah tugas yang rumit dan membosankan. Ini bisa dibandingkan dengan membersihkan apartemen. Katakanlah seseorang berkata bahwa akan sangat baik jika rumah dijaga kebersihannya (saya setuju dengan itu). Orang yang sama cukup mampu menyedot debu lantai (saya bisa), tetapi sering kali tidak. Alasannya sederhana: dia memiliki hal lain yang lebih penting untuk dilakukan. Misalnya, itulah mengapa saya sangat senang memiliki penyedot debu robot Roomba. Hal ini memungkinkan saya untuk menikmati kebersihan dan pada saat yang sama tidak terlibat dalam menata diri sendiri. Yang membawa saya ke pemikiran saya selanjutnya, diarahkan pada orang-orang di luar dunia Linux.bahwa semua pemfaktoran ulang kode ini adalah tugas yang rumit dan membosankan. Ini bisa dibandingkan dengan membersihkan apartemen. Katakanlah seseorang berkata bahwa akan sangat baik jika rumah dijaga kebersihannya (saya setuju dengan itu). Orang yang sama cukup mampu menyedot debu lantai (saya bisa), tetapi sering kali tidak. Alasannya sederhana: dia memiliki hal lain yang lebih penting untuk dilakukan. Misalnya, itulah mengapa saya sangat senang memiliki penyedot debu robot Roomba. Hal ini memungkinkan saya untuk menikmati kebersihan dan pada saat yang sama tidak terlibat dalam menata diri sendiri. Yang membawa saya ke pemikiran saya selanjutnya, diarahkan pada orang-orang di luar dunia Linux.bahwa semua pemfaktoran ulang kode ini adalah tugas yang rumit dan membosankan. Ini bisa dibandingkan dengan membersihkan apartemen. Katakanlah seseorang berkata bahwa akan sangat baik jika rumah dijaga kebersihannya (saya setuju dengan itu). Orang yang sama cukup mampu menyedot debu lantai (saya bisa), tetapi sering kali tidak. Alasannya sederhana: dia memiliki hal lain yang lebih penting untuk dilakukan. Misalnya, itulah mengapa saya sangat senang memiliki penyedot debu robot Roomba. Hal ini memungkinkan saya untuk menikmati kebersihan sekaligus tidak harus merapikan diri. Yang membawa saya ke pemikiran saya selanjutnya, diarahkan pada orang-orang di luar dunia Linux.Orang yang sama cukup mampu menyedot debu lantai (saya bisa), tetapi sering kali tidak. Alasannya sederhana: dia memiliki hal lain yang lebih penting untuk dilakukan. Misalnya, itulah mengapa saya sangat senang memiliki penyedot debu robot Roomba. Hal ini memungkinkan saya untuk menikmati kebersihan sekaligus tidak harus merapikan diri. Yang membawa saya ke pemikiran saya selanjutnya, diarahkan pada orang-orang di luar dunia Linux.Orang yang sama cukup mampu menyedot debu lantai (saya bisa), tetapi sering kali tidak. Alasannya sederhana: dia memiliki hal lain yang lebih penting untuk dilakukan. Misalnya, itulah mengapa saya sangat senang memiliki penyedot debu robot Roomba. Hal ini membuat saya bisa menikmati kebersihan sekaligus tidak harus merapikan diri. Yang membawa saya ke pemikiran saya selanjutnya, diarahkan pada orang-orang di luar dunia Linux.ditujukan untuk orang-orang di luar dunia Linux.ditujukan untuk orang-orang di luar dunia Linux.
Inilah yang ingin saya katakan kepada mereka yang berada di luar komunitas Linux: Ada kekuatan yang sangat nyata dalam proses pengembangan yang digunakan untuk bekerja di Linux. Alat tertentu tidak dapat sepenuhnya mengatasi tugas bekerja di Linux. GitHub, misalnya, melakukan pekerjaan yang bagus pada proyek di mana kode baru selalu ditambahkan setelah kode yang ada. Anda dapat, tentu saja, menggunakan perintah git push --force, secara paksa memasukkan cabang tertentu ke dalam repositori, tetapi kemudian komentar yang dilampirkan ke komit akan, pada kenyataannya, "menggantung di udara", dan diskusi tentang komit ini tidak akan ada artinya.
Alat pengembangan modern banyak menyederhanakan. Mereka memungkinkan Anda untuk memicu eksekusi beberapa tindakan ketika kondisi tertentu muncul, mereka mendukung integrasi berkelanjutan dan proses penyebaran proyek, memberi tahu pemrogram tentang perubahan dalam kode, dan menyelesaikan banyak tugas lainnya. Namun mereka tentu mempersulit proses memecah hasil pekerjaan seseorang menjadi potongan-potongan kecil yang mudah dan nyaman untuk dikerjakan. Penggunaan email teks biasa sangat menyulitkan, namun organisasi kerja ini, harus dicatat, tidak mengganggu penerapan proses pengembangan yang mengarah ke tujuan tertentu.
Bahkan jika dimungkinkan untuk menilai secara objektif dan akurat seberapa besar ekosistem Linux akan menang dan kalah (tidak ada yang akan hilang) dengan meninggalkan proses pengembangan yang ada, itu hampir tidak akan mengubah apa pun. Faktanya adalah bahwa situasi saat ini dengan sempurna menggambarkan sifat manusia, ketika orang berusaha untuk melestarikan apa yang sebelumnya telah ditunjukkan dirinya dengan sangat baik dalam praktiknya.
Apakah ada jalan keluar dari situasi ini?
Saya sangat yakin bahwa jika kami memiliki alat yang dapat memberikan manfaat yang sama dengan komunitas Linux dari metodologi pengembangannya, ini akan sangat bermanfaat bagi semua orang. Dan jika alat seperti itu memang ada, maka komunitas Linux pun dapat mengganti email teks biasa dengan mereka.
Saya tidak punya jawaban untuk pertanyaan seperti apa alat tersebut. Tetapi saya akan berani mengambil kesempatan dan merenungkannya sedikit:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
