Konten
1. Pengantar
Perangkat lunak adalah industri yang bergerak cepat. Umur beberapa keterampilan sebenarnya tampaknya menurun seiring waktu; bahasa dan kerangka kerja memiliki umur yang terbatas. Oleh karena itu, salah satu kebiasaan yang paling penting untuk dikembangkan adalah mempertahankan pemahaman tentang 'praktik terbaik' saat ini. Praktik terbaik adalah pola teknik, teknologi bantu, kebiasaan, dan platform yang dapat membantu tim pengembangan perangkat lunak dalam menghasilkan perangkat lunak berkualitas lebih tinggi secara lebih efisien.
Praktik terbaik berubah tergantung pada waktu dan lingkungan di mana kode diproduksi. Perusahaan pertama yang pernah saya magangi memproduksi perangkat lunak perutean faks untuk perusahaan raksasa. Proses penerapan mungkin melibatkan pengiriman teknisi ke lokasi dengan hard drive untuk mentransfer versi baru. Perusahaan tempat saya bekerja saat ini dapat membangun server yang dihosting AWS beberapa kali sehari tergantung pada berapa banyak perubahan kode yang telah dilakukan pada hari tertentu. Ini adalah contoh bagaimana 'waktu untuk melepaskan' telah dikompresi selama 25 tahun terakhir menjadi hampir seketika di beberapa lingkungan. Dengan demikian, praktik terbaik untuk mengelola perubahan yang sangat cepat juga perlu berkembang.
Saat menggunakan praktik terbaik, dukungan kode dan hutang teknis kurang memberatkan baik untuk programmer individu dan perusahaan secara keseluruhan. Kode yang dibuat dengan praktik terbaik cenderung memiliki masa pakai yang lebih lama, serta biaya perawatan yang lebih murah. Selain itu, pewarisan kode ini lebih mungkin menjadi solusi yang bisa diterapkan untuk masalah yang awalnya tidak dirancang untuk dipecahkan oleh kode. Dan, mungkin yang paling penting bagi sebuah organisasi, pergantian pengembang/pembagian tanggung jawab jauh lebih mudah. Sementara beberapa pengembang membuat kode untuk keamanan pekerjaan, pengkodean untuk keusangan Anda sendiri lebih baik untuk reputasi dan keandalan kode Anda.
Praktik terbaik inti adalah dasar dari reputasi programmer yang baik. Praktik terbaik pertama dan terpenting sebenarnya cukup tidak logis: tulis lebih sedikit kode. Hal ini diperkuat dengan membuat lingkungan — dan interaksi antar lingkungan — sesederhana dan dapat diandalkan. Saat melakukan ini, cobalah untuk menghindari membuat kesalahan keamanan dasar. Kemudian biasakan pengujian unit, karena semua orang suka tidur… dan jika Anda tidak menulis pengujian unit, Anda tidak bisa tidur dengan andal! Terakhir, jika Anda bisa, siapkan lingkungan bangunan dan pengujian yang terintegrasi. Ini telah menjadi bagian mendasar dari setiap pendekatan praktik terbaik.
Namun, ingatlah bahwa semua praktik ini akan berubah seiring waktu dan berkembang. Jadi menyadari tren industri dan tetap berada di depan kurva pada dasarnya penting untuk mengetahui kebiasaan dan alat mana yang harus Anda adopsi/asuh atau biarkan berhenti berkembang.
Oleh karena itu, sebagai pengembang berpengalaman, tetap waspada terhadap praktik terbaik saat ini — dan menggabungkan 'apa yang dilakukan anak-anak keren' dengan apa yang sudah Anda ketahui — adalah keterampilan yang penting. Sumber utama pribadi saya untuk informasi ini adalah posting pekerjaan, survei stack overflow, dan berbagai forum forum. Tetapi mengetahui apa yang terjadi, dan menerapkannya, adalah tugas yang terpisah.
Umumnya, pengetahuan menerapkan praktik terbaik adalah tugas yang lebih berat daripada mengetahui apa adanya. Waktu yang diperlukan untuk mempelajari kembali suatu kebiasaan (misalnya mengingat untuk menggunakan komentar yang cukup), atau membangun kembali lingkungan yang saat ini nyaman, sering kali tampak mahal atau membuat frustrasi untuk mempertahankannya di awal. Dan, sayangnya, itu. Tetapi ada banyak cara untuk belajar menerapkan praktik terbaik baru, dan itu pasti layak dilakukan.
2. Praktik Terbaik Inti
Terlepas dari apa yang terbaik untuk dilakukan, beberapa hal akan selalu menjadi praktik terbaik inti yang akan disetujui oleh sebagian besar pengembang:
- Tulis lebih sedikit kode
- Buat lingkungan sesederhana mungkin
- Hindari masalah keamanan standar
- Tulis tes unit dasar
Keempat praktik ini merupakan inti dari memiliki kode yang lebih dapat dipelihara dan digunakan kembali.
Tulis Lebih Sedikit Kode
Basis kode cenderung membengkak. Ketika masalah ditemukan, mereka cenderung diperbaiki secepat mungkin, dengan dampak minimal pada kode yang berjalan dan berfungsi. Saya telah bekerja di tempat-tempat di mana potongan kode penting dikelilingi oleh cabang-cabang kecil yang menangani masalah pemangku kepentingan. Ini, tentu saja, adalah tradeoff.
Kode lama sering memiliki masalah struktural yang membatasi perluasan atau implementasi ulang, tetapi pada saat yang sama berisi beragam fitur yang sangat spesifik. Jadi, ketika basis kode membengkak, itu membengkak dengan perbaikan untuk masalah yang dihadapi pelanggan atau terkait arsitektur. Dengan demikian, menghancurkan seluruh basis kode Anda selalu lebih mahal daripada yang terlihat, dan Anda ingin bekerja sangat keras untuk menjaga kode/lingkungan minimalis.
Praktik terbaik yang paling penting sebagai pengembang adalah menulis kode yang lebih sedikit dan lebih cerdas. Seperti yang biasa dibor ke dalam diri saya sebagai seorang anak: Kurangi, Gunakan Kembali, Daur Ulang. Kurangi jumlah kode yang Anda tulis, gunakan kembali kode Anda sendiri dan programer lain secara teratur, dan daur ulang ke lebih banyak ruang hard drive bila Anda bisa.
Untuk membantu Anda melakukan ini, baca kode orang lain sesekali. Kode Anda akan meningkat, jika Anda membacanya secara kritis, dan kode mereka akan meningkat jika Anda menyebutkan masalah yang Anda lihat di dalamnya. Membaca dengan maksud membuat modifikasi kecil (dan bahkan membuatnya) akan membuat tugas ini jauh lebih bermakna, jadi saya melakukan ini jika waktu memungkinkan. Perhatikan bahwa jika Anda melakukan pembersihan tidak terjadwal dalam pengaturan profesional, mendorong tambalan ke kode produksi sering kali tidak disukai. Saya sarankan untuk membicarakan apa yang Anda lakukan dengan pengelola resmi terlebih dahulu.
Mempelajari 'Pola Desain' mungkin atau mungkin tidak membantu Anda mengatur kode Anda lebih efektif, tetapi mencari tahu bagaimana para akademisi berpikir solusi untuk masalah umum harus diatur adalah cara yang baik untuk memberi Anda kerangka untuk organisasi masa depan. Akhirnya, pada struktur kode, sesuatu yang saya rasa harus selalu saya sebutkan adalah: jika Anda memikirkan sesuatu, dan yakin itu brilian, kemungkinan besar Anda salah.
“Optimasi prematur adalah akar dari segala kejahatan” — Donald knuth
Sebagai seseorang yang memelihara basis kode yang ditulis oleh pengembang yang percaya pada kekuatan magisnya sendiri, saya secara pribadi dapat membuktikan fakta bahwa mereka mengecewakannya secara teratur. Pada dasarnya, sebagian besar kode ditulis satu atau dua lapisan abstraksi di atas kompiler.
Penulis kompiler adalah profesional kinerja dan logika, dengan fokus pada pengoptimalan kode tingkat perakitan. Ketika, dalam bahasa tingkat yang lebih tinggi yang digunakan oleh lebih dari 95% programmer profesional, Anda khawatir tentang pengoptimalan, Anda (umumnya) membuat kesalahan. Jika Anda melampaui pemrograman dengan dasar-dasar yang baik, yang mungkin Anda inginkan adalah pengaturan lingkungan yang lebih tepat.
Lingkungan harus sederhana dan padat
Semakin unik dan rumit komponen yang dimiliki suatu sistem, semakin sulit seluruh sistem untuk memahami dan melakukan refactor. Dengan demikian, praktik terbaik modern cenderung memfokuskan kode unik dalam suatu sistem ke dalam bagian-bagian yang digabungkan secara longgar, dan bagian-bagian yang digabungkan secara longgar ini sesederhana mungkin untuk dikerjakan. Ambil tiga lingkungan ini, misalnya:
Di sebelah kiri adalah tumpukan LAMP standar. Selama sepuluh tahun, tumpukan pemrograman utama untuk pengembangan web tumpukan penuh adalah Linux Apache MySQL PHP. Tumpukan ini mencakup semua yang Anda butuhkan untuk membuat aplikasi web sisi server yang menampilkan halaman HTML statis kepada pengguna, dan masih ada orang yang mengirimkan data dengan tumpukan ini hari ini.
Tumpukan perangkat lunak tengah adalah pendekatan yang lebih modern. Sangat modern sehingga menghindari ORM dan memiliki pengembang yang menulis kueri MongoDB/SQL mentah. Keputusan ini dibuat untuk meningkatkan kecepatan pengembangan, dengan mengorbankan beberapa fitur yang termasuk ORM. Ujung depan tumpukan perangkat lunak ini mencakup React, yang pada dasarnya adalah lingkungan pengembangan kompilasi sendiri yang menggunakan npm untuk membangun kode yang dapat digunakan. Ini kontras dengan penyertaan Javascript/Silverlight di lingkungan sekolah lama (relatif) di setiap halaman.
Tumpukan perangkat lunak di sebelah kanan bahkan lebih terkotak daripada dua lainnya. Kerangka Istirahat Django mungkin digunakan untuk berinteraksi dengan klien Angular menggunakan Pola desain MVC. Django memiliki ORM yang terpasang di dalamnya, dan ORM itu dapat berbicara dengan basis data apa pun yang Anda gunakan serta MongoDB. Dalam contoh ini, Ngnix dipilih karena sedikit lebih ringan dari Apache dalam beberapa hal. Dan contoh ini, seperti contoh sebelumnya yang lebih 'modern', menggunakan cloud hosting karena lebih murah meminta orang lain mengelola kegagalan perangkat keras Anda sampai Anda menggunakan ton (mungkin secara harfiah) perangkat keras.
Namun, secara keseluruhan, lingkungan ini cenderung mengabstraksikan kompleksitasnya menjadi bagian-bagian yang terisolasi. Tidak ada pengembang atau teknisi yang bisa mengetahui segalanya. Hasilnya adalah seiring waktu, kode yang paling rumit untuk ditulis umumnya telah diabstraksikan. Contoh utamanya adalah komponen lingkungan yang digunakan secara luas oleh para ahli kelas dunia yang menulis dan memelihara daripada pengembang internal: server web, jaringan, NOC, dan mesin basis data. Jadi 'perlu diketahui' Anda sebagai pengembang standar jarang akan mencakup penyimpanan jutaan titik data di B-Tree, mencari tahu bagaimana menjaga database agar tidak memiliki kondisi balapan, atau menghindari kebocoran memori selama jendela uptime 99.9999% server web.
Banyak lingkungan modern mengandung ORM, sampai pada titik di mana pengembangan database telah mengurangi nilai sebagai pilihan karir. Setelah menulis prosedur tersimpan yang berisi 1000+ baris kode, seseorang berkata, "SQL itu keren, tapi Anda tidak bisa berbuat banyak dengannya" bagi saya pernah... mengecewakan. Tapi ada alasan untuk ini: sebagai praktik terbaik, kode tidak boleh disimpan di database Anda. ORM modern seperti Entity Framework, model Django, dan Hibernate (yang belum saya gunakan) mengabstraksi database dari kode. Namun, pasti ada tradeoff antara memiliki Administrator Basis Data yang dapat menyesuaikan struktur data untuk kinerja dan memiliki pemrogram yang dapat membuat dengan bebas.
Tetapi kebanyakan, ORM juga mengabstraksi komunikasi antara dua sistem: kode dan data. Standar komunikasi seringkali berakhir sangat kompleks. Hasil? Mereka cenderung menjadi abstrak. Saat mengajar Python di kamp pelatihan, salah satu siswa saya ingin menggunakan API Twitter secara mendalam. API Twitter luas dan berfitur lengkap. Oleh karena itu, beberapa fitur khusus hanya tersedia jika Anda menggunakan OAuth 1 daripada OAuth 2.
Ternyata di mana OAuth 2 memiliki beberapa langkah sederhana dan andal, OAuth 1 adalah… bizantium. Hal ini menyebabkan pengembangan standar OAuth 2 yang lebih sederhana dan berbagai perpustakaan yang dirancang untuk mengelola handshaking. Secara umum, sangat masuk akal untuk mencoba dan menjaga metode komunikasi Anda sesederhana mungkin dan data Anda tetap bersih. Untuk alasan ini, komunikasi TCP/IP umumnya dilakukan dengan perpustakaan dan data yang diteruskan dengan JSON. Situs web menggunakan REST. Kompartemenisasi dan antarmuka investasi waktu rendah yang andal adalah norma, dan seharusnya begitu.
Dan membuat komunikasi dengan investasi rendah itu bekerja secara konsisten membutuhkan tes. Tes menulis tidak menyenangkan pada awalnya. Anda tahu apa yang ingin Anda lakukan, dan Anda tahu kasus penggunaan Anda, jadi mengapa menulis tes? Karena itu mengharuskan Anda untuk berpikir dua kali dan akan mengirim Anda ke arah yang lebih baik secara keseluruhan.
Tes unit bukanlah praktik terbaik inti sampai Integrasi Berkelanjutan dimungkinkan, tetapi sekarang, bekerja dengannya adalah hal yang mendasar. Pengujian end-to-end lebih sulit untuk disiapkan, tetapi sekarang juga merupakan praktik terbaik inti. Ini karena seiring perkembangan yang semakin cepat, pengembang menjadi bertanggung jawab atas lebih banyak sistem.
Jika sistem rusak, waktu yang Anda habiskan untuk memperbaikinya adalah waktu yang dapat Anda gunakan untuk membangun sesuatu yang baru. Jadi dalam jangka panjang, pemuatan awal semua jenis pengujian otomatis memungkinkan Anda mengurangi keseluruhan waktu yang Anda habiskan untuk pemeliharaan situs. Dan, terlebih lagi, memungkinkan Anda untuk tidur lebih nyenyak (Anda tidak menyadari betapa menyenangkannya tidur sampai Anda terbangun pada pukul 3:00 pagi untuk mencari catatan transfer uang). Karena pengujian sangat penting, banyak tim menggunakan Pengembangan Berbasis Tes, yang landasannya adalah menulis tes sebelum Anda menulis satu baris 'kode' yang memecahkan masalah Anda.
Akhirnya, dalam membuat lingkungan Anda sederhana dan solid, saya merekomendasikan dokumentasi. Tidak ada yang namanya kode dokumentasi diri. Memilih nama variabel deskriptif yang sederhana sangat membantu, tetapi menempatkan sedikit penjelasan di bagian atas kelas atau fungsi tidak akan membunuh Anda. Saya berjanji. Mungkin, sebaliknya, membantu Anda menemukan transfer uang di log di tengah malam.
Hindari Masalah Keamanan Sederhana
Tidak ada yang tahu apa-apa tentang keamanan digital. Saya yakin Anda lima dolar Anda dapat memasukkan 'data pelanggaran' ke dalam mesin pencari pilihan Anda sekarang dan menemukannya. Ini sebagian karena dunia ini besar dan keamanannya sulit, tetapi terutama karena sistem apa pun memiliki lubang keamanan. Jadi tugas utama Anda sebagai pengembang sebenarnya bukan untuk membuat sistem Anda antipeluru, tetapi untuk menghindari memberi tanda 'masuk ke sini' yang besar.
Saat-saat kode saya dilanggar adalah ketika saya menggunakan kata sandi default, atau memiliki pintu belakang pengembangan terbuka lebar yang saya tutup hanya untuk membuat orang lain membuka lagi. (Sumpah. Tentu saja. Tidak pernah salahku, bahkan sekali pun.) Secara umum, Anda ingin menghindari hal-hal yang paling sederhana dan berharap Anda adalah target yang lebih sulit daripada aplikasi atau database berikutnya.
Keamanan komunikasi intra dan antar-proses adalah tempat kelemahan keamanan yang Anda buat secara pribadi. Dengan demikian, kerangka REST dan komunikasi objek sederhana adalah standar industri. Di mana ini mulai salah adalah di mana Anda mengambil objek sederhana yang telah Anda lewati dan menjalankannya sebagai input secara terprogram. Misalnya, mengambil objek JSON dari pos HTTP, melakukan deserialisasi, dan melemparkan variabel dari sana ke kueri secara langsung sebagai string. Ini berarti bahwa ketika Anda meneruskan variabel, Anda ingin memastikan jenisnya semaksimal mungkin.
Di mana kode Anda berakhir — dan perpustakaan Anda dimulai — adalah tempat kesalahan keamanan yang belum Anda hasilkan secara pribadi akan muncul. Ketika saya melihat perpustakaan yang sudah ketinggalan zaman, saya juga melihat catatan tempel untuk versi baru. Alasan Microsoft menambal komputer Anda dua kali seminggu bukan karena mereka suka menghabiskan uang untuk pemrogram. Itu karena OS yang banyak digunakan seperti Windows memiliki ribuan pemrogram yang mencoba untuk memecahkannya setiap saat. Jika salinan lokal Windows Anda kedaluwarsa, Anda membuka diri terhadap lebih banyak kerentanan. Server dan kerangka kerja Anda tidak jauh berbeda.
Di sisi pribadi, Anda juga tidak ingin ingatan Anda menjadi satu titik kegagalan. Jika Anda bertanggung jawab atas sistem (yang, karena pekerjaan 'pengembang' semakin besar, lebih mungkin) pada akhirnya Anda akan memiliki banyak kata sandi, kunci SSH, sertifikat server, dll untuk dikelola. Mereka umumnya berbasis teks, jadi saya sarankan mencari pengelola kata sandi dan menggunakannya. (Suka Troy Hunt, saya menggunakan KeePass dan gratis). Itu juga menghasilkan kata sandi, jadi Anda tidak punya 'Naga94!' sebagai kata sandi Anda untuk 75 situs dan sistem yang berbeda. Gunakan generator untuk membuat yang besar, salin file kata sandi Anda sesekali, dan lanjutkan. Juga, putar kata sandi dan kunci ini secara teratur. Jangan berakhir di Slashdot.
Terakhir, hindari injeksi kueri. Ini mudah dilakukan, dan hampir tidak disebutkan lagi karena kerangka kerja ORM/REST cenderung memblokirnya. Tidak sempurna, tentu saja, tapi cukup baik. Jika Anda akan menjalankan sesuatu yang berasal dari komunikasi antar atau intra-proses, pastikan itu hanya satu kueri sebelum Anda menjalankannya. Selesai.
Kontrol Sumber, Integrasi Bangun, dan Integrasi Uji
Praktik terbaik inti terakhir yang harus saya sebutkan adalah kontrol sumber, integrasi build, dan integrasi uji. Jika Anda tidak menggunakan kontrol sumber, Anda tidak mengetahui di mana kode Anda berubah, atau bagaimana kode itu berubah. Selain itu, jika Anda tidak menggunakannya, Anda akan lebih tersesat daripada yang diperlukan.
Mengenai integrasi, Jenkins dan TeamCity merasa seperti seseorang telah menemukan api, jika Anda belum menggunakannya. Untuk bacaan lebih lanjut, ini adalah awal yang baik. Memiliki sistem yang menjalankan pengujian unit dan dibuat untuk Anda berarti penerapan dapat diandalkan. Deployment menjadi andal berarti rilis lebih merupakan pertanyaan "Apakah kode dan pelanggan siap satu sama lain?", daripada "Kapan tepatnya, kita dapat menjadwalkan semua ini sehingga benar-benar akan bersatu?"
Saya melakukan beberapa otomatisasi QA untuk grup Wells Fargo sepuluh tahun yang lalu, dan rilis dijadwalkan seperempat kali, mulai pukul 2:00 pagi dengan 2-3 jam penerapan dan 4-n [N menjadi, dalam beberapa kasus, 28] jam dari pengujian. Tidak semua pengujian yang perlu kami lakukan dapat dilakukan dengan server integrasi sekarang, tetapi rilis itu sendiri akan lebih lancar dengan teknologi saat ini. Dan untuk menggunakan teknologi yang lebih baik, Anda perlu tahu apa itu, dan tren saat ini.
3. Melacak Tren Industri
Kecepatan dan efisiensi prosesor mungkin meningkat dua kali lipat setiap beberapa tahun selama beberapa dekade, tetapi pemrograman bergantung pada manusia — dan kami berubah jauh lebih lambat. Jika Anda mengawasi alat dan praktik baru yang digunakan orang lain untuk menghasilkan perangkat lunak, Anda juga dapat mengadopsinya untuk membantu produktivitas Anda.
Tempat terbaik untuk mengetahui teknologi dan praktik baru apa yang efisien adalah lowongan pekerjaan. Banyak pekerjaan (terutama di perusahaan kecil) tidak pernah mencapai papan pengumuman yang luas, jadi begitu sebuah perusahaan beriklan secara agresif untuk suatu posisi, mereka mencari sesuatu yang spesifik yang tidak dapat mereka temukan di antara kontak manajer pengembangan mereka yang ada. Jadi, ketika sebuah perusahaan bersedia mengambil risiko mempekerjakan orang yang sama sekali tidak diketahui, mereka biasanya mencoba untuk menyatakan persis kompetensi teknis apa yang mereka inginkan yang tidak diketahui secara lengkap.
Perusahaan yang lebih kecil dan lebih baru cenderung menggunakan teknologi paling mutakhir. Ini terutama karena mengubah budaya mereka memfokuskan mereka pada proyek-proyek investasi rendah dengan pengembalian cepat, tetapi ada juga beberapa faktor lain di tempat kerja, termasuk yang berikut:
- Omset di perusahaan kecil lebih tinggi, dan pekerja teknologi lebih mudah menemukan pekerjaan berikutnya dengan pengalaman terkini
- Pemilik proyek di perusahaan kecil cenderung memiliki lebih banyak kekuatan untuk memilih teknologi mereka sendiri
- Proyek yang lebih kecil berarti menggunakan perangkat lunak baru memiliki risiko yang lebih rendah
Perusahaan yang lebih besar cenderung menentang hal ini dan mengadopsi teknologi baru secara lebih konservatif. Keandalan, rasio biaya/manfaat, dan risiko jauh lebih penting bagi perusahaan tradisional dengan persyaratan kelangsungan bisnis. Jadi, jika Anda melihat lowongan pekerjaan, Anda akan cukup sering memperhatikan bahwa perusahaan besar berada dua hingga empat tahun di belakang teknologi mutakhir.
Setiap tahun, Stack Overflow bertanya kepada semua pengembangnya dalam bahasa apa mereka memprogram, dan ingin mengembangkan . Jika Anda mengetahui apa yang ingin dipelajari oleh programmer lain, dua atau tiga kemudian (jika tidak terlalu rumit — saya melihat Anda, CULisp) akan jauh lebih banyak digunakan. Pengembang umumnya ingin tetap bekerja, jadi mereka berusaha menyelaraskan pembelajaran mereka dengan kebutuhan calon pemberi kerja di masa depan. Dengan demikian, pengembang terus berusaha untuk mengganti bagian yang paling tidak efisien dari waktu mereka dengan menggunakan alat yang lebih efisien. Yang mengatakan, bagian yang paling memakan waktu dari pengembangan perangkat lunak akan selalu menyesuaikan alat dan kode apa bisa lakukan untuk fungsionalitas pengguna akhir orang dan bisnis menggunakan.
Jika Anda pergi lebih dalam dari sumber informasi dasar ini, Anda mungkin menemukan bahwa ada tempat lain untuk melihat apa yang akan datang. Slashdot, Quora, Reddit, dan forum/tempat pertemuan online lainnya berisi lebih banyak informasi — yang seringkali tidak dapat diandalkan, dan harus diperiksa dengan sumber lain — daripada outlet media standar. Mempelajari bahasa apa yang akan menjadi panas selanjutnya sering kali merupakan masalah membaca tren industri yang diyakini para pengembang bermanfaat. Tetapi mengetahui apa tren ini tidak cukup; Anda akan perlu untuk berlatih mereka sendiri.
4. Praktik Terbaik dan Karir Anda
Dalam beberapa hal, pendekatan terbaik untuk mempelajari metode pengembangan perangkat lunak adalah dengan berpindah pekerjaan. Teknologi dan praktik memiliki kurva adopsi yang serupa — curam pada awalnya, diikuti oleh pertumbuhan yang lambat jika digunakan secara luas, dan kemudian menurun secara perlahan. Perbedaan terbesar antara berbagai teknologi adalah apakah ada adopsi yang luas, dan panjang siklus hidup. Oleh karena itu, jika Anda berada di bidang seperti pengembangan front-end, kurva pertumbuhan dan adopsi suatu teknologi dapat terjadi seluruhnya dalam rentang tahun, dan penurunan tidak akan melibatkan banyak pekerjaan pemeliharaan. Hasil? Jika Anda ingin tetap relevan dalam karir pengembangan front-end Anda, Anda tidak bisa berpuas diri.
Cara Memilih Pekerjaan Teknik Anda Selanjutnya
Umumnya, ketika Anda mencari posisi baru, saya sarankan Anda mencari tiga hal. Mari kita hancurkan ini.
belajar: Pertama dan terpenting, Anda ingin posisi baru mengajari Anda sesuatu. Sebagai pengembang berpengalaman, Anda akan selalu memiliki pilihan untuk memilih antara dua jenis lingkungan kerja: lingkungan di mana Anda memiliki pengalaman yang luas, atau lingkungan baru. Kemungkinan besar Anda akan dibayar lebih untuk bekerja dengan teknologi yang sudah Anda ketahui. Yang mengatakan, jika Anda menggabungkan teknologi yang sebagian Anda kenal, dan teknologi yang tidak Anda ketahui, Anda dapat menambah nilai sambil juga memperoleh bakat/poin poin tambahan di resume Anda.
Kenikmatan: Hal terpenting kedua tentang posisi apa pun, secara teknis, adalah memilih masalah dan situasi yang Anda sukai. Semakin Anda menikmati masalah yang Anda pecahkan, semakin besar keinginan Anda untuk mengembangkan keahlian Anda dan meluangkan waktu/usaha untuk unggul dalam apa yang Anda lakukan.
Kesesuaian: Ketiga, mengetahui sifat perusahaan. Perusahaan kecil cenderung memberi karyawan mereka sejumlah besar tanggung jawab. Di perusahaan yang cukup kecil, Anda tidak dapat memiliki jabatan pekerjaan yang akurat; Saat ini saya bertanggung jawab atas manajemen instans AWS, proses pembangunan TeamCity, administrasi database, pemrograman dalam lima atau enam bahasa berbeda, pemberitahuan rilis, perbaikan terbaru, keputusan arsitektur, dan sebagainya.
Di posisi sebelumnya, saya memiliki tanggung jawab tunggal (memverifikasi dan memperbaiki hasil rekonsiliasi akuntansi untuk departemen penagihan internal, misalnya), dan telah menemukan bahwa semakin besar perusahaan, semakin banyak waktu saya terfokus pada satu set tugas. Umumnya, jika Anda ingin memperdalam pemahaman Anda tentang serangkaian tugas tertentu, Anda akan dilayani dengan lebih baik di perusahaan besar. Bekerja dengan tanggung jawab yang luas dan beragam (dan jaring pengaman yang terbatas) paling sering terjadi pada tanggung jawab yang kecil.
Paling sering, sebuah perusahaan akan tetap berpegang pada teknologi dan praktik yang digunakannya saat Anda mulai bekerja di sana (kecuali jika Anda dipekerjakan untuk menerapkan sesuatu yang baru!). Namun, semakin kecil dan fleksibel perusahaan, semakin besar kemungkinan Anda akan diberdayakan untuk menerapkan alat apa pun yang Anda inginkan. Manfaatkan ini, teliti solusi yang paling layak untuk masalah tersulit Anda, dan buat mereka bekerja.
Sebaliknya, mungkin ada keuntungan bekerja di perusahaan yang lebih besar, jika Anda bisa mendapatkan izin untuk menerapkan sistem atau praktik baru, Anda juga dapat memperoleh pelatihan tentang cara melakukannya. Selain itu, kegagalan yang membawa malapetaka lebih mungkin ditoleransi di perusahaan yang lebih besar, sehingga risiko dalam memperoleh keakraban dengan teknologi baru secara signifikan lebih rendah.
Pendidikan lebih lanjut
Beberapa praktik terbaik paling mudah diperoleh dalam lingkungan skolastik (atau pendidikan lainnya) yang lebih formal. Meskipun cukup mudah untuk memperoleh bahasa baru sendiri, terkadang cukup sulit untuk mendorong diri sendiri untuk mempelajari seluk beluk topik yang lebih dalam. Landasan teori yang kuat berguna untuk mempertahankan karier yang stabil, seperti halnya gravitas pendidikan lanjutan atau kredensial kamp pelatihan yang baru dan panas.
Pasar untuk programmer saat ini sedang booming. Saya belum melihatnya sebagai kuat sejak 1999ish. Jika Anda menikmati pemrograman untuk kepentingannya sendiri, dan pasar mengalami sedikit penurunan, gelar lanjutan adalah investasi yang sangat baik ketika pekerjaan lebih sulit ditemukan. Menjadi lebih fleksibel dan memahami bagaimana teknologi dibangun akan membuat Anda lebih mudah dipekerjakan dalam jangka panjang. Pengeluaran setelah bekerja (atau saat menganggur) selama 2-4 tahun dapat meningkatkan pendapatan seumur hidup Anda secara signifikan, serta menambah keamanan kerja.
Tetapi jika Anda sedang terburu-buru, bootcamp juga merupakan tempat yang baik untuk mempelajari apa pun yang baru dan yang akan datang. Salah satu 'praktik terbaik' saat ini untuk menemukan pekerjaan baru adalah memiliki repositori kode GitHub yang solid yang telah Anda buat. Jika Anda membuat repositori ini di bootcamp, serta batu penjuru yang menarik, kamp pelatihan itu mungkin menghabiskan waktu dengan baik, bahkan untuk pengembang berpengalaman. Codementor akan menjadi tempat yang tepat untuk mendapatkan panduan tentang cara membangun basis kode GitHub untuk mengesankan.
Saat saya menuruni tangga 'investasi waktu', konferensi adalah tempat yang baik untuk mengetahui apa yang sedang hangat, serta dapat mengikuti lokakarya dengan pengembang yang telah menciptakan teknologi terbaru. Amazon berjalan setiap bulan (minimal) acara di AWS, dan segala macam acara lainnya dijadwalkan secara teratur. Penyaji dan pendidik di konferensi mana pun akan bias mendukung teknologi yang telah mereka kembangkan, kerjakan, atau dibayar selama bertahun-tahun untuk mendukungnya. Yang mengatakan, karena mereka so diinvestasikan dalam teknologi tertentu, mereka umumnya informatif dan tertarik untuk membantu Anda memperluas basis pengetahuan Anda dengan teknologi pilihan mereka.
Pelatihan/sertifikasi teknologi khusus selalu tersedia. Saya tahu, di suatu tempat di belakang kepala saya, bahwa hidup saya akan jauh lebih mudah jika saya menghabiskan enam bulan untuk mendapatkan Bersertifikasi Oracle DBA di usia awal hingga pertengahan dua puluhan. Perusahaan kecil tidak terlalu menghormati sertifikasi, tetapi perusahaan besar melihat sertifikasi sebagai mitigasi risiko mereka. Jika Anda disertifikasi dengan teknologi tertentu, kemungkinan besar (di mata mereka) Anda akan kompeten dengan teknologi spesifik itu dengan cara yang diharapkan. Dengan demikian, mendapatkan sertifikasi dapat menjadi langkah besar menuju karir yang relatif stabil di pasar yang penuh gejolak. Sebagai peringatan, itu juga bisa menjadi investasi besar dalam teknologi yang menghilang dari pasar kerja.
Kontribusi open source selalu tersedia. Meskipun perangkat lunak OS terkenal berantakan, mengerjakan beberapa proyek akan membantu Anda memahami standar apa yang akan membantu di dunia yang ideal. Meskipun ini mungkin merupakan langkah yang menakutkan bagi pengembang yang lebih baru, ini patut dicoba. Setelah bekerja dengan sejumlah basis kode yang dibuat secara profesional, taruhan saya adalah jika Anda ingin masuk dan menulis komentar/dokumentasi logis di 10 proyek sumber terbuka teratas, Anda dapat mulai besok dan tidak ada yang akan mengeluh (selama kontribusi Anda membuat nalar!).
Saya menemukan pengajaran itu melalui pembuat kode mengajari saya jumlah yang luar biasa. Setiap pertanyaan seorang siswa benar-benar baru bagi saya, dan saya menghabiskan cukup banyak waktu untuk meneliti dan memperbaiki hal-hal yang saya tidak tahu bisa rusak. Jenis pengalaman ini tercermin selama waktu yang saya habiskan untuk mengajar kamp pelatihan.
Cara investasi terendah mutlak untuk mempelajari beberapa metode baru untuk manajemen kode adalah pergi ke hackathon. Saya hanya membuat satu 'produk menyenangkan yang layak' (permainan) selama hackathon seperti itu, tetapi saya belajar banyak dari berbagai programmer lain.
5. Kesimpulan
Sebagai pengembang, mempelajari dan menggunakan praktik terbaik adalah landasan untuk mempertahankan karier yang solid. Satu-satunya yang konstan dalam industri komputer adalah perubahan, dan tertinggal di belakang kurva itu mahal. Dengan terus mengamati bagaimana industri berubah, Anda dapat menghasilkan kode yang lebih baik dengan lebih cepat. Dengan menghasilkan kode yang lebih baik lebih cepat, Anda dapat membuat solusi yang lebih efektif.
Ada banyak sumber yang merinci bagaimana yang dimiliki orang lain meningkatkan kualitas kode mereka, atau membangun bisnis dengan kode, tetapi semua teknologi yang Anda gunakan selama karier Anda pasti akan berubah atau berubah saat Anda membangunnya. Tetap waspada terhadap lingkungan Anda dan karier Anda dapat berkembang.
Sumber: https://www.codementor.io/blog/updating-your-best-practices-7gzzfh3vrx
