Get best of the week

Tunjukkan saya solusi karena itu para pengembang tidak akan berdebat, dan saya akan memberi Anda bir



Ada dua kubu yang tidak bisa didamaikan. Beberapa mengatakan: Anda harus secara akurat dan kompeten menggambarkan komitmen Anda. Setiap komit adalah karya yang lengkap dan bermakna. Jika Anda tidak dapat membuat deskripsi komit yang jelas dan sederhana, maka Anda memiliki komitmen yang salah.

Orang lain menganggap bahwa Anda membuat komitmen sesuka Anda, ini adalah bagian dari alur kerja pribadi Anda. Tapi kumpulan permintaan dijelaskan secara rinci: apa yang dilakukan, bagaimana dilakukan, mengapa itu dilakukan. Saat diuji, masalah apa yang terpecahkan, apa yang harus Anda perhatikan.

Saya seorang pendukung setia pendekatan kedua - tidak nyaman bagi saya untuk mengalahkan pekerjaan saya menjadi potongan-potongan mikro. Saya mengambil tugas kecil dan secara acak terburu-buru di sekitar basis kode, bereksperimen dan membuat perubahan dalam urutan yang ternyata. Jika saya dapat mengklik tombol, dan pekerjaan saya akan direstrukturisasi menjadi komitmen yang baik, saya akan mengkliknya. Tetapi tidak ada tombol, tetapi saya tidak ingin merusak diri saya sendiri. Pada saat yang sama, saya mencapai keterampilan tertentu dalam menggambarkan kumpulan permintaan. Saya kebetulan menemukan kode di Microsoft (melalui outstaff, itu tidak masuk hitungan), dan di sana saya mendapat standar teratas untuk memproses kumpulan permintaan. Selama bertahun-tahun, saya baru saja mengembangkan praktik ini. Biasanya saya berhasil meyakinkan tim untuk menggunakan pendekatan seperti itu.

Tetapi pada pekerjaan terakhir, saya mendapatkan devlid - pendukung setia komitmen rinci. Oh, kami berdebat lama. Posisi bawahan saya berperan, kebiasaan Sovkovsky untuk setuju dengan hal utama tidak mudah untuk diam. Aku tidak begitu kategoris seperti biasa, dan diletakkan di kedua bilah. Ditumpuk, tetapi tidak yakin.


Jika tiba-tiba para pengembang bersatu dalam satu pemerintahan, menetapkan peraturan dan mulai menyatakan pendekatan tertentu yang dilarang, perang saudara akan dimulai pada hari berikutnya. Semua karena di dunia pengembang ada kepercayaan akan tujuan dan terukur. Dalam kebenaran independen dari persepsi manusia. Dan jika semua ini ada, itu berarti bahwa salah satu pihak yang berselisih jelas secara objektif salah.

Perselisihan kerja serius pertama saya terjadi cukup awal. Saya masih seorang green juni, yang mengira dia tengah apper, dan memang pengembang yang sangat keren dan cerdas. Salah satu pengembang nyata dari tim saya melemparkan PR. Kami memiliki praktik bahwa semua anggota tim membuat kode ulasan. Saya membuka kode, dan segera melihat masalahnya. Seorang pria menulis tes untuk beberapa fungsi yang mengambil angka. Jadi dia memberinya 0, 1000, dan acak (0, 1000).

Pada saat itu, saya sangat merasa bahwa rekan satu tim lain melihat saya sebagai pendatang baru yang bodoh. Dan dia menunggu sebentar untuk mengolesi mereka dengan visinya. Saya beruntung - acak dalam tes!

Saya tidak benar-benar memahami teori pengujian unit, tetapi saya membaca beberapa buku, dan ingat dengan kuat - unit test yang sama pada basis kode yang sama harus memberikan hasil yang sama. Saya menghabiskan sekitar satu jam untuk memikirkan komentar sehingga tidak terlihat beracun, tetapi saya menjelaskan bahwa hanya monyet, yang diajarkan untuk menghitung kemarin, bisa memikirkan keputusan seperti itu. Pada akhirnya, tentu saja, dia tampak sangat bodoh, seperti segala sesuatu yang magang kemarin yang membayangkan diri mereka sebagai pengembang yang diperas dari diri mereka sendiri.

Keesokan harinya, saya menyadari bahwa saya telah membuka portal ke neraka. Ada seratus komentar lagi di bawah saya. Untuk sisa hari itu, alih-alih tim enam pengembang, kami adalah tim enam monyet. Kami berdebat dalam bahasa Inggris di PR sendiri, meskipun semua orang orang Rusia. Ketika stok kata-kata tidak cukup, mereka memanggil. Mereka saling menjatuhkan diri dengan tautan, kutipan dari buku, studi, beralih ke individu. Seorang kolega menjawab salah satu komentar saya dengan tangkapan layar dari kamus bahasa Inggris untuk mengejek bahasa Inggris saya. Tapi kami belum sampai pada kompromi.

