Seberapa layak untuk memiliki satu webapp di beberapa repositori kecil pribadi?

Kami adalah tim dengan anggaran rendah yang bekerja pada aplikasi web. Karena beberapa komplikasi, kami mungkin perlu bekerja dari jarak jauh mulai Januari dan seterusnya. Setelah beberapa konsultasi dan googling, kami menyimpulkan bahwa beberapa repositori kecil adalah pilihan yang lebih murah. Kami sedang memikirkan:

Backend dan layanan
Middleware
Paling depan

Dengan cara ini kita dapat berpisah dalam tim yang relevan, masing-masing bekerja dari jarak jauh di repositori mereka. Seberapa layak untuk memiliki aplikasi kita di beberapa repositori kecil pribadi?

Selain itu pertimbangan apa yang harus kita ambil jika kita bekerja dengan cara ini?

Catatan: Saya bertanya tentang satu proyek besar yang terbagi atas beberapa repositori kecil. Ini berbeda dari pertanyaan terkait yang diajukan di situs ini , karena mereka meminta beberapa proyek dalam satu atau beberapa repositori. Selain itu, kami memilih untuk menyelami proyek, sebagian besar karena kami tidak mau menginvestasikan satu repositori pribadi besar kecuali kami akan tetap menggunakannya.

project-management team repository

— Perak
sumber

Menurut repositori, maksud Anda repositori kode (ala git atau svn)?

— Jay Elston

Hanya sedikit yang benar dalam pemisahan tim adalah masalah yang jauh lebih besar daripada pemisahan repo. Tim tempat saya bekerja memiliki beberapa lusin repo tetapi kami masih satu tim.

— Ixrec

Jawaban:

"... kami menyimpulkan bahwa beberapa repositori kecil adalah pilihan yang lebih murah."

Itu keren. Memecah dan menaklukkan. Anda memecah usaha menjadi potongan-potongan logis, memberikan masing-masing bagian ke tim hard-core yang berbeda, bekerja seperti orang gila selama beberapa bulan, menyatukan semuanya, dan ...

dan...

Yah, itu akan menjadi mimpi buruk. Pasti tidak akan lebih murah. Kenapa bisa begitu?

"Biaya" terbesar dalam proyek perangkat lunak apa pun adalah komunikasi. Anda tidak menghemat uang dengan menulis kode lebih cepat. Itu tidak akan diakui oleh programmer rahasia. ( Psst. Jangan beri tahu siapa pun. Sungguh tidak penting seberapa cepat Anda menulis kode. ) Waktu yang dihabiskan untuk menulis kode benar-benar dikerdilkan oleh waktu yang dihabiskan untuk merencanakan dan berbicara dan bernegosiasi dan berkelahi dan berbicara serta bertemu dan berbicara lebih banyak lagi Berkompromi dan menyadari bahwa Anda seharusnya tidak berkompromi dan berjanji untuk melakukan yang lebih baik dan berteriak serta berharap dan "menyelesaikan" (itu bukan kata-kata, sialan) dan mengulang kembali dan ping dan berbicara dan tidak bisa tidur.

Jadi, Anda memecah pekerjaan Anda menjadi potongan-potongan terpisah dan menyerahkan masing-masing potongan ke tim yang terpisah. Apa yang baru saja kamu lakukan? Anda menambahkan beban komunikasi. Jika Anda beruntung dantim Anda sempurna, sama sekali tidak ada perbedaan biaya antara satu repositori besar dan beberapa repo kecil. Jika Anda tidak beruntung (sedikit yang), membobol tim yang terpisah sebenarnya akan lebih mahal. Cukup sulit untuk tetap selaras ketika Anda semua berada di basis kode yang sama, menginjak kaki masing-masing. Sekarang bayangkan betapa sulitnya ketika tiga tim yang berbeda berpikir persyaratannya berarti sesuatu yang sedikit berbeda (dengan tidak ada cara untuk memperbaiki dengan cepat karena mereka tidak melanggar barang-barang tim lain), memiliki budaya yang sedikit berbeda, dan, pada akhirnya, adalah sangat termotivasi untuk menghindari kesalahan ketika terjadi kesalahan sehingga mereka lebih dari bersedia untuk membuang tim lain di bawah bus.

Saya tahu, saya tahu ... tim Anda lebih baik dari itu. Tetapi apakah mereka benar-benar? Apakah Anda cukup percaya diri untuk mempertaruhkan uang untuk itu?

Lihat, dalam pendekatan mana pun (repo besar / banyak repo kecil) Anda harus mengejek banyak omong kosong di awal. Anda mulai bekerja dengan buta. Secepat mungkin, segera setelah tersedia, Anda harus mulai menggunakan implementasi konkret dari lapisan lain. Ini akan mengidentifikasi masalah dan kesalahpahaman sejak dini. Tentu, ini akan sedikit bergelombang, tetapi jauh lebih tidak bergelombang daripada berkembang secara mandiri dengan spek yang goyah dan berjabat tangan, dan kemudian melipat semuanya bersama-sama hingga larut.

Maksud saya adalah, repo besar / repo kecil bukan masalah. Yang penting adalah bagaimana Anda menyusun tim Anda. Idealnya, tim Anda memiliki identitas independen kecil dalam identitas kohesif yang lebih besar. Agak seperti organ dalam suatu organisme atau mungkin jamur lendir . Terlepas dari bagaimana Anda menyusun kode, beri semua orang kesempatan untuk saling bertemu. Buat komunikasi menjadi mudah. Buat kesalahan bersama dan perbaiki lebih awal dan sering.

— Hanya sedikit Roger
sumber

Saya tidak setuju dengan sebagian besar jawaban ini. Komunikasi tentu saja penting, tetapi; hanya karena Anda membagi basis kode menjadi beberapa repositori, ada: 1. kolaborasi - kolaborator dapat melihat basis kode (dan memodifikasi jika mereka benar-benar perlu), 2. dokumentasi . Jika Anda membuat REST API secara terpisah dari frontend, API dapat didokumentasikan dengan sangat baik dan tidak ada kerumitan terjadi (kecuali jika Anda memiliki pengembang front-end pemula atau dokumentasi omong kosong). Bagaimana aku tahu? Saya menulis / memelihara REST API yang digunakan oleh pengembang pihak ketiga, dan mungkin saya mendapatkan satu email per minggu tentang cara menggunakannya.

— Chris Cirefice

@ ChrisCirefice Itu pendekatan lain sepenuhnya. Ini adalah jenis binatang yang berbeda untuk bersama-sama mengembangkan sistem daripada mengembangkan bagian dari itu. Dalam kasus Anda, pengembang front-end beradaptasi dengan keputusan Anda, tetapi dalam kasus op, keputusan backend diambil paralel dengan kebutuhan dan keinginan front-end

— Machinarius

@Machinarius Itu kurang lebih benar. Bos saya mengolok-olok frontend dan membuat semua keputusan tentang bagaimana aplikasi seharusnya terlihat / berfungsi. Pengembang frontend mulai bekerja pada kerangka, saya mengembangkan titik akhir API yang diperlukan di backend, dan orang-orang frontend kemudian pasang panggilan API untuk mendapatkan data secara paralel. Ini dilakukan setiap minggu, jadi saya tidak melihat banyak perbedaan dalam kasus saya, dan masih berfungsi dengan baik. Pengembang terpisah sedang mengerjakan berbagai aspek secara bersamaan, meskipun itu jelas tidak disebutkan dalam komentar saya sebelumnya.

— Chris Cirefice

