Haruskah programmer terbaik Anda harus memeriksa kode orang lain ke dalam kontrol sumber?


29

Salah satu perbedaan antara svn dan git adalah kemampuan untuk mengontrol akses ke repositori. Sulit untuk membandingkan keduanya karena ada perbedaan perspektif tentang siapa yang harus diizinkan melakukan perubahan sama sekali!

Pertanyaan ini adalah tentang menggunakan git sebagai repositori terpusat untuk tim di suatu perusahaan. Asumsikan bahwa anggota tim memiliki tingkat keterampilan yang berbeda-beda, seperti halnya kebanyakan perusahaan.

Git tampaknya menganggap bahwa satu-satunya programmer terbaik Anda (paling produktif, paling berpengalaman) dipercaya untuk memeriksa kode. Jika itu masalahnya, Anda menyempatkan waktu untuk benar-benar menulis kode untuk meninjau kode orang lain untuk memeriksanya. Apakah ini berhasil? Saya benar-benar ingin memfokuskan pertanyaan ini pada apa penggunaan waktu programmer terbaik Anda, bukan pada praktik kontrol versi terbaik secara umum . Sebuah akibat wajar mungkin, apakah programmer yang baik berhenti jika sebagian besar pekerjaan mereka adalah untuk meninjau kode orang lain? Saya pikir kedua pertanyaan ini bermuara pada: apakah ulasan tersebut sepadan dengan produktivitas yang dicapai?


5
Tentukan "programmer terbaik"? Terbaik dalam hal apa? Mengikuti aturan sewenang-wenang? Mengeluarkan kode? Menulis kode zero-defect?
Timo Geusch

3
Maaf, saya masih mencoba menyiasati konsep meninjau kode yang tidak terkontrol (yaitu tidak dicentang) ... pasti salah satu manfaat utama menggunakan SCS adalah bahwa Ulasan dapat dilakukan terhadap yang diketahui / dikendalikan iterasi kode?
Andrew

2
@Andrew dengan gitpengembang apa pun dapat memiliki repo sendiri (di komputer pribadinya) dan repo pribadi publik (yang ada di server, di belakang apache) yang hanya dapat ditambahkan perubahannya. Perbedaannya adalah, bahwa hanya repo pengembang utama yang "diberkati", yang darinya setiap orang harus keluar. Kode checkout keluar dari repo publik pengembang dan menggabungkannya ke repo publiknya. Anda berdua telah mengetahui / mengendalikan iterasi serta kontrol sumber setiap saat.
Hubert Kario

32
"Git tampaknya menganggap bahwa satu-satunya programmer terbaik Anda (paling produktif, paling berpengalaman) dipercaya untuk memeriksa kode" adalah anggapan yang salah. Git dapat dikonfigurasi sesuai keinginan Anda. Model "Permintaan tarik" hanyalah satu cara - idealnya cocok untuk proyek sumber terbuka dengan sejumlah besar kontributor yang tidak diketahui. Di sebagian besar lingkungan komersial, model "permintaan tarik" akan menjadi tanda bahaya, menunjukkan proses dan prosedur SDLC dan QC yang buruk.
mattnz

4
Saya yakin @mattnz benar di sini. Ini semata-mata merupakan hasil dari pengaruh open source yang kuat pada git di mana ada tim pengembang inti yang mengontrol keadaan repo, tetapi yang lain juga dapat berkontribusi.
Steven Evers

Jawaban:


53

Karena tidak jelas dari pertanyaan Anda, saya hanya ingin menunjukkan bahwa alur kerja gatekeeper sama sekali tidak diperlukan dengan git. Ini populer di proyek sumber terbuka karena banyaknya kontributor tidak tepercaya, tetapi tidak masuk akal dalam organisasi. Anda memiliki opsi untuk memberi semua orang akses push jika Anda mau.

Apa yang diabaikan orang dalam analisis ini adalah bahwa programmer yang baik menghabiskan banyak waktu berurusan dengan kode rusak programmer lain. Jika setiap orang memiliki akses push, maka build akan rusak, dan programmer terbaik cenderung menjadi yang sering mengintegrasikan dan melacak pelakunya ketika hal-hal rusak.

