Saya pemrograman di Jawa, dengan gaya yang sangat OO, sendiri. Tidak pernah memiliki kesempatan untuk bekerja dengan programmer lain (setidaknya saya belum profesional, belum).
Karena penasaran, saya ingin bertanya: Bagaimana cara bekerja dengan tim pada suatu proyek bekerja, terutama ketika bekerja pada proyek OO?
Bagaimana cara membagi tugas? Bagaimana Anda mengembangkan sesuatu yang akan berhasil bekerja dengan sesuatu yang dikembangkan programmer lain? Bagaimana dan kapan programmer berkomunikasi?
Terima kasih
object-oriented
teamwork
Aviv Cohn
sumber
sumber
Jawaban:
Semoga saya bisa membantu Anda sedikit, atau setidaknya mengarahkan Anda ke arah yang benar!
Sebagai sedikit pelepasan tanggung jawab hukum, ini adalah topik besar - dan yang menurut saya perlu " dilemparkan " untuk mendapatkan pemahaman yang mendalam. Yang mengatakan, saya akan memberikan lari cepat dari dua masalah utama:
Mengenai proyek-proyek OOP secara khusus - Sejujurnya saya tidak dapat melihat terlalu banyak masalah khusus untuk OOP yang tidak ada di tempat lain.
Bahkan, saya pikir pemrograman bergaya OOP sangat cocok untuk pengembangan tim. Salah satu etos kunci dari OOP adalah bahwa saya seharusnya tidak mengetahui semua detail tentang setiap objek yang berinteraksi dengan saya: Saya hanya perlu tahu apa yang bisa dilakukannya, dan bagaimana saya bisa mendapatkannya untuk melakukannya.
Abstraksi yang dapat diberikan OOP luar biasa dalam sebuah tim.
Kontrol Sumber
Perlu ada tempat sentral untuk menyimpan proyek, dan yang memungkinkan banyak pengembang untuk mengakses basis kode pada satu waktu. Di sinilah sistem seperti Git (atau SVN) masuk untuk bermain.
Saya hanya dapat berbicara secara spesifik tentang Git, karena saya tidak pernah menggunakan SVN - namun saya tahu mereka mirip tetapi dengan terminologi yang berbeda.
Menggunakan Git saya dapat membuat repositori dengan semua kode sumber untuk proyek yang diberikan, dan kemudian memungkinkan tim saya untuk mengakses repositori. Untuk setiap fitur atau perbaikan bug yang kemudian dibuat, pengembang individu dapat membuat "cabang" mereka sendiri yang berarti pengembangan dapat terjadi pada trek paralel.
Setelah fitur atau perbaikan selesai, maka dapat " digabungkan " kembali ke basis kode proyek utama. " Konflik " apa pun kemudian dapat dideteksi oleh Git dan diselesaikan pada tingkat sumber oleh pengembang yang bertanggung jawab.
Saya tidak yakin apakah Anda akan menggunakan Git sebelumnya, tetapi pada awalnya bisa terlihat sangat kompleks - tetapi berkat popularitasnya yang baru (sebagian untuk Github ) ada banyak sekali tutorial dan sumber daya di luar sana.
Jika Anda belum pernah menggunakannya sebelumnya, maka saya sarankan mendaftar ke GitHub dan merasakannya seperti itu! (Atau, Bitbucket adalah alternatif yang serupa, tetapi ini memungkinkan Anda untuk memiliki repositori pribadi gratis.)
Git Flow adalah alur kerja berbasis Git yang luar biasa yang sangat berguna bagi tim. Seperti halnya Git pada umumnya, begitu Anda bekerja dengannya sebentar saja menjadi sulit membayangkan bekerja dalam tim tanpanya!
Komunikasi
Setelah Anda melewati semua hambatan teknis, Anda benar-benar turun ke masalah mendasar yang mengganggu sebagian besar proyek (teknis atau tidak) - dan itulah komunikasi.
Seluruh tim perlu menyadari siapa yang melakukan apa, kapan mereka melakukannya dan apa pengaruhnya.
Tanggung jawab perlu didefinisikan dengan jelas
Ini jelas, tetapi sebagian besar proyek akan menggunakan beberapa bentuk sistem tiket - di mana setiap permintaan fitur atau bug dicatat, dan kemudian ditugaskan kepada anggota staf tertentu. ( Jira , Unfuddle dll) Seringkali ini dibangun untuk sistem kontrol sumber yang membuat hidup sedikit lebih sederhana. (BitBucket dan GitHub keduanya menyediakan pelacakan masalah untuk repositori Git yang dihosting bersama mereka.)
Ini berhenti, atau membantu mencegah setidaknya, pengembang tidak sengaja mengerjakan masalah yang sama.
Ini bukan perbaikan lengkap; Anda masih perlu memastikan pengembang mengetahui tentang tanggung jawab pengembang lainnya. Saya tahu di masa lalu bahwa saya telah memperbaiki masalah lain yang saya temukan ketika memperbaiki bug tertentu, murni karena itu masuk akal. (" Yah, saya sudah di sini. Ini bisa dilakukan dengan refactor dan mungkin saya bisa memeriksa masalah lain. ") Lalu saya harus minta maaf kepada pengembang lain karena mereka sedang mengerjakan masalah lain yang saya punya diperbaiki - membuang-buang waktu kita.
Secara umum, masalah ini dapat diperbaiki dengan ...
Pertemuan rutin
Beberapa metodologi manajemen / pengembangan proyek menentukan metode komunikasi tertentu atau interval pertemuan. Secara umum, sistem yang paling produktif yang saya lihat adalah pertemuan pagi di mana setiap orang dalam tim akan memberikan apa yang mereka lakukan - jika Anda membatasi ini hanya untuk anggota tim pengembangan dan memiliki pedoman yang jelas tentang apa untuk berkomunikasi maka ini bisa sangat efektif. Saya selalu berusaha untuk tetap berpegang pada:
Anggota tim lain dapat segera menerima bahwa " Fergus sedang memperbaiki bug yang dicatat kemarin, tetapi itu berarti dia sedang mengerjakan beberapa kode yang perlu saya perhatikan - saya akan memeriksanya sebelum saya membuat perubahan. ".
Pertemuan arsitektur
Saya baru-baru ini bekerja dengan tim yang hebat yang memiliki " obrolan teknologi " dua minggu sekali , di mana masalah yang lebih besar / arsitektur akan dibahas. Setiap anggota tim memiliki waktu untuk memahami masalah yang lebih besar yang dihadapi proyek dan dapat mendiskusikan potensi perbaikan.
Saya pribadi menyukai ini, saya tidak banyak berkontribusi karena saya cukup baru dalam proyek ini - tetapi bisa mendengarkan diskusi memberi saya banyak wawasan; segera saya dapat memahami proyek serta gaya berpikir individu.
Komunikasi adalah satu masalah yang dapat menjatuhkan tim mana pun . Teknis atau tidak, jika orang tidak menyadari gambaran yang lebih besar maka ada kemungkinan lebih besar bahwa mereka akan gagal.
Masalah lain
Baik untuk memastikan semua orang memiliki konfigurasi atau gaya yang sama ketika bekerja dalam sebuah tim. Apa yang saya maksud?
Konfigurasi
Jika Anda bekerja pada proyek Java - maka mungkin memastikan (untuk lingkungan pengembangan setidaknya, tentu saja tidak untuk pengujian.) Versi JVM yang umum di antara tim mungkin ide yang bagus? Kemudian IDE. Ini sangat membantu jika seluruh tim menggunakan Eclipse atau NetBeans atau IDE pilihan Anda.
Pada proyek web, mungkin semua pengembang membutuhkan tumpukan tertentu; dengan versi Apache atau PHP tertentu .
Memikirkan faktor-faktor seperti ini hanya memungkinkan tim untuk "gel" sedikit lebih cepat dalam pikiran saya.
Gaya
Tab vs spasi? CamelCase atau spacing_with_underscores? Sekecil pertanyaan-pertanyaan ini mungkin ketika Anda bekerja sendirian, ketika Anda bekerja dengan tim yang lebih besar Anda benar-benar ingin berjuang menuju gaya yang sama.
Bahkan, Anda seharusnya tidak benar-benar dapat memberi tahu siapa yang menulis bagian kode tertentu - Anda hanya perlu tahu bahwa itu milik .
Inilah sebabnya mengapa banyak proyek sumber terbuka menerbitkan pedoman format kode sumber / panduan gaya secara terbuka - untuk gagasan tentang apa yang terkandung di dalamnya, lihat Google StyleGuides untuk proyek sumber terbuka mereka sendiri.
Tugas dan Tes Unit
Ini tidak terbatas pada tim, tetapi saya akan segera menyinggung ini untuk satu alasan khususnya: itu membuat kehidupan tim jauh lebih mudah.
Jika Anda memiliki alur kerja yang kompleks dengan banyak dependensi, atau proses pembangunan yang lama - maka sering kali berguna untuk mengotomatisasi ini menggunakan pelari tugas. Untuk proyek web, GruntJS luar biasa, meskipun berasal dari Jawa, saya kira Apache Ant mungkin sangat mirip.
Sebagai seorang individu saya menggunakan GruntJS untuk membangun situs saya sebelum saya menyebarkannya ke server FTP saya - satu perintah Grunt adalah semua yang saya butuhkan untuk CSS / Sass saya untuk dikompilasi dan diperkecil , aset saya dikompresi dan kemudian file saya akan diunggah.
Namun sebagai anggota tim, saya dapat menggunakan GruntJS untuk memeriksa bahwa saya belum melanggar tes apa pun - dan bahwa saya belum memperkenalkan bug apa pun dengan tidak sepenuhnya menyadari bagian lain dari proyek ini. Ini tentu saja, tambahan untuk manfaat yang diberikannya kepada saya sebagai pengembang individu.
Saya juga dapat menggunakannya sehingga saya dapat mengkloning proyek menggunakan paket kontrol sumber mewah saya (Git) - dan menjalankan satu perintah untuk menginstal semua dependensi saya. Ini adalah nilai tambah yang besar, karena waktu yang dihabiskan untuk mendapatkan pengembang baru ke posisi di mana mereka dapat benar-benar mulai berkembang bisa sangat besar - bahkan tanpa mempertimbangkan waktu yang diperlukan untuk membiasakan diri dengan basis kode yang tidak dikenal.
Dokumentasi
Proyek-proyek terbaik yang saya lihat memiliki dokumentasi (dan seringkali cukup berlebihan) yang ditujukan untuk pengembang. Dokumen semacam ini dapat menjelaskan hal-hal seperti:
1. Lingkungan pengembangan:
2. Alur kerja
3. Tanggung jawab dalam tim:
4. "Jalur pipa " untuk masa depan
Contohnya
Mungkin patut untuk melihat alur kerja proyek sumber terbuka untuk merasakan bagaimana cara kerjanya - apakah itu proyek yang sudah mapan dengan alur kerja mereka sendiri (sering banyak didokumentasikan), atau salah satu dari banyak contoh di GitHub.
Kata peringatan terakhir
Jika Anda menemukan diri Anda bekerja dalam tim yang berhasil melakukan semua ini dengan benar .. Anda akan benci berada di tempat lain ..! Ambillah dari saya, setelah Anda mengalami tim yang bagus maka tiba-tiba masalah di tempat lain benar-benar dapat menyeret Anda. (Namun itu cerita untuk posting lain!)
sumber