Pilihan teknologi, arsitektur, dan desain dalam proyek perangkat lunak - tanpa uang tunai

Teman! Kami melanjutkan serangkaian publikasi "tanpa potongan" tentang proses desain, teknologi IT dan cara bekerja secara efektif. Hari ini kita akan berbicara tentang topik yang sangat menyakitkan yang menyebabkan mulas di otak - pilihan teknologi, bahasa pemrograman, peran arsitek, analis, pemimpin tim, dan paranormal untuk memecahkan masalah epik: luncurkan solusi perangkat lunak, jika mungkin, dalam waktu yang wajar. Dan kita akan tinggal secara terpisah, agar tidak bosan sama sekali, pada analisis korelasi ukuran bagian-bagian tubuh dari satu bagian tim dengan produktivitas otak yang lain. Tuang kopi dan ayo pergi!

Bagaimana menjadi ahli

Untuk memahami secara obyektif mengapa masih belum ada kejelasan dalam masalah yang ditunjukkan dan ada begitu banyak perselisihan "agama" dengan pengorbanan manusia, Anda perlu terganggu, tersenyum dan menggambar kehidupan seorang spesialis IT dengan pisau dapur dalam bentuk garis putus-putus di atas meja dengan kotak-kotak yang berarti pengetahuan yang diperoleh.


Kegembiraan dimulai dengan fakta bahwa, biasanya, bahkan di universitas khusus tidak ada pengetahuan yang cukup untuk pemrograman profesional dan kompetensi spesialis secara langsung tergantung pada pergulatan mental dengan kemalasan: ambil buku / kode selama beberapa jam atau tumbang dengan sekaleng bir di depan TV. Jelas, hanya sebagian kecil yang mampu bertahan di jejaring sosial, serial televisi, game online dan belajar tanpa pamrih, tetapi bahkan jika, seperti para bhikkhu, mereka terus-menerus dan setiap hari mengorbankan sebagian dari hidup mereka, mereka dapat dengan mudah memahami satu, yah, kadang-kadang dua bahasa pemrograman industri dan beberapa teknologi terkait. Dan kumisnya, pensiun dimulai dan saat lebah menanam lebah.

Tetapi dengan kesulitan seperti itu, pengetahuan yang diperoleh untuk sukses, ternyata, masih tidak cukup dan spesialisasi yang konstan dalam proyek-proyek pembangunan diperlukan, lebih disukai dengan tenggat waktu yang lebih rendah, karena keterampilan menulis segera dengan cepat dan benar hilang segera.

Akibatnya, hanya beberapa kotak yang dapat dipotong dengan pisau, dan semakin banyak ke kanan, semakin sedikit kotak, karena anak-anak lahir, kenalan muncul, hobi dan Anda ingin setidaknya hidup sedikit setidaknya untuk diri sendiri di malam hari dan akhirnya mendapatkan cukup dari tangki kecil.

Sebuah analogi yang sangat dimengerti dari seorang pakar IT, mungkin, adalah spesialis seni bela diri yang, setelah sekolah, meninggalkan Voronezh ke Cina, menghabiskan 10 tahun di sebuah biara, mengisi buku-buku jari di jarinya ke pundaknya, memotong pedang genitalnya dan kereta api selama 20 jam sehari. Seorang pejuang bahkan akan senang mengetahui beberapa dialek Cina, tetapi suatu hari ia akan bertemu dengan seorang pria berkulit gelap yang telah mendedikasikan dirinya untuk Capoeira . Kemungkinan besar, pada tingkat tanda-tanda, mereka akan saling memahami dan akan dapat memilih teknologi untuk proyek perangkat lunak, tetapi, sayangnya, paling sering Anda harus bertemu penggemar agresif cosplay dan fiksi ilmiah - dalam kostum Jedi dengan lightsaber plastik di tangan mereka.

Copy-paste, frameworks dan fiksi ilmiah

