Hai Baru-baru ini, saya membuat laporan untuk siswa tentang benjolan apa yang dapat diisi dengan melakukan pengembangan web modern. Bagaimana berbagai keputusan yang kami buat selama proses pengembangan terkait, bagaimana pilihan teknologi mempengaruhi ukuran tim, bagaimana ukuran tim mempengaruhi pendekatan pengujian, bagaimana pendekatan pengujian terkait dengan struktur seluruh perusahaan ....

Ternyata sesuatu seperti pencarian dengan pilihan terdistribusi: dari mana bahasa pemrograman untuk memilih dan kepada siapa lebih baik untuk menyewa tim yang akan membuat produk yang paling berguna yang pernah ada. Saya sarankan Anda membaca posting ini, memilih opsi Anda, menyelesaikan pencarian dan mendiskusikan apa yang telah menjadi menyakitkan.

upd - menambahkan beberapa teks ke kat.

Dari ide ke prototipe

Misalkan teman saya Valera dan saya memutuskan untuk memulai. Uber untuk X , atau yang lainnya. Berkumpul di bar, mendiskusikan ide ini, topik keren. Harus dilakukan. Tiga bulan tidak tidur, tidak makan, tidak meninggalkan rumah. Dikembangkan Mereka mulai dan menyadari bahwa tidak ada yang membutuhkannya.

Kesedihan. Ayo coba lagi. Kali ini kami mempelajari pasar, melihat apa yang dibutuhkan pengguna, masalah apa. Kami membuat semacam prototipe sepenuhnya di atas lutut, dengan cepat dan gratis di dua malam. Prototipe lepas landas. Keren, teruskan.

Memilih Teknologi

Sekarang kita dapat mengambil dan membuat aplikasi besar dari prototipe, mengembangkannya. Tetapi untuk ini kita perlu mengambil pendekatan yang lebih serius terhadap pilihan teknologi yang akan kita gunakan.

Bahasa

Dalam rangka. Bahasa apa yang harus ditulis? Anda dapat mengambil fungsional modis: Haskell, Erlang, Lisp (sangat modis di kalangan kakek lebih dari 70). Atau JS pembunuh lainnya, yang sangat keren, dikompilasi ke dalam JS, memiliki semua fitur yang diperlukan. Tetapi kemungkinan besar, kita tidak akan memiliki siapa pun untuk disewa dalam setahun, karena pembunuh JS berikutnya tidak akan lepas landas, dan harus mempelajari kembali atau menulis ulang proyek.

Percobaan nomor dua. Anda dapat memeriksa sesuatu berdasarkan waktu. Misalnya, PHP. Ini adalah bahasa yang baik, kadang-kadang modis untuk dikritik, memiliki kelemahan, tetapi mudah untuk melakukan logika bisnis di dalamnya, cukup cepat, skala yang baik, Anda dapat mempekerjakan orang kapan saja, di mana saja. Tetapi dia tidak terlalu produktif. Oleh karena itu, kita memerlukan banyak besi atau menulis kompiler kita sendiri, seperti yang dilakukan Facebook atau VK.

Lebih banyak opsi? Anda dapat menggunakan Perl, tetapi kemudian tidak ada seorang pun yang akan dipekerjakan kemarin. Lebih?
Jawa Jawa adalah norma. Sebagai bahasa, itu tidak terlalu, menurut pendapat subjektif saya, tetapi JVM adalah mesin virtual yang hebat, semuanya baik-baik saja, ini bekerja dengan cepat, tetapi masih membutuhkan banyak perangkat keras. Dan ketika kami menulis di Jawa pembangun abstrak dari pabrik strategi, alih-alih membuat fitur, pengguna pergi ke pesaing.

Baiklah, kita masih punya Python. Pada prinsipnya, semuanya baik-baik saja. Tapi kami menjalankan aplikasi dengan Python, menggunakan satu inti dari 56, jika tidak ... semuanya baik-baik saja. Atau Anda dapat mengambil sesuatu yang modern: Go, Rust, sesuatu yang lain. Tapi levelnya terlalu rendah, dan kami hanya melakukan fitur untuk waktu yang lama ... Kami masih harus memilih beberapa bahasa. Biarlah JS pada akhirnya, turunlah.

Basis data

Base. JS tanpa basis dokumen - uang sia-sia. Basis dokumen memiliki kelebihan. Mereka memungkinkan kita untuk dengan cepat mengembangkan prototipe, bukan untuk mandi tentang skema, data sosis bolak-balik. Ada banyak plus, minus satu: bubur dari data. Ketika kita memiliki sepuluh, dua puluh atau empat puluh koleksi daripada tiga, ketika kita mencoba untuk merekatkan sesuatu yang baik dan dapat dicerna dari mereka tanpa adanya skema, itu menjadi semakin sulit untuk dilakukan. Sekali lagi kami membuat fitur untuk waktu yang lama.