Pertanyaannya rumit. Di satu sisi, kita semua tidak tahu sama sekali apa yang bertanggung jawab atas parameter ini, fungsi kita meneruskannya ke yang lain, dari jaringan internal yang tidak memiliki dok. Oleh karena itu, secara teoritis, fungsi bisa jatuh pada nilai apa pun, yang berarti tes dapat menangkapnya, dan kemudian kita bisa mengantisipasi kesalahan pada prod. Di sisi lain, kami sudah memiliki masalah membangun berkubang secara acak. Karena itu, jika proyek tersebut sedang dibangun secara lokal dan mulai runtuh, kami dengan bodoh memesan bangunan baru dan tidak melihat log apa pun. Lagi pula, proses pembuatannya memakan waktu empat jam, dan tidak ada yang akan melihat permintaan tarik sampai lulus CI.

Selain itu, mobil-mobil sering sibuk - itu jauh lebih pragmatis untuk memesan membangun sementara itu masih sedang dipesan daripada mencari "masalah" potensial (yang hampir selalu berubah menjadi waktu tunggu terbang dalam uji integrasi). Ini berarti bahwa bahkan jika tes acak gagal, kami tidak akan memperhatikan.

Semuanya terselesaikan pada dealik berikutnya. Kami menelepon seluruh tim, dan selama setengah jam terus berdebat - dalam bahasa Rusia. Kami tidak memperhatikan bagaimana manajer pembangunan Amerika kami bergabung dengan panggilan itu, dan terus saling menghancurkan dengan argumen dengan nada tinggi. Sampai mereka mendengar, “Hai teman-teman, sama sekali tidak penting. Gabungkan saja apa adanya. " Saya tidak tahu berapa lama dia mendengarkan kami sebelumnya, dan ketika dia mengerti apa yang sedang kita bicarakan, tapi kami berhenti dengan mendebat. Mereka membeku dan melupakannya. Berpisah dalam kedamaian, tetapi tidak yakin.


Sejak itu, saya mendapatkan pengalaman untuk memahami - tetapi tidak peduli sama sekali, kasus acak, cacat, atau batas. Tes unit sialan ini akan mengganggu - kami akan menulis ulang. Semuanya lebih baik daripada berdebat sepanjang hari. Tetapi jika Anda membayangkan bahwa saya berada di dunia yang ideal, di mana selalu perlu untuk membuat keputusan yang lebih tepat, saya tidak tahu apa yang harus dilakukan. Kami membekukan uji dengan keacakan, dan sekarang saya memahami ini sebagai pilihan yang mendukung keandalan, tetapi merugikan kenyamanan pengembangan.

Suatu hari saya menghadapi dilema yang sama. Saya bermain dengan kode waktu baru dan menulis hal yang dapat digunakan seperti ini

// LessThan<T>  MoreThan<T> -    ,   . 
// ,        

//      , 
//   ,   100
const consumeNumberLessThan100 = (v: LessThan<100>) => 
    doWork(v);

//     ,   100
const consumeNumberMoreThan100 = (v: MoreThan<100>) => doWork(v);

const sample = (x: number) => {

    //     check  , 
    //   x  100
    //  "<"  ">"  , 
    //     -   
    const lessThan100 = check(x,'<', 100);

    if (lessThan100) {
        //     -  
        //       
        //    ,  lessThan100  - LessThan<100>
        //    
        consumeNumberLessThan100(lessThan100); 

        //   -  ,   , 
        //  ,   > 100.
        consumeNumberMoreThan100(lessThan100);
    }

    const moreThan100 = check(x, '>', 100);

    if (moreThan100) {
        consumeNumberMoreThan100(moreThan100); // 
        consumeNumberLessThan100(moreThan100); // 
    }

    consumeNumberLessThan100(x); // 
    consumeNumberMoreThan100(x); // 
}

Saya pikir, sial, ini sangat keren - sehingga Anda dapat menangkap sejumlah besar kesalahan pada tahap sebelumnya. Desain alat pembatasan nilai saya sangat buruk, tetapi untuk sekarang ini hanya sebuah konsep. Di masa depan, Anda dapat dengan mudah mengembangkannya, membangun DSL yang kuat dan merumuskan kondisi yang sangat kompleks untuk pencocokan parameter yang dijamin pada tahap kompilasi. Saya menemukan cara untuk meningkatkan keandalan basis kode apa pun, bersemangat, dan mengirim cuplikan ke berbagai pengembang yang sudah dikenal.

