Bagaimana berkomunikasi dengan rekan kerja yang menganggap kerangka kerja sebagai hit kinerja

Bagaimana kita bisa menjual ide seperti "kita harus menggunakan jQuery karena sangat dioptimalkan dan kompatibel dengan peramban silang" atau "kerangka kerja entitas itu keren karena rapi dan merawat model kita secara otomatis" ketika respons umum adalah pernyataan kosong seperti "jquery tidak berkinerja baik "atau" entitas membawa 12 kolom di atas meja ketika kita hanya membutuhkan 10 "?

Saya seorang pria pragmatis yang cenderung mempercayai aksioma yang telah saya kembangkan melalui pengalaman (ini bukan masalah kinerja sampai ada perlambatan yang terlihat). Saya tidak tahu apakah ada "kategori" spesifik yang cocok dengan ekstrim lain, sedangkan semuanya adalah masalah kinerja sampai terbukti sebaliknya ... atau bahkan di mana untuk memulai komunikasi di sini.

Bawakan mereka fakta-fakta sulit!

Misalnya ada tolok ukur kinerja untuk kerangka kerja ORM dan JS. Di atas itu semua kerangka kerja dan ORM memiliki argumen penjualan yang baik di beranda mereka.

Setelah membaca komentar Anda, saya percaya pada kasus Anda masalahnya bukan teknologi yang tepat. Ini adalah orang-orang yang menolak untuk belajar teknologi baru.

Saya menghadapi masalah ini sebelumnya, orang yang ingin menemukan kembali roda. Saya biasanya menjelaskan kepada mereka bahwa kita dapat membuat produk lebih baik dan lebih halus jika kita menghabiskan waktu menyempurnakan apa yang penting, dan bukan apa yang ada di bawahnya. Plus ... Maksudku kerangka kerja ada untuk ALASAN, dan kinerja benar-benar tidak banyak masalah hari ini. Keandalan lebih penting, dan jika kerangka kerja memiliki ulasan / peringkat yang baik maka mereka mungkin lebih dapat diandalkan daripada sesuatu yang bisa dilakukan orang dengan cepat.

Semua orang tampaknya tidak setuju dengan kolega Anda, tetapi saya pikir Anda harus menanggapi argumennya dengan serius jika tidak ada alasan lain selain memahami sudut pandangnya. Saya sangat percaya pada kerangka ketika Anda membutuhkannya atau ketika mereka benar-benar memberikan optimasi, tetapi saya juga percaya bahwa terlalu mengandalkan pada suatu kerangka kerja dapat menyebabkan pengembangan yang lemah dalam beberapa kasus.

Saya pikir Anda harus mendekati masalah lebih sedikit dari sudut pandang bahwa rekan kerja Anda salah dan lebih dari sudut pandang bahwa penggunaan kerangka kerja yang Anda pikirkan akan meningkatkan waktu pengembangan, kinerja, pemeliharaan, dll.

Saya selalu mencoba untuk mengingat untuk menggunakan alat yang tepat untuk pekerjaan yang tepat. Saya tidak perlu sled 12lb (jQuery) untuk memalu paku untuk menggantung gambar (swap gambar). Tetapi jika saya mengalami situasi di mana saya menggantung gambar yang membutuhkan lonjakan kereta api untuk tetap di dinding, saya lebih baik memiliki kereta siap untuk pergi.

dia benar, ada overhead

tetapi asumsi bahwa overhead kerangka lebih dari solusi kode tangan mungkin tidak benar, dan bahkan jika itu benar, overhead mungkin tidak signifikan.

mengusulkan tes:

• Anda berdua menulis sesuatu yang realistis tetapi relatif kecil
• Anda menggunakan jQuery (atau apa pun) dan dia tidak dapat menggunakan apa pun
• mengukur dua hal:
  1. berapa lama Anda berdua untuk kode solusi (dengan asumsi keterampilan pengkodean Anda setara)
  2. berapa lama untuk menjalankan (siklus hidup penuh) setiap solusi

kemungkinan besar, akan ada overhead kecil dengan kerangka kerja - sangat kecil - tetapi perbedaan besar dalam berapa lama waktu yang dibutuhkan untuk kode [dan debug!] solusinya

maka teman Anda bisa berdebat dengan fakta, bukan dengan Anda

Catatan: bersiaplah untuk resistensi lanjutan; berkali-kali pushback terhadap framework ditulis dalam istilah teknis, tetapi sebenarnya merupakan tabir asap untuk "tidak ditemukan di sini" atau "Saya tidak ingin belajar alat lain"

Ingatkan kolega Anda yang menemukan kembali roda itu bahwa apa yang dia lakukan adalah berbagai Optimalisasi Dini. Bagaimana dia bisa tahu bahwa kerangka kerja ini merepresentasikan hit kinerja yang tidak dapat diterima sampai mereka terbukti menyebabkan masalah. Sementara itu, produktivitas timbal balik Anda pasti akan turun dengan semua pekerjaan ekstra yang harus Anda lakukan.