Ok, mari kita ambil basis relasional. MySQL, PostgreSQL, atau Oracle jika Anda punya cukup uang. Dengan basis data relasional, suatu hari Anda dapat bekerja dan menemukan diri Anda dalam neraka dari transaksi dan penyimpanan. Ini tidak selalu terjadi dengan proyek kami. Tetapi jika itu terjadi, maka seluk-beluk logika ini tidak mungkin diuji. Dan bahkan jika tiba-tiba kita mencapai batas vertikal dari server emas besar tempat kita meng-host basis data, maka akan sangat sulit untuk memisahkannya. Kami melakukan fitur untuk waktu yang lama.

Baiklah Mereka mengambil beberapa basis, ORM menggedor di depannya untuk membuatnya lebih mudah untuk berpindah dari satu SQL ke yang lain. Suatu hari (spoiler: tidak pernah).

Arsitektur

Arsitektur mana yang akan diambil? Guys on Habré menulis bahwa microservices itu keren. Oleg Bunin berkata: "ambil microservices."

Jika Anda mulai dengan microservices, maka dengan probabilitas delapan puluh persen batas-batasnya akan salah karena mereka belum sepenuhnya memikirkan model domain dan kurang memahami di mana harus memotong dan di mana tidak. Plus, mereka semua mengambil layanan microser, menempatkannya dalam batch di seluruh cluster mereka, dan sebulan kemudian muncul pertanyaan: "Bagaimana saya bisa menguji ini semua sekarang?" Layanan sudah berfungsi dalam produksi, tetapi kami tidak mengujinya. Menggunakan metodologi yang dikenal (uji piramida, tes integrasi manual, tes ujung ke ujung), sulit untuk menguji layanan-layanan mikro. Karena itu, kami telah melakukan fitur untuk waktu yang lama.

Baiklah kalau begitu mari kita memukul monolit. Ini adalah ide yang tepat untuk startup. Anda dapat hidup dengan monolit yang luar biasa untuk waktu yang sangat lama dan tidak memiliki masalah. Tetapi jika kita memutuskan untuk memperluas tim, maka kita harus berhati-hati. Skala monolith normal, sedangkan pengembang 20, 30, 50. Selanjutnya, kecepatan pengiriman fitur turun secara eksponensial, dan kami kehilangan pengguna.

Di mana memulai proyek?

Itu semua harus diluncurkan di suatu tempat. 2018, opsi paling logis untuk melakukan ini di cloud. Jalankan itu tidak di awan - anak laki-laki akan tertawa. Tetapi, pertama, ada undang-undang federal 152, yang secara signifikan membatasi pilihan penyedia cloud yang dapat di-host. Kedua, sangat mudah untuk secara tidak sengaja melakukan kunci pribadi ke akun Anda di Amazon di Github, dan seseorang pasti akan datang dan menghabiskan semua uang Anda. Dan jika ini tidak terjadi, maka di beberapa titik tarif cloud akan menerobos Anda.

Anda dapat menyewa pusat data. Mungkin ini awalnya tidak begitu hemat sumber daya, tetapi dalam jangka panjang mungkin akan lebih murah daripada hosting di cloud. Tetapi di sini kita membutuhkan orang-orang yang akan mendukungnya. Dalam pengalaman saya, mereka yang menyukainya dan tahu bagaimana melakukannya, tidak benar-benar suka berkomunikasi dengan orang lain, sehingga mereka diatur dalam departemen. Dan departemennya adalah separatisme. Maksud saya, akan lebih mudah untuk bertukar pengalaman dalam tim admin, tetapi di masa depan ini mungkin tidak bekerja dengan baik. Akan ada pertanyaan dengan memprioritaskan tugas dari kolega lain, dengan sinkronisasi. Spesialis lain tidak akan tahu apa yang terjadi di dalam departemen yang mendukung pusat data kami.
Secara umum, separatisme tidak cocok untuk kita. Secara logis, kita beralih ke masalah merekrut tim.

Tim

Pengembangan

Katakanlah kita menemukan bahasa, basis data, dan di mana akan menjadi tuan rumah proyek. Saatnya merekrut tim. Anda dapat mengambil beberapa orang yang sangat keren yang akan menyelesaikan semua masalah: pengembang seratus kali lipat, ninja backend, Anda mengerti. Mungkin itu akan memberi tumpangan. Namun pada kenyataannya, kemungkinan bintang yang diundang akan:

• dudes beracun yang tidak akan melakukan apa pun dan menciptakan suasana yang buruk di tim,
• atau idealis membangun sedikit demi sedikit sebuah arsitektur yang sempurna, menempatkan ORM di depan pangkalan yang tidak perlu Anda ubah ...

