Saya ingin berkembang untuk waktu yang lama, tetapi, seperti yang sering terjadi, saya tidak terlalu percaya pada diri saya sendiri. Saya percaya bahwa kereta saya sudah lama pergi, dan otak bukan lagi yang menguasai profesi yang sulit ini. Untung saya terbujuk, apalagi mereka memberi saya kesempatan untuk membuktikan diri dan magang di bagian development. Itu terjadi begitu saja dan pada awalnya saya tidak dapat mempercayainya. Sepanjang waktu tampaknya bagi saya bahwa sekarang semua orang akhirnya akan mengerti bahwa saya adalah seorang yang bodoh dan melambaikan pena mereka untuk mengucapkan selamat tinggal. Tetapi ini tidak terjadi, mereka terus mendukung saya, dan saya berusaha sebaik mungkin untuk tidak mengecewakan siapa pun.
Saya magang di departemen backend kami, yang menangani produk pelacakan, dan pada saat yang sama saya bekerja di departemen integrasi teknis saya sendiri (selama 6 bulan sekarang). Bahasa utama di tim adalah Python . Saya mengajarinya sendiri untuk magang. Pada dasarnya, tentu saja, pada manual dan video di Internet.
Saya memiliki basis kecil - Saya menulis beberapa proyek pelatihan dalam C, tetapi secara umum saya tidak dapat mengatakan bahwa saya setidaknya seorang pembuat kode yang agak berpengalaman ketika saya diterima untuk magang. Dari puncak pengalaman yang rendah hati ini, saya ingin memberi tahu Anda tentang beberapa hal yang tidak saya ketahui atau hampir tidak saya ketahui pada awalnya.
Kerja tim dengan Git
Ketika seseorang datang untuk magang pertamanya, dia membayangkan apa itu Git (jika tidak, dia tidak mungkin diambil sama sekali), tetapi dia tidak tahu banyak tentang bagaimana mereka bekerja dengannya dalam sebuah tim. Kita semua membuat akun di GitHub pada satu waktu dan dengan senang hati menyerahkan baris kode pertama ke cabang master, merasa seperti profesional sejati. Jadi: ini bukan pendekatan terbaik untuk proyek besar.
Dalam pengembangan tim, pekerjaan dengan Git dilakukan sesuai dengan git-flow yang disetujui . Misalnya, kami memiliki dua cabang: develop dan master. Tidak seorang pun, kecuali pemimpin tim, dapat mengunggah kode ke cabang master, karena tim harus memastikan bahwa ada kode yang berfungsi di sana yang tidak akan merusak produksi saat diterapkan. Tanggung jawab untuk ini akan berada di pundak pemimpin tim, dan tidak ada yang mau membuat pemimpin tim marah.
Untuk mencegah situasi seperti itu, ada tim review. Setiap pengembang mengerjakan tugas di cabangnya sendiri dan di akhir pekerjaan menempatkan permintaan penggabungan di cabang pengembangan. Dan pemimpin tim sudah menempatkan permintaan penggabungan di cabang master dan bertanggung jawab atas kualitas kode kepada pemiliknya. Dengan demikian, kemurnian kode yang berakhir pada produksi dijamin, dan risiko menuangkan sesuatu yang akan merusak pekerjaan proyek diminimalkan.
Kesimpulan: Jika Anda ingin lebih mempersiapkan kerja tim, baca git-flow dan mulailah menambahkan komitmen baru ke proyek hewan peliharaan Anda melalui cabang.
Arsitektur kode itu penting
Ketika saya datang ke magang, saya berharap mereka akan memberi tahu saya apa yang harus saya lakukan, memberikan beberapa tes fungsi atau unit kecil, dan saya akan mengerjakannya di bawah pengawasan tim.
Namun, semuanya ternyata berbeda. Tidak, tidak ada yang menginstruksikan saya untuk melakukan sesuatu yang sangat rumit, tetapi saya diberi proyek mini (tonggak sejarah) untuk pemantauan (Python + Prometheus + Grafana ), yang harus saya lakukan selama magang. Selain itu, saya sendiri harus memikirkan arsitekturnya, menguraikan proyek menjadi tugas dan memindahkannya melalui tahapan Kanban. Itu mengasyikkan, tapi sangat tepat. Pendekatan ini memungkinkan kurator dan saya sendiri untuk memahami dengan jelas apa masalah saya dan mulai memperbaikinya.
Sejujurnya, keputusan pertama saya tidak berhasil. Dan yang kedua juga. Saya melakukan tugas yang terlalu besar, mengembalikannya ke backlog beberapa kali, membangun arsitektur yang tidak berhasil dan tidak dapat memperhitungkan nuansanya.
Namun, saat ini, sebagian besar proyek telah diimplementasikan, dan saya menjadi semakin sadar tentang bagaimana kode saya memengaruhi sisa proyek. Ini menyenangkan. Saya membaca beberapa artikel tentang arsitektur bersih, mempelajari kelas abstrak, mempelajari cara merencanakan antarmuka terlebih dahulu dan baru kemudian memulai implementasi. Saya tidak dapat mengatakan bahwa saya telah memahami semuanya, tetapi saya benar-benar memahami ungkapan "Masalah apa pun dapat diselesaikan dengan memperkenalkan tingkat abstraksi tambahan, kecuali untuk masalah jumlah tingkat abstraksi yang berlebihan." Dan saya juga belajar untuk menilai kekuatan saya dengan benar (tapi ini tidak akurat).
: . , , . , Netflix, . , .
Di perusahaan kami, semua layanan diluncurkan dalam kontainer. Karenanya, setiap pengembang harus memahami cara kerja Docker yang sama , cara menulis Dockerfile sederhana , atau meningkatkan layanan mereka melalui Docker Compose .
Untuk orang yang menulis hanya untuk dirinya sendiri dan di komputernya, sulit untuk memahami mengapa containerization diperlukan. Namun, pada proyek besar, perlu dipastikan bahwa kode berfungsi terlepas dari lingkungannya. Beberapa saat kemudian, ketika Anda mengetahui dasar-dasarnya, akan menjadi jelas betapa nyamannya itu. Anda tidak perlu menginstal dependensi di lingkungan Anda, tidak perlu peluncuran proyek yang lama dan sulit. Anda dapat menjalankan pengujian atau memisahkan pro dan dev hanya dengan menulis beberapa konfigurasi sekali.
Saran yang sama dapat mencakup bekerja dengan IDE. Sebelum memulai magang, saya menulis semua program saya secara eksklusif di Emacs, tetapi ketika saya mulai bekerja, saya memutuskan untuk beralih ke alat yang lebih canggih, dan pada akhirnya saya tidak menyesalinya. Di beberapa tempat saya masih lebih suka menggunakan konsol (misalnya, lebih mudah untuk mengabaikan semua kontainer
docker stop $(docker ps -qa)), tetapi sebaliknya saya berterima kasih kepada GUI Git dan tip di PyCharm.
Kesimpulan: Baca tentang Docker. Coba jalankan kode Anda di wadah. Cobalah IDE untuk bahasa Anda dan lihat manfaatnya untuk Anda.
Dokumentasi dan pengujian sama pentingnya dengan kode
Kurator saya pernah berkata bahwa tes adalah dokumentasi developer kedua. Dan ini sangat benar, karena jika dokumentasi sebenarnya kurang, Anda selalu dapat pergi ke pengujian dan melihat perilaku apa yang diharapkan.
Sebelum magang, saya menggunakan UnitTest dan PyTest, tetapi hanya sebagai bagian dari pelatihan saya. Dan Mock , misalnya, tidak digunakan sama sekali, karena proyek saya tidak terlalu rumit sehingga perlu mengganti data (yah, atau pengujian saya sangat buruk).
Saya akan merekomendasikan semua pengembang pemula untuk menulis tes untuk semua logika yang terjadi dalam proyek. Bahkan jika menurut Anda perilakunya sudah jelas, yang terbaik adalah tetap berpura-pura. Lagi pula, ketika orang lain menulis fungsi yang menggunakan kode Anda, ada kemungkinan dia tidak akan menjelaskan secara detail dan pengujian Anda yang gagal akan menyelamatkan proyek dari masalah.
Dan untuk meminimalkan risiko, tulis dokumentasi yang jelas. Di Admitad, metode atau fungsi tanpa dokumentasi akan menimbulkan pertanyaan untuk ditinjau. Dua minggu kemudian, tidak ada yang mau membuang waktu mencoba mencari tahu kode orang lain lagi. Ini hanya soal menghormati rekan kerja.
Selain itu, saya akan mengatakan bahwa kami juga menganotasi jenis secara detail dengan Python, tetapi jika Anda menulis dalam bahasa yang diketik dengan kuat, komentar ini bukan untuk Anda. (Menggunakan linter seperti Flake8 sangat membantu dalam hal ini ).
Kesimpulan: Perhatikan tes dan dokumentasi. Mulailah dengan readme Git biasa - jelaskan bagaimana menjalankan proyek, apa yang dilakukannya, dan apa yang Anda harapkan. Coba tulis pengujian untuk metode dan fungsi utama, atau lebih baik lagi, buat Docker Compose yang menjalankan semua pengujian.
Pengalaman apa yang Anda miliki?
Untuk pengembang mapan, saran saya mungkin tampak sepele dan jelas. Saya memahami Anda dengan sempurna, tetapi pada awalnya saya sangat kurang dalam pengetahuan sistem. Saya yakin banyak dari mereka yang menguasai profesinya sendiri menghadapi masalah ini.
Oleh karena itu, saya mendorong Anda untuk berbagi pengalaman dan pengamatan yang telah Anda pelajari setelah bulan-bulan pertama (atau tahun-tahun) Anda di industri ini. Nasihat apa yang akan Anda berikan pada diri Anda sendiri di awal karier Anda? Keterampilan apa yang akan Anda rekomendasikan untuk dikembangkan? Baik saya dan orang otodidak lainnya mungkin membutuhkan tip Anda, jadi silakan tinggalkan komentar.