Jelas, hanya sedikit yang dapat mempelajari dan mempelajari Kebenaran tanpa pamrih, dan dalam kehidupan nyata, pertemuan dan perselisihan tentang teknologi dan bahasa pemrograman terjadi terutama antara penggemar “seri” yang berbeda dan modis, yang sering tidak mengetahui perbedaan antara IP dan TCP. Masalahnya diperparah oleh pemasaran agresif eksternal - sebagian besar vendor TI besar secara aktif "merekrut" pengikut ke dalam jajaran mereka menggunakan saluran informasi yang dipompa. Anda tidak perlu pergi jauh untuk contoh - Mozilla mempromosikan Rust, Google mempromosikan Go, Oracle tertarik (?) Dalam mempromosikan Java, Microsoft mengembangkan C #, JetBrains adalah Kotlin, alien adalah Haskell, dan komunitas ilmiah tidak terlalu gembira ketika di bawah kedok AI dan ML, sebuah neuron dan dataatanisme, untuk banyak uang dijual ... kursus akademik berdebu dalam teori probabilitas, penggaris dan statistik untuk selama-lamanya, amin :-)


Dan ketika penggemar Game of Thrones mulai berdebat dengan penggemar Klan Soprano tentang manfaat pemrograman berorientasi aspek , campuran dan penutupan , yang tersisa hanyalah tertawa dengan tulus dan menaburkan debat dengan pasir suci dari Tibet dan kentang McDonald's. Anda tidak akan bisa menunggu kesimpulan yang berguna dan obyektif, dan Anda akan semakin bingung - dan, lebih buruk lagi, Anda akan mendapatkan poppin virus dan mulai berjalan dalam mantel bergaris.

Tradisi dan "kebenaran"

Faktanya adalah merakit, misalnya, mobil yang terbuat dari besi adalah tugas yang cukup mahal dan panjang: Anda membutuhkan bahan, pengelasan, pengetahuan, kamar, poster seorang gadis dengan bentuk yang benar, dll. Dan menulis program, terutama tidak sendiri, sangat umum. Kreativitas virtual - meledak dan terus menghancurkan dan merentangkan dunia. Lautan konten digital, sering kali tidak mengerti dan primitif, tempat semua penulis dan artis membanjiri web. Sebagai hasil dari kesederhanaan relatif dari "ekspresi diri", di dunia, dalam periode waktu yang relatif singkat, setelah Perang Dunia Kedua, sejumlah besar tidak hanya program, tetapi juga bahasa pemrograman muncul. Menulis bahasa pemrograman baru tidak sulit, jauh lebih sulit - untuk membuatnya mendapatkan popularitas. Kebetulan secara historis bahwa bahasa yang belajar "menulis dengan benar" (misalnya C ++, Java, ECMA262) populer sekarang, dan bahasa yang "dibuat kemudian dan tampaknya lebih baik" (misalnya C #, Python3, Rust, Kotlin) jauh kurang populer. Memilih bahasa yang "lebih tepat", Anda berisiko tidak menemukan cukup pengembang yang mengetahuinya, atau mungkin bahasa itu berhenti berkembang atau naik ke keabadian, seperti Haskell. Oleh karena itu, dipandu oleh akal sehat, mereka sering memilih teknologi tradisional, sehingga, bahkan jika tidak cukup "benar" dan konsisten, penuh dengan kruk dan jejak pertumbuhan, tetapi diuji, populer dan dikembangkan.


Dalam konteks graphomania pengembangan aktif (terutama ke arah front-end, meskipun npm juga menyenangkan), saya ingin memperingatkan terhadap penggunaan perpustakaan dan kerangka kerja tanpa pertimbangan. Penting untuk melihat sejarah pengembangan kerangka kerja, kontingen pengembang (semakin sederhana teknologinya, semakin banyak kejutan yang ada) dan durasi dukungan versi.

Biasanya, dalam proyek-proyek open source, tidak lazim untuk mempertahankan kerangka kerja untuk waktu yang lama, misalnya 3-5 tahun atau lebih - ini klise, mahal dan membosankan. Oleh karena itu, biasanya, setelah mendapatkan sejumlah besar "kruk," versi berikutnya dibuat, dalam satu atau dua tahun, dan saya merekomendasikan bahwa pengguna versi sebelumnya mentransfer proyek mereka ... lakukan sendiri, karena versi sebelumnya tidak akan diperbarui lagi dan kesalahan keamanan di dalamnya juga tidak akan diperbaiki. Contoh dari "tidak bertanggung jawab" seperti itu hanyalah lautan.

Perpustakaan dan kerangka kerja komersial, sebagai suatu peraturan , tidak menderita penyakit yang serupa pada masa kanak-kanak (walaupun tidak semua, Anda perlu hati-hati melihat dokumentasi dan mempelajari masalah ini secara menyeluruh) dan menjaga kompatibilitas ke belakang selama 5 tahun atau lebih. Harap perhatikan hal ini, jika tidak, Anda tiba-tiba harus menulis ulang solusi web Anda dari awal!

Secara umum, pada titik ini, lebih baik menggunakan pepatah tentang tit dan crane.

Baru atau ... selesai

Masalah psikologis lain yang sangat populer dalam pengembangan adalah pilihan antara "lakukan dari awal" dan "siapkan". Saya akan memberi tahu Anda sebuah rahasia - semua orang ingin menjadi dewa, pengembang pemula, yang, kebetulan, adalah normal, mereka ingin memompa dan mendapatkan entri dalam resume dan memilih untuk "melakukannya dari awal." Tetapi kemudian, biasanya, mereka pergi karena bosan setelah enam bulan atau satu tahun, dan seringkali karena kurangnya pengalaman, kreasi mereka harus ditulis ulang berulang-ulang dari awal. Para biksu Shaolin yang berpengalaman, biasanya, mengasuransikan diri mereka dari kesalahan dan kejutan anak-anak, memilih solusi dan perpustakaan yang sudah jadi, dan menghabiskan waktu luang yang tersisa untuk mengembangkan non-standar, eksklusif untuk fungsi proyek web ini. Dan itu tidak akan membosankan!


Asosiasi yang baik mungkin memilih database - apa yang harus diambil untuk proyek web, database Oracle atau database MySQL (ya, saya tahu bahwa mereka sekarang sedang dikembangkan oleh satu perusahaan). Menurut pengalaman - 99% dari tugas pengembangan web, bahkan di bawah beban tinggi, diselesaikan dengan sangat baik dan dengan kecepatan tinggi di MySQL. Dan jika hasilnya tidak berbeda, mengapa ...? :-)

Oleh karena itu, biasanya proyek perangkat lunak sekarang terdiri dari sekumpulan perpustakaan dan kerangka kerja yang siap pakai dan teruji, dengan periode dukungan yang baik dan hanya sebagian kecil dari fungsi khusus untuk proyek ini. Dan ini, IMHO, sudah benar.

Sulit dan panjang atau ... cepat dan mudah?

Ini juga dikenal sebagai penyebab banyak perselisihan yang tak berujung. Faktanya, teknologi IT modern dan bahasa pemrograman dibagi, secara kasar, menjadi 2 bagian: sederhana untuk mayoritas (tidak perlu menggali lebih dalam, beberapa hari untuk memahami) dan sulit untuk minoritas (perlu spesialisasi serius dan panjang, berbulan-bulan untuk memahami). Seperti yang kita lihat di atas, kebanyakan orang tidak ingin belajar, jadi jika Anda menerapkan teknologi yang tepat dan dapat diandalkan, Anda tidak akan berhasil karena tidak ada yang bisa sepenuhnya memahaminya dan Anda akan bermain rolet Rusia dengan kotak hitam. Contoh populer: pilihan antara redis atau cassandra - produk dengan urutan kompleksitas yang berbeda. Atau, contoh lain: python atau C ++.

