Halo, nama saya Dmitry Karlovsky, dan saya pengendara sepeda profesional. Sepanjang karier saya, saya telah membuat banyak sepeda: besar dan kecil, cepat dan nyaman, bengkok dan lurus. Oleh karena itu, sangat liar bagi saya untuk melihat programmer pintar membuat aplikasi besar dan kompleks, tetapi pada saat yang sama menghubungkan kiri lain ke proyek, alih-alih menulis beberapa garis sederhana dengan tangan saya sendiri. Alasan untuk ini adalah ketakutan akan sepeda dalam produksi yang telah berkembang di antara programmer dan mendukung dirinya sendiri.

Evolusi Programmer

Untuk kesederhanaan presentasi, kami membedakan 3 kelompok program bersyarat. Bersyarat, karena tidak ada batas yang jelas di antara mereka, dan orang yang sama di daerah yang berbeda dapat menjadi milik kelompok yang berbeda.

Pemula

• Dia masih memiliki sedikit pengalaman dan pengetahuan, tetapi dia cepat belajar yang baru, karena dia belum memiliki kebiasaan.
• Karena efek kebaruan, ia melihat dengan baik kekurangan solusi yang ada dan memiliki keinginan kuat untuk melakukan sendiri tanpa kekurangan ini.
• Dia tidak tahu bagaimana dan mengapa praktik-praktik dan prinsip-prinsip ini atau lainnya dibentuk, dan jika dia tahu, dia tidak merasakan alasan kemunculan mereka di kulitnya sendiri.
• Sebagian besar kode yang ditulis olehnya dibuang atau di refactored tanpa bisa dikenali. Paling-paling, dengan tangannya sendiri di bawah arahan rekan yang lebih berpengalaman.
• Dia dipukuli tanpa ampun karena menulis sepeda karena perpustakaan pihak ketiga lebih mungkin berubah menjadi lebih baik dalam hal banyak kriteria.

Spesialis

• Sebagian besar perpustakaan populer ditulis olehnya di waktu luangnya dari pekerjaan utamanya, karena mereka masih berjabat tangan baik untuk sepeda maupun untuk membuka kode sumber.
• Sebagai aturan, kualitas kodenya sesuai dengan kualitas rata-rata kod dalam ekosistem. Jika semua orang menulis mie dari callback, maka tidak ada yang tersisa untuknya.
• Sebagai aturan, ia menggunakan kode pihak ketiga, karena itu sendiri tidak jauh lebih baik, atau bahkan lebih buruk, karena keterbatasan waktu.
• Dengan demikian, ia terus menerima sepeda secara eksplisit (pada tinjauan kode) atau secara implisit (laporan bug).
• Ketika beberapa masalah membuatnya benar-benar, dia melihat sepeda. Dan karena ada sebagian besar programmer seperti itu, ternyata 100.500 sepeda tidak kompatibel satu sama lain, didukung oleh satu setengah pengembang.

Profesional

• Dia mampu memecahkan masalah yang lebih baik daripada rata-rata untuk rumah sakit, tetapi karena sumber daya yang terbatas, dia terpaksa memilih apa yang harus dicurahkan waktu.
• Karena kebiasaan, mereka memukulinya. Terutama jika perusahaan mempraktikkan scrum, di mana semua keputusan dibuat oleh mayoritas, tunduk pada efek Dunning-Krueger.
• Seringkali karena kompleks yang terbentuk pada dua tahap pertama, ia membatasi diri dan percaya bahwa ia tidak dapat melakukan apa pun lebih baik daripada perpustakaan pihak ketiga yang "diuji", "dipikirkan", "didukung oleh sejumlah besar pengembang."

Penyebab ketakutan

Mengikuti evolusi pemrogram, mudah untuk memperhatikan bahwa pada awalnya ia memiliki sedikit keterampilan, tetapi tanpa rasa takut, dan ketika ia memperoleh keterampilan, rasa takut akan sepeda muncul dan semakin meningkat. Untuk mengatasi rasa takut ini, Anda perlu menganalisis penyebabnya.

Saya tidak bisa berbuat lebih baik