Satu hal tentang semua orang yang memiliki akses push adalah bahwa ketika sesuatu rusak, semua orang yang menarik akan rusak sampai komit yang melanggar dikembalikan atau diperbaiki. Dengan alur kerja gatekeeper, hanya gatekeeper yang terpengaruh. Dengan kata lain, Anda hanya memengaruhi salah satu programmer terbaik Anda, bukan semuanya.

Mungkin ternyata kualitas kode Anda cukup tinggi dan rasio biaya-manfaat dari penjaga gerbang masih tidak sepadan, tetapi jangan abaikan biaya yang sudah diketahui. Hanya karena Anda terbiasa kehilangan produktivitas itu tidak berarti itu tidak terjadi.

Juga, jangan lupa untuk menjelajahi opsi hybrid. Sangat mudah dengan git untuk mengatur repositori yang dapat didorong oleh siapa pun, lalu gatekeeper seperti pengembang senior, penguji, atau bahkan server integrasi berkesinambungan otomatis memutuskan apakah dan ketika perubahan membuatnya menjadi repositori kedua yang lebih stabil. Dengan begitu Anda bisa mendapatkan yang terbaik dari kedua dunia.


10
+1: Untuk ... Pemrogram yang baik menghabiskan banyak waktu berurusan dengan kode rusak pemrogram lain.
Jim G.

3
+1 Jawaban terbaik. Terutama menunjukkan bahwa satu dev melakukan bug build-breaking berdampak negatif pada semua orang.
Evan Plaice

Berada dalam situasi itu, ternyata dua programmer terbaik penuh waktu digunakan untuk meninjau dan memperbaiki kode orang lain. Tentu kualitas kode pada VCS bagus tetapi semangat untuk kedua ini berkurang lebih cepat daripada flush toilet. Apa yang dimulai sebagai ide yang tampaknya baik berubah menjadi mimpi buruk ketika keduanya berlari keluar pintu ke tempat-tempat di mana mereka bisa mendapatkan, katakanlah, tugas yang lebih kreatif.
Newtopian

1
Poin bagus, @Newtopian. Tempat-tempat di mana saya telah melihat keberhasilan ini memiliki lebih banyak model layanan-mikro, dan hanya satu tim scrum yang memiliki akses ke setiap layanan-mikro yang diberikan, tetapi tanggung jawab tersebar ke seluruh sistem secara keseluruhan. Jika Anda tidak memiliki setidaknya beberapa programmer berpengalaman per tim scrum, praktik perekrutan Anda perlu ditingkatkan.
Karl Bielefeldt

40

Saya telah bekerja di pekerjaan di mana check-in terbatas hanya untuk lead tim (dan lead tim tidak dapat memeriksa kode mereka sendiri). Ini berfungsi sebagai mekanisme kami untuk menerapkan tinjauan kode, terutama karena sejumlah insiden di mana komitmen buruk masuk ke basis kode bahkan di sekitar check-in yang terjaga keamanannya dan analisis statis.

Di satu sisi, itu berhasil. Sejumlah komitmen buruk ditemukan sebelum mereka masuk ke basis kode (dan segera dilupakan selama sekitar satu minggu sampai seseorang menemukan mereka). Ini menyebabkan lebih sedikit gangguan pada basis kode. Plus, saya bisa mendorong kembali beberapa format / struktur hal sebelum mereka menjadi hutang teknologi; tangkap beberapa bug sebelum menjadi bug. Dan itu memberi saya perasaan yang hebat untuk apa yang dilakukan tim saya.

Di sisi lain, itu menyebabkan saya secara spontan menjadi marah ketika 3 baris perubahan saya memerlukan waktu 4 jam untuk dilakukan karena harus melacak petunjuk lain dan membuat mereka untuk melakukan komitmen. Itu mendorong saya untuk melakukan komitmen yang jauh lebih jarang daripada praktik terbaik, dan kadang-kadang menyebabkan masalah mencoba melacak perubahan pada pengembang yang melakukannya.

Saya biasanya tidak akan merekomendasikan itu kecuali di lingkungan yang paling membutuhkan. Melakukan ulasan dan melakukan itu sebenarnya tidak terlalu buruk. Memiliki proses saya sendiri tergantung pada tingkah orang lain meskipun menyebalkan. Jika Anda tidak dapat mempercayai pengembang Anda untuk memeriksa kode, dapatkan pengembang yang lebih baik.


8
@ HubertKario - Jika pengembang terbaik Anda menghabiskan waktu melakukan ulasan kode dan sisanya diblokir secara efektif sampai selesai, saya tidak melihat terlalu banyak perbedaan praktis.
Telastyn

6
Bagaimana mereka diblokir? Anda membuat tambalan (komit secara lokal), kirimkan ke hulu, dan terus bekerja di widget baru (buat komit lokal baru). Jika perubahan Anda diterapkan kata demi kata, Anda hanya perlu checkout dan menggabungkan repo pemimpin. Jika itu tidak diterapkan kata demi kata, Anda masih dapat melakukan rebase pada karya selanjutnya. Jika perubahan benar-benar penting, Anda dapat mempublikasikannya di repo publik Anda sendiri dan memberi tahu orang untuk checkout dari sana atau hanya mengirimnya tambalan. Dalam hal ini gitakan mendeteksi bahwa perubahan sudah dibuat dan lewati saja menerapkan patch hulu tertentu.
Hubert Kario

9
Baris terakhir dalam pertanyaan ini adalah benar-benar inti di mata saya. Pengembang yang tidak tepercaya akan menjadi paling tidak efektif dan paling membenci pekerjaannya. Jangan mempekerjakan orang yang tidak akan Anda percayai. Ini sia-sia membuang-buang uang untuk orang yang Anda tidak akan membiarkan melakukan pekerjaan Anda membayar mereka
Jimmy Hoffa

1
@ HubertKario - Anda tahu lebih baik dari saya. Lingkungan tempat saya berada membuatnya menyebalkan untuk menyulap berbagai cabang / perubahan.
Telastyn

5
@Telastyn Saya tidak tahu apakah saya seharusnya menafsirkan jawaban Anda secara harfiah seperti yang saya lakukan, tetapi kelemahan lain dari itu adalah riwayat anotasi / menyalahkan akan semuanya salah. Jika Anda menemukan beberapa kode yang tidak Anda mengerti, Anda akhirnya akan meminta peninjau yang melakukan itu, bukan programmer yang menulisnya.
Daniel Kaplan

28

Tidak. Siapa pun harus dapat berkomitmen.

Jika Anda memiliki masalah dengan bug yang dilakukan, itu bukan kebijakan kontrol sumber yang salah. Para devs yang gagal memastikan apa yang dia lakukan berhasil. Jadi yang harus Anda lakukan adalah menentukan pedoman yang jelas tentang apa yang harus dilakukan dan kapan.

Hal hebat lainnya disebut unit test;)

Ada alternatifnya.

a) Jika Anda menggunakan kontrol versi terdistribusi, Anda dapat membuat repo utama yang hanya dapat menarik permintaan. Dengan cara itu semua pengembang bisa mendapatkan versi kode mereka sendiri sementara Anda mendapatkan kontrol dari cabang utama.

b) Dalam subversi dan sejenisnya Anda bisa menggunakan cabang di mana setiap dev harus membuat tambalan untuk membawanya ke cabang utama.


1
Ini. Jika Anda melakukan tanpa unit dan membuat tes, memiliki persyaratan peninjauan kode adalah perban yang tidak sempurna.
Brian Knoblauch

ya. Itu sebabnya saya menyebutkan alternatifnya. Ulasan kode lebih baik daripada tidak sama sekali. Tidak bisa versi kode adalah rasa sakit tidak ada pengembang yang harus terkena.
jgauffin

2
Tes unit tidak membantu jika ditulis dengan huruf <masukkan fav 4 huruf Anda di sini> sebagai kode unit.
ott--

@BrianKnoblauch: orang bisa berpendapat bahwa yang sebaliknya juga benar. Idealnya, Anda harus memiliki keduanya.
Doc Brown

@ ott - Saya baru saja mendengar cerita tentang seorang dev yang pergi setelah melakukan perbaikan yang mengerikan dan mengomentari semua Asserts dalam unit test-nya. Tes berhasil secara default sehingga butuh beberapa saat untuk menyadari masalah ini!
Alex

8

Anda harus melihat proyek-proyek seperti Gerrit yang memungkinkan semua pengembang untuk mendorong kode mereka ke cabang 'review' dan begitu Anda senior / pemimpin pengembang senang dengan perubahan ini, mereka dapat mendorong mereka ke master / rilis.

Jika mereka tidak senang, mereka dapat meninggalkan komentar di sebelah sebaris kode, meminta tambalan yang diperbarui, dll.

Dengan cara ini siapa pun dengan perubahan yang tertunda dapat mengeluarkannya segera setelah siap dan hanya orang yang memenuhi syarat (dengan hak +2 yang tepat di Gerrit) yang dapat mendorong kode itu untuk menguji dan kemudian diproduksi.


2
Kami menggunakan gerrit dengan sukses besar. Memecahkan setiap masalah OP memiliki masalah dengan dan bahkan beberapa dia tidak tahu dia punya.
mattnz

8

Tidak, itu menggunakan talenta terbaik Anda. Bayangkan sebuah perusahaan penerbitan mengambil penulis mereka yang paling sukses dan membuat mereka melakukan pengeditan; ide buruk.

Seharusnya ada ulasan kode, tapi itu tidak berarti selalu seorang Sr memeriksa kode jr. Akhirnya, semua orang di tim harus diharapkan untuk mencapai tingkat di mana mereka dapat berkontribusi kode dengan panduan minimal. Mereka melewati tiga tingkat kepercayaan:

  1. Tidak ada - Saya ingin melihat setiap baris kode sebelum Anda memeriksanya.
  2. Beberapa - Beri tahu saya apa yang Anda lakukan dan saya akan memberikan umpan balik
  3. Kebanyakan - Lakukan pekerjaan Anda dan hanya meminta bantuan saat dibutuhkan.

Keuntungan membebaskan bakat Anda:

  • fokus pada desain
  • keterlibatan dalam menyiapkan standar pengkodean dan strategi penegakan (tanpa secara manual melakukannya sendiri)
  • mengatasi masalah pengkodean yang sulit
  • memberikan bimbingan (tanpa harus menyetujui setiap baris kode)

Ada pengembang yang tertarik pada jalur manajemen yang mungkin memilih untuk tidak membuat kode sepanjang hari; biarkan yang lain sendirian.


1
+1. Biarkan tim meninjau tim - baik, peninjau dan peninjau, dapat untung, bahkan jika peninjau kurang berpengalaman daripada yang ditinjau. Dan Anda dapat melakukan semua ulasan SETELAH check-in. IMO, jika Anda mencegah orang-orang check-in, produktivitas mereka akan menurun (terlepas dari motivasi mereka).
Andy

5

apakah ulasan tersebut sepadan dengan produktivitas yang dicapai?

Itu tergantung pada tim "keseimbangan" dan pada bagaimana ulasan diatur. Keduanya adalah masalah manajemen dan kerja tim, tidak ada jumlah sihir kontrol versi teknologi (terpusat atau didistribusikan) dapat memiliki pengaruh besar pada itu.

Jika dilakukan dengan salah , produktivitas tentu saja akan membunuh manfaat dari ulasan tersebut; jawabannya adalah tidak menjatuhkan ide ulasan tetapi untuk mengetahui bagaimana melakukannya dengan benar .

Satu pendekatan untuk mengetahui apakah ulasan Anda OK adalah dengan menggunakan alat pelacak masalah untuk melacak waktu yang dihabiskan untuk ulasan (beberapa alat peninjau kode juga memungkinkan untuk itu). Jika Anda mengetahui bahwa ulasan membutuhkan banyak waktu, investasikan upaya untuk menemukan alasan dan cara untuk meningkatkan hal-hal. Juga, tidak ada salahnya memiliki 1: 1 reguler dengan anggota tim untuk menemukan masalah potensial dengan ulasan kode.


Jika pemrogram "terbaik" dalam tim dipaksa menghabiskan berjam-jam menggali melalui sampah yang tidak dapat dipahami yang dihasilkan oleh pembuat kode yang jelek, solusinya adalah memecat pembuat sampah, bukan untuk menarik teknologi VCS.

  • Dalam salah satu proyek sebelumnya saya ditugaskan untuk meninjau perubahan kode yang dilakukan oleh anggota tim yang kinerjanya rendah secara permanen, dalam komponen yang memakan waktu hampir satu jam untuk hanya membangun dan menjalankan tes. Saya mulai membaca perbedaan dan ketika saya melihat perubahan yang tidak dapat dikompilasi, saya cukup menyelesaikan ulasan, memposting komentar yang diperlukan dan meminta manajemen untuk memastikan bahwa permintaan ulasan lebih lanjut datang dengan konfirmasi tertulis bahwa kode mereka dikompilasi. Tidak ada "permintaan ulasan" sejak dan segera pria itu pergi.

Di sisi lain, ketika tim cukup seimbang, ulasan kode menyenangkan dan mendidik. Dalam proyek saya sebelumnya, kami memiliki persyaratan untuk review kode 100% dan tidak butuh banyak waktu juga tidak mengganggu. Ada bug yang ditemukan melalui ulasan, dan ada perdebatan tentang gaya pengkodean dan pilihan desain, tapi itu terasa ... normal .


Jika perubahan kode diblokir selama berhari-hari ... berminggu-minggu untuk mendapatkan QA untuk pengujian "karena ulasan", mempelajari tentang trik VCS akan menjadi cara yang paling tidak mungkin untuk menyelesaikan masalah ini. Sebagai gantinya, orang akan lebih memfokuskan upaya mereka untuk menemukan masalah dengan cara bagaimana proses peninjauan diatur.

  • - Oh, integrasi perubahan ini sangat tertunda karena pengulas tiba-tiba sakit, sungguh sial.
    - Halo! Ya ampun, pernahkah Anda berpikir untuk memiliki pengulas cadangan untuk menangani kasus seperti itu?

4

Iya nih. Tetapi hanya jika Anda berbicara tentang kontrol sumber didistribusikan. Dengan terpusat - itu tergantung.

Jika hanya ada sedikit programmer, dibutuhkan sedikit waktu. Tentunya kurang dari perbaikan yang akan diperlukan untuk menghapus bug dan hutang teknis nanti.

Jika ada sangat banyak programmer, Anda dapat mendelegasikan tugas tinjauan kode aktual ke letnan dan meminta pengembang memimpin perubahan (hampir) tidak perlu dipertanyakan lagi. Ini berfungsi untuk kernel Linux, saya tidak berpikir bahwa ada proyek perangkat lunak yang lebih besar ...

Sekali lagi, jika proyek kecil, pemimpin akan dengan cepat melihat siapa yang memberikan kode yang baik dan siapa yang menghasilkan kode yang buruk. Dia akan dengan cepat melihat bahwa J.Random menulis kode yang baik yang hanya perlu memeriksa untuk keputusan arsitektur sementara magang menulis kode yang buruk yang perlu ditinjau baris demi baris sebelum penggabungan. Umpan balik dengan cara ini akan mengurangi beban perawatan dan memberikan pengalaman langsung tentang apa pun yang dipelajari oleh pekerja magang dan yang harus disimpan di perusahaan. Menarik dan menggabungkan cabang dari gitrepo lain membutuhkan waktu belasan detik, biasanya membaca judul pesan komit akan membutuhkan lebih banyak waktu, jadi setelah saya tahu siapa yang bisa dipercaya untuk menulis kode yang bagus menggabungkan kode orang lain adalah masalah.


2

Peninjauan kode tidak selalu membutuhkan perhatian hanya programmer terbaik Anda. IMO, itu harus menjadi hal yang informal. Hanya pendapat kedua atau sepasang mata kedua pada sepotong kode dari non-pemula sebelum diperiksa ke dalam produksi. Ini membantu mengurangi kelalaian besar sambil juga membantu orang menjadi lebih baik dalam mengkodekan sebagai keahlian dengan terkena perspektif pengembang lainnya.

Semacam lite pemrograman pemrograman yang kurang menjengkelkan. Dengan kata lain, itu tidak akan lama dan Anda tidak harus menunggu seseorang berjam-jam. Apa pun dalam proses pengembangan Anda yang melibatkan orang menunggu sesuatu adalah buang-buang uang dan melumpuhkan momentum / moral, IMO.

Jika tinjauan kode dimaksudkan untuk menghentikan 99,5% bug sebelum mereka masuk ke basis kode Anda di tempat pertama, tidak akan ada titik nyata untuk kontrol versi yang canggih. Yang mengatakan, git mengintimidasi pada awalnya tetapi penggunaan umum dasar tidak begitu rumit dan sangat dapat dikonfigurasi. Anda harus dapat berhenti selama beberapa jam untuk mengajari semua orang bagaimana menggunakannya. Semua orang berkomitmen. Semua kecuali pemula pemula melakukan review sampai mereka menunjukkan keahlian pada sesuatu.


0

Selama perubahan yang diajukan telah ditinjau oleh 'programmer terbaik', siapa pun harus diizinkan mengirimkan kode. Satu-satunya orang yang seharusnya memiliki kemampuan untuk menegakkan kontrol pada repositori adalah Release Engineer, jika orang itu ada.

Secara pribadi, saya akan sangat kesal jika saya harus memeriksa kode orang lain.

Beberapa masukan pada hasil edit Anda: Tidak, seharusnya tidak. Ulasan adalah kejahatan yang perlu, mereka melakukan lebih baik daripada merugikan dan programmer yang baik akan menghargai ini. Mungkin ada keengganan untuk berpartisipasi dalam ulasan karena mereka tidak menyukai gagasan 'programmer yang lebih rendah' ​​mengkritik kode mereka. Sayang sekali. Mereka akan jauh lebih mungkin untuk berhenti jika codeline terus-menerus buggy dan mereka malah menghabiskan waktu mereka membersihkan setelah pengiriman setengah-setengah orang lain.


0

Ya, review tidak sia-sia. Saya tidak yakin ada hit produktivitas jika proses peninjauan proporsional karena alasan berikut:

  • Itu membuat programmer jujur ​​- jika Anda tahu itu akan ditinjau, orang akan mengambil jalan pintas lebih sedikit
  • Ini membantu programmer baru belajar dari programmer yang lebih berpengalaman
  • Ini membantu mentransfer pengetahuan khusus domain
  • Tinjauan adalah gerbang lain tempat bug dan masalah potensial dapat ditemukan dan diperbaiki

Dengan tidak mengizinkan semua programmer menggunakan kontrol sumber, mereka kehilangan kemampuan untuk melacak perubahan, membatalkan kesalahan dan melihat riwayat perubahan yang masuk akal. Saya tidak yakin Anda hanya menginginkan programmer "terbaik" Anda untuk dapat masuk ke git.

Karena itu, saya pikir masuk akal jika Anda memiliki seseorang yang bertanggung jawab atas cabang-cabang utama tertentu, seperti cabang rilis. Dalam hal ini saya akan membayangkan bahwa setiap orang dapat menggunakan repositori git, tetapi hanya orang-orang tertentu yang bergabung ke dalam cabang rilis. Saya tidak yakin ada cara untuk menegakkan ini di git, tetapi seharusnya bisa dilakukan dengan proses dan hanya memeriksa tidak ada orang lain yang memeriksa ke dalamnya.

Penggabungan ke cabang rilis dapat dilakukan oleh programmer "terbaik", atau lebih mungkin dilakukan oleh orang-orang yang kompeten setelah peninjauan yang cukup telah terjadi.


1
-1: Itu membuat programmer jujur ​​- jika Anda tahu itu akan ditinjau, orang akan mengambil jalan pintas lebih sedikit. - Hmm ... Saya akan khawatir tentang pengenalan moral hazard. Artinya, pengembang bisa menjadi malas atau ceroboh karena mereka tahu bahwa pengembang yang lebih senior akan selalu bertanggung jawab atas kode mereka dalam bentuk tinjauan kode.
Jim G.

1
Peninjau tidak bertanggung jawab atas kode sama sekali, tetapi sebaliknya memberikan saran dan instruksi tentang masalah dengan kode. Pengembang asli harus memperbaiki masalah dan masih bertanggung jawab atas kode.
Steve

-1

apakah pemrogram yang baik berhenti jika sebagian besar pekerjaan mereka adalah meninjau kode orang lain?

Jika mereka tidak menikmati pekerjaan dan dipaksa untuk melakukan kegiatan ini, maka YA. Sangat mungkin terjadi. Menemukan pekerjaan menarik berikutnya untuk pengembang yang baik bukanlah tantangan besar saat ini.

Haruskah programmer terbaik Anda harus memeriksa kode orang lain ke dalam kontrol sumber?

Benar-benar tidak. Sudah pasti membuang-buang waktu mereka, kecuali untuk beberapa logika kritis yang perlu dalam keadaan padat-batu .

Namun, pengembang junior atau berpengalaman mungkin harus dalam masa percobaan untuk kualitas kode , hanya untuk berada di sisi yang aman dan memastikan bahwa kode mereka mengikuti pedoman pengembangan tim, setidaknya selama beberapa minggu sebelum mendapatkan hak istimewa untuk berkomitmen sendiri.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.