Pengantar pengembangan solusi Open Source khas

Pada 11 September, Java Meetup diadakan di St. Petersburg, didedikasikan sepenuhnya untuk Apache Ignite . Terima kasih banyak kepada penyelenggara atas undangan dan kesempatan untuk berbicara tentang Sumber Terbuka atas nama pengembang Sumber Terbuka ini. Mengingat reaksi positif dari para hadirin, saya memutuskan untuk berbagi presentasi dengan mereka yang tidak dapat menghadiri pertemuan.

Di bawah potongan Anda akan menemukan versi teks dari presentasi, penuh dengan persepsi subjektif dari Open Source, baik positif maupun negatif.




Jadi, nama saya Anton Vinogradov, dan selama 4 tahun terakhir saya telah mengembangkan proyek Open Source Apache Ignite. Dengan menggunakan contohnya, saya ingin berbicara tentang bagaimana Open Source dilakukan, apa manfaat pribadi yang dapat Anda peroleh dari berpartisipasi dalam komunitas, dan pada akhirnya, saya ingin menginspirasi Anda untuk berpartisipasi.




Saya akan berbicara tentang Open Source menggunakan contoh Apache Ignite - salah satu dari banyak proyek Yayasan Perangkat Lunak Apache. ASF adalah salah satu komunitas Open Source terbesar dengan sejarah hampir 20 tahun. Ini berutang keberhasilannya, pertama-tama, pada proses dan prinsip motivasi, ditetapkan sejauh 1999, tetapi masih relevan saat ini. Sisi "filosofis" dari komunitas ini dijelaskan secara rinci dalam artikelnya oleh Dmitry Pavlov , tetapi kami akan mempertimbangkan sisi "terapan" dari pengembangan Open Source menggunakan contoh Apache Ignite.

Misalkan Anda memutuskan untuk berkontribusi pada pengembangan masyarakat. Bagaimana cara melakukannya?


Secara umum, tidak ada yang bisa mengatakan bahwa Open Source adalah tentang kode. Banyak kegiatan yang berbeda dapat memberikan kontribusi yang signifikan, dan hanya beberapa di antaranya yang terkait langsung dengan kode.

• Jika Anda menemukan masalah - nyatakan di daftar pengguna, di mana itu akan diselesaikan;
• Jika Anda siap, Anda dapat berpartisipasi dalam studi tugas pada devlist dan dalam koordinasi tindakan;
• Jika Anda adalah pengembang yang keren, ini adalah kesempatan bagi Anda untuk menulis banyak kode yang bagus;
• Yang akan dapat merevisi resensi keren;
• Jika Anda seorang manajer yang baik, Anda dapat membantu dengan rilisnya;
• Jika Anda adalah pendongeng yang baik atau hanya penggemar proyek ini, seperti saya, maka Anda dapat mempopulerkan solusinya.

Kontribusi paling penting bagi Open Source adalah untuk memberi tahu komunitas tentang masalah produk dan kekurangannya. Tetapi di sini penting untuk dipahami bahwa Open Source bukan pengembangan khusus dan komunitas tidak berutang apa pun kepada Anda. 90% dari kesuksesan terserah Anda. Jika Anda menemukan masalah, maka kontribusi Anda ke Open Source akan menjadi analisis terperinci dan mencari solusi. Diharapkan bahwa Anda akan secara aktif berpartisipasi dalam diskusi tentang masalah tersebut. Jika Anda melaporkannya dan pergi, masalahnya tidak akan terpecahkan.

Pilihan ideal: Anda datang, membicarakan masalah dan siap untuk mengarahkan utas ini sampai akhir, untuk menyelesaikan masalah.

Setiap masalah yang dibahas, tetapi tidak diselesaikan dalam daftar pengguna, masuk ke dalam devlist, di mana itu sedang diselesaikan. Di sini, pengembang mendiskusikan cara menerapkan fitur atau menutup bug dengan benar.


Devlist adalah semacam "tempat kekuasaan" dari proyek di mana Anda dapat berbicara dengan pengembang keren yang berpotensi dapat menghasilkan banyak uang di pelatihan, seminar, konsultasi, menulis artikel. Tetapi orang-orang ini sibuk menulis kode nyata, persis kode yang sekarang berada di ujung tombak kemajuan. Menurut saya, Anda tidak punya cara lain untuk berkomunikasi dengan orang-orang ini, kecuali pada pengabdi.

Selain itu, devlist adalah korespondensi yang bijaksana, di mana Anda memiliki kesempatan untuk berpikir selama satu atau dua jam dan hanya kemudian membalas dengan surat, tidak seperti kurir, di mana sulit untuk membaca korespondensi dan memahami segala sesuatu secara global. Dalam pemahaman saya, devlist adalah jurnal teknis khusus yang bagus sehingga Anda tidak hanya bisa membaca, tetapi juga mengambil bagian langsung dalam pembuatannya.

Bekerja di devlist, seperti pekerjaan apa pun di Open Source, bersifat publik. Jika Anda membuat kontribusi untuk itu, itu akan di-google-kan oleh majikan atau kolega Anda saat ini / masa depan. Bagi saya pribadi, ketika mengevaluasi seorang kandidat untuk pekerjaan, partisipasinya dalam para gadis lebih penting daripada profilnya di github. Profil pada github mencirikan hanya kemampuan untuk menulis kode, dan pengalaman pada devlist juga mencirikan pengalaman pengembangan tim. Apalagi pengalaman seperti itu di mana tanggung jawab individu itu penting, dan bukan kolektif. Menurut pendapat saya, keterampilan ini paling penting bagi pengembang yang baik, dan paling baik dikembangkan saat berkomunikasi dalam penganut Open Source.

Kami melanjutkan langsung ke pengembangan.


Setelah menyetujui perbaikan pada devlist, dan biasanya keputusan desain dasar disetujui, tugas siap untuk implementasi. Tugas ini paling sering direalisasikan oleh orang yang sama yang mengusulkan dan menyampaikannya, tetapi tidak selalu. Satu orang tidak dapat dikuasai oleh beberapa fitur dalam jumlah waktu yang wajar - terutama jika fitur dalam setengah Ignite.

Jika Anda adalah pengembang yang baik dan siap untuk melihat Open Source - datang dan pilih salah satu tugas yang dikerjakan, koordinasikan dengan penulis dan mulailah menggergaji.

Di Open Source, semua komunikasi bersifat publik. Diskusi tersebut ada di devlist atau di pelacak isu. Penting untuk menghindari penerapan sesuatu tanpa diskusi, karena ada kemungkinan besar melakukan sesuatu yang salah. Merupakan praktik yang baik untuk mengklarifikasi semua poin kunci sebelum memulai pengembangan, agar tidak melakukan terlalu banyak pekerjaan.

Sekarang tentang yang penting.

Pengembangan open source adalah sekolah yang baik dan gratis. Pengembang keren, profesional di bidangnya, menguraikan tugas, memungkinkan Anda untuk mengimplementasikannya, membantu dengan kesulitan apa pun - dan akhirnya muncul komit yang mencirikan Anda sebagai pengembang yang hebat. Seperti yang saya katakan, ini dapat di-Google, ini adalah bagian dari portofolio Anda.

Jika Anda tidak ingin menjual sesuatu secara gratis, pertimbangkan bahwa kontribusi ini, secara kasar, adalah riwayat kredit Anda. Ini menunjukkan bahwa Anda melakukan semuanya dengan benar, Anda dapat menulis kode dan mendiskusikan tugas, dan mudah untuk bekerja dengan Anda.

Momen berbahaya dalam pengembangan Open Source adalah bahwa siapa pun dapat masuk ke dalamnya. Saya pikir dalam setiap proyek Open Source ada seseorang yang mengalihkan perhatian semua orang selama bertahun-tahun, dan kemudian pergi tanpa memberikan kontribusi apa pun. Dan bagus jika dia pergi.

Tidak menjadi orang itu merupakan kontribusi penting bagi komunitas Open Source!

Jadi, Anda memutuskan untuk mengajukan sesuatu di Open Source. Sangat mungkin bahwa pertama kali Anda melakukan kesalahan. Seiring waktu, Anda akan mendapatkan pengalaman yang akan membantu Anda melakukan segalanya dengan benar - tetapi bukan yang pertama kali.

Dalam hal ini, ulasan akan membantu Anda.


Di sebagian besar proyek (di Apache Ignite pasti), tinjauan terjadi sebelum komit, yang memungkinkan Anda untuk menjaga brunch master atau pengembangan. Dan kami memiliki sejumlah persyaratan mendasar yang harus dipenuhi sebelum kode dikirimkan untuk ditinjau.

Gaya kode.
Proyek ini memiliki banyak kode, ditulis oleh orang yang berbeda, dengan motivasi dan waktu yang berbeda. Jika itu ditulis dengan cara yang berbeda, itu tidak mungkin dibaca. Oleh karena itu, gaya kode sangat penting bagi kami. Jika Anda diberitahu dalam ulasan bahwa Anda memerlukan saluran kosong, itu penting.

Setiap fitur harus melalui regresi.
Jika proyeknya besar, maka Anda tidak akan pernah menebak bagaimana kelengkapan kecil Anda akan memengaruhi semua fungsi. Saat ini, kami memiliki sekitar 50 ribu tes, setiap fitur ditutupi oleh satu atau lebih. Mengenai tes jatuh, regresi akan membantu menentukan bahwa Anda telah melanggar sesuatu. Bagi Anda, ini adalah cara yang baik untuk tidak terlalu banyak berpikir dan cepat memahami segalanya - apakah ada gangguan atau tidak. Jika kita berbicara tentang biaya pengujian, kita memiliki sekelompok ~ seratus mesin yang menjalankan regresi satu brunch dalam dua jam.

Perubahan area material.
Jika Anda mengubah sesuatu di "inti" - Anda harus melalui pembandingan. Tidak peduli seberapa keras dan menyelesaikan semua masalah fitur, jika memperburuk pasangan throughput / latensi, maka tidak dapat digabungkan. Penurunan kinerja dalam produk kami tidak dapat diterima.