Seorang pemula benar-benar tidak bisa. Dia harus mengarahkan usahanya untuk menjelaskan esensi dan pentingnya masalah yang dia lihat dengan penampilannya yang baru kepada rekan kerja dan pengembang perpustakaan yang lebih berpengalaman.

Seorang spesialis kemungkinan besar akan berhasil tidak lebih buruk jika ia berpengalaman dalam masalah dan berkonsultasi dengan spesialis dan profesional lainnya.

Seorang profesional mampu melakukan yang lebih baik dalam banyak kasus, karena ia sudah berpengalaman dalam topik dan bahkan memiliki keterampilan analisis yang komprehensif. Sayangnya, biasanya tidak ada yang berkonsultasi dengannya, karena ada beberapa profesional lain, dan mereka terlibat dalam topik lain. Dan spesialis tidak memiliki wawasan.

Tidak akan ada orang yang memperbaiki cacat

Biasanya penulis sepeda motor termotivasi dengan baik untuk memperbaiki cacat pada gagasannya. Tetapi cepat atau lambat, motivasi ini berlalu, jika dia melakukannya setelah jam. Dan di sini, perpustakaan pihak ketiga, tampaknya, memungkinkan Anda untuk menghemat sumber daya, karena orang lain yang tidak perlu membayar terlibat dalam dukungannya. Tetapi tidak mungkin untuk mempengaruhi mereka, dan oleh karena itu, untuk mendapatkan tenggat waktu, Anda harus menyingsingkan lengan baju Anda dan memperbaiki cacat Anda sendiri, setelah itu akan lama dan sulit untuk memecah patch Anda ke dalam repositori utama, tanpa jaminan kesuksesan.

Tidak ada yang akan meningkat dan berkembang

Di sini situasinya sama dengan cacat. Tetapi jika dengan cacat biasanya jelas bagi semua orang bahwa mereka perlu diperbaiki, maka pandangan tentang arah pengembangan berbeda untuk setiap orang. Pengembang pihak ketiga akan mengembangkan perpustakaannya di mana ia membutuhkannya, dan bukan untuk Anda. Pada kecepatan yang nyaman baginya, dan bukan untuk Anda. Jadi, jika diperlukan vektor pengembangan tertentu, sepeda Anda memberi Anda kendali dan kepastian - dua kualitas yang jauh lebih penting bagi manajemen daripada waktu dan uang.

Saya tidak bisa menggunakannya di tempat lain

Jika Anda ingin menggunakan sepeda di luar perusahaan, Anda harus mengembangkannya di waktu luang, atau menyetujui pembukaan sumber, yang biasanya lebih sulit, tetapi sangat mungkin. Bagaimanapun, perusahaan menerima PR hampir tanpa biaya di antara karyawan potensial, serta penguji beta gratis (atau bahkan kontributor, tetapi Anda tidak boleh bergantung pada ini) pada orang pengguna sepeda lainnya.

Waktu dan uang akan terbuang sia-sia

Di sini, pertama-tama, perlu dibandingkan dengan alternatif. Jika tidak ada, maka tidak ada pilihan - Anda harus memotongnya. Jika ada alternatif, maka ada baiknya membandingkan dalam hal uang dan waktu:

• Biaya menulis sepeda Anda berkualitas baik. Ini termasuk waktu aktual menulis kode, serta tes menulis, dan mentransfer proyek ke sepeda, dan menilai biaya cacat yang diperkenalkan.
• Manfaat yang diberikan sepeda. Ini mungkin penghematan karena fitur tertentu, semakin sedikit cacat, dan faktor lainnya.
• Biaya mengintegrasikan solusi pihak ketiga. Sekali lagi, termasuk penilaian biaya pengujian dan cacat yang diperkenalkan.
• Pembatasan yang diberlakukan oleh solusi pihak ketiga. Mungkin ternyata solusi pihak ketiga tidak cocok sama sekali. Atau itu akan memperlambat perkembangan sebanyak 2 kali.

