Cara belajar dari open source


8

Saya melihat masalah ini cukup sering. Saya suka proposisi nilai tertentu dari proyek open-source. Saya mencoba tutorial dasar. Bagus. Berhasil! Tetapi jika saya beralih ke masalah yang lebih kompleks, saya menghabiskan berjam-jam melakukan penelitian, debugging, frustrasi, dll.

Apa strategi Anda untuk mempertahankan motivasi dalam open-source? Apa hadiah sumber terbuka setelah keberhasilan tutorial dasar? "Keberhasilan" open-source apa yang Anda alami?


1
Apakah Anda berbicara tentang berkontribusi pada proyek sumber terbuka atau menggunakan perangkat lunak sumber terbuka? Tidak jelas bagi saya dari pertanyaan itu.
Paddyslacker

katakanlah menggunakan API open-source
poseid

4
Selamat datang di pengembangan perangkat lunak. Ini adalah hidup kita, kita coba kita gagal kita coba lagi sampai kita mengetahuinya.
Chris

Jawaban:


4

Saya berasumsi Anda sedang melihat perpustakaan open source kecil seperti yang ditemukan di github. Dalam kasus saya, saya sering menggunakannya untuk memecahkan masalah tertentu. Jika tidak menyelesaikannya dengan bersih, maka saya menggali, mempelajari cara kode bekerja dan membuat perubahan seperlunya. Jika perubahan saya adalah untuk sesuatu yang bermanfaat atau perbaikan bug, saya berusaha menghubungi pemilik open source atau bercabang cabang saya sendiri.

Di lain waktu saya hanya mengadaptasi sesuatu yang dekat dengan kebutuhan saya sendiri, dalam hal itu saya hanya menyimpan perubahan dan terus maju. Saya menambahkan jam tangan atau memeriksa kembali secara teratur untuk melihat apa yang telah diperbarui.

Seperti dalam catatan, ini adalah kehidupan pengembangan perangkat lunak. Lingkungan yang terus berubah.


4

Anda bertanya bagaimana Anda menjaga motivasi dalam menggunakan proyek API open source yang diberikan?

Kuncinya adalah mencari tahu proyek Open Source mana yang bagus. Kualifikasi utama dalam Open Source adalah kenyataan bahwa Anda memiliki akses ke kode sumber, yang sangat berguna ketika Anda perlu mencari tahu bagaimana segala sesuatunya bekerja (yang biasanya terjadi ketika Anda memerlukan perilaku untuk berubah dalam beberapa situasi), tetapi ini tidak menyiratkan apa pun selain itu. Ini termasuk kualitas proyek yang sama sekali tidak terkait dengan keterbukaan sumber.

Kualitas terdiri dari beberapa hal yang kurang lebih halus ketika berbicara tentang proyek kode:

  • Seberapa baik API dirancang? Apakah kode yang Anda perlu tulis agar panggilan API benar-benar dibaca dengan mudah?
  • Seberapa baik kode aktual yang ditulis dalam API? Apakah mudah untuk memahami apa yang terjadi? Apakah struktur data dipilih dengan baik dan tidak memiliki karakteristik runtime yang mahal? Apakah nama variabel dipilih dengan baik? Apakah kode tersebut sesuai dengan standar pengkodean?
  • Apakah API didokumentasikan? Ini adalah desain dan javadoc dari kode aktual, dan apakah ini berguna? Ini lebih penting daripada yang mungkin Anda pikirkan, karena ini menunjukkan kematangan kode.
  • Apakah proyek memiliki halaman web? Apakah ini diperbarui dan tanpa tautan yang terputus? Apakah ini memberikan akses mudah ke kode sumber, unduhan dan dokumentasi?
  • Apakah proyek memiliki komunitas dan milis? Apakah arsip tersedia dan dapat diakses? Apakah komunitas bermanfaat?

Semua hal ini berguna untuk diingat ketika memilih apakah Anda ingin menggunakan proyek open source yang diberikan atau tidak. Setiap derivasi dari yang terbaik harus menyebabkan tanda peringatan berkedip di kepala Anda karena itu merupakan indikasi bahwa ini bukan proyek yang terbaik.

Kemudian ketika Anda menemukan proyek, Anda menyukai apa yang Anda lihat, ada tes terakhir:

  • Seberapa sulit untuk bangun dan berjalan dari awal dengan program sederhana menggunakan API dengan cara yang bermanfaat?

Ini seharusnya

  1. dijelaskan dalam lokasi yang mudah dikenali di situs web proyek dan / atau dalam dokumentasi dalam bundel unduhan.
  2. mudah untuk mendapatkan yang benar - dokumentasi harus akurat, program mudah ditulis atau diadaptasi dari contoh sederhana yang diberikan, dan keduanya dijelaskan dengan baik dan mudah dimengerti.
  3. cepat untuk mendapatkan hak - jika Anda perlu melakukan apa saja debugging pada titik ini untuk mendapatkan program untuk menjalankan seperti yang dijelaskan, sesuatu yang sangat salah.

Jika terbukti bahwa ini adalah kasus penggunaan yang diantisipasi dan diprioritaskan, maka ini harus sederhana. Jika terbukti bahwa proyek ini tidak peduli dengan hal khusus ini, maka saya akan sangat mempertimbangkan untuk tidak menggunakannya! Jika menanjak di sini, akan menanjak berkali-kali, dan akan lebih baik jika tidak menggunakannya.


terima kasih telah menunjuk ke arah kualitas perangkat lunak.
Poseid
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.