Bagaimana dengan menjelaskan kinerja yang mencapai waktu pengiriman proyek ketika Anda tidak menggunakan beberapa kerangka kerja yang sangat menghemat waktu dan teruji pertempuran ini?

Salah satu opsi adalah untuk memberitahunya bahwa ia akan bertanggung jawab atas penyempurnaan kinerja - jika dapat ditunjukkan ada masalah kinerja! Atau, jika Anda memiliki sumber daya, bangun dua konsep Bukti: Anda membangun milik Anda dengan jQuery, dan semua yang Anda inginkan. Ia dapat membangunnya dengan sistem super cepat yang digulung tangan sendiri. Jangan biarkan ini berlangsung selama lebih dari beberapa hari (ini adalah bukti konsep) dan lihat siapa yang berkinerja lebih baik di akhir.

Dan tentu saja seperti yang disebutkan orang lain, dapatkan beberapa angka keras dan profil kinerja untuk kedua sisi argumen.

Pertama, ia mungkin tepat untuk situasi spesifik Anda.

Karena tampaknya Anda mengalami masalah untuk membuatnya melihat sudut pandang Anda, Anda perlu melakukan pekerjaan yang lebih baik untuk meyakinkannya.

Anda berdua berada di dua titik berbeda di sepanjang garis antara "Bangun" dan "Beli". Ini adalah garis yang cukup panjang. Di sebelah kiri, di "Bangun" Anda memiliki SpaceX, yang harus membangun seluruh industri. Di sebelah kanan, dalam "Beli" Anda memiliki outsourcing lengkap dari semua fungsi TI ke IBM, HP, dan sejenisnya, dan bisnis tidak memiliki kode sama sekali. Di tengah, sekitar 2 mm terpisah, adalah kalian berdua. Anda berdua perlu meyakinkan manajemen bahwa pendekatan Anda pada "build vs buy" pada framework dan orm dan semacamnya - dan dengan "buy" Maksud saya "tidak dibangun di rumah" - adalah demi kepentingan terbaik perusahaan, lama -istilah. Twitter akan mati jika mereka melakukan outsourcing ke IBM. Mereka menggulung sendiri. Berpikir tentang itu.

Either way, manajemen perlu turun dari lapangan golf dan masuk ke sana dan melakukan pekerjaan mereka.

Nah untuk ORM satu jawabannya adalah "Hanya jika Anda menulis permintaan Anda seperti itu, yang sama dapat dikatakan untuk SQL". Seperti yang orang lain katakan, fakta sulit adalah yang Anda butuhkan.

Juga, ajukan pertanyaan spesifik untuk menggali apa yang dia katakan - "Bisakah Anda memberi saya contoh JQuery tidak tampil karena itu bukan pengalaman saya".

Opsi ketiga, dan pengembang tua yang bijak menyarankan ini kepada saya, cukup sertakan "hal" itu (dengan asumsi itu tidak memiliki masalah buruk).

Mencari persetujuan hanya mengarah pada jawaban "tidak". Dapatkan di sana, maka Anda dapat meminta mereka untuk menunjuk ke area tertentu dan meminta mereka untuk memberi tahu Anda apa masalahnya.

"Hei, kode EF ini, hanya mengembalikan 2 item data yang dibutuhkan dari tabel itu, apa masalahnya" dll.

Jelas, Anda perlu cukup percaya diri pada diri sendiri dan alat yang Anda gunakan sebelum melanjutkan dengan pendekatan ini! :-)

Yah menolak perpustakaan seperti itu di luar kendali adalah bodoh dan terkadang sombong. Jam produk diinvestasikan dalam ini dan pemikiran di belakang mereka membuat menolaknya hanya konyol.

Bisa jadi rekan kerja Anda benar karena Anda perlu membandingkan dan mengalahkan tuntutan perangkat lunak, yang merupakan bagian dari desain. Bisa jadi solusi ORM atau ActiveRecord adalah hanya untuk banyak kerja keras atau sebaliknya, bahwa perangkat lunak membutuhkan solusi yang benar-benar digabungkan untuk DB dan ORM tidak akan memotongnya.

Mempertimbangkan hal-hal ini penting setiap kali Anda mendesain perangkat lunak.

Untuk perpustakaan sisi klien saya harus mengatakan itu benar-benar bodoh karena Anda selalu dapat menemukan kerangka kerja yang cocok untuk kebutuhan Anda. Dan seperti yang dikatakan beberapa orang di depan saya, Apa yang lebih baik daripada kerangka yang diuji pertempuran?

Biarkan dia mengeluarkan semua masalah lintas browser, dia akan mendatangi Anda dengan sukarela tentang cara menggunakan kerangka kerja.

Btw, saya pernah punya bos yang tidak bertanggung jawab atas kerangka kerja. Saya hanya menunjukkan kepadanya betapa mudahnya membuat permintaan ajax alih-alih menyalin fungsi berulang-ulang (yang merupakan ide bodoh di tempat pertama), yah dia tidak tahu bagaimana kode begitu ..