Pada akhirnya ... ya, kami sudah melakukan fitur untuk waktu yang lama. Pilihan lain adalah mengambil cewek dan cowok biasa yang baru saja menulis kode, melakukan fitur dengan baik. Tetapi jika Anda mengambil banyak pengembang yang tidak terlalu berpengalaman dengan latar belakang yang berbeda, mereka dapat menulis kode dengan gaya yang berbeda, melakukan hal-hal yang berbeda, dan dengan ukuran tim yang cukup, semua orang akan sesak, mereka semua akan memiliki kurung kurawal di masing-masing pull-quests masing-masing. Ini tidak terlalu efektif. Bagaimana ini bisa diselesaikan? Bos bisa membaca semua kode. Saya dapat membaca semua pencarian-menarik, dan teman saya dan pendiri Pendiri Valera kemudian akan membacanya kembali untuk kedua kalinya (kalau-kalau, Anda tidak pernah tahu). Jelas bahwa ini tidak skala dan semua fitur secara perlahan dibuat.

Opsi yang lebih tepat adalah menentukan gaya kode untuk perusahaan. Untuk banyak bahasa, sudah ada, dan Anda cukup mengikutinya. Atau jika seseorang benar-benar menginginkannya, Anda dapat mengambil yang sudah jadi dan menariknya sedikit, dan kemudian melihat pull-quests dan mengatakan bahwa kurung kurawal tidak ada di sana, itu harus ada di sana sesuai dengan gaya kode. Anda tidak dapat berdebat dengan argumen seperti itu, tetapi dalam kenyataannya itu tidak jauh lebih baik dari versi sebelumnya, toh kami perlahan-lahan membuat fitur. Pilihan yang benar untuk semua bahasa modern adalah memeriksa ini secara otomatis.

Ok Kami mencetak pengembang, kode ara. Tetapi kami mulai merilis fitur dalam produksi, dan kami perlu memastikan bahwa kami menggulungnya tanpa bug, bahwa tidak ada yang salah dengan kami.

Jaminan kualitas

Kita dapat mengatakan bahwa kita tidak memerlukan spesialis QA. Banyak yang melakukan ini, kadang-kadang berhasil. Tetapi tidak semua pengembang suka menulis tes. Mereka bisa dipahami. Dan lebih baik memotivasi mereka untuk menulis tes, tetapi kenyataannya kejam: tes unit tidak menangkap semua bug. Dan jika beberapa pengembang tidak suka menulis tes dan masih mulai menulisnya, maka kemungkinan besar itu akan menjadi unit test.

Plus masih ada pendekatan ketika Anda meminimalkan waktu rata-rata antara kegagalan bukan waktu rata-rata untuk pulih. Waktu yang berarti antara kegagalan adalah ketika seorang spesialis QA mengatakan: "kami tidak akan merilis, saya memiliki bakat yang buruk, akan ada bug, mari kita mulai dalam dua minggu." Dan waktu yang berarti untuk memulihkan adalah ketika Anda menggulung sesuatu, Anda segera melihat pada metrik bahwa ada sesuatu yang rusak, dan setelah dua menit semuanya dibatalkan, diperbaiki dan semuanya baik-baik saja. Tetapi untuk memutar kembali proyek dalam dua menit, Anda harus menutupi semuanya dengan metrik normal, dan ini tidak selalu sepele. Dan jika metrik berada dalam kondisi menyedihkan, dan kami meluncurkan rilis yang buruk, kami dapat mengetahuinya setelah semua pengguna menyerahkan kami ke pesaing.

Pilihan lain: masih membuat departemen QA. Anda ingat: departemennya tidak terlalu bagus, itu separatisme, tidak cocok untuk kita. Separatisme dapat diatasi dengan bantuan tim lintas fungsi. Ya, mereka memecahkan masalah bahwa admin kami duduk terpisah, penguji terpisah.

Tetapi mereka menciptakan masalah lain. Karena pengembang, penguji, dan semua anggota tim lintas fungsi lainnya mulai berkomunikasi lebih banyak di dalam tim mereka dan menyelesaikan masalah sebelumnya, mereka kurang berkomunikasi dengan kolega mereka dalam fungsi mereka: back -ders dan penguji lainnya, mereka mulai menemukan kembali roda, melakukan hal yang sama secara paralel, isolasi antar tim. Penusuk untuk sabun: ada satu separatisme, itu menjadi yang lain.

Bagaimana cara mengatasinya? Berkomunikasi dengan kolega dalam kelompok hobi. Di suatu tempat itu disebut guild, di suatu tempat itu adalah komunitas. Jika kami skala tim dengan tim lintas-fungsional sehingga mereka tidak mandiri, kami hanya mengatur lingkaran penggemar backend, bahasa fungsional, keamanan ...

Ringkasan

Padahal, tidak semuanya buruk. Anda dapat menemukan jalan keluar dari situasi apa pun, menemukan solusinya. Mungkin tidak ideal, tetapi paling cocok dalam situasi ini dengan masalah minimal. Kompromi selalu memungkinkan.

Namun - semua ini menarik. Sangat menarik untuk memecahkan masalah yang telah diselesaikan seseorang, masalah baru bahkan lebih menarik untuk dipecahkan. Sangat menarik untuk berbagi pengetahuan.