API
Ada dua poin. API baru tidak boleh merusak kompilasi mereka yang menggunakan versi produk yang lama. Dan metode tidak akan muncul yang akan ditinggalkan dalam beberapa bulan. Melakukan API - lakukan segera.

Masukan pengkaji adalah kontribusi sumber terbuka paling penting dan paling sulit. Peninjau adalah orang yang siap membantu Anda, dalam beberapa kasus ia mengerjakan hingga 90% dari pekerjaan. Peninjau mendorong, menjelaskan, hampir menulis kode untuk Anda, jika perlu. Masalahnya adalah bahwa ketika suatu fitur jatuh ke master, terdaftar oleh kontributor, dan bukan oleh reviewer. Hargai kerja serampangan dari resensi buku.

Jika Anda bekerja di komunitas Open Source, cobalah untuk membuat resensi nyaman. Aturan dasarnya adalah untuk membuat perbaikan seminimal mungkin, tetapi sejelas mungkin. Jika Anda melihat sebelum peninjauan bahwa Anda dapat mengurangi volume perbaikan dan meningkatkan kelengkapannya, lakukanlah.

Versi Apache Ignite saat ini adalah 2.6. Rilis terjadi kira-kira setiap 3 bulan.


Rilis 2.7 sedang dipersiapkan oleh seorang karyawan Sbertekh Nikolai Izhikov, selama hampir satu tahun sekarang sebagai pengangkut dalam proyek tersebut. Ini adalah acara penting untuk proyek ini, karena untuk pertama kalinya dalam sejarahnya, rilis tersebut tidak dilakukan oleh karyawan Gridgain, perusahaan yang membuat Apache Ignite dan memindahkannya ke ASF. Ini sangat baik, karena kami bergerak menuju Open Source yang ideal, ketika produk tersebut dilepaskan dari perusahaan komersial tertentu dan ada secara mandiri. Kami berharap pengalaman ini akan berhasil, dan rilis berikutnya akan dilakukan oleh karyawan dari perusahaan lain, di mana kami memiliki komisaris - Trend Micro, WhatsApp, Nexign, Aurea, Pivotal, Yahoo, dll.


Mempopulerkan solusi - seperti dalam kasus devlist - adalah kontribusi tidak hanya untuk proyek, tetapi juga untuk diri sendiri. Hal-hal seperti itu di-Google dan memengaruhi pengambilan keputusan. Juga, ini adalah cara bagi Anda untuk menunda kode untuk sementara waktu dan melakukan sesuatu yang menarik, tetapi tidak kalah bermanfaat.

Kami beralih ke pertanyaan utama: mengapa layak berpartisipasi dalam proyek Open Source?


Saya tidak akan berhenti mengulangi: partisipasi dalam Open Source adalah pertumbuhan Anda yang cepat. Menurut pengamatan saya, itu sekitar tiga tahun, jika tidak lebih, dibandingkan dengan pengembangan yang diterapkan. Ini adalah kesempatan Anda dalam sebuah wawancara untuk mengejutkan lawan Anda dengan kalimat "Saya melihat benda ini, saya tahu persis cara kerjanya, tetapi Anda salah!" - Saya melakukan ini dua kali, pengalaman itu tak terlupakan.

Setiap programmer yang baik harus mengawasi tren. Open Source adalah tren terpanas dan paling menjanjikan di zaman kita dalam pengembangan perangkat lunak. Partisipasi dalam tren ini memberikan jaminan rasa hormat dari kolega Anda (sekarang) dan beberapa stabilitas, jaminan keuangan (di masa depan).


Banyak perusahaan tidak memiliki Open Source sebanyak yang diperkirakan. Banyak perusahaan mencari karyawan yang secara fundamental berpengalaman di Open Source, atau untuk proyek tertentu secara penuh waktu. Penting bagi perusahaan untuk memiliki keahlian internal pada proyek, untuk dapat mempengaruhi perkembangannya. Misalnya, perusahaan mungkin meminta Anda untuk menambahkan keamanan pada produk atau memperbaiki bug yang hanya ada dalam produksinya. Dan lakukan dengan cepat, bukan ketika komunitas setuju. Jika Anda memiliki pengalaman bekerja di Open Source atau dalam proyek tertentu, ini akan menjadi keunggulan kompetitif bagi Anda ketika merekrut atau terus bekerja di perusahaan Anda.

Sebagai bukti, tim kami, yang memotong Open Source di Sberbank Technologies, memiliki lowongan yang sangat menarik ( MSK dan SPB ) dan Apache Ignite bukan satu-satunya produk yang kami selesaikan.



Saya harap semua orang tertarik, dan banyak yang akan berpikir untuk berpartisipasi dalam gerakan Open Source, dan mereka yang sudah memikirkannya akan beralih ke tindakan nyata.

Ps Bagi mereka yang suka suara hangat dan tabung - versi audio "Uncategorized" tersedia.