Pendapat dibagi lagi, dan tidak ke arah saya. Komplikasi ulang, rekayasa berlebihan, tidak didukung, semua orang akan macet penjaga Anda dengan bantuan pemain untuk eni. Tidak terbaca. Bagus sebagai eksperimen buruk dalam proyek ini. Contoh penggunaan diambil dari jari. Turun ke bisnis, Phil.

Para pendukung pendekatan mengatakan, ya, sangat dapat diandalkan. Semakin cepat Anda menangkap kesalahan, semakin baik. Selain itu, jika Anda menulis fungsi yang bekerja dengan jumlah terbatas, Anda masih harus menulis cek, tetapi itu hanya akan bekerja di runtime, dan akan menambah jumlah kode di badan fungsi.

Sekarang saya sedikit lebih pintar dari sebelumnya, dan belajar mendengarkan argumen. Saya membayangkan diri saya menulis fungsi yang dilindungi oleh tipe saya di proyek nyata. Seperti semua orang yang menggunakannya bertanya apa ini. Bagaimana, setelah meraba-raba chip, mereka mulai melapisi basis kode dengan DSL kustom yang tampak busuk. Ketika kami memeriksa tiga ratus kali nilai-nilai yang sebenarnya tidak akan pernah melebihi yang diizinkan. Pendekatannya benar-benar mengerikan untuk digunakan, beberapa masalah dapat diselesaikan atau dihaluskan, tetapi misalnya, kasus seperti itu

consumeNumberLessThan100(90);

Jangan halus dengan cara apa pun. Saya harus membuktikan kepada kompiler bahwa 90 kurang dari 100. Saya akan menyediakan aktivitas apa pun, dan hasilnya akan berubah

consumeNumberLessThan100(assert(90, '<', 100));

Itu tidak terlihat sangat keren. Semua argumen melawan ada di tangan, tetapi mereka tidak bertentangan dengan argumen. Ternyata dilema - kemudahan pengembangan, atau keandalan. Di sini kita jatuh ke dalam perangkap, kita mulai berpikir bahwa kita perlu menghitung kenyamanan seperti apa yang ada dan reliabilitas seperti apa yang ada di sana. Tetapi kemudahan dan keandalan dalam pengembangan adalah hal yang sangat, sangat kompleks. Mereka terdiri dari ribuan parameter.

Misalnya, kenyamanan adalah ketika IDE mengkompilasi kode untuk Anda pada sepasang karakter yang dimasukkan, ketika kode mudah dibaca, ketika Anda dapat mengubah fungsionalitas metode tanpa melihat dokumen. Ketika kompiler tidak dimuat dengan analisis statis, build cepat, editor teks langsung membuat karakter. Tetapi ketika kompiler mendeteksi dan menyoroti kesalahan untuk Anda, ini juga merupakan kenyamanan. Dan juga keandalan. Yang pada gilirannya dikumpulkan dari sejumlah besar hal yang sama sekali berbeda.

Anda harus duduk dan menghitung berapa lama proyek akan berlangsung, ke arah mana ia akan pergi, berapa kali dalam sejarah umat manusia seseorang akan memanggil satu atau metode lain dari basis kode Anda, pengembang mana yang akan bekerja di sini. Ini adalah daftar pertanyaan tanpa akhir untuk sebagian yang baik di mana tidak mungkin untuk menghitung jawaban yang benar. Tebak saja.


Suatu hari, seorang teman meminta saya untuk menyiapkan pertanyaan teknis untuk wawancara dengan Andrei Breslav. Saya pergi ke dermaga Kotlin untuk menemukan poin kontroversial dalam desain. Mereka ada di sana, seperti di tempat lain, kegelapan. Tapi yang paling menarik minat saya adalah pendekatan untuk menangani pengecualian. Penangan pengecualian di Kotlin adalah ekspresi, pendekatan yang sepenuhnya fungsional dan andal. Itu hanya untuk menangani kesalahan tidak perlu. Yang menjatuhkan semua reliabilitas ke nol. Dan ini menarik karena tepat di dermaga, para pengembang tidak terlalu malas untuk menjelaskan pilihan mereka: "ada studi bahwa penanganan kesalahan wajib sangat mengurangi produktivitas pengembang dengan sedikit penurunan kesalahan."

Saya gila, bagaimana Anda bisa menulis kode jika Anda tidak tahu apa yang harus dilakukan ketika itu tidak berfungsi dengan benar!? Jika Anda tidak tahu cara menangani pengecualian, maka jangan mengatasinya - bukan solusi untuk masalah, tetapi rak. Pada titik tertentu, kode akan jatuh, dan masalah yang selalu ada akan menyebabkan kerusakan yang bisa diantisipasi.

