Pengembangan Tumpukan Penuh

Nov 25 2022

Istilah full-stack developer semakin sering digunakan akhir-akhir ini. Terutama dalam diskusi seputar struktur tim, persyaratan perekrutan atau untuk menyimpulkan kehebatan murni seorang individu.

Foto oleh Mike Marrah di Unsplash

Ketika saya melihat pernyataan semacam ini di CV atau mendengar seseorang menggambarkan diri mereka sebagai full-stack, sejumlah pertanyaan muncul di benak saya:

Apa yang Anda maksud dengan pengembangan tumpukan penuh?
Tumpukan apa yang Anda klaim penguasaannya?
Seberapa luas pengetahuan Anda untuk setiap elemen? Seberapa penuh yang dibutuhkan?

Apakah full-stack developer adalah hal yang nyata? Apakah mereka benar-benar ada?
Jika mereka memang ada mengapa mereka berguna?
Apakah full-stack cara lain untuk mengatakan Jack of all trades, master of none?

Latar belakang

Sebelum kita masuk ke perincian, ada baiknya menentukan apa yang ingin kita kembangkan dan berikan.

Mengklaim sebagai full-stack developer untuk PoC yang berjalan di laptop Anda bisa dibilang merupakan deskripsi yang adil karena Anda adalah satu-satunya orang yang mengembangkan setiap bagian dari solusi tersebut. Skalanya sangat kecil, dan dampak dari desain atau pengembangan yang buruk sangat terbatas. Pada dasarnya Anda membuktikan sebuah konsep yang tidak memberikan layanan, selama itu dapat bekerja selama satu jam demo ke CIO, tidak apa-apa.

Jika kami mendefinisikan solusi sebagai sistem produksi yang menangani data pelanggan langsung dan menghasilkan wawasan / data yang mendorong terciptanya nilai bisnis, situasinya berbeda, dan dampak kesalahan pengkodean atau praktik buruk jauh lebih tinggi.

Untuk keperluan postingan ini, kami akan mempertimbangkan sistem yang memproses data pelanggan nyata dalam jumlah besar (10 GB per hari) (termasuk PII) dan menyediakan layanan bisnis utama dengan ketersediaan minimal 29 detik.

Mengapa full-stack developer berharga?

Mengesampingkan keberadaan orang-orang seperti itu, manfaat yang mereka berikan terbukti dengan sendirinya. Mereka mampu merancang, membangun, dan menjalankan solusi tanpa dukungan eksternal apa pun; ini berarti bahwa semua bengkel desain yang memakan waktu dan rawan kesalahan, integrasi komponen, siklus pengujian, dan serah terima operasi sebagian besar dihilangkan. Tidak perlu menjadwalkan rapat, atau lebih buruk lagi, serangkaian rapat, antara keamanan, platform, DB, ops, … UKM karena Anda dapat merancang, membangun, dan menjalankan solusinya. Sejumlah kecil dari dewa ini (g kecil) seperti pengembang mampu memberikan pekerjaan tim lintas fungsional yang besar dan karena menghilangkan overhead penyerahan, pengiriman juga jauh lebih cepat dan lebih sedikit rawan kesalahan.

Jadi, berdasarkan manfaat yang jelas ini, mengapa tidak ada lebih banyak tim yang terdiri dari orang-orang ini di semua organisasi TI? Mengapa perusahaan tidak aktif merekrut dan melatih untuk membangun tim ninja ini? Apakah karena pengembangan yang setara dengan Batman atau Tony Stark tidak benar-benar ada?

Untuk menjawab pertanyaan ini, kita perlu melihat seperti apa tumpukan yang (sangat) disederhanakan itu.

Tumpukan Sederhana

Saya meninggalkan infrastruktur platform untuk tujuan penyederhanaan.

Melihat elemen-elemen di atas, jelas bahwa menjadi ahli di setiap lapisan akan menantang. Namun, dengan asumsi saya tidak perlu mengetahui SEMUANYA di setiap lapisan, dapatkah saya mengurangi pengetahuan yang diperlukan dan tetap dianggap full-stack? Mengambil Aplikasi Front-End sebagai domain contoh, kami dapat dengan mudah menghapus Android dan iOS dan hanya fokus pada saluran web dan mungkin menyempurnakan lebih jauh dan mengatakan itu terbatas pada Bereaksi, bagaimana itu bisa membantu?

