Ironisnya, mencapai kesederhanaan itu sendiri tidaklah mudah. Kami beruntung orang-orang sangat peduli terhadap hal ini.

Saya menghadiri konferensi dotgo di Paris pada tahun 2015 dan Russ Cox menjadi pembicara utama. Dia mengajak penonton untuk bergabung dengannya dalam eksplorasi kesederhanaan dan kemudahan, yang pada akhirnya menyimpulkan (seperti yang diharapkan banyak orang) bahwa dibutuhkan banyak cinta dan perhatian untuk membuat sesuatu yang mudah digunakan, dan itulah yang mendorong sebagian besar dia dan rekan-rekannya ' motif untuk membuat Go apa adanya. Itu adalah pembicaraan yang luar biasa dan menekankan kemanusiaan dari pemrograman dibandingkan kemurnian yang melingkupi keahlian tersebut.

Saya pikir ini adalah upaya yang sangat indah untuk mendedikasikan diri seorang insinyur perangkat lunak, karena sangat mudah untuk mengkhianati kesederhanaan demi membangun sesuatu yang berhasil. Ini adalah alasan yang sama mengapa saya menghidupkan kembali kecintaan saya pada pengembangan Ruby on Rails, dua tahun penuh sejak saya meninggalkan agensi lama di London bernama New Bamboo (sekarang Thoughtbot) dan menuju Typeform di Barcelona. Saya mendapat hak istimewa dan kemewahan untuk memulai proyek baru dengan tim saya menggunakan Rails yang mendukung Node, PHP, dan Go dan saya dengan senang hati berbagi pengalaman saya di New Bamboo dengan cara yang sangat langsung.

Jika Anda belum pernah menggunakan Rails sebelumnya, Anda hampir pasti pernah mendengarnya. Ini adalah kerangka kerja yang terkenal karena memilih "kesederhanaan dan senyuman" dibandingkan kemurnian teknis, yang tidak disukai beberapa pengembang tetapi disukai oleh orang-orang seperti saya. DHH dan kelompoknya di Basecamp (née 37 Signals) membuat keputusan berani untuk mengatasi sendiri kompleksitas tumpukan web sehingga pengguna kerangka kerja tidak perlu melakukannya dan hasilnya sangat mudah digunakan.

Sama seperti Russ Cox dan pengembang Go, hal ini memerlukan pembentukan banyak konvensi dengan mengorbankan kemampuan konfigurasi, dan dengan Go dan Rails, hal ini mungkin tidak terasa mudah sampai Anda menghabiskan cukup waktu untuk menyerap budaya alat tersebut. Ketika Anda melakukannya, Anda mulai memahami bahwa mereka ada sehingga kode dapat membuat begitu banyak asumsi untuk Anda, dan kemudian proyek Anda berikutnya yang menggunakan bahasa atau kerangka kerja tersebut dapat di-bootstrap lebih cepat dengan mempertimbangkan hal tersebut.

Saya menyebutkan pengalaman Typeform secara khusus karena kami menghadapi keputusan itu secara langsung. Apakah tim saya bertanggung jawab untuk menangani kerumitannya, atau bolehkah menyerahkannya kepada pengguna akhir (pengembang lain) dan menutupinya dengan dokumentasi? Sekali lagi semuanya sederhana versus mudah dan kami memutuskan bahwa lebih baik bagi kami untuk melakukan apa pun yang kami bisa untuk memberikan kontribusi seintuitif mungkin. Aplikasi Rails kami tidak dapat sepenuhnya berinteraksi dengan database karena kami telah menggunakan arsitektur layanan mikro, jadi tantangan utamanya adalah melihat bagaimana kami dapat memperlakukan API sebagai backend persistensi sehingga pengembang lain dapat mengandalkan dokumentasi dan tutorial yang ada tentang model. Kami menulis kode yang nantinya akan menjadi permata bernama Pupper (bukannya saya menyarankan Anda menggunakannya karena cukup kasar di bagian tepinya), itu adalah produk dari serangkaian konvensi tambahan yang kami definisikan atas nama kesederhanaan:

  1. Model dengan API untuk backend harus memiliki klien terkait yang menangani permintaan.
  2. Model dan klien harus berada dalam modul yang diberi nama API, misalnya. jika kita harus berintegrasi dengan layanan bernama Rainbow, maka kelas-kelas ini harus berada di dalam modul bernama Rainbow.
  3. Jika suatu model dipanggil Rainbow::Colour maka klien API-nya harus dipanggil Rainbow::ColoursClient.