Dalam bahasa sederhana, memang, pemrograman sering jauh, banyak urutan besarnya lebih cepat - bandingkan skrip python dengan 5 baris dan kode C serupa dengan 100 baris. Tapi, biasanya, bahasa "sederhana" dan teknologi universal kadang-kadang bekerja jauh lebih lambat dan mengkonsumsi lebih banyak RAM :-) Bagaimanapun, Anda harus membayar semuanya.


Namun demikian, bahasa "sederhana" semakin banyak digunakan untuk menyelesaikan sebagian besar tugas proyek perangkat lunak, di mana persyaratan khusus untuk kecepatan super dan RAM tidak diperlukan. Dan besi menjadi lebih murah dan lebih murah. PHP sekarang sangat populer untuk pengembangan web yang cepat, dan python, dengan sintaks yang sangat jelas dan mudah dibaca, untuk tugas-tugas umum dan pembelajaran mesin. JavaScript sangat nyaman untuk mengotomatisasi tidak hanya antarmuka web, tetapi juga ... membuat aplikasi server yang sangat cepat di Node.js. Go, bahkan dengan sintaksis primitifnya, memungkinkan Anda untuk membuang lebih banyak tugas yang lebih kuat, tetapi jauh lebih sulit untuk memahami tugas-tugas Java dalam tugas sistem, dan aplikasi seluler dapat dengan cepat dibuat dengan urutan yang lebih mudah dan lebih mudah diakses oleh pemula untuk dikembangkan di Kotlin. Adalah mungkin dengan risiko yang jauh lebih rendah untuk menjalankan aplikasi beban tinggi di Rust tanpa mempelajari seluk-beluk manajemen memori di C ++. Tapi tidak ada orang waras yang mau menulis game di Jawa, mengingat minecraft populer, yang hanya bisa dimainkan pada jarak 10 meter dari layar, menyipitkan mata :-)

Oleh karena itu, untuk setiap tugas, disarankan untuk memilih alat khusus dan populer yang dipertajam olehnya. Semakin banyak alat siap pakai yang digunakan, semakin baik.

Ini lucu, tetapi dalam realitas saat ini, bahkan bukan pilihan bahasa, tetapi pilihan fitur bahasa dapat memiliki pengaruh yang menentukan pada kesuksesan. Misalnya, memiliki tim yang tidak memiliki pengalaman dalam pemrograman berorientasi objek dan pengetahuan tentang pola desain, Anda dapat menulis kebun binatang objek terang-terangan sehingga mungkin lebih mudah untuk menyelesaikan masalah dengan 100 fungsi dalam satu file monolitik, dapat dimengerti oleh semua orang daripada bersembunyi dari ratusan objek di kantor monster dengan dudukan, bukan kepala dan telinga, bukan kaki. Itulah sebabnya, seringkali, bahasa-bahasa sederhana (seperti python, php, javascript, ruby) yang tidak memberikan peluang berlebihan untuk pengembangan graphomania dan perfeksionisme, yang berfokus pada kejelasan, ketidakjelasan (python) dan keringkasan (php), membuatnya semakin mungkin untuk berhasil. Bukan untuk apa-apa cerita begitu populer ketika sebuah situs web mulai dibuat di C ++ dan apa mimpi buruk itu berbalik nanti.

Analogi yang baik di sini adalah contoh dari ksatria abad pertengahan yang mahal dan sulit untuk "disetel" dan ... hooligan dengan senjata api. Anda dapat melatih seluruh hidup Anda dan menjadi samurai Java multi-utas, tetapi tiba-tiba Anda dapat mengakhiri hidup Anda ketika bertemu seorang anak sekolah dengan solusi yang serupa dan jauh lebih sederhana dalam python atau Go.

ARSITEKTUR DAN ARSITEKTUR