Berdasarkan cakupan pengurangan kami, apa yang perlu saya ketahui tentang aplikasi web React?

Yah pertama-tama Anda akan perlu memahami bagaimana aplikasi satu halaman bekerja terutama prinsip-prinsip inti yang diperlukan untuk membangun, men-debug dan menjalankan aplikasi web dan alat terkait misalnya npm, webpack, manajemen konten, devtools bereaksi, pedoman UX, ...

Anda juga harus sangat paham dengan fungsionalitas yang disediakan oleh pihak ketiga misalnya UI material, redux, bootstrap, … dan solusi manajemen paket seperti npm (termasuk mengelola kerentanan keamanan — biasanya pertimbangan DevOps, lihat catatan selanjutnya).

Bagaimana dengan kinerja misalnya waktu untuk cat konten pertama, waktu untuk interaktif, waktu pemblokiran, … Haruskah saya mengadopsi arsitektur aplikasi web progresif dan / atau pekerja layanan untuk membantu? Anda perlu memahami faktor kinerja dan bagaimana berbagai pola inti dapat membantu memanfaatkan perkakas untuk mendukung analisis, misalnya React DevTools atau Lighthouse.

Aksesibilitas adalah suatu keharusan untuk semua aplikasi terlepas dari apakah aplikasi dikirimkan secara internal atau eksternal. Bagaimana saya memastikan kepatuhan terhadap pedoman WCAG?

Singkatnya hanya di lapisan Front-End banyak yang harus diketahui dan bisa dibilang ini membuatnya tetap ringan. Lapisan yang tersisa tidak berbeda dan dalam banyak kasus kompleksitasnya meningkat. Dan yang lebih buruk lagi, pola dan prinsip arsitektural, praktik terbaik, dan kerangka kerja JANGAN TAMPILAN .

Jadi, dengan asumsi saya telah berhasil menjejalkan pola, standar, praktik terbaik, dan keterampilan langsung untuk setiap lapisan ke dalam kepala saya tanpa meledak, apa lagi yang perlu saya ketahui? Apakah ada kemampuan pendukung yang diperlukan?

Kemampuan Pendukung

Duduk di samping tumpukan teknologi, ada sejumlah kemampuan pendukung yang diperlukan untuk merancang, membangun, mengirimkan, dan menjalankan semua komponen solusi.

Arsitektur & Teknik SW

Kumpulan keterampilan inti untuk mendukung desain arsitektur di seluruh lapisan menciptakan implementasi yang baik dalam bahasa / kerangka kerja apa pun

SOLID (Tanggung jawab tunggal, Terbuka/Tertutup, Pergantian, Segregasi antarmuka, Pembalikan ketergantungan)
kegunaan kembali 'penyakit', pemeliharaan, portabilitas, ekstensibilitas, …
Penskalaan horizontal dan vertikal
Struktur pengkodean
Penebangan
Ulasan kode
…

Setiap lapisan dan komponen dalam setiap lapisan (mengabaikan Front-End dari perspektif saluran web karena diterapkan oleh browser atau biasanya di luar kendali kami karena itu adalah sisi klien) dalam tumpukan yang disederhanakan di atas memerlukan pertimbangan cermat dari perspektif keamanan misalnya

API : TLS, DDoS, autentikasi dan otorisasi, COR, kebijakan keamanan konten, …
Layanan Mikro : TLS (termasuk MA), kontrol akses, manajemen rahasia, validasi masukan pengguna, …
Data : kontrol akses, enkripsi saat istirahat, manajemen kunci, grup dan subnet keamanan jaringan, …
Platform (tambahan) : keamanan jaringan, konfigurasi komponen tetap misalnya ChefInspec

Semua pengembang membutuhkan keterampilan pengujian inti, tidak ada alasan untuk tidak dapat menguji fitur Anda sendiri. Dan dalam lingkungan full-stack yang berarti setiap komponen pada diagram di atas.

Memahami dan mampu menerapkan berbagai jenis dan fase pengujian (sementara tidak menandai pekerjaan rumah Anda sendiri):

Fungsional dan non-fungsional
Kotak hitam vs kotak putih
Unit, integrasi, sistem, penerimaan pengguna, regresi, asap, …

Mengembangkan dan memelihara jaringan pipa Continuous Integration dan Continuous Deployment

Pengaktif inti untuk CICD sering kali dibuat oleh tim terpusat/berdedikasi, tetapi setiap orang setidaknya harus dapat memperbarui dan memelihara saluran pipa. (Ya, saya tahu; jika Anda memiliki tim DevOps, Anda tidak melakukan DevOps tetapi banyak organisasi melakukannya)

Menggunakan alat-alat seperti:

Jenkins, TravisCI, Spinnaker
GitHub, Bitbucket
Sonarqube
Zaproxy
Veracode, Snyk
Docker, Jangkar, Pelabuhan
…

Jika kami mengabaikan pendekatan "Anda membangunnya, Anda menjalankannya", persyaratan pada pengembang full-stack di sekitar operasi disederhanakan secara signifikan

Fokus harus pada membangun aplikasi Anda agar dapat dioperasikan. Termasuk semua kait diagnostik yang diperlukan, log peristiwa, dan buku proses sehingga tim yang menjalankan dapat melakukan triase dan berpotensi menyelesaikan masalah tanpa perlu meminta bantuan dari tim pengembangan

Tentu saja, akuntabilitas untuk kapabilitas di atas kemungkinan akan didasarkan pada bagaimana organisasi Anda dikelola — mungkin pengembangan hanya pengujian unit saja, atau semua pengujian berada dalam tim scrum dengan pengecualian pengujian keamanan. Tetapi jika Anda dapat melakukan pengembangan API dan manajemen pipa CICD tanpa memerlukan dukungan dari orang lain, ini akan menghemat banyak waktu.

Seperti lapisan tumpukan teknologi, cakupan kemampuan pendukung yang diperlukan untuk mengklaim status tumpukan penuh sangat luas.

Kesimpulan

Saya percaya pengembang full-stack yang sebenarnya adalah mitos (sebagian besar) dan sejak stack melampaui menjalankan assembler pada 6502 pada 1980-an. Jangan membodohi diri sendiri dengan berpikir bahwa mendapatkan ujung depan dan menjalankan berbicara dengan beberapa API yang ditulis dalam Node yang berjalan pada simpul K8 berarti Anda adalah pengembang tumpukan penuh.

Orang-orang ini mitos bukan hanya karena kedalaman pengetahuan dan pengalaman yang harus mereka miliki dalam domain teknis yang berbeda, tetapi juga karena cakupan ini terus meningkat — setiap tahun ada perkembangan besar dalam teknologi dan pola di setiap domain, mengikuti sampai saat ini sangat, sangat sulit.

Juga, orang-orang ini umumnya akan meminta lebih banyak uang daripada yang mampu dibayar oleh sebagian besar organisasi TI, tetapi jika mereka benar-benar full-stack, mereka sepadan - seperti iklannya.

Saya mengusulkan bahwa hal terbaik yang dapat Anda capai adalah penguasaan domain pilihan Anda (lapisan tertentu dengan tumpukan teknologi terbatas di dalam lapisan itu) dan, paling banter, kompetensi dan kesadaran akan kurangnya pengetahuan Anda di bidang lain.

Cara yang lebih baik bagi sebuah tim untuk menjadi sukses adalah tidak mencoba untuk merekrut atau melatih full stack developer tetapi malah membuat domain misalnya front-end, back-end, database, dll dan untuk bekerja menuju pengetahuan tingkat ninja dalam domain yang diberikan (sekali lagi tumpukan akan dibatasi) dengan pengetahuan yang tumpang tindih/menyilang ke domain lain dengan antarmuka, standar, praktik terbaik, dan kerangka kerja yang sangat jelas untuk mendukung pengembangan berkualitas tinggi. Jika individu dapat menjangkau beberapa domain pada tingkat ahli, itu bagus, tetapi menurut pengalaman saya, ini benar-benar pengecualian.

Bonus komentar:

Apa yang perlu Anda ketahui untuk menjadi "lebih" sukses sebagai pengembang ilmu data (perhatikan penggunaan kata pengembang di sana daripada istilah ilmuwan data - saya menganggap Anda sudah menjadi ilmuwan data yang baik? Dan jika tidak, saya tidak dapat membantu Anda di sana!). Jika kami mendefinisikan pengembang ini sebagai seseorang yang dapat berkembang di setiap area ini tetapi ahli di bagian Ilmu Data* yaitu target saya yang dikurangi di atas, industrialisasi tumpukan yang lebih luas adalah sesuatu yang akan dilakukan oleh Insinyur Pembelajaran Mesin… tetapi diskusi itu adalah untuk lain waktu.