Pertanyaan Bagaimana programmer bekerja sama dalam sebuah proyek?


Saya selalu memprogram sendiri, saya masih mahasiswa jadi saya tidak pernah diprogram dengan orang lain, saya bahkan belum pernah menggunakan sistem kontrol versi sebelumnya.

Saya sedang mengerjakan proyek sekarang yang membutuhkan pengetahuan tentang bagaimana pemrogram bekerja sama dalam sebuah perangkat lunak di sebuah perusahaan.

Bagaimana perangkat lunak dikompilasi? Apakah ini dari sistem kontrol versi? Apakah itu oleh programmer individu? Apakah ini berkala? Apakah ketika seseorang memutuskan untuk membangun atau sesuatu? Apakah ada tes yang dilakukan untuk memastikan "berhasil"?

Apapun akan dilakukan.


75
2018-06-08 18:33


asal


Jawaban:


Sebenarnya, ada banyak variasi dalam proses ini karena banyak perusahaan yang ada. Artinya: setiap perusahaan memiliki sedikit konvensi yang berbeda dari yang lain, tetapi ada beberapa praktik terbaik umum yang umumnya digunakan di sebagian besar tempat.

Praktik terbaik yang selalu berguna

  • Semua kode sumber proyek dan apa pun yang diperlukan untuk membuatnya berada di bawah kontrol versi (Juga disebut kontrol sumber). Siapa saja harus dapat membangun seluruh proyek dengan satu klik.
    Selanjutnya, file yang tidak perlu (file obyek atau biner yang dikompilasi) seharusnya tidak ditambahkan ke repositori, karena mereka dapat diregenerasi dengan mudah dan hanya akan membuang-buang ruang di repo.
  • Setiap pengembang harus memperbarui dan melakukan ke versi kontrol beberapa kali per hari. Sebagian besar ketika mereka telah menyelesaikan tugas yang mereka kerjakan dan mengujinya cukup sehingga mereka tahu bahwa itu tidak mengandung bug sepele.
  • Lagi: siapa saja harus dapat membangun proyek dengan satu klik. Ini penting dan membuatnya mudah diuji untuk semua orang. Keuntungan besar jika non-programmer (mis. Bos) dapat melakukannya juga. (Itu membuat mereka merasa dapat melihat apa yang sedang dikerjakan oleh tim.)
  • Setiap pengembang harus menguji fitur baru atau perbaikan bug yang mereka tambahkan sebelum mereka melakukan itu ke repositori.
  • Mengatur server yang teratur (dalam interval yang ditentukan sebelumnya) memperbarui dirinya dari repositori dan mencoba membangunnya segala sesuatu dalam seluruh proyek. Jika gagal, ia mengirim e-mail ke tim bersama dengan komit terbaru ke kontrol versi (sejak komit itu gagal membangun) untuk membantu mendebug masalah.
    Praktek ini disebut integrasi berkelanjutan dan bangunan juga disebut bangun malam.
    (Ini tidak berarti bahwa pengembang tidak boleh membangun dan menguji kode pada mesin mereka sendiri. Seperti yang disebutkan di atas, mereka harus melakukan itu.)
  • Tentunya, semua orang harus terbiasa dengan desain dasar / arsitektur proyek, jadi jika ada sesuatu yang diperlukan, anggota tim yang berbeda tidak harus menemukan kembali roda. Menulis kode yang dapat digunakan kembali adalah hal yang baik.
  • Semacam komunikasidiperlukan antara anggota tim. Setiap orang harus menyadari apa yang dilakukan orang lain, setidaknya sedikit. Lebih banyak lebih baik. Inilah sebabnya mengapa standup harian berguna dalam tim SCRUM.
  • Pengujian unit adalah praktik yang sangat bagus yang membuat pengujian fungsionalitas dasar dari kode Anda secara otomatis.
  • SEBUAH perangkat lunak pelacakan bug (kadang disebut perangkat lunak pelacakan waktu) adalah cara yang sangat baik untuk melacak bug apa yang ada di sana dan tugas apa yang dimiliki oleh anggota tim yang berbeda. Ini juga bagus untuk pengujian: penguji alfa / beta proyek Anda dapat berkomunikasi dengan tim pengembangan dengan cara ini.

Hal-hal sederhana ini memastikan bahwa proyek tidak lepas kontrol dan semua orang bekerja pada versi yang sama dari kode. Proses integrasi continuos membantu ketika sesuatu berjalan sangat buruk.

Ini juga mencegah orang melakukan hal-hal yang tidak membangun ke repositori utama.
Jika Anda ingin menyertakan fitur baru yang memerlukan waktu beberapa hari untuk diterapkan dan itu akan memblokir orang lain dari membangun (dan menguji) proyek, gunakan ranting fitur kontrol versi Anda.

Jika itu tidak cukup, Anda dapat mengaturnya untuk melakukan pengujian otomatis juga, jika itu mungkin dengan proyek yang bersangkutan.

Beberapa pemikiran lagi

Daftar di atas bisa sangat berat pada pandangan pertama. Saya menyarankan agar Anda mengikutinya pada sesuai kebutuhan dasar: mulai dengan kontrol versi dan pelacak bug, lalu nanti siapkan server integrasi berkelanjutan, jika Anda membutuhkannya. (Jika ini adalah proyek besar, Anda akan membutuhkannya segera.) Mulailah menulis tes unit untuk bagian yang paling penting. Jika itu tidak cukup, maka tulis lebih banyak lagi.

Beberapa tautan yang bermanfaat:
Integrasi berkelanjutan, Bangunan harian adalah teman Anda, Kontrol versi, Pengujian unit

Contoh:

Untuk kontrol versi, saya cenderung menggunakannya Git untuk proyek pribadi saya saat ini. Subversi juga populer, dan misalnya, VisualSVN cukup mudah untuk mengatur jika Anda menggunakan server Windows. Untuk klien, TortoiseSVN bekerja paling baik untuk banyak orang. Berikut ini adalah perbandingan antara Git dan SVN.

Untuk perangkat lunak pelacakan bug, Jira dan Bugzilla sangat populer. Kami juga digunakan Mantis di tempat kerja sebelumnya.

Untuk perangkat lunak integrasi berkesinambungan, ada Teamcity untuk satu (juga, CruiseControl dan itu Mitra NET dapat dicatat).

Jawaban atas pertanyaan Anda "siapa yang memutuskan desain utama proyek?"

Tentu saja, itu akan menjadi pengembang utama.
Di perusahaan, pengembang utama adalah orang yang berbicara dengan orang keuangan / pemasaran proyek, dan memutuskan arcithecture sesuai dengan kemampuan keuangan perusahaan, fitur yang direncanakan persyaratan dari pengguna, dan waktu yang tersedia.

Ini adalah tugas yang rumit, dan biasanya lebih dari satu orang terlibat. Kadang-kadang anggota tim juga diminta untuk berpartisipasi atau bertukar pikiran tentang desain keseluruhan proyek atau bagian-bagian tertentu.


54
2018-06-08 19:00



Saya seorang mahasiswa juga, yang menyelesaikan kursus rekayasa perangkat lunak baru-baru ini di mana seluruh semester terdiri dari proyek kelompok raksasa. Mari saya mulai dengan mengatakan bahwa kita dapat melakukan dengan 3 orang apa yang dibutuhkan 12 dari kita sepanjang semester untuk dilakukan. Bekerja dengan orang adalah hal yang sulit. Komunikasi adalah kuncinya.

Pasti menggunakan repositori. Setiap orang dapat mengakses semua kode dari jarak jauh, dan menambahkan / menghapus / mengubah apa pun. Tetapi bagian terbaik tentang subversi adalah bahwa jika seseorang melanggar kode, Anda dapat kembali ke versi sebelumnya dan menilai apa yang salah dari sana. Komunikasi masih menjadi kunci, tahu apa yang dilakukan rekan tim Anda sehingga tidak ada konflik. Jangan duduk di kode Anda juga, buatlah komitmen yang cepat dan bermakna ke repositori menjadi yang paling efektif.

** Saya juga merekomendasikan pelacak bug, seperti Redmine. Anda dapat mengatur akun untuk semua orang, dan menetapkan tugas orang dengan prioritas yang berbeda, dan juga melacak dan melihat apakah orang-orang telah mengurus masalah tertentu, atau jika lebih banyak yang muncul.

Dan, seperti yang telah dikatakan sebelumnya, pengujian unit akan sangat membantu. Semoga berhasil! Semoga ini membantu :-)


11
2018-06-08 19:41



Hal-hal besar adalah:

  • Sebuah rencana - Jika orang tidak tahu kemana mereka pergi, mereka tidak akan pergi kemana-mana. Oleh sebab itu, dimulainya setiap proyek memerlukan beberapa orang (seringkali proyek graybeards) untuk masuk ke ngerumpi dan membuat rencana; rencana tidak perlu terlalu rinci, tetapi masih diperlukan.
  • Sistem kontrol versi - Tanpa ini, kamu tidak bekerja sama. Anda juga perlu komitmen teguh bahwa jika hal-hal tidak dilakukan, mereka tidak dihitung. “Oh, itu ada di salah satu kotak pasir saya” hanyalah alasan saja.
  • Pelacak masalah - Anda tidak dapat melacak hal-hal ini melalui folder email. Pasti harus didukung database.
  • Sistem pemberitahuan - Orang perlu tahu kapan hal-hal yang berkomitmen untuk kode yang mereka pertahankan atau komentar dibuat untuk bug yang menjadi tanggung jawab mereka. E-mail bisa bekerja untuk ini, seperti halnya IRC (disediakan semua orang menggunakannya, tentu saja).
  • Membangun sistem - Itu tidak terlalu penting bagaimana ini terjadi, asalkan dengan satu tindakan Anda bisa mendapatkan versi lengkap keadaan saat ini, baik dari kotak pasir pengembangan Anda dan dari repositori utama. Pilihan terbaik untuk ini tergantung pada bahasa apa yang Anda gunakan.
  • Test suite - Test suite membantu orang menghindari kesalahan konyol. Ini harus mudah dijalankan sebagai build (menjadi bagian dari build) baik). Perhatikan bahwa tes hanya pengganti mentah untuk kebenaran, tetapi mereka sangat jauh lebih baik daripada tidak sama sekali.

Akhirnya, Anda perlu kesediaan untuk bekerja sama untuk memenuhi rencana tersebut. Itu terlalu sering menjadi bagian yang sulit.


8
2018-06-08 20:00



Umumnya adalah praktik yang baik untuk tidak memeriksa membangun artefak ke dalam repositori. Repositori akan berisi pohon sumber, konfigurasi bangunan, dll - apa pun yang ditulis oleh manusia. Insinyur perangkat lunak akan memeriksa salinan kode mereka ke sistem file lokal mereka dan membuatnya secara lokal.

Ini juga merupakan praktik yang baik untuk memiliki tes unit yang dijalankan sebagai bagian dari proses pembangunan. Dengan cara ini, pengembang akan langsung tahu jika perubahannya telah membatalkan tes unit apa pun, dan akan memiliki kesempatan untuk memperbaikinya sebelum memeriksa perubahannya.

Anda mungkin ingin melihat dokumentasi untuk sistem kontrol versi (salah satu dari Subversion, CVS, Git, dll) dan untuk membangun sistem (misalnya, di Java ada Ant dan Maven).


7
2018-06-08 18:37



bagaimana programmer bekerja sama dalam sebuah   perangkat lunak di sebuah perusahaan

Pengembang tidak pernah bekerja sebagai tim. Tim mengisap. Dilbert lucu bukan karena dia karakter lucu seperti Goofy. Dia lucu karena dia nyata dan orang-orang mengenali situasi yang dia hadapi.

Comic


5
2018-06-09 12:27



Tidak ada standar untuk hal-hal yang Anda tanyakan. Sebaliknya, ada konvensi dan ini sangat bergantung pada ukuran dan kematangan organisasi. Jika Anda berada di sebuah organisasi kecil, katakanlah beberapa programmer, maka hal-hal mungkin akan menjadi agak informal dengan pengembang individu melakukan pengkodean, membangun, dan menguji.

Dalam organisasi yang lebih besar, mungkin ada insinyur dan proses pembangunan yang berdedikasi. Organisasi semacam ini biasanya akan melakukan pembangunan formal secara teratur, katakanlah sekali sehari, menggunakan kode sumber apa pun yang diperiksa. Proses ini juga biasanya akan menyertakan BVT (Uji Validasi Build) dan mungkin beberapa tes regresi. Pengembang akan memeriksa kode dari repositori, mengerjakan bagian mereka sendiri secara lokal, lalu memeriksanya.

Di organisasi terbesar, seperti Microsoft atau Google, mereka akan memiliki grup dan lab lengkap yang sepenuhnya berdedikasi yang akan membangun basis yang lebih banyak atau lebih sedikit, sehingga hasil dari setiap operasi tersedia. Organisasi-organisasi ini memiliki proses dan prosedur yang sangat formal di tempat tentang apa yang akan diperiksa dan kapan, apa proses peninjauan kode, dll.


3
2018-06-08 18:43



Jawaban singkat - "Itu tergantung".

Saat ini, saya sedang mengerjakan proyek sendiri, jadi saya yang membuat / menggunakan VCS. Saya tahu tempat lain di mana Anda memiliki tim yang mengerjakan proyek bersama merasa ngeri e-mail. Atau tim besar (+5) menggunakan VCS.

Pada catatan itu, saya sangat menyarankan untuk belajar setidaknya beberapa VCS, dan Joel Spolsky memiliki pengantar yang bagus tutorial untuk Mercurial. Bazaar (pilihan pribadi saya) serupa, dan kemudian Git adalah yang terdekat berikutnya dalam hal kesamaan, tetapi mungkin lebih populer daripada (setidaknya ATM). Setelah itu Anda memiliki SVN yang sangat lemah dalam perbandingan.

Sebenarnya, Joel pembicaraan tentang sebagian besar pertanyaan Anda - Saya sarankan membaca 10 tahun arsip yang dia miliki - itu semua adalah informasi yang sangat berguna, dan sebagian besar berkaitan dengan situasi Anda saat ini dan dekat masa depan.


2
2018-06-08 18:45



Tidak ada buku masak untuk bekerja dengan pengembangan perangkat lunak, tetapi secara umum sistem kontrol versi harus menjadi jantung dari sistem build Anda, bahkan jika Anda bekerja dalam proyek di mana Anda adalah satu-satunya pengembang. Bahkan dalam hal ini, mampu mengembalikan versi dan membaca log versi merupakan bantuan yang sangat disambut baik dalam memperbaiki bug. Ini bukan satu-satunya fitur dari sistem kontrol versi, tetapi ini saja membenarkan menginstal, mengkonfigurasi dan memelihara sistem kontrol versi.

Pembuatan dapat dilakukan oleh setiap pengembang saat menambahkan kode baru, atau secara berkala oleh "server build". Pendekatan terakhir membutuhkan lebih banyak penyiapan, tetapi membantu menemukan kesalahan pembuatan lebih cepat.


2
2018-06-08 22:18



Pemrograman yang tepat adalah hal yang mendalam yang sangat diuntungkan dari pengalaman. Berpasangan seperti menjalankan beberapa prosesor kesadaran ... seseorang dapat mengabaikan sesuatu yang dilihat oleh yang lain dan selama mereka berkomunikasi dapat menghasilkan kemajuan besar.


1
2018-06-08 18:35



Pertama-tama, tim bekerja dengan menggunakan repositori (yang dapat menjadi kontrol versi profesional, atau hanya sekelompok direktori yang dianggap sebagai 'hidup', namun sistem kontrol revisi adalah standar de facto). Juga, bagaimana strategi yang dikelola proyek tergantung pada bagaimana Anda bekerja (air terjun, gesit, dll.). Jika Anda bekerja dalam iterasi, Anda membangun komponen / plugins / modules / libraries yang berkelanjutan, dan Anda melakukan pengujian unit, sampai selesai sebagai selesai. Sebagai tim, Anda bekerja dalam tim yang berarti Anda tidak bekerja di seluruh proyek di mana pun pada waktu yang sama. Sebaliknya, Anda mendapat tugas untuk tampil di dalam bidang proyek. Pada beberapa kesempatan Anda harus memperbaiki kode yang bukan milik Anda, tetapi itu biasanya terjadi ketika perilaku aneh terjadi. Pada dasarnya, Anda melakukan pengujian terhadap bagian-bagian yang Anda kembangkan.

Biarkan saya mencontohkan ini untuk Anda. Anda berada di dalam tim pekerja konstruksi. Arsitek datang dengan rencana untuk sebuah bangunan, mandor melihat apa yang dibutuhkan untuk membangun dan kemudian menyewa konstruktor. Tukang batu melakukan dinding, memeriksa mereka untuk kekuatan dan merekatkannya dengan baik. Tukang listrik melakukan semua kabel di dalam gedung sehingga listrik dapat mengalir. Setiap pria memiliki pekerjaan sendiri. Kadang-kadang, tukang listrik mungkin ingin berdiskusi dengan tukang batu jika dinding tertentu dapat diukir, tetapi selalu bersama dengan mandor.

Saya harap ini adalah bantuan untuk Anda!


1
2018-06-08 19:32



Biasanya, sistem kontrol sumber berisi kode sumber dan biasanya tidak memiliki binari. Jika Anda ingin membuatnya dan menjalankannya, Anda akan memeriksa kode dan membuatnya di komputer lokal Anda.

Beberapa tempat menjalankan bangun malam untuk memastikan semuanya berfungsi. Bahkan mungkin ada beberapa tes otomatis yang dijalankan sisi server. Jika build atau apa pun gagal, seseorang akan diberitahu secara otomatis.


0
2018-06-08 18:38