Memang, 10-15 tahun yang lalu perlu untuk mempelajari dan membaca buku tebal untuk waktu yang lama untuk memahami prinsip-prinsip menempatkan objek dan interaksinya pada server dan cluster yang terpisah (j2ee, corba, com). Gaung booming ini pada arsitektur dan arsitek masih dapat ditemukan dalam kreasi mengerikan seperti Spring . Tetapi zaman berubah, teknologi menjadi lebih kuat dan terjangkau. Dengan menyebarkan beberapa server web Apache gratis, database MySQL, dan antrian RabbitMQ di suatu tempat di Amazon , Anda dapat memecahkan sebagian besar masalah yang sebelumnya tersedia dalam konfigurasi server aplikasi yang dapat dimengerti oleh minoritas yang luar biasa.


Jika tugasnya adalah untuk mendukung koneksi jaringan besar, Anda dapat meningkatkan sekelompok mesin Node.js, atau lebih tepatnya, mesin dengan Erlang dan tidur nyenyak, daripada menulis solusi server Anda sendiri, misalnya, Go atau C ++.

Jika Anda perlu melakukan riset, terus-menerus, dalam aliran, memilih salah satu dari 10-20 model pembelajaran mesin dan dengan cepat menyebarkannya di cloud untuk layanan pelanggan, maka, tentu saja, python dengan sejumlah besar perpustakaan akan menjadi solusi yang sangat nyaman dan praktis, dan seterusnya.

Tentu saja, dalam proyek-proyek khusus yang sempit, pengetahuan mendalam tentang OOP, FP , arsitektur, Ilmu Komputer tentu saja masih diperlukan, tetapi semakin sering cukup untuk mengetahui dari mana blok untuk merakit solusi dan ini sering akan mengarahkan sistem perangkat lunak ke tujuan.

Pencocokan Tim

Berdasarkan hal tersebut di atas, jelas bahwa tim kemungkinan besar akan berkembang hanya dalam kerangka terbatas dari serangkaian teknologi yang dipilih untuk proyek tersebut. Unit akan mulai menggali topik terkait, dan sebagian kecil dari mereka akan membaca literatur khusus, tetapi ini, sayangnya, merupakan kasus luar biasa. Oleh karena itu, disarankan untuk memilih yang sudah berpengalaman dalam bahasa / perpustakaan yang ditunjukkan, yang dapat diperiksa dalam resume dan dalam wawancara. Dan hanya mereka yang benar-benar tidak dapat dirobohkan oleh acara TV dan jejaring sosial yang dapat diambil untuk "pertumbuhan" setelah menerima kontrak yang telah ditandatangani sebelumnya oleh darah arteri :-)

Namun, dalam proyek non-standar, Anda harus menemukan setidaknya satu pengembang yang mengetahui sesuatu yang lain dan sangat baik, kecuali untuk python, ruby, php, javascript, go, perl, bash, chanson. Peluang pejuang mengetahui algoritma, pola desain, standar jaringan, dan OOP juga meningkat secara signifikan.


Jika proyek terkait dengan pembelajaran mesin dan Anda perlu menggali sesuatu secara mendalam, Anda harus menemukan seorang analis matematika sungguhan, lebih disukai dengan gelar ilmiah dan pengetahuan tentang python. Saya serius - untuk pembelajaran mesin, tanpa pendidikan khusus, Anda perlu belajar keras selama beberapa jam sehari (teori probabilitas, aljabar linier, metode kuadrat terkecil, statistik, teorema Bayes dan tekniknya) selama beberapa bulan, jika tidak bertahun-tahun.

Proses atau teknologi?

Anda sering dapat menemukan proyek perangkat lunak yang berumur panjang dan besar yang ditulis dalam bahasa pemrograman yang tampaknya tidak pantas atau kumpulan perpustakaan. Misalnya, orang sering menemukan skrip kontrol bash besar atau pustaka dan kerangka kerja ilmiah besar untuk perhitungan akurat pada ... python dengan mengetik bebek Dodbyba. Rahasianya ada pada proses dan praktik yang ketat. Menggunakan:

• desain awal, pengujian stres dan analisis risiko
• unit otomatis dan pengujian integrasi (sebaiknya cakupan 100%)
• standar pengkodean umum
• dokumentasi kode dan komponen sistem yang baik
• komunikasi transparan maksimum dalam tim
• pemantauan dan analisis lingkungan server

