Segera setelah pengembang memasuki perusahaan dan menerima tugas, paling sering ternyata dia perlu bergabung dengan proyek bersama beberapa tim, dan tidak menulis kodenya dari awal.
Setiap kode memiliki logikanya sendiri, berdasarkan prinsip-prinsip tertentu, di dalamnya terdapat pola dan karakteristik teknologi tim yang diikuti oleh programmer. Tetapi bagaimana cara dengan cepat mulai memahami proyek orang lain, walaupun faktanya itu hampir tidak kecil, dan seringkali tidak ada dokumentasi sama sekali, atau apakah itu tidak memadai dan tidak akurat?
Kami mengingatkan Anda: untuk semua pembaca "Habr" - diskon 10.000 rubel saat mendaftar untuk kursus Skillbox apa pun menggunakan kode promo "Habr".
Skillbox merekomendasikan: Kursus online Profesi Pengembang Frontend .
Bahkan, dokumentasi terbaik adalah kode itu sendiri dan mereka yang membuat kode ini (asalkan mereka masih di suatu tempat di dekatnya dan belum meninggalkan perusahaan). Bagaimana saya bisa mengurangi waktu ke minimum dan cepat mulai bekerja, membuat kontribusi saya?
Saya telah berulang kali menghadapi situasi ini selama 15 tahun terakhir dari pekerjaan saya sebagai seorang programmer, dan inilah pemikiran saya mengenai hal ini.
Tujuan dan sasaran proyek
Hal pertama yang harus Anda lakukan adalah meluangkan sedikit waktu untuk memahami tugas apa yang sedang dilakukan aplikasi yang Anda buat kode. Ini adalah tantangan global; Setelah menyelesaikannya, Anda akan mengatasi semua hal lainnya.
Anda tidak dapat mengerjakan suatu proyek tanpa menyadari mengapa itu diperlukan sama sekali. Pemahaman umum akan memungkinkan Anda untuk dengan cepat memahami hal-hal kecil. Selain itu, pekerjaan Anda sendiri akan dilakukan lebih harmonis dengan anggota tim lainnya. Bata demi bata - beginilah cara rumah dibangun.
Arsitektur
Setelah Anda mempelajari tugas utama, curahkan diri Anda untuk analisis eksekusi kode dan logikanya.
Arsitektur beberapa proyek agak rumit, terutama jika teknologi dasar dari proyek ini tidak terlalu akrab bagi Anda. Pada awalnya, cobalah mencari dokumentasi teknis (atau tanyakan kepada rekan Anda tentang hal itu) untuk melihat logika dasarnya.
Dengan mengingat struktur proyek, Anda akan dapat mulai bekerja lebih cepat, dan agar tidak mengganggu fungsi semua bagian lain yang terlibat dalam anggota tim.
Mungkin ada fragmen dalam proyek yang melanggar logika umum, tetapi, mengetahui ide dan arsitektur, Anda dapat memperbaiki masalah, mengatur ulang atau mengubah "batu bata" sehingga cocok dengan bangunan umum.
Pola
Ada sejumlah besar pola yang digunakan pengembang saat menulis kode. Ini adalah pola struktural, "perilaku", teknologi dan lainnya. Semua itu membantu menentukan cara untuk memecahkan masalah umum ketika merancang program.
Memahami pola apa yang digunakan dalam proyek Anda saat ini akan membantu, di tingkat kelas, untuk memahami bagaimana fungsi harus dibangun ke dalam kode. Sebagai hasilnya, Anda akan dapat membuat kode yang koheren yang akan sesuai dengan logika dan pola umum, yang pada akhirnya akan mengarah pada jumlah komentar yang jauh lebih sedikit pada kode, pemahaman yang lebih baik tentang hal itu dan penghapusan kesalahan jika perlu.
Setelah bekerja sedikit pada proyek, Anda akan dapat memahami sekilas bagian mana dari kode yang cocok dengan keseluruhan struktur dan apa yang memerlukan refactoring.
Pedoman
Sebagian besar tim memiliki aturan tertentu, atau lebih tepatnya, seperangkat aturan yang menurutnya semua orang bertindak. Ini bukan hanya tentang prinsip-prinsip umum pekerjaan, tetapi juga tentang penggunaan kelas dan tingkat aplikasi. Jika perwakilan tim dipandu oleh pedoman yang sama, maka kode yang dikembangkan lebih mudah dipahami dan dibaca.
Kemungkinan besar, tim yang Anda ikuti juga memiliki panduan yang perlu Anda pelajari. Pertama-tama, mereka berhubungan dengan bahasa pemrograman, yang merupakan bahasa utama selama pengembangan.
Anda dapat bertanya di mana mendapatkan semua informasi tentang proyek, arsitektur, templat, dan pedomannya. Ada beberapa metode untuk mendapatkan yang diperlukan, kecuali yang sudah disuarakan di atas:
- Carilah informasi apa pun, bahkan apa pun yang dapat dianggap tidak relevan; Bangun basis pengetahuan Anda sendiri tentang istilah umum, singkatan, dan konsep yang digunakan tim Anda.
- Setelah database ini siap, Anda dapat mendiskusikan semua masalah yang menarik bagi Anda dengan manajer proyek, karena Anda sudah berbicara dalam bahasa yang sama.
- Selain itu, ada baiknya berbicara dengan arsitek aplikasi dan pemimpin tim tentang keseluruhan arsitektur proyek Anda. Kemudian cobalah untuk mempelajari lebih lanjut tentang arsitektur ini dan teknik optimasi kode yang terkait dengannya. Jika Anda melihat sesuatu yang, menurut pendapat Anda, melanggar logika umum aplikasi, pastikan untuk membicarakan hal ini dengan ketua tim.
- Cari tahu dari rekan tim Anda pola dan aturan apa yang digunakan selama bekerja pada kode - baik selama penulisan dan dalam pemeliharaan di masa depan. Setelah Anda tahu poin utama, bandingkan mana yang paling baik dan bertindak sesuai di masa depan.
- Cobalah untuk membersihkan bagian kode dari masalah potensial dan nyata - ini akan membantu Anda mendapatkan pemahaman yang lebih dalam tentang proyek dan kode tersebut. Apa yang digunakan tim Anda untuk membersihkan kode?
Secara umum, refactoring adalah kesempatan terbaik untuk melibatkan tim Anda dalam diskusi tentang pedoman mana yang harus ditinjau dan mana yang harus digunakan di masa depan.
Bagikan pengalaman Anda sendiri dengan tim, berpartisipasi aktif dalam rapat kerja, diskusikan masalah saat ini, arsitektur aplikasi dan elemen-elemennya, templat, dan poin penting lainnya. Rapat kerja dapat menjadi saluran yang andal untuk mendapatkan informasi tambahan; ada baiknya berbicara tentang pengamatan / pencapaian mereka, tentang apa yang dapat bermanfaat bagi semua orang.
Sebagai hasilnya, Anda tidak hanya dapat dengan cepat mulai bekerja, tetapi juga bergabung dengan tim, menjadi peserta yang tak tergantikan dalam waktu singkat.
Tentu saja, Anda akan bertemu orang-orang yang sulit berkomunikasi; akan ada masalah dengan kode tersebut. Tapi ini terjadi hampir selalu - ada tim di mana semuanya sempurna, tetapi mereka sedikit.
Skillbox merekomendasikan: