Hai Nama saya Nikolai Izhikov. Dalam posting ini saya ingin berbicara tentang satu elemen penting dari interaksi yang kita temui dalam proses pengembangan perangkat lunak, terutama dalam open source. Ini adalah panduan dan tinjauan kode.
Saya akan memberikan saran
berbahaya tentang cara membuat fitur saya dan membawanya untuk bergabung dalam wizard proyek opensource dalam konteks perbedaan budaya, temporal, konseptual, dan lainnya antara anggota masyarakat. Ini biasanya pertanyaan yang sulit, terutama bagi mereka yang baru memulai di open source.
Mari kita mulai dengan pengantar kecil. Ketika berkomunikasi dengan orang-orang, terutama dalam obrolan atau melalui surat, terutama dalam bahasa Inggris, selalu ingat bahwa pesan Anda mungkin diterima secara berbeda dari yang Anda harapkan. Siapa yang akan membaca surat itu tidak diketahui. Dia bisa menjadi seorang Hindu, orang Inggris, atau hanya orang yang mengantuk. Akan selalu ada perbedaan dalam memahami kata-kata tertentu, dan tanpa membahas detail teknis, saya akan memberi tahu Anda cara meminimalkannya.
Peringatan: kisah itu mengandung sarkasme.
Kiat buruk untuk kontributor
Jangan membicarakan fitur baru dengan siapa pun
Jika Anda ingin menerapkan fitur baru, jangan bicarakan revisi Anda dengan siapa pun. Seseorang dapat menguping dan melakukannya di depan Anda! Atau, setelah mendengar detailnya, mereka mungkin memberi tahu Anda bahwa Anda tidak memahami sesuatu - untuk mengkritik ide Anda. Kritik sangat menyakitkan. Mungkin fitur seperti milik Anda telah dibahas, dan Anda memerlukan yang lain ... Secara umum, jangan beri tahu siapa pun apa yang ingin Anda lakukan. Tidak pernah.
Jangan pernah melakukan dokumentasi teknis
Pengendara dan orang yang berpengalaman dari komunitas sangat suka memahami kode tambalan yang diterima. Karena itu, jangan sekali-kali melakukan dokumentasi teknis. Wiki, Jira, Diskusi daftar surat - semua ini omong kosong. Dan omong kosong itu bukan untukmu!
Saat Anda mengirim tambalan ke [+5000, -3500] dengan deskripsi perbaikan dalam bentuk "Peningkatan metode pabrik dan beberapa peningkatan lainnya", semua orang akan mengetahuinya sendiri, dan pada saat yang sama akan memahami seberapa baik Anda.
Jangan pernah menjalankan tes
Setiap tes berbahaya karena dapat merusak sesuatu. Jika Anda masih berhasil menjalankan tes, jangan tampilkan hasilnya. Kesalahan dalam hasil dapat menyebabkan penolakan tambalan! Dan pasti tidak pernah menulis tes baru. Jalankan Semua akan lebih lama, konsumsi CPU akan meningkat. Bagaimanapun, pengembang yang baik menulis kode tanpa bug - kolega yang berpengalaman akan melihat tambalan Anda dan memahami bahwa tidak ada kesalahan di sana.
Jangan pernah baca caranya
Datang ke proyek opensource, tidak pernah membaca Bagaimana-Untuk. Mereka ditulis untuk orang bodoh, bukan?
Rancang kode Anda dengan cara Anda sendiri. Kalau tidak, bagaimana semua orang akan mengerti bahwa Anda adalah pengembang yang baik dan orang kreatif yang serba guna dengan rasa keindahan yang berkembang?
Kirim tambalan karena nyaman untuk Anda. Sebagai contoh, proyek ini terkait dengan infrastruktur GitHub - kirimkan ketika dikirim ke kernel linux, tepat di surat itu. Anda bahkan bisa tidak di lampiran, tetapi langsung di teks. Bagaimanapun, Linus Torvalds tidak akan memberi saran buruk! Dan jika proyek diadopsi secara berbeda, maka ini adalah masalah proyek.
Jangan ragu untuk menyulitkan API Publik
Saat mengembangkan API Publik baru, cobalah membuatnya abstrak dan serumit mungkin. Setiap pertanyaan pengguna tentang perilaku API yang tidak jelas selalu dapat dijawab: “Apakah Anda belum membaca manual? Halaman 42, semuanya ditulis dengan jelas! Baca lagi! ” Dalam proyek yang serius, semuanya harus rumit. Kami punya proyek serius?
Jangan menyarankan atau membicarakan masalah
Jangan berkonsultasi dengan siapa pun dan jangan memberi tahu siapa pun tentang masalah yang dihadapi dalam pengembangan. Jauh lebih menyenangkan untuk memahami satu hal. Bagaimanapun, pengembang yang baik selalu berhasil pertama kali, mereka tidak memiliki masalah. Jika orang lain mengetahui tentang masalah Anda, mereka akan menjadi lebih pintar dan menulis kode lebih cepat dari Anda. Ini seharusnya tidak diizinkan. Dan memang tidak lazim untuk membicarakan masalah seseorang.
Keterbatasan keputusan akhir juga tidak layak disebutkan. Bagaimanapun, solusinya mungkin diminta untuk diselesaikan. Siapa yang peduli dengan pembatasan? Ketika seorang pengguna mulai memperkenalkan produk Anda ke dalam produk dan menghadapi batasan, ia akan lebih tertarik dan lebih menyenangkan. Dia akan datang kepada Anda dan meminta Anda untuk menyelesaikannya. Dan sampai saat ini, dalam hal apapun jangan katakan kepadanya tentang pembatasan - bagaimana jika dia memutuskan untuk tidak menerapkan apa pun?
Peninjau yang sangat baik akan menemukan segalanya dan dia akan menanyakan detailnya. Dalam hal apapun jangan katakan padanya tentang apa pun.
Jika Anda memiliki pertanyaan, tulis di daftar dev
Tip ini melengkapi yang sebelumnya. Cara terbaik adalah tidak hanya untuk tidak memberitahu siapa pun apa pun, tetapi juga untuk mengajukan pertanyaan terutama pada daftar dev.
Berikut adalah contoh pertanyaan yang suka dijawab oleh semua orang. Jika Anda menulis semacam tes, pastikan untuk bertanya, "Apakah Anda perlu memeriksa null dari koleksi ini?". Anda tidak perlu memikirkannya sendiri, Anda selalu dapat bertanya pada lembar dev. Lagi pula, ada banyak orang yang hanya menunggu untuk ditanyai pertanyaan seperti itu. Mereka akan berusaha untuk merespons dengan lebih cepat.
"Bagaimana saya melakukan tugas itu?" - Pertanyaan bagus lainnya. Dalam kasus apa pun tidak menunjukkan detail: ID tugas akan cukup. Semua yang membutuhkannya akan melihat sendiri.
"Kerangka mana yang digunakan?" - juga pertanyaan yang sangat bagus. Selalu menarik untuk menjawabnya, dan Anda bisa berdebat.
Perbaiki semua masalah proyek dalam satu permintaan tarik
Ini tip favorit saya. Perbaiki semua masalah proyek dalam satu permintaan tarik, terutama jika Anda bekerja di perusahaan. Hanya ada orang bodoh di proyek sebelum Anda, mereka menulis kode dengan buruk. Dan Anda menulis dengan baik. Dengan demikian, Anda hanya harus:
- Perbaiki semua kode yang ada yang tidak Anda mengerti;
- ganti nama semua, menurut Anda, variabel yang salah nama;
- perbaiki semua komentar javadoc yang ada.
Secara umum, Anda dapat mengambil dan mengambil beberapa kelas, pabrik, dll., Membuat transformasi lain sehingga kode lebih baik. Ini akan terlihat sangat mengesankan di area yang tidak relevan dengan tugas Anda. Sehingga Anda dapat lebih sepenuhnya mengungkapkan potensi Anda. Untuk Kemuliaan OOP! Amin!
Minta tinjauan kode terlebih dahulu
Saat Anda melakukan tugas, dan kemudian mengirim permintaan untuk meninjau kode, prosesnya mungkin memakan waktu cukup lama. Semua pakar biasanya sibuk. Manfaatkan trik ini: ketika tugas Anda, tampaknya bagi Anda, akan segera berakhir, minta tinjauan terlebih dahulu. Lagipula, mereka tidak akan langsung melihat - sampai tangan Anda mencapai Anda, Anda bisa menyelesaikan semuanya.
Nah, kalau si reviewer tiba-tiba punya waktu, sementara tugas belum selesai, maka dia sial. Jelaskan situasinya, katakan bahwa besok semuanya akan siap. Dengan cara ini Anda mempercepat proses (setidaknya berdasarkan ulasan) dan bergabung lebih cepat.
Bosan dengan tugas - jatuhkan
Setiap orang yang bekerja di sumber terbuka memiliki banyak waktu. Tidak perlu menyelesaikan apa pun. Ulasan kode lulus, menerima komentar. Dan mengapa mengedit dan membawa sesuatu untuk digabungkan? Ambil puzzle berikut dan lakukan. Inilah jalan menuju sukses! Peninjau memiliki banyak waktu, dan tambalan berikutnya akan terlihat tanpa hasil!
Reviewer adalah musuhmu
Dan apa lagi nama orang yang berdiri di antara Anda dan komit master? Kritik terhadap kode adalah kritik terhadap Anda secara pribadi! Dia pikir dia siapa? Dalam komunikasi pribadi, "bom" sebanyak mungkin! Jika tidak, bagaimana resensi tahu bahwa Anda peduli? Ini adalah aturan dasar pengembangan!
Saya merekomendasikan saran ini dalam pengembangan sehari-hari. Ini membantu mencapai hasil dan melakukannya dengan benar.
Nasihat Buruk untuk Peninjau
Jangan mengotomatiskan pemeriksaan rutin
Jika Anda telah mencapai level dalam proyek ketika tambalan untuk peninjauan sudah dikirim kepada Anda, jangan pernah mengotomatiskan pemeriksaan rutin! Jauh lebih menyenangkan untuk menghabiskan beberapa siklus ulasan untuk pemecahan masalah dan diskusi:
- pemformatan kode;
- penamaan variabel;
- memeriksa apakah variabel-variabel tersebut ditandai sebagai final, yang dapat ditandai oleh mereka;
- ... dan yang lainnya.
Dalam hal apapun pemeriksaan rutin tidak boleh otomatis. Ya, dan tes untuk mengemudi tanpa hasil.
Jangan pernah ungkapkan semua aturan permainan sampai akhir.
Untuk menjadi yang terdepan, Anda harus selalu memegang sepasang kartu As di lengan baju Anda. Jangan memberi tahu siapa pun tentang perlunya kompatibilitas ke belakang. Lebih baik untuk mengatakan sebelum komit: "Di sini, menurut aturan kami, kompatibilitas mundur harus dipastikan. Mohon perbaiki. ” Ini akan sangat efektif jika Anda sudah meninjau lima kali. Yang keenam masih bisa berkata: "Saya bukan ahli, jadi Anda harus menunggu review dari Tuan X, yang akan melihat lagi."
Komentar semacam itu, terutama pada tahap akhir tinjauan, selalu menambah motivasi bagi kontributor.
Emosi, otoritas, dan tidak, terima kasih
Tip ini tumpang tindih dengan tip kontributor terbaru. Tulis komentar pada permintaan tarikan sedekat mungkin secara emosional. Jika suatu tempat tidak dicentang nol atau variabel tidak dinamai seperti itu, tambahkan gairah untuk komentar Anda. Biarkan mereka melihat bahwa Anda peduli.
Jika terjadi perselisihan, jangan berikan argumen teknis. Dengan argumen teknis, mungkin Anda salah. Rujuk ke pihak berwenang - ini adalah argumen terbaik dalam perselisihan, Anda akan selalu menang.
Jika seseorang benar-benar memeriksa ulasan Anda, Anda tidak boleh mengucapkan terima kasih. Mereka masih mau berkomitmen untuk open source! Dalam hal apapun tidak perlu berterima kasih, dan mereka akan datang lagi!
Sekarang serius: apa yang harus Anda pikirkan ketika mempersiapkan dan melakukan tinjauan kode?
Saya harap semua orang mengerti bagaimana melakukan dan lulus ulasan? Pada masing-masing tips ini, selain sarkasme, ada rasa sakit yang sering terjadi dalam latihan.
Saya akan menjadi kapten Bukti dan memberi tahu Anda apa yang benar-benar perlu Anda pikirkan ketika mempersiapkan dan melakukan tinjauan kode. Pertimbangan lebih lanjut berlaku baik untuk yang mengembangkan fitur, dan yang akan memeriksanya. Namun, ini adalah dua sisi dari koin yang sama.
Konsensus dalam komunikasi adalah, pertama, dapat dicapai, dan kedua, perlu bagi proyek untuk bergerak maju. Saat ini, beberapa produk dapat dikembangkan sendiri. Biasanya ini adalah kerja tim.
Gunakan akal sehat
Ini adalah saran yang paling penting. Gunakan akal sehat, itu mengarahkan. Tampaknya bagi saya bahwa nasihat ini berlaku untuk semua situasi kehidupan. Jika Anda melakukan sesuatu, pertimbangkan apakah ini memenuhi aturan sederhana akal sehat?
Asumsikan ...
Ini tentang budaya. Saya telah mengunjungi beberapa komunitas open source besar. Saya tidak tahu apakah ini adalah bagian dari mentalitas Rusia, tetapi seringkali seseorang yang dapat dianggap sebagai bos secara bersamaan dianggap sebagai orang yang secara tidak sengaja jatuh ke tempatnya. Diyakini bahwa dia menginginkanmu buruk, secara default ada keraguan tentang profesionalismenya. Karena itu, sangat penting dalam pekerjaan apa pun untuk mengasumsikan setidaknya sedetik bahwa:
- Peninjau (kontributor, bos atau kolega Anda) bukan musuh Anda . Dia tidak ingin Anda menjadi buruk. Ini adalah asumsi sederhana, tetapi cukup sering tidak dibuat. Saya menyarankannya untuk melakukan hal yang sama.
- Orang yang menulis komentar kepada Anda juga seorang insinyur yang baik. Anda, tentu saja, baik, telah membuat fitur seperti itu. Tetapi ada banyak insinyur bagus lainnya di dunia. Dan orang yang mengirimi Anda komentar juga berlaku untuk mereka.
- Orang ini juga ingin tugas Anda selesai.
Ketika dia meminta sesuatu, dia memiliki semacam motivasi. Dia melakukannya karena suatu alasan. Apalagi jika orang ini bukan hari pertama di proyek. Tentunya ada beberapa alasan. Anda dapat bertanya tentang alasan ini: Mengapa Anda perlu melakukan hal itu? Mengapa kompatibilitas diperlukan di sini? Jika Anda mengajukan pertanyaan sederhana dengan tenang, masuk akal, dan mendengarkan jawaban, Anda dapat mencapai lebih banyak.
Nilai apa yang akan diberikan produk?
Tinjauan ini tidak hanya tambalan siap pakai, tetapi juga perbaikan proyek, koreksi. Sebenarnya, tinjauan kode dimulai pada saat Anda baru saja mendiskusikan revisi Anda. Pada titik ini, tanyakan pada diri Anda: nilai apa yang akan diberikan produk kepada produk?
- Apakah ini akan menjadi fitur baru?
- Apakah ini peningkatan yang ada?
- Perpanjangan fitur yang ada?
- Apakah ini akan menjadi kode refactoring? Tidak ada yang salah dengan itu. Beberapa kritis terhadap refactoring, tetapi itu perlu. Dan Anda perlu menyadari bahwa Anda melakukannya, dan bukan fitur baru atau sesuatu yang lain.
- Apakah itu mempercepat suatu proses, meningkatkan kinerja?
- Apakah ini perbaikan bug?
Ada opsi lain. Dalam hal apa pun, mulai mengembangkan sesuatu, untuk menyelesaikan masalah, Anda harus memahami nilai apa yang akan Anda tambahkan ke proyek.
Mengapa revisi (fitur) begitu saja?
Ada sejumlah pertanyaan berguna untuk diajukan.
Mengapa membuat fitur? Mengapa fitur ini diperlukan? Jawaban untuk pertanyaan ini penting.
Di mana awal pekerjaan? Dalam latihan saya, kebetulan saya diminta untuk mengulang aplikasi tertentu. Ada aplikasi A, Anda perlu membuat aplikasi B, yang melakukan hampir sama dengan perubahan kecil. Saya mulai melakukan pekerjaan dan ternyata A pada dasarnya tidak bekerja. Bahkan, ini digunakan di suatu tempat dalam produksi menggunakan antarmuka manusia-mesin - yaitu, seseorang duduk dan terus-menerus me-restart program, memperbaiki pengecualian null pointer secara harfiah di udara. Di mana awal pekerjaan? Dalam hal ini, ia akan berada dalam memperbaiki program A sehingga ia bekerja secara stabil, kemudian dalam program menulis B.
Di mana selesainya pekerjaan? Bagaimana seharusnya pekerjaan yang dilakukan terlihat ideal? Sangat penting untuk merumuskan sejak awal kemana Anda akan pergi.
Di mana akhir tahap saat ini? Jelas bahwa Anda tidak bisa memakan gajah segera dan lebih baik memecah pekerjaan menjadi beberapa tahap. Penting untuk memahami di mana akhir tahap saat ini. Seringkali proyek meningkat dan tidak berakhir hanya karena ruang lingkup proyek menjadi sangat besar.
Mengapa fitur ini dipecah pada tahap seperti itu? Ini tentang MVP dan semua itu. Tolong pikirkan juga ini.
Sekarang tentang API Publik
Ada banyak artikel tentang properti API Publik. Baca sebelum Anda menerapkannya. Sebagai contoh yang baik, saya bisa mengutip kerangka kerja JQuery, Spring di Jawa. Ada juga contoh negatif. Mereka yang telah pemrograman di Jawa selama bertahun-tahun, mungkin hanya mengingat yang buruk dari sudut pandang API Publik EJB 2.1. Fungsionalitas di sana mungkin bagus, tetapi jika API Publik buruk, tidak ada yang bisa meyakinkan pengguna untuk menggunakan produk.
API Publik tidak hanya alat untuk pengguna pihak ketiga. Ini dan API komponen internal, yang Anda gunakan sendiri di antara mereka sendiri. Properti penting dari API Publik:
- Kesederhanaan.
- Buktinya.
- Default yang benar. Layak untuk dipikirkan, jika, misalnya, pada lingkungan pengujian Anda membuat 500 utas, seperti dalam produksi. Atau sebaliknya, dalam produksi secara default ada 3 utas, seperti dalam lingkungan pengujian.
- Hapus pesan kesalahan. Ini adalah momok dari begitu banyak produk. Ketika sesuatu masuk ke dalam sistem, tidak jelas apa yang dilakukan salah. Kemarin berfungsi, hari ini pengecualian null pointer. Apa yang sebenarnya Anda lakukan salah dan cara memperbaikinya tidak jelas dari pesan kesalahan.
- Sulit untuk membuat kesalahan. Ada banyak rekomendasi untuk skor ini. Kompilasi pemeriksaan waktu selalu lebih baik daripada pemeriksaan runtime, dll.
- Log yang jelas dan memadai. Ini sangat penting ketika Anda menulis kode yang akan digunakan kembali dan digunakan di suatu tempat ke server.
- Kemampuan memonitor. Anda perlu memahami bahwa log dan pemantauan juga merupakan bagian dari API Publik Anda. Saat parsing kesalahan, pengguna akan melihat bagaimana metrik yang Anda keluarkan dalam pemantauan berperilaku.
Perubahan Subsistem
Ketika Anda datang ke tinjauan kode, penting untuk memiliki di kepala Anda daftar lengkap sistem dan subsistem dari produk besar di mana Anda berubah. Dalam proyek perusahaan, mungkin tidak jelas: apakah itu skema database, atau pengontrol, atau presentasi, semacam sistem pelaporan, unggahan, unduhan, dll.
Ketika bekerja dengan produk kotak, penting untuk bertanya pada diri sendiri pertanyaan: bagaimana perubahan mempengaruhi proses yang ada dalam sistem? Apakah ada kompatibilitas ke belakang? Apakah itu memengaruhi kinerja? Jika itu memengaruhi, maka kinerja apa? Bagaimana hal ini memengaruhi pengalaman pengguna?
Proses sistem standar
Setiap sistem bisnis memiliki proses standar: mulai, instalasi, beberapa daftar operasi. Bagaimana alirannya sekarang? Sebelum meninjau kode, penting untuk memahami hal ini. Anda harus melalui kode yang mengimplementasikan proses ini. Dalam kasus Ignite, ini adalah:
- Node Start / Stop (server / klien, koordinator / reguler) - mulai, hentikan node, mulai server atau node klien, mulai koordinator atau node normal
- Node Join - dalam hal simpul / koordinator / server / klien baru
- Aktivasi klaster (& penonaktifan)
- Ganti koordinator
- Buat / Hapus Cache
- Kegigihan / BLT / MVCC
Jelas bahwa rangkaian proses ini cukup besar. Penting untuk dipahami bahwa proses tersebut ada dan bagaimana mereka berubah.
Kasus sudut
Dalam aplikasi bisnis Anda, pemulihan bencana, inisialisasi sistem awal, shutdown node, restart, memperbarui aplikasi Anda, dan hal-hal serupa dapat terjadi. Dalam kasus Ignite, kami memiliki kasus sudut berikut:
- pergantian koordinator;
- simpul drop;
- masalah jaringan - ketika pesan jaringan tidak mencapai;
- file rusak.
Kita harus memeriksa dan memverifikasi hal-hal ini agar semuanya beres.
Fitur kode yang bagus
Jadi kita sampai pada kodenya. Saya menyarankan Anda untuk tidak malas dan mencari di dalamnya:
- kesederhanaan
- diperpanjang
- testabilitas
- keandalan
- kecepatan kerja tinggi.
Konkurensi
Java memiliki kekhasan tersendiri ketika menulis kode konkurensi. Jika Anda memiliki sistem bisnis, dan ada sedikit konkurensi di sana, Anda tidak perlu mempertimbangkan fitur-fitur ini. Namun, biasanya beberapa sinkronisasi melewati database. Dalam hal-hal seperti Ignite, ini sedikit lebih rumit. Dan di sini, tidak hanya fungsi kode yang penting, tetapi juga propertinya:
- Seberapa sulit untuk memahami model konkurensi Anda?
- Struktur data bersama - bagaimana integritasnya dijamin?
- Kunci - apa dan mengapa?
- Threads - kolam mana yang digunakan? Mengapa
- Jaminan visibilitas perubahan - untuk apa mereka disediakan?
Pertanyaan-pertanyaan ini harus ditanyakan sebelum merevisi kode konkurensi. Jelas bahwa daftar ini dapat dilanjutkan untuk waktu yang sangat lama.
Tes kinerja. Tingkatan yang dicapai
Jika Anda mengembangkan beberapa jenis sistem, ia memiliki klien, instalasi, maka itu jelas bekerja dengan beberapa kinerja. Di dunia saat ini, tidak mungkin untuk meningkatkan daya perangkat keras tanpa batas. Kami membutuhkan tes dan pemantauan kinerja. Saat melakukan tinjauan kode, penting untuk dipahami:
- Apakah pengujian kinerja diperlukan sama sekali? Mungkin ini semacam penyempurnaan yang tidak perlu tes kinerja?
- Jika perlu, yang mana? Ada banyak teknik dan metode pengukuran, dll.
- Di mana-bagaimana-apa yang perlu diukur?
- Benchmark apa yang indikatif? Jumlah node? Besi? Menyalakan konfigurasi? Sifat beban?
Total
Secara keseluruhan, tinjauan kode adalah praktik yang sangat bermanfaat. Saya harap semua pengembang (termasuk produk perusahaan) telah menerapkannya di rumah. Jika tidak, harap terapkan sesegera mungkin. Saya akan dengan senang hati membahas praktik tinjauan kode dengan Anda di komentar.
Video ceramah:Presentasi tersedia di sini .