Halo, nama saya Pavel dan saya full-stack di Mad Devs * tepuk tangan *.Terhadap latar belakang sejumlah besar artikel dan bahan tentang fakta bahwa
tumpukan penuh tidak diperlukan ,
tumpukan penuh tidak ada ,
tumpukan penuh buruk , ada pendapat tentang
keuntungan tumpukan penuh dibandingkan spesialis , dan mengapa
tumpukan penuh diperlukan .
Saya ingin meninggalkan daftar tautan ke artikel lain tentang tumpukan penuh di awal artikel, tetapi jumlahnya terlalu banyak, jadi saya minta maaf. Saya hanya ingin mengatakan bahwa ada cukup bahan tentang mengapa tumpukan penuh itu baik dan mengapa tumpukan penuh itu buruk. Dan masing-masing dari mereka setidaknya 50% benar.
Mungkin ada emosi dan pikiran pribadi yang tidak mengklaim sebagai pilihan terakhir.
Seperti yang sudah saya katakan, nama saya Pavel, akan segera 7 tahun sejak saya mendapatkan uang untuk pemrograman. Dan selama periode ini saya menyebut diri saya di resume, di wawancara dan di tempat lain:
Backend developer dengan pengetahuan dan keterampilan di Frontend dan DevOps . Dalam satu atau lain cara, dalam karier profesional, ia sering bekerja sebagai pendukung proyek, tetapi ia tidak pernah takut pada front atau ops. Karena itu, ia dengan bangga menambahkan kedua area ini ke dalam uraiannya. Benar, dengan kedatangan Mad Devs dan, setelah mengerjakan salah satu proyek dengan tim MadOps kami, saya menghapus DevOps dari deskripsi saya, karena sekarang saya percaya bahwa saya tidak mengerti sama sekali. Segala sesuatu dalam perbandingan diketahui, seperti yang Anda tahu. Saya berharap suatu hari nanti akan bekerja dengan spesialis front-end yang sama yang akan "membujuk" saya untuk menghapus nota tambahan front-end. Hal utama adalah tidak bertemu backender, yang akan memaksa Anda untuk menghapus backend dari resume, jika tidak maka tidak ada yang tersisa.
Argumen paling sering dari para ahli yang menulis dan percaya bahwa tumpukan penuh adalah suara yang buruk seperti ini:
Tidak ada perendaman di salah satu bidang ,
Anda tidak bisa menjadi Pengembang Fullstack Senior ,
spesialis kelas tinggi yang sempit menghasilkan lebih dari tumpukan penuh yang kuat , dll. Dan Anda tahu, saya setuju dengan mereka.
Selama beberapa bulan terakhir, saya telah mengerjakan proyek Alat Peklo, yang menggunakan Ruby di backend, VueJS di depan, dan Go untuk mengimplementasikan generator teks.
Dan saya merasakan masalahnya:
- Saya merasa bahwa kode ini dapat ditulis lebih baik, dan akan bekerja lebih cepat atau menggunakan lebih sedikit sumber daya sistem;
- Saya merasa bahwa konfigurasi webpack saya dapat dikonfigurasi lebih baik, ada banyak sampah di dalamnya sekarang;
- Saya merasa bahwa tata letak ini dapat dilakukan menggunakan CSS modern, fitur SCSS, atau mengambil PostCSS atau ekstensi lain;
- Saya merasa bahwa kode pada rel dapat dioptimalkan sehingga lebih sedikit permintaan dalam database dibuat, misalnya;
- Saya merasa bahwa indeks perlu dikonfigurasi secara manusiawi dalam database;
- Saya merasa bahwa Dockerfile ini perlu ditulis ulang sehingga ada lebih sedikit (atau lebih) lapisan;
- dan seterusnya, seterusnya, seterusnya ...
Saya bisa merasakan semuanya. Apalagi saya benar-benar ingin melakukan semuanya. Dan, ketika satu menit gratis muncul, saya menyelesaikan sebagian setidaknya satu dari masalah ini.
Anda bertanya kepada saya:
mengapa Anda tidak segera menggunakan benda N di tempat ini sehingga tidak ada masalah seperti itu?Dan saya akan menjawab:
Saya tidak tahu hal N, begitu baik sehingga saya dapat dengan cepat menerapkannya dalam proyek dalam kasus tertentu. Saya hanya mengambil waktu dari pengembangan - baca masalahnya:
Tidak ada perendaman lengkap .
Dan saya tidak akan berbohong, karena proyek yang saya kerjakan membutuhkan fitur. PekloTool adalah alat profesional untuk menghasilkan kampanye iklan kontekstual. Alat ini masih muda, pengembangan telah berlangsung selama lebih dari setahun, tetapi sudah mulai berproduksi penuh beberapa bulan yang lalu. Hasilnya, sekarang kami melakukan semua fitur yang berguna untuk produk semacam itu.
Bagaimana saya tahu bahwa fitur diperlukan dan fitur itu akan berguna? Sangat sederhana
karena saya tumpukan penuh . Saya melihat seluruh proyek. Saya melihat tujuan proyek, saya melihat cara kerjanya, saya melihat tiang temboknya, tidak hanya yang teknis yang saya tulis di atas, tetapi tiang tembok yang akan dilihat pengguna.
Dan di sini kita sampai pada poin utama dari artikel ini: Saya percaya bahwa tumpukan penuh modern tidak boleh hanya sebuah encoder yang dapat melakukan backend, front-end, atau yang lainnya. Fullstack adalah seseorang yang terlibat dalam pengembangan proyek. Selain kompetensi backend, frontend, dll tumpukan penuh harus memiliki pemahaman tentang bidang subjek proyek, pengetahuan UX / UI dan bahkan sedikit pemasaran. Fulstack harus tahu bagaimana proyek memenuhi tugas utamanya: apakah itu menghasilkan uang atau menyelamatkan dunia. Tumpukan penuh harus berjalan kaki singkat dengan "pelanggan" proyek. Setiap proyek memiliki "pelanggan", jika perusahaan outsourcing, itu adalah pelanggan, di perusahaan produk itu adalah pemangku kepentingan atau produk. "Pelanggan" harus melihat dalam tumpukan lengkap yang spesialis dengan siapa Anda dapat berkonsultasi tentang semua masalah mengenai proyek.
Dalam buku pegangan dari Mad Devs pendatang baru (dokumen yang sama yang Anda baca pada hari pertama perusahaan) ada item yang disebut: "Affinity Pelanggan" (
Eng. - "Kedekatan pelanggan"). Saya menggambarkan esensi istilah dalam paragraf sebelumnya. Setumpuk penuh harus selalu diletakkan di atas topi pelanggan, opsi yang ideal adalah ketika "pelanggan" membuat tugas lari bersama-sama dengan tumpukan penuh. Artinya, setumpuk penuh memahami sejarah penampilan setiap tugas, dan tidak hanya menyelesaikan tugas yang diberikan. Saya percaya bahwa jika seseorang hanya melakukan tugas dan pekerjaannya berakhir di sana, bahkan jika dia melakukan backend, frontend, ponsel, dll., Ini bukan tumpukan penuh. Ini hanya back-end yang dapat melakukan front-end, atau sebaliknya.
Jadi saya menulis semua ini, dan pembaca mungkin memiliki dua pemikiran:
- omong kosong apa Di sini untuk masing-masing. Jika Anda berpikir demikian, kemungkinan besar Anda adalah spesialis sempit, maka pendapat Anda jelas. Tapi, jika Anda full-stack, saya akan “membuat Anda bahagia”. Anda kehilangan lapisan besar kegiatan yang bermanfaat yang akan bermanfaat bagi proyek Anda, dan juga kehilangan peluang untuk memperoleh kompetensi penting yang dapat menentukan pengembangan karier Anda selanjutnya;
- Apakah ini tumpukan penuh seharusnya pada pemilik produk? Ya kamu benar Dengan pengecualian beberapa poin: product-oouner sering menjadi pemimpin tim dari keseluruhan proyek. Saya tidak akan mengaitkan kualitas kepemimpinan dengan setumpuk penuh. Ini tentang hal lain. Nah, produk-oouner harus dapat mempertimbangkan biaya pengembangan proyek, setumpuk penuh tidak diperlukan untuk memikirkan keuangan yang terkait dengan pengembangan. Dari posisinya, sudah ada uang untuk pengembangan. Tentu saja, ia dapat menawarkan opsi untuk mengurangi biaya pembangunan, tetapi hanya dalam bentuk persentase atau kualitatif, bukan secara kuantitatif. Mungkin beberapa saat saya kehilangan beberapa hal yang seharusnya bisa dilakukan oleh produk, tapi saya bisa, saya penuh.
Ada sisi lain dari koin yang ingin saya gambarkan. Ini
menyedihkan . Masalah dengan tumpukan penuh adalah bahwa mereka kelebihan beban. Ini jelas. Sebagai aturan, kami melakukan tugas yang sangat banyak, fitur yang kompleks. Kami masih berkomunikasi dengan pelanggan untuk mendapatkan fitur dan tugas yang saya tulis di atas. Plus, ketika Anda melihat keseluruhan proyek dari sudut pandang teknis, Anda sering mengerjakan infrastruktur, arsitektur, dan hal-hal lain. Semakin banyak informasi, semakin banyak gagasan, dan semakin banyak gagasan, semakin besar peluang mereka untuk menjadi kenyataan. Akibatnya, Anda sering berpikir: mungkin basis data NoSQL, atau mungkin GraphQL, atau mungkin yang lain. Di sinilah lapangan kerja muncul dengan sendirinya. Saya tidak berbicara tentang fakta bahwa saya segera menjalankan untuk mentransfer semuanya ke GraphQL bersyarat, tetapi Anda kadang-kadang menerima beberapa ide yang lebih kecil sendiri dan menerapkannya. Singkatnya, sangat sibuk.
Apakah kamu mau apa? Saya ingin mencoba perpustakaan baru, mempelajari konfigurasi Gitlab CI lebih banyak, merokok sesuatu yang menarik dan relatif baru untuk diri saya sendiri di depan, misalnya, Logux. Tetapi tidak ada waktu, Anda bertanggung jawab untuk proyek tersebut. Saya tidak akan mengatakan bahwa
kesedihan ini, hanya kesedihan yang menyedihkan. Sebaliknya, saya mendapat perhatian besar: mulai saat saya melihat ulasan positif dari pengguna; ketika mereka dengan senang hati menulis tentang fitur karena Anda tidak tidur selama beberapa hari; ketika jumlah pengguna bertambah.
Sebagai kesimpulan, saya menyatakan gagasan bahwa spesialis yang sempit dan luas memiliki kelebihan mereka sendiri untuk proyek, karier, lingkungan, dan kerugian mereka. Menurut pendapat saya, saya akan menjelaskan kelebihan dan kekurangan profesional tertentu dalam salah satu materi berikut, kecuali tentu saja ini diterima dengan hangat.
Saya senang bahwa saya penuh, karena ini adalah pekerjaan yang saya sukai, yang saya tidak keberatan lakukan pada akhir pekan, dan yang saya lakukan dengan senang hati.