Anda dapat membuat solusi perangkat lunak, pada prinsipnya, pada teknologi apa pun yang akan hidup selama bertahun-tahun dan menyenangkan pelanggan. Dan sebaliknya, bekerja dengan "pamer" yang terlalu mahal dengan kotak hitam, tidak menyelidiki detail teknologi, mendorong kelalaian dan kepentingan pribadi alih-alih kepentingan tim, Anda dapat mencoba memulai proyek selama berbulan-bulan, memperbaiki satu kesalahan dan memunculkan puluhan - sayangnya, situasi ini cukup umum.

Ringkasan

Untuk merangkum dan memprioritaskan:

• Semakin banyak orang dapat mengamati situasi ketika kecepatan peluncuran proyek perangkat lunak merupakan faktor penentu keberhasilan. Melakukan sesuatu yang tidak perlu lama dan sulit lebih buruk daripada dengan cepat merilis solusi yang berguna bagi pelanggan dan mengumpulkan umpan balik untuk brengsek berikutnya
• Suatu permulaan yang cepat hanya dimungkinkan ketika menggunakan komponen, kerangka kerja dan pustaka yang siap pakai maksimal dengan periode dukungan yang memadai (dengan mempertimbangkan umur yang diharapkan dari sistem web Anda)
• Sayangnya, pengetahuan algoritmik dan arsitektur kurang diminati. Lebih sering, pengalaman dalam memecahkan masalah yang serupa dan praktik menggunakan kotak peralatan dan kekuatan penyedia cloud disambut.
• Tidak perlu membatasi diri Anda dan melakukan segalanya pada satu teknologi dan hanya satu, TERBAIK, bahasa pemrograman - senjata api di tangan seorang anak lebih efektif daripada studi seni bela diri oleh samurai semua kehidupan sadar dan tidak sadar. Perfeksionisme dan idealisasi membunuh sistem perangkat lunak. Pilih senjata yang tepat untuk setiap tugas dalam proyek. Ambil yang sudah jadi dan fokuskan upaya yang tersisa pada non-standar.
• Teknologi yang dipilih harus sederhana, jelas, dan dapat diakses oleh sebagian besar tim. Lihatlah apa yang mereka tulis pada proyek serupa di main dan ambil sendiri tumpukan teknologi ini. Jangan mengotomatiskan hosting dengan Haskell dan jangan menulis situs web di C ++ :-) Jika proyek Anda "lepas landas" dan mulai berkembang, hanya dengan demikian Anda dapat mempertimbangkan menulis ulang bagian-bagian kecilnya dalam teknologi dan bahasa pemrograman yang lebih kompleks. Tetapi biasanya, proyek perangkat lunak tidak mencapai tahap ini atau mencapai beberapa tahun kemudian.
• Kerangka kerja ini memungkinkan Anda untuk mempercepat peluncuran proyek perangkat lunak berdasarkan pesanan. Pastikan untuk memeriksa ketersediaan dokumentasi yang baik dan tentukan periode dukungan untuk kerangka kerja sehingga tidak ada masalah dengan penulisan ulang lengkap dalam 2-3 tahun. Ini adalah kasus yang sangat sering terjadi pada pelanggan kami.
• Jangan percaya pada kemampuan tim untuk belajar - ada terlalu banyak gangguan dalam hidup dan situasinya semakin buruk. Pelajarilah resume Anda dengan hati-hati, periksa sertifikat dan ujian dan cobalah untuk fokus sebanyak mungkin pada hasil praktis. Letakkan praktik di atas teori, setidaknya pada saat membuat versi pertama dari solusi yang berfungsi.
• Teknologi dan bahasa pemrograman bukan merupakan faktor penentu keberhasilan. Fokus pada membangun proses yang paling penting dan menerapkan pengembangan kunci dan praktik desain. Proses yang benar, sebagai suatu peraturan, dijamin akan mengarah pada hasil yang "benar". « » « », . , 2-3 .

, , !