Tim kami memiliki satu backender, satu orang untuk menulis dan memelihara layanan, dua ujung depan, dua orang yang bekerja pada versi mobile, dan pemimpin tim, juga bos kami, yang bertanggung jawab membuat semuanya berjalan baik. Kami hampir tidak menyentuh kode apa pun di luar area mereka. Masalah komunikasi itu nyata, seperti halnya dengan tim mana pun, tetapi memecah tim tidak akan menjadi masalah, karena kami sudah bekerja secara independen. Terima kasih atas jawaban Anda, karena memberi saya wawasan untuk ditunjukkan kepada pemimpin tim.

— Perak

Di mata saya membelah repositori sangat tergantung pada tujuan Anda dan alat yang Anda gunakan.

Misalnya, jika Anda menulis aplikasi web Ruby on Rails tanpa API publik (atau pribadi) yang akan dikonsumsi oleh frontend Anda (oleh AJAX misalnya), maka saya sebenarnya tidak melihat bagaimana Anda dapat membagi repositori tanpa menyebabkan sakit kepala besar untuk tim Anda. Kerangka kerja Rails benar-benar berfungsi paling baik dengan arsitektur tipe monolitik dalam kasus itu.

Namun, jika Anda berencana untuk menulis API di Rails atau Node.js, tetapi ingin frontend Anda ditulis dalam Ember.js atau yang lainnya, maka masuk akal untuk membagi repositori. Hal yang sama berlaku jika data aplikasi web Anda akan dibagikan di masa depan oleh klien lain (seperti melalui aplikasi Android / iOS). Jika Anda berencana untuk menulis API untuk dikonsumsi oleh banyak klien, bagi repo Anda. Beberapa orang akan berpendapat bahwa bahkan memisahkan API ke dalam aplikasi yang berbeda sepenuhnya adalah ide yang buruk, yang sepenuh hati saya tidak setuju dengan (dan tampaknya begitu untuk alasan yang baik !

Memisahkan repositori jika Anda sudah berencana untuk memecah aplikasi web seperti yang saya jelaskan adalah satu-satunya pilihan logis. Namun, perlu diingat bahwa karena akan lebih sulit bagi orang untuk menelusuri kode satu sama lain, Anda perlu memastikan bahwa Anda memiliki komunikasi yang baik , tetapi dokumentasi yang lebih penting . Tanpa mendokumentasikan API, misalnya, dua tim Anda yang lain akan sangat marah karena tim API tidak mendokumentasikan arsitekturnya, dan tim API Anda akan marah karena semua orang terus bertanya kepada mereka. Ini bahkan lebih benar untuk tim jarak jauh .

Jadi, semuanya tergantung pada bagaimana Anda ingin menyusun aplikasi di tempat pertama. Jika Anda membuat aplikasi web monolitik (dan Anda tahu atau yakin itu hanya akan menjadi aplikasi web ), maka miliki satu repositori. Jika Anda berencana membuat hal-hal seperti microservices atau REST API yang dikonsumsi oleh banyak klien (atau Anda berencana untuk masa depan ), bagi repo.

— Chris Cirefice
sumber

Repo tunggal tidak harus menjadi monolith. Lapisan fisik dan logis dapat disimpan dalam repo yang terpisah, tetapi tidak harus demikian. Repo tunggal dapat berisi API backend serta lapisan lainnya. Beban komunikasi (dokumentasi adalah bagian dari komunikasi) tidak lebih atau kurang dengan satu repo besar atau beberapa repo kecil. Itu maksud saya - repo tidak masalah. Yang penting adalah bagaimana tim Anda / tim berpikir tentang masalah dan bekerja sama untuk menyelesaikannya.

— Scant Roger

Kami memiliki aplikasi yang sudah dipisahkan dalam entitas yang berbeda. Backend dan layanan berada di satu sisi. Ujung depan hanya mengkonsumsi layanan melalui klien. Front ender kami hanya tahu cara kerja layanan. Tim kami memiliki satu backender, satu orang untuk menulis layanan, dua ujung depan dan dua orang yang bekerja pada versi mobile, dan mereka hampir tidak menyentuh kode apa pun di luar wilayah mereka.

— Perak