Etiket Sumber Terbuka

Saya sudah mulai bekerja pada proyek open source pertama saya di Codeplex dan menemukan beberapa kode yang mengerikan. (Saya memang tahu bahwa C # masih memiliki pernyataan "goto") Saya mulai menambahkan fitur yang diinginkan "pemilik" dan setelah menjelajahi basis kode dan melihat apa yang berantakan (misalnya menggunakan "goto") Saya ingin membersihkannya sedikit. Tapi saya agak khawatir dan itulah sebabnya saya beralih kepada Anda semua: apakah etiket yang tepat bagi saya untuk "memperbaiki" "kode buruk" atau haruskah saya membiarkannya dan bekerja pada fitur-fitur baru? Seperti yang saya katakan sebelumnya, saya baru di seluruh adegan OSS dan bekerja pada tim secara umum jadi saya ingin tidak mengacaukannya.

Tidak apa-apa untuk melakukan ini, jika Anda sederhana tentang hal itu dan tidak merusak apa pun . Anda tidak dapat berkeliling memformat ulang kode dan memperkenalkan bug. Apakah ada tes unit yang baik? Jika tidak, saya akan mulai berkontribusi dengan menambahkan tes unit, dan kemudian perbaiki struktur nanti.

Tujuan open source adalah untuk mendapatkan lebih banyak perhatian pada suatu proyek dan memperbaikinya. Itu termasuk membuat kodenya lebih baik. Yang mengatakan, itu adalah bentuk yang baik untuk beriklan di daftar apa yang ingin Anda lakukan. Anda mungkin mendapat dorongan balik, atau Anda mungkin mendapatkan banyak +1. gotoPernyataan - pernyataan itu mungkin ada di sana karena penulis aslinya tidak bisa memikirkan cara yang lebih baik untuk menyelesaikan pekerjaan. Jika Anda mendapat dorongan kembali, ada baiknya untuk memasukkan dialog untuk mencari tahu dari mana tekanan itu berasal. Cobalah untuk tidak membiarkannya menjadi masalah pribadi, dan cobalah untuk mengatasi masalah.

Intinya, tes unit berbicara lebih keras daripada dogma. Jika Anda dapat membuktikan bahwa kode tersebut tidak berfungsi dalam kasus-kasus tertentu seperti sekarang, Anda akan mendapatkan acungan jempol atau penulis asli akan masuk dan memperbaiki beberapa hal.

Ingat, dalam open source, komunitas lebih penting daripada kode. Jika tidak ada komunitas (baik pengguna dan pengembang), maka tidak ada proyek.

Orang-orang yang sangat defensif tentang kode mereka umumnya tidak mempostingnya untuk dunia periksa, dan jika mereka melakukannya, komunitas di sekitarnya tidak bertahan lama. Bersikaplah bijaksana, tetapi jangan khawatir bahwa Anda akan melukai perasaan.

Katakan saja apa yang ingin Anda lakukan sebelum menginvestasikan terlalu banyak waktu untuk itu. Terkadang ada alasan historis untuk hal-hal yang tidak jelas. Alasan goto dihindari adalah mereka dapat menghasilkan jalur yang tidak terduga melalui kode. Karenanya, bahaya menghapus goto adalah Anda tidak melihat salah satu jalur yang menguntungkan, dan secara tidak sengaja menghilangkannya dari refactor.

Di sisi lain, mungkin penulis aslinya tidak bisa memikirkan cara yang lebih bersih untuk menulisnya saat itu. Di sinilah kode berbicara lebih keras daripada kata-kata, karena mereka mungkin tidak percaya itu bisa dilakukan lebih bersih sampai Anda menunjukkannya. Salah satu kontribusi open source pertama saya adalah perbaikan undo stack yang secara signifikan meningkatkan kinerja, tetapi beberapa pengembang inti mengatakan itu terdengar terlalu rumit ketika saya pertama kali menggambarkannya. Contoh kode pendek membawa mereka.

Jika ternyata benar-benar ada alasan bagus untuk meninggalkannya, saya akan mendorong setidaknya untuk komentar yang menjelaskan alasan itu.

Berbicara dari pengalaman ...

Proyek Open Source pertama yang saya berkontribusi, saya penuh dengan kencing dan cuka ketika saya mulai juga.

Apa yang segera saya lakukan adalah melalui banyak file sumber dan mulai menyesuaikan hal-hal dengan preferensi pribadi saya, membuat tambalan besar, dan mengirimkannya.

Jika Anda bekerja dengan seseorang yang 'baik' (seperti saya), ia akan langsung menolak tambalan itu. Sebagian besar karena, ketika Anda berkontribusi pada proyek open source, Anda diharapkan untuk memecah perbaikan Anda menjadi potongan ukuran gigitan yang mengatasi satu masalah. 'Dihapus semua foto' bukan contoh yang baik dari komit atom. Bahkan jika Anda memecahnya menjadi lebih kecil, komitmen yang terdokumentasi dengan baik terlebih dahulu mungkin masih ditolak.

Alasannya adalah, karena kode ini dikerjakan oleh banyak orang (dengan gaya yang berbeda) dari waktu ke waktu, tidak benar-benar layak untuk menerima perubahan di seluruh perpustakaan agar sesuai dengan gaya satu pengembang. Jika mengubah gaya demi gaya itu layak maka setiap proyek sumber terbuka tidak akan pernah bergerak maju karena kode akan terus diedit agar sesuai dengan gaya pengembang yang berbeda.

Kode refactoring dan menambahkan fungsionalitas (atau menghapus cacat usang) biasanya lebih diutamakan daripada kode 'pembersihan'.

Bagian tersulit dan paling memuaskan dari mengerjakan proyek sumber terbuka adalah, Anda akan ditanya mengapa Anda mengusulkan untuk melakukan perubahan yang Anda kirimkan. Jika Anda bisa memberikan alasan yang bagus, ada kemungkinan patch Anda akan dikirim lebih baik.

Saran saya adalah melakukan beberapa perubahan ini pada satu file sumber untuk memberikan rasa apa yang Anda coba lakukan terlebih dahulu. Jika perubahan dibenarkan dan diterima dengan baik, tanyakan apakah lebih banyak perubahan seperti itu akan meningkatkan kualitas proyek. Dengan begitu Anda tidak akan membuang banyak usaha untuk apa-apa jika tambalan Anda ditolak di masa depan.

Mengembangkan open source lebih dari sekadar menulis kode. Anda sedang berupaya membangun hubungan saling percaya karena para penjaga gerbang (pengembang yang mengontrol akses push) akan melakukan apa yang harus mereka lakukan untuk melindungi integritas proyek. Saat Anda mengirimkan lebih banyak tambalan, gatekeeper akan merasakan gaya Anda lebih baik dan Anda tidak perlu terlalu banyak membenarkan perubahan Anda.

Ini adalah proses yang membutuhkan waktu tetapi sangat bermanfaat. Anda tidak hanya akan belajar banyak karena dapat melihat, dan mengkritik kode orang lain, tetapi Anda akan dikritik pada gaya Anda sendiri.

Sebelum Anda membuang banyak waktu untuk mencoba 'memperbaiki ketidakadilan dari kesalahan gaya pengkodean orang lain' tanyakan pada diri sendiri ini:

Apakah perubahan yang Anda usulkan didasarkan pada nilai tambah pada proyek atau apakah itu didasarkan pada agama gaya internal Anda sendiri.

Ada banyak agama di Stack Overflow (dan situs Stack Exchange terkait). Maksud saya banyak . Orang-orang berpikir dan berbicara tentang gaya tanpa akhir, seolah-olah semakin Anda membicarakannya, semakin dekat Anda dengan gaya pengkodean 'sempurna, ideal, tidak dapat dihancurkan, dan sempurna'. Saya terlalu banyak membicarakannya karena itu menyenangkan.

Di dunia Open Source, gaya tidak begitu penting. Fungsinya adalah .

Catatan: Semua saran ini mengasumsikan bahwa gatekeeper Anda adalah programmer yang masuk akal dan berbakat. Jika ya, anggap diri Anda beruntung karena Anda tidak terjebak dengan salah satu cengeng b & # & es yang satu-satunya perhatian adalah melindungi 'bayi' mereka. Mereka memang ada di alam liar, jadi jangan heran jika Anda menemukan satu.

Kualitas> Etiket

Menurut pendapat saya Anda tidak perlu khawatir mengedit kode orang lain segera setelah Anda menemukan itu memiliki kualitas yang buruk. Untuk mencapai kualitas perangkat lunak yang baik, Anda hanya perlu merawat kode bersih. Saya tidak melihat masalah dengan melakukan perbaikan pada kode orang lain, orang lain harus menyadari dan bersyukur bahwa ada coders yang bekerja pada kode mereka.

Jika Anda bisa mencari cara yang lebih baik untuk menyelesaikan masalah tanpa menggunakan "goto", maka saya sarankan lakukan saja. Upaya sedikit dalam membuat kode lebih baik hari ini dapat menghemat lebih banyak upaya di masa depan.

Berkomunikasi dengan penulis asli juga merupakan ide bagus.

Secara implisit tidak ada yang salah goto. Lihatlah kode perakitan - banyak foto (lompatan dan cabang) di semua tempat.

Alasan mengapa gotomemiliki nama yang buruk akhir-akhir ini adalah karena makalah Dijkstra, Go To, pernyataan yang dianggap berbahaya yang menunjukkan pernyataan goto sebagai hal yang sangat buruk.

Perhatikan bahwa itu 50 tahun yang lalu di mana rekayasa perangkat lunak bahkan belum bernama, dan sebagian besar bahasa pemrograman pada dasarnya abstraksi dari mesin yang mendasarinya sehingga bahasa mesin berisi goto, begitu pula mereka. Anda dapat mencoba memprogram beberapa di Microsoft Basic (yang asli, di Apple) [atau Commodore 64) untuk mendapatkan gambaran bagaimana pola pikir itu.

Yang diperdebatkan Dijkstra adalah bahwa untuk menjaga hal-hal sederhana tidak melompati semua tempat, tetapi sebaliknya menjaga jalur program yang lebih sederhana dengan akhir yang umum. Misalnya pengembalian dari suatu metode. Dengan kata lain - hanya lompatan lokal, bukan lompatan global.

Ini adalah langkah menuju membawa hal-hal seperti pemanggilan metode dengan argumen, modularisasi kode, paket dll yang semuanya telah diperkenalkan untuk menjinakkan kompleksitas pengembangan perangkat lunak. Pernyataan kebohongan hanyalah pengamat pertama dalam perang itu.