Dari seorang penerjemah: kami menerbitkan untuk Anda
sebuah artikel oleh pengembang Jack Finlay. Jack berbicara tentang kasusnya sendiri - upaya untuk mengatur pekerjaan sebagai tim junior, di mana semua orang sama dan tidak ada manajer teknis. Artikel ini akan bermanfaat bagi programmer pemula.
Beberapa proyek mungkin macet dan berakhir tanpa hasil karena sejumlah alasan. Bimbingan teknis adalah sesuatu yang sering kurang. Masalah ini dapat menyebabkan kegagalan. Setelah itu terjadi dengan proyek dalam pengembangan yang saya ambil bagian.
Skillbox merekomendasikan: Kursus praktis dua tahun "Saya seorang Pengembang Web PRO . "
Kami mengingatkan Anda: untuk semua pembaca "Habr" - diskon 10.000 rubel saat mendaftar untuk kursus Skillbox apa pun menggunakan kode promosi "Habr".
Waktu dapat mengajarkan Anda banyak hal. Sayangnya, kami memperoleh pengalaman karena bekerja tidak hanya dengan proyek yang berhasil, tetapi juga dengan yang tidak berhasil.
Pengalaman dan kepemimpinan pribadi
Lebih tepatnya, kekurangannya. Tidak ada pengembang utama atau senior dalam proyek kami. Pada prinsipnya, sudah jelas apa yang akan terjadi pada pekerjaan kami, tetapi pada saat itu kami tidak mengerti ini.
Tim tidak punya pengalaman. Hampir semua dari kami adalah pelajar, dan tidak ada yang bisa memimpin kami. Maka tampaknya tidak perlu bagi kami.
Selama satu musim panas, jumlah anggota tim meningkat lima kali lipat. Masalah? Semua tentang tingkat profesional yang sama. Semua orang tidak memiliki pengalaman. Kami dibagi menjadi beberapa kelompok, yang masing-masing bertanggung jawab atas sesuatu.
Selain itu, hampir semua peserta proyek adalah orang-orang baik yang bertanggung jawab. Tetapi ini adalah proyek komersial pertama kami. Tim saya sangat bagus, kami bekerja dengan sempurna, tetapi hasilnya gagal.
ToolkitKomponen utama pekerjaan seorang profesional adalah alat. Tanpa alat yang tepat, aliran proses normal tidak mungkin. Tim yang baik biasanya memiliki pemimpin yang tahu siapa yang membutuhkan alat apa dan di mana mendapatkannya.
Basis dataDalam proyek ini, kami memiliki akses ke database bersama yang dihosting di mesin virtual, salah satu yang paling lambat yang bisa diperoleh. Secara alami, kami mengalami semua "kesenangan" dari pekerjaan seperti itu: kehilangan data, tabel jatuh, tindakan simultan pada elemen yang sama. Semua ini melambatkan pekerjaan kami.
Kami tidak dapat mereproduksi basis data baik secara lokal maupun di cloud tanpa melakukan operasi pencadangan dan pemulihan. Tidak ada cara untuk mendapatkan database "bersih" dalam kondisi yang sama di mana kami ingin menyebarkannya di lingkungan yang berbeda. Basis data hanya dapat dibuat sebagai klon dari basis data server kami.
Tetapi proyek hanya bekerja dengan database, yang terletak di server produksi. Ini berarti bahwa kami tidak dapat menguji basis data dan proyek tergantung padanya secara lokal. Beberapa kali muncul situasi ketika kami harus menggulingkan pangkalan ke titik tertentu, karena pada malam hari seseorang menghancurkannya dengan tindakan ceroboh. Ini sangat menghambat proses pengembangan.
Migrasi dan pembaruan basis data dilakukan secara manual. Itu berarti ... ya, kami membuang-buang waktu lagi.
Sekarang nampak jelas bahwa pengembang harus memiliki database lokal di mesin mereka. Selain itu, Anda harus menggunakan alat migrasi otomatis. Ini memberi pengembang kebebasan dan ruang untuk bermanuver dalam situasi tertentu.
PerformaPengembang membutuhkan kinerja tinggi baik pada mesin lokal maupun di server tempat proyek sedang diuji. Tetapi karena kami memiliki alat yang lambat, kami bahkan tidak bisa memimpikannya.
Banyak perangkat sangat lambat yang telah digunakan selama bertahun-tahun. Keyboard, trackpads - semua ini membosankan.
Servernya juga lambat, seperti yang saya sebutkan di atas. Akibatnya, seluruh proses pengembangan melambat. Tes juga berlangsung lambat.
Kesimpulannya sederhana, dalam gaya identitas perusahaan, adalah untuk memberikan pengembang peralatan dan sumber daya yang mereka butuhkan untuk proses pengembangan normal.
Kontrol Sumber
Itu umumnya kekacauan. Kami menggunakan sistem kontrol sumber perusahaan, tetapi masalahnya bukan pada perangkat lunak. Tidak ada strategi sama sekali. Tim pengembangan yang terpisah bekerja masing-masing "di rawa mereka sendiri", dan kami tidak sepakat kapan kami akan menggabungkan brunch individual menjadi satu. Hasilnya adalah apa yang terjadi: konflik, konflik selama merger di mana-mana. Harus menghabiskan banyak waktu untuk menyelesaikan masalah dan sinkronisasi yang tepat.
Integrasi dan penyebaranKami umumnya tidak memiliki solusi CI / CD. Penerapannya sederhana: kami menyalin sumber daya dari folder bawaan dan menempelkannya ke server menggunakan Remote Desktop. Jika Anda melakukan sesuatu yang serupa, Anda dapat memahami rasa sakit saya.
Bagi mereka yang belum mengalami masalah: jika Anda memiliki sesuatu selain file yang diperlukan dalam buffer, ini akan membunuh mengunggah file ke server. Jika orang lain dari tim bergabung dengan server untuk mengunggah file, Anda akan mengalami masalah. Selain itu, beberapa file mungkin ditransfer rusak.
Saran saya adalah memilih solusi CI / CD untuk Anda sendiri.
Kontrol kualitas
Elemen penting lain dari proses pengembangan adalah kontrol kualitas.
Ulasan rekanPekerjaan ini adalah bersama kami bahwa anggota tim berkumpul dan melihat pekerjaan yang dilakukan. Dan kadang-kadang kita bahkan tidak melihat kodenya, jadi sejumlah besar momen berlalu. Masalah lain adalah kami tidak memiliki pengalaman, yang berarti memahami apa itu kode yang baik. Kami tidak dapat segera mengisolasi kesalahan dalam kode yang segera dilihat oleh pengembang berpengalaman.
Jika tim memiliki pengembang senior, ia akan segera memberi tahu kami di mana masalahnya dan bagaimana cara mengatasinya. Tapi dia tidak ada di sana, kami bekerja secara mandiri.
PengujiKami juga tidak memilikinya. Kami melakukan tes sendiri. Sekali lagi tanpa pengalaman. Akibatnya, kami menghabiskan waktu berharga untuk menangkap serangga dan menghilangkannya.
Jika Anda menginginkan kode yang baik, Anda perlu penguji, dan yang profesional. Pengembang tidak selalu mengatasi masalah pengujian perangkat lunak.
Kualitas kode
Banyak dari kita di awal perjalanan adalah perwakilan dari budaya "copy-past". Ini berarti bahwa pengembang mencari solusi yang diperlukan untuk proyek di Stackoverflow dan memasukkan potongan yang ditemukan tanpa sedikitpun suara hati. Hasilnya bukan kode yang sangat baik, yang praktis tidak dapat dibaca dan pengembang mana yang merasa sulit untuk menjelaskan sepenuhnya. Bahkan orang yang menyalin situs tertentu sering tidak dapat mengetahui karyanya.
Saya hanya dapat menyarankan satu hal: jika Anda menyalin kode, Anda harus sepenuhnya memahaminya. Tanpa ini, proyek normal tidak dapat direalisasikan.
Kode spagetiPemahaman yang buruk tentang arsitektur proyek menyebabkan kekacauan total. Kode spaghetti adalah deskripsi lembut tentang apa yang terjadi pada akhirnya.
Beberapa bagian melewati tangan yang berbeda, dari pengembang yang berbeda, masing-masing menambahkan sesuatu yang berbeda. Kode akhir dari proyek ini adalah serangkaian ide dan “tongkat penyangga”.
Kami tidak memiliki sistem injeksi ketergantungan, dan kami tidak menggunakan pola desain umum. Ini menyebabkan banyak kode buruk yang baru saja mulai "membusuk".
Apa yang bisa saya katakan? Keterbacaan kode sama pentingnya dengan operasi yang tepat, dan kedua hal ini berjalan seiring. Gaya yang jelas, konsisten, dan kode yang konsisten memberikan hasil yang paling efektif.
Kesimpulan
Banyak masalah muncul karena kurangnya pengalaman kami. Kami hanya tidak tahu bagaimana cara mengerjakan proyek. Kami tidak dapat menerapkan lingkungan dengan baik. Kami tidak memiliki alat dan teknologi yang diperlukan.
Pemimpin tim yang baik akan menyelesaikan semua masalah ini. Dia akan meramalkan banyak hal sebelumnya.
Omong-omong, proyek itu sendiri bukan yang terburuk dari apa yang bisa terjadi. Saya bertemu banyak kolega masa depan dengan siapa saya berkomunikasi sejauh ini. Mendapat pengalaman yang diperlukan untuk bekerja sebagai profesional. Dan saya menyadari bahwa tanpa kepemimpinan yang tepat, bahkan tim yang paling cakap pun tidak menyadari potensi penuhnya. Tidak pernah.
Skillbox merekomendasikan: