Berkali-kali saya ditanya mengapa saya lebih suka menggunakan bahasa pemrograman seperti Haskell dan Rust, karena mereka bukan alat yang paling banyak digunakan dan populer. Posting ini ditulis dengan tujuan untuk mengungkap apa yang ada di kepala saya ketika saya memikirkan pilihan teknologi.
Pengembangan perangkat lunak dengan persyaratan operasi jangka panjang dan tingkat keandalan tertentu dalam arti mirip dengan permainan catur. Varian perkembangan peristiwa di keduanya cukup sulit untuk dipahami otak manusia, peran pengalaman sangat penting dan setiap gerakan / pilihan bisa menjadi kritis. Kemiripan berlanjut dalam arti bahwa, seperti catur, perkembangannya sangat "posisional" - seluruh rangkaian gerakan dapat ditujukan untuk mempersiapkan manuver yang akan menghasilkan kemenangan bidak. Tampaknya ini hanya satu bidak, tetapi untuk permainan yang serius ini bisa menjadi keuntungan yang signifikan. Mirip dengan permainan posisi papan catur, selama desain dan pengembangan proyek besar, kami terus-menerus membuat keputusan yang ditujukan untuk memecahkan masalah yang lebih besar atau memenuhi persyaratan proyek.Efek dari setiap solusi, bahkan yang kecil, cenderung terakumulasi menjelang akhir permainan, atau pada saat produk perangkat lunak beroperasi. Perbedaannya, yang memperburuk situasi, adalah bahwa pengembangan perangkat lunak, tidak seperti catur, tidak diselesaikan di komputer, dan Anda tidak bisa begitu saja mengambil dan menemukan gerakan terbaik dengan menjalankan mesin komputer. Oleh karena itu, perlu untuk membuat banyak keputusan yang secara bertahap membawa kita ke tujuan ini, dan semua cara yang meningkatkan "posisi" strategis kita adalah baik.dan Anda tidak bisa pergi begitu saja dan menemukan gerakan terbaik dengan menjalankan mesin komputer. Oleh karena itu, perlu untuk membuat banyak keputusan yang secara bertahap membawa kita ke tujuan ini, dan semua cara yang meningkatkan "posisi" strategis kita adalah baik.dan Anda tidak bisa pergi begitu saja dan menemukan gerakan terbaik dengan menjalankan mesin komputer. Oleh karena itu, perlu untuk membuat banyak keputusan yang secara bertahap membawa kita ke tujuan ini, dan semua cara yang meningkatkan "posisi" strategis kita adalah baik.
Solusi dapat disederhanakan menjadi beberapa kategori: arsitektural, metodologis dan instrumental. Arsitek berbicara tentang bagaimana kita menyusun sebuah proyek. Metode menentukan bagaimana kita mengatur proses kerja, memastikan kualitas dan kebenaran implementasinya. Alat menentukan apa yang perlu dikerjakan oleh tim pengembangan untuk mendapatkan hasil. Untuk siklus pengembangan penuh, sejumlah besar alat digunakan saat ini: Anda perlu memformalkan persyaratan, proses pengembangan, Anda perlu menulis kode program dan mengujinya, membuat rilis, dll. Meskipun begitu banyak tugas, pilihan bahasa pemrograman dapat memainkan peran paling penting, karena itu menentukan sekumpulan parameter berikut:
- Dasar kecepatan perangkat lunak.
- , .
- , . , .
- // , .
- , , .
- .
Selain itu, pilihan bahasa pemrograman juga dapat secara signifikan memengaruhi masalah metodologis, misalnya, alat ekosistem bahasa dapat menentukan bagaimana dan sejauh mana pengujian unit ditulis. Infrastruktur yang baik untuk pengujian properti dapat memberikan dorongan ke arah ini, dan kurangnya infrastruktur yang baik untuk pengujian unit dapat membuatnya sulit untuk ditulis dan dipelihara.
Alat-alat tersebut juga mempengaruhi masalah arsitektural - penggunaan kembali modul dalam sistem terkait dengan seberapa nyamannya membagi blok secara konseptual dan menyusun kode. Misalnya, bekerja secara eksplisit dengan sistem efek memungkinkan Anda untuk lebih menggeneralisasi kode dan memastikan bahwa modul kode tidak melakukan operasi I / O, seperti bekerja dengan jaringan dan disk, yang memungkinkan Anda untuk mempertimbangkan keamanan dan arsitektur.
Berdasarkan hal ini, Anda harus menyadari bahwa memilih bahasa pemrograman yang tepat untuk sebuah proyek dan tim dapat memiliki konsekuensi yang luas. Mengingat analogi catur, kami ingat bahwa setiap nilai tambah kecil akan masuk ke celengan bahasa tersebut dan dapat memainkan peran penting dalam perkembangan besar. Perlu juga disebutkan bahwa kita berbicara tentang memilih alat pengembangan untuk situasi di mana tidak ada batasan ketat pada pilihan teknologi terkait, misalnya, dengan ekosistem besar yang sudah tertulis pada sesuatu. Di Typeable, kami dipandu oleh pertimbangan berikut untuk bahasa tujuan umum:
- . . , , .
- — , , . . - , , , .
- . GIL (Global Interpreter Lock) . .
- , . , , , .
- . , CS . « » , IT , .
- , .
Sebagai hasil dari semua hal di atas, ada cukup banyak blok di kotak alat kami yang memungkinkan kami mengambil posisi percaya diri dalam banyak proyek. Kembali ke analogi catur, ini adalah prinsip kami yang memungkinkan kami memainkan permainan posisi. Permainan posisi adalah permainan yang bertujuan untuk menciptakan posisi jangka panjang yang membuka peluang bagi pemain dan meminimalkan kelemahan. Ini berlawanan dengan permainan menyerang, "tajam", di mana ada bagian besar risiko, dan pemain penyerang mencoba untuk menyelesaikan permainan ini sebelum lawannya dapat mengambil posisi bertahan yang baik. Pengembangan "Sharp" adalah pemrograman Olimpiade, MVP untuk eksperimen pemasaran, banyak tugas dalam ilmu data, dan seringkali pembuatan perangkat lunak yang menyertai publikasi Ilmu Komputer. Mereka dipersatukan oleh fakta bahwa mereka seringkali tidak membutuhkan dukungan jangka panjang,mereka hanya perlu bekerja pada titik waktu tertentu. Permainan posisi adalah permainan jangka panjang, di mana pemeliharaan dan peningkatan kemampuan adalah indikator utamanya. Inilah yang kami lakukan, dan kami membutuhkan dasar yang baik agar yakin dengan kinerja jangka panjang dari perangkat lunak yang kami tulis dan perbarui. Proyek semacam itu juga dapat dimulai dengan MVP, tetapi diselesaikan dengan prasyarat yang sama sekali berbeda.
Mengapa daftar pertimbangan untuk memilih teknologi persis seperti ini? Ada beberapa alasan untuk ini. Pertama, diharapkan untuk mengecualikan masalah mode dan tren teknologi untuk meningkatkan prediktabilitas dalam jangka waktu yang lama. Kompiler dengan sejarah panjang dan komunitas aktif, meskipun merupakan pilihan yang konservatif, tetapi dapat diandalkan, sebagai lawan dari hal-hal baru yang bersinar yang muncul dari tahun ke tahun. Tentunya beberapa dari mereka akan berpindah dari kategori terakhir ke kategori pertama, tetapi kita akan mencari tahu tentang ini nanti, mungkin dalam beberapa tahun. Alih-alih tren, kami mencoba menggunakan Ilmu Komputer dasar dan sejumlah besar penelitian tentang topik ini telah menemukan aplikasi dalam bahasa pemrograman yang kami gunakan. Sebagai contoh: teori tipe adalah disiplin terkait matematika dan Ilmu Komputer yang berhubungan dengan masalah mendasar dari persyaratan formalisasi. Inilah tepatnyaapa yang kita butuhkan untuk menulis perangkat lunak. Selain itu, ini adalah pengalaman kumulatif orang lain yang terlibat dalam ilmu eksakta, dan menurut saya, mengabaikan pengalaman ini adalah tindakan yang bodoh. Lebih baik mengambil disiplin seperti itu sebagai dasar daripada tidak mengambil apapun, atau mengambil pendapat subjektif berdasarkan pengalaman hidup satu orang.
Kedua, kami mencari implementasi dari sejumlah besar prinsip yang telah kami ambil dalam bahasa pemrograman dan kompiler. Untuk alasan ini, selain Haskell tercinta kita, Rust juga mulai muncul di toolbox kita. Dengan persyaratan waktu nyata dan batasan ketat pada penggunaan memori, kami membutuhkan sesuatu yang levelnya cukup rendah. Ketegangan pengetikan di C masih menyisakan banyak hal yang diinginkan, jadi jika memungkinkan menggunakan Rust untuk tugas seperti itu, kami lebih suka melakukannya.
Alasan ketiga: kami membuat perangkat lunak terutama untuk pelanggan kami, dan kami ingin mereka dilindungi dari prasangka kami. Oleh karena itu, ketika memilih instrumen, risikonya tidak dapat melebihi level tertentu, yang harus disepakati dengan klien. Tetapi bahkan dengan kondisi seperti itu, kami memiliki teknologi yang cukup marjinal seperti GHCJS, karena dengan analisis gabungan dari kekuatan dan kelemahan, gambaran itu masih menarik bagi kami dan klien kami. Kami sudah menulis tentang bagaimana kami sampai pada keputusan ini: Elm vs Reflex .
Saat bekerja dengan basis kode yang besar dan perangkat lunak yang kompleks, semua cara dan justifikasi teoretis adalah baik, karena Anda harus dapat menjaga kompleksitas ini. Ide kami tentang pendekatan yang tepat adalah untuk mempertahankan setiap pion, meningkatkan posisinya dengan lancar dan akurat, sehingga proyek dapat bertahan dalam kondisi baik hingga saat itu dapat memainkan peran yang menentukan bagi bisnis klien kami. Kami berharap Anda juga demikian.