Sebaiknya secara terpisah mengevaluasi biaya beralih dari solusi pihak ketiga ke sepeda, jika tiba-tiba ternyata beberapa pembatasan lebih tidak dapat diterima. Sering terjadi bahwa sekarang lebih menguntungkan untuk menerapkan solusi pihak ketiga, dan kemudian dengan cepat mentransfernya ke sepeda Anda ketika (dan jika) Anda membutuhkannya, daripada menghabiskan waktu untuk membangun sepeda sekarang.

Penilaian ini membantu keduanya untuk memahami apakah permainan itu layak untuk diterangi dan menjelaskan kepada manajemen mengapa itu layak untuk Anda buat sendiri dan tidak mengambil milik orang lain (atau sebaliknya).

Saya akan dikutuk karena saya mengutuk pendahulu saya

Sangat diragukan bahwa motor ini menempati bagian yang signifikan dari proyek tersebut. Jadi mereka akan mengutuk lebih banyak untuk sisa kode. Jadi sepeda harus dilakukan setidaknya tidak lebih buruk. Dan bahkan lebih baik jika tidak ada yang ingin menggantinya dengan perpustakaan pihak ketiga atau sepeda lain. Untuk melakukan ini, Anda perlu:

1. Kehadiran keuntungan yang jelas dan penting bagi proyek.
2. Antarmuka penggunaan yang sederhana sehingga Anda tidak perlu melakukan pembungkus.
3. API yang fleksibel sehingga Anda tidak perlu melihat sepeda baru dengan sedikit perubahan persyaratan.
4. Cakupan tes yang baik, yang akan memungkinkan lebih sedikit flashing dalam laporan bug dan menghidupkan kembali refactoring dengan baik.
5. Dokumentasi yang komprehensif sehingga Anda tidak perlu mencari pembuat sepeda untuk memahami cara mengendarainya.

Saya tidak mau bertanggung jawab

Itu normal jika Anda tidak peduli tentang proyek yang sedang Anda kerjakan. Jika Anda tidak peduli dengan apa yang Anda persembahkan sepertiga dari waktu Anda dalam sehari, maka Anda harus mempertahankan sudut pandang Anda. Dan semakin tinggi status Anda, semakin bertanggung jawab untuk mendekati apa yang harus dikatakan. Memang, tidak hanya bagaimana Anda bekerja, tetapi bagaimana orang lain akan bekerja, dan ke mana proyek secara keseluruhan akan pergi, tergantung pada suara Anda.

Rekomendasi

Saya harap saya bisa menunjukkan ketakutan sepeda yang tidak berdasar. Semakin dekat Anda dengan profesionalisme, semakin banyak sepeda ambisius yang bisa Anda pakai. Lebih baik memulai dengan sepeda yang lebih kecil, yang memiliki risiko lebih rendah, tetapi yang memberikan sedikit pengalaman di bidang ini. Dan dengan portofolio ini, lakukan hal-hal yang lebih keren dan menarik. Penting untuk tidak melupakan bahwa seorang profesional sejati tidak hanya melakukan hal-hal keren, tetapi juga tahu kapan harus meninggalkan kreasi mereka. Karena itu, selalu lakukan analisis yang akan memberi Anda keyakinan bahwa Anda melakukan segalanya dengan benar, dan manajemen akan berada di pihak Anda, dan mereka yang datang setelah Anda akan memahami jenis sepeda apa itu, mengapa sepeda itu ada di sini, dan mengapa itu tidak mungkin dilakukan sebaliknya.

Nah, untuk membantu Anda dengan analisis perpustakaan pihak ketiga, pada malam hari saya menulis aplikasi yang memungkinkan Anda memperkirakan waktu untuk menyelesaikan masalah proyek di GitHub . Semakin besar angkanya, semakin buruk proyek dengan dukungan, dan semakin lama Anda harus menunggu solusi untuk masalah Anda. Sebagai contoh: perbandingan Angular, VueJS, React, dan tentu saja $ mol di mana motor ini ditulis. Ingatlah bahwa tautan terakhir adalah satu kali, karena memompa semua masalah terbuka Angular memakan semua batas GitHub, yang dengan fasih menunjukkan bahwa pengelolanya tidak dapat mengatasi dukungan dari monster yang mereka hasilkan.