Tetapi argumen logis yang menentang tidak diperlukan, Anda hanya dapat melakukan statistik. Untuk pengembang kotlin, penelitian mematahkan logika karena mereka memiliki filosofi. Filsafat mereka adalah pragmatisme. Iron, pragmatisme yang tidak bisa dipecahkan, secara konsisten dibangun ke dalam semua fitur dari bahasa pemrograman ini. Kaum idealis yang melihat Haskels / Idris dan para govnokoder yang menulis golang melakukan hal yang persis sama. Filosofi kompromi yang masuk akal berkuasa dalam basis kode F #. Dan tidak ada perasaan bahwa salah satu dari mereka benar, dan sisanya bodoh.

Semua orang ini jauh lebih pintar dan lebih berpengalaman daripada orang-orang seperti saya, dan mereka tampaknya sudah lama mengerti bahwa Anda sedang mengembangkan filosofi untuk diri sendiri, dan kemudian Anda hanya mengikutinya. Karena fitur pembunuh dari setiap filosofi adalah untuk menyelesaikan dilema.

Maka filsafat muncul dalam segala hal di TI, dan filsafat adalah kebalikan dari gagasan objektivitas tunggal dan sejati, karena filsafat menawarkan untuk memilih kebenaran subjektif untuk diri Anda sendiri.

Masing-masing dari kita memiliki filosofi kita sendiri - itu tidak dijelaskan dalam satu kata, itu adalah satu set pola kompleks untuk membuat keputusan. Dan kita sering mengubah atau mengembangkannya. Dalam praktiknya, ternyata Anda memiliki proyek dengan filosofi Anda sendiri, yang ditulis dalam bahasa pemrograman dengan filosofi Anda sendiri, menggunakan kerangka kerja dan alat, yang masing-masing memiliki filosofi sendiri. Dan pengembang menulis proyek ini, masing-masing dengan filosofi sendiri. Dan setiap kali Anda perlu membuat semacam keputusan, hanya kombinasi keadaan yang memengaruhi yang akan dibuat. Bukan manajemen kompleksitas, bukan pengalaman, bukan pendekatan, bukan pengetahuan, tetapi hanya kecelakaan.

Dan semua proyek ini berhasil. Bagian terbesar dari semua tugas yang diselesaikan pengembang adalah penghapusan konsekuensi kesalahan pengembang lain, tetapi proyek berhasil dan menyelesaikan masalah orang. Orang pintar datang dengan praktik dan pola arsitektur. Memprogram bahasa dengan kontrol tipe yang kuat dan kontrak - semuanya, jika saja para pengembang tidak terlalu keliru. Dan setiap hari saya membuka Edge Board di tempat kerja, dan saya melihat ada lebih banyak bug daripada tugas. Di mana setiap bug, ini adalah yang lain, mengelola kompleksitas, pengembang omong kosong.

Filosofi pengembangan hanyalah pilihan cara Anda mencapai final. Tetapi jika tidak ada filsafat, tetapi hanya logika objektif murni, maka setiap argumen akan sampai pada masalah pencipta yang mahakuasa dan batu yang tak tertahankan.


Saya sudah dalam pengembangan untuk waktu yang lama, dan saya telah belajar bagaimana melakukan apa yang mereka katakan, bahkan ketika saya pada dasarnya tidak setuju, dan mulai menulis komitmen yang sangat detail. Devlid saya adalah vampir yang nyata. Itu tidak hanya memerlukan deskripsi - dia ingin saya menulis apa yang dilakukan oleh setiap file, mengapa melakukannya, bagaimana melakukannya. Masalah apa yang dilakukan komit?

Saya menambahkan delapan komitmen ekstra-detail, deskripsi terperinci yang sama dari kumpulan permintaan - dan saya menyukainya kapet. Sejak itu, kami hampir tidak mengerjakan proyek khusus ini, tetapi dari waktu ke waktu saya pergi ke sana untuk mengagumi komitmen ini. Serius, sungguh, sangat keren. Dan di semua proyek lain, kecuali yang pribadi, saya sekarang menerapkan pendekatan ini.

Sangat sulit bagi saya untuk membangun kembali alur kerja. Satu setengah bulan telah berlalu, dan masih sulit bagi saya untuk menulis kode seperti ini. Tapi sepertinya itu sepadan.

Atau tidak. Sejujurnya saya tidak tahu. Dan saya tidak tahu bahwa jika itu benar-benar layak, apakah itu membuat saya dua bulan benar-benar idiot. Sekitar sepuluh orang berjalan di suatu tempat di dunia yang telah saya pelajari untuk tidak melakukan komitmen seperti itu. Apakah mereka idiot? Saya kira tidak.


Podcast saya

More articles:


All Articles