Hal ini memungkinkan kami membuat asumsi tentang kode sehingga pengembang dapat berbagi kegembiraan kami saat menghadirkan fitur baru yang hebat hanya dalam waktu 30 menit. Jika Anda berani melihat penerapannya di Pupper, Anda akan melihat ada sedikit keajaiban metaprogramming yang diperlukan untuk memungkinkan asumsi tersebut (dan berbagai asumsi lainnya) ada dan, meskipun kode itu mungkin tidak intuitif, Saya bangga dengan spagetinya karena alasan keberadaannya. Saya sangat menikmati menyusunnya karena kesederhanaan adalah sebuah tantangan, dan hal itu mengobarkan kembali hasrat saya untuk memprogram hal-hal seperti itu.

Kesederhanaan ditujukan untuk pengguna akhir, bukan pencipta

Saya tidak ingin bersikap tidak adil kepada komunitas PHP, Java, atau JS ketika saya mengatakan hal ini, tetapi menurut saya telah ada tren jangka panjang menuju jenis rekayasa berlebihan tertentu yang pada dasarnya salah memahami maksud dan tujuan kesederhanaan - yang mana adalah kesederhanaan ditujukan untuk pengguna akhir dan bukan pembuatnya.

Saya pernah mencoba memulai proyek dengan Symfony dan saya benar-benar bingung dengan dokumentasinya. Rel terkadang terasa membosankan karena seperti menyatukan balok-balok Lego untuk sebagian besar tujuan, namun Symfony 'menarik' dalam cara Terry Pratchet ingin Anda mengetahuinya. Saya tidak dapat menulis pengontrol atau mengurai masukan formulir tanpa menyertakan setengah lusin kelas dari berbagai namespace, dan saya harus memutuskan apakah saya mengonfigurasi rute, model, entitas, dan layanan menggunakan anotasi dalam komentar, YAML, atau XML. Saya pikir pengaturan semacam ini relatif mudah untuk dibuat dibandingkan dengan kerja keras yang dilakukan 37 Signals dan tim Go untuk mencapai apa yang mereka inginkan, karena rasanya seperti membuat furnitur IKEA tanpa instruksi grafis dibandingkan mendapatkan sesuatu yang disatukan secara intuitif. Saya tidak mengerti mengapa saya harus peduli bahwa pengontrol mengharuskan saya mengimpor permintaan, respons, serializer JSON, dan entah apa lagi. Sementara itu Laravel mencoba meniru Rails sehingga orang lebih mudah memulainya.

Tentu saja, bagi banyak orang, hal ini tidak masalah dan itulah sebabnya kerangka kerja seperti itu terus ada, dan tentu saja hal ini tidak menjadikan Anda pengembang yang lebih baik atau lebih buruk karena memiliki preferensi tersebut. Bagi saya ini terasa seperti konsekuensi alami dari orang-orang yang mengembangkan dengan IDE, karena setengah dari hal ini hanyalah boilerplate yang dapat diimpor secara otomatis oleh editor Anda, jadi siapa yang peduli, bukan? Menurut saya, memiliki IDE sebagai ketergantungan implisit pada proyek Anda tidak akan membuatnya menjadi sederhana, karena kode Anda kemudian menjadi mimpi buruk untuk dinavigasi bagi pengembang yang lebih memilih editor teks seperti VS Code, Atom, Sublime Text, vim, atau emacs.

Saya rasa hal yang sama juga berlaku untuk beberapa tren terkini di komunitas JS. Peralatannya fenomenal, jangan salah paham: perpustakaan seperti Babel dan Webpack benar-benar luar biasa dan merupakan keuntungan bagi pengembang yang sudah lama tidak puas dengan ekosistem Javascript. Namun, pengalaman menyiapkan paket-paket ini masih menyisakan banyak hal yang tidak diinginkan, dan saya merasa seolah-olah komunitas lebih mementingkan kesederhanaan bagi pengelola dibandingkan bagi pengguna perpustakaan tersebut. Babel melakukan transisi kontroversial ke arsitektur mikro-modul yang berarti npm install babel tidak lagi menyediakan instalasi Babel yang fungsional atau berguna. Sebaliknya saya mungkin perlu menjalankan npm install babel-core babel-cli babel-preset-es6 babel-preset-react (atau yang serupa) untuk mendapatkan hasil yang sama. Mengapa, sebagai pengguna perpustakaan ini, saya terpaksa mengetahui tentang babel-core dan babel-cli sebagai paket independen? Akibatnya, banyak pengembang memilih untuk menerbitkan repositori forkable dengan semua konfigurasi ini dilakukan untuk Anda.

UX juga tidak kalah tepat jika antarmukanya bukan grafis, melainkan kode.

Di sisi lain, benang melakukannya dengan benar. Ia tahu Anda mungkin ingin menyimpan ketergantungan pada proyek Anda, jadi yarn add melakukannya untuk Anda. Ini berarti kode Anda tidak rusak ketika seseorang di tim Anda mencoba menjalankannya karena Anda melakukan npm install, bukan npm install --save. React sangat bagus dan menyenangkan untuk memulainya, karena yang Anda perlukan untuk membuat sebuah komponen hanyalah sebuah fungsi dan beberapa sintaksis yang memerlukan banyak pemahaman tentang HTML. Semua yang saya lihat sejauh ini tentang TypeScript adalah sama. Mereka berusaha keras untuk membuat pengalaman itu benar-benar menyenangkan bagi pengembang. Dan Elm layak mendapat perhatian khusus karena panjangnya bahasa yang digunakan untuk menjelaskan kesalahan untuk Anda; sesuatu yang mulai diadopsi oleh Ruby dengan fitur 'maksud Anda?'.

Hal ini membawa saya pada pemikiran terakhir saya, yang sederhana itu sulit bukan hanya karena mengharuskan Anda menulis kode yang memperhitungkan banyak asumsi, namun karena memerlukan banyak empati terhadap orang-orang yang akan menggunakan perpustakaan itu, yaitu kerangka kerja, atau bahasa itu. Dibutuhkan begitu banyak belas kasih terhadap rekan-rekan Anda sehingga Anda bersedia membuat hidup Anda menjadi rumit sebagai pengelola sehingga mereka tidak menanggung beban tersebut dengan penerapannya sendiri.

Pengalaman pengguna adalah bidang yang besar dan menarik yang sebagian besar diarahkan pada desain antarmuka grafis, namun tidak kalah tepat jika antarmuka tersebut berupa kode. Saya sangat menghormati para pengembang open source yang memberikan begitu banyak cinta dan perhatian, karena tanpanya tidak akan ada kerangka kerja seperti Rails yang membuat pengembangan aplikasi yang cepat menjadi begitu menyenangkan; tidak akan ada bahasa seperti Ruby, Go, dan Elixir yang membuat penulisan kode menjadi begitu sederhana dan menyenangkan dengan cara yang sangat berbeda; tidak akan ada React atau React Native untuk mengubah pengembangan aplikasi satu halaman di web. Hal ini tidak membuat alat yang lebih rumit menjadi kurang bernilai, tetapi hal yang sama tidak membuat saya senang.

Jadi ini adalah pujian saya terhadap Prinsip Senyuman Lebih Besar dari DHH (seperti yang dijelaskan dalam Doktrin Rails), prinsip pembangunan yang paling penting, yang menjelaskan semua ini dengan jauh lebih indah daripada yang pernah saya bisa. Untuk itu, saya akan meninggalkan kutipan fantastis tentang pencipta Ruby, yang menunjukkan betapa menyenangkannya prinsip ini:

Ruby tidak hanya berusaha mengenali tetapi juga mengakomodasi dan meningkatkan perasaan programmer. Apakah itu karena kekurangan, imajinasi, atau kegembiraan. Matz melewati rintangan penerapan yang sangat rumit untuk membuat mesin tersebut tampak tersenyum dan menyanjung manusia yang bersekongkol dengannya.
— DHH

Bukankah itu luar biasa?