Git dan pengembangan tim (untuk boneka)

Rekan penulis artikel: RicardoMilos

Pendahuluan

Hai Jika Anda datang ke sini, maka Anda tertarik dengan pertanyaan tentang bagaimana programmer bekerja dalam sebuah tim. Jika sebelumnya Anda hanya bekerja dalam solo, mungkin bagi Anda tampaknya bekerja dalam tim lebih mudah, karena ada lebih banyak tangan dan karenanya Anda dapat melakukan pekerjaan lebih cepat. Tapi tidak sesederhana itu. Sekarang kita akan membiasakan diri dengan alat apa yang sedang dikembangkan dan apa yang terjadi di dalam tim.

Git

Tentunya Anda terbiasa dengan situasi ini:



Ini adalah masalah versi. Biasanya, masalah seperti itu terjadi pada orang-orang kreatif yang terus-menerus mengulang semuanya dan mencapai yang ideal. Sayangnya, dalam pemrograman juga, jauh dari selalu semuanya ternyata benar pada kali pertama. Bayangkan sebuah situasi: Anda menemukan cara untuk mengulang beberapa kode sehingga bekerja sedikit lebih cepat. Anda menulis ulang, mengkompilasi, menjalankan, dan memahami bahwa sekarang program tidak berfungsi sama sekali. Semuanya rusak.

Dan di sini Anda menyadari bahwa Anda tidak menyimpan opsi yang berfungsi, dan tombol Z pada keyboard Anda rusak, sehingga Anda bahkan tidak dapat melakukan spam ctrl + z. Dalam kemarahan, Anda menerobos monitor dengan tangan kanan Anda yang dipompa. Di malam hari, Anda menangis, terbungkus selimut, dan memikirkan nasib programmer.

Situasi yang menyedihkan ... Dan untuk mencegah hal ini terjadi, Anda perlu menyimpan versi kode Anda.

Nah, programmer adalah orang pintar, dan mereka sangat mengerti bahwa menyimpan semua versi dalam bentuk tumpukan file tidak nyaman sebanyak mungkin dan bahwa sesuatu yang sangat mendesak perlu diciptakan yang akan memfasilitasi penyimpanan versi dan dengan demikian menyelesaikan masalah versi.

Dan di sini kita bisa menggambar analogi dengan game. Hampir semua proyek AAA memiliki sistem penyimpanan. Sebagai contoh yang baik, game Papers Please.



Hampir sama, semua sistem kontrol versi berfungsi.

Version Control System (VCS) adalah sistem yang merekam perubahan pada file atau set file dalam jangka waktu yang lama, sehingga Anda nanti dapat kembali ke versi tertentu.

Klasifikasi SLE:

1. Lokal
2. Terpusat
3. Didistribusikan

Kami sudah menemukan mata uang keras lokal (ini adalah tumpukan yang sama dari file yang sama)

Mata uang keras terpusat

• server pusat
  semua file di bawah kontrol versi
• sejumlah klien
  menerima salinan file

Contoh:

• CVS
• Subversi
• Paksa

Mata uang keras yang didistribusikan

1. Klien sepenuhnya menyalin seluruh repositori
2. Server pusat bertanggung jawab untuk menyediakan salinan master
3. Sinkronisasi mungkin
   
   • Dengan server
   • Dengan klien mana pun
   
   

Contoh:

• Git
• Mercurial
• Bazaar

Mengapa saya perlu SLE

1. Menyimpan semua perubahan proyek
2. Kemampuan untuk beralih "ke setiap tahap proyek"
3. Kemampuan untuk melakukan pengembangan tim secara simultan
4. Kemampuan memecahkan masalah seperti berikut ini

Git

Git - Sistem Kontrol Versi Terdistribusi
Diposting oleh Linus Torvalds
2005 - versi pertama

Instalasi:
Linux: sudo apt install git
Windows / macOS: tautan

Pengembang menggunakan:

• GNU / Linux
• Android
• Anggur
• Google
• Chromium
• jQuery
• Php
• MediaWiki
• Qt

Konsep dasar

Repositori (repositori, repo) - tempat di mana mata uang keras menyimpan metadata dan database objek proyek
Direktori kerja - salinan versi tertentu dari proyek yang diekstrak dari repositori
Area yang disiapkan ( area bertahap) - file layanan yang berisi informasi tentang apa yang harus dimasukkan dalam revisi proyek selanjutnya
Revisi (revisi) - objek yang menyimpan perubahan dalam keadaan proyek (versi proyek)
Berkomitmen - membuat revisi baru

Konfigurasikan GIT

Pengaturan Nama Pengguna

git config --global user.name "Your Name" git config --global user.email you@abc.net 

Pengaturan disimpan dalam file .gitconfig tersembunyi (dalam direktori home pengguna)

 [user] name = John Doe email = jdoe@example.com 

Buat Repositori

 mkdir first_git_repo cd first_git_repo git init 

Status File Proyek

1. Diperbaiki
   file sudah ada di repositori
2. Dimodifikasi
   file berbeda dalam konten dari negara yang berkomitmen
3. Disiapkan
   file yang dimodifikasi yang akan menjadi komitmen setelah membuat revisi baru (file ini akan jatuh ke dalam revisi ini)

Bekerja dengan kode

• Inisialisasi Repositori
  
  

   git init 

• Atau beralih ke revisi tertentu
  

   git checkout _ 

1. Ubah kode proyek: membuat / menghapus / mengedit file
   Dalam IDE apa pun
2. Lihat Status
   git status
3. Menambahkan File yang Dimodifikasi ke dalam Indeks
   (transisi ke status Stadium)
   git add ___
4. Membuat revisi (dari Tahapan ke Repo)
   git commit -m ""

Ringkaslah

Bekerja dengan mata uang keras

Apa yang harus disimpan?

[+] Semua file kode sumber
[+] Semua sumber yang diperlukan untuk kompilasi
[+] pengaturan kompilasi proyek
[-] pengaturan proyek di IDE
[-] file dikompilasi dari sumber
[-] file yang dapat dieksekusi

Hapus dari indeks

git rm _

Komit dapat berisi perubahan ke banyak file

Kapan harus berkomitmen?

• Ketika saya menyelesaikan tugas kecil
• Jika masalahnya besar - bagi menjadi beberapa bagian logis
• Kode harus operasional!

Lihat Sejarah

 git log git log --graph 

Nomor Revisi = SHA-1 Ubah Hash

Beralih ke audit

 git checkout sha1_hash git checkout _8__sha1 

Cabang

Cabang adalah urutan komit di mana fungsional dikembangkan secara paralel

Cabang utama - master

Cabang di GIT

Tampilkan semua cabang yang ada di repositori

git branch

Buat cabang

git branch

Beralih ke cabang

git checkout
Seharusnya tidak ada perubahan yang belum disimpan saat ini.

Buat cabang dan beralih ke sana

git checkout -b

Gabungkan Cabang

Gabung cabang - proses mengintegrasikan perubahan (melakukan) dari satu cabang ke yang lain:

b1 - cabang tempat kita menambahkan perubahan
b2 - cabang dari mana kita menambahkan perubahan

 git checkout b1 git merge b2 

Lihat Sejarah

Utilitas jendela:

• gitg
• gitk
• gitx
• gitKraken

Hapus cabang

Hapus cabang

git branch –d _

HAPUS satu cabang

git branch –D _

Atau lebih tepatnya, hapus cabang tanpa menunggu komit untuk pindah ke master

Perubahan buffer yang belum disimpan

Atau "apa yang harus dilakukan jika Anda perlu beralih ke cabang lain, dan melakukan lebih awal?"

Tulis perubahan pada buffer sementara

git stash

Ekstrak perubahan ini dari buffer

git stash pop

Tautan yang bermanfaat:

git-scm.com/book/en/v2
githowto.com/ru
en.wikipedia.org/wiki/version_system

Pengembangan tim

Jadi, jika Anda sampai pada baris ini, itu berarti Anda setidaknya memiliki sedikit kesepakatan dengan git (saya sangat berharap begitu). Tapi bagaimana dengan pengembangan tim? Mari kita lihat masalah ini secara lebih rinci.

Teka-teki lucu:

Diberikan:

• N pengembang
• Tempat kerja
• Kerangka Acuan (TOR)
• Internet

Pertanyaan:

• Bagaimana cara melaksanakan suatu proyek tanpa menarik perhatian petugas penertiban?

Jawabannya adalah:

• Tim yang terkoordinasi dengan baik dan kerja keras

Hmm, apa itu tim? Seperti apa dia?

Sebuah tim adalah sejumlah kecil orang:

• dengan keterampilan yang saling melengkapi (seseorang sedang pemrograman, seseorang sedang merancang, dll.)
• bercita-cita untuk tujuan bersama (mereka semua harus memenuhi tugas pelanggan untuk mendapatkan kepuasan diri yang lengkap)
• berbagi tanggung jawab untuk mencapai tujuan proyek (jika tiba-tiba salah satu anggota tim mengalami kesulitan dengan TK pribadinya, teman satu timnya akan selalu membantu dia (ini tidak boleh disalahgunakan, jika tidak, Anda tidak akan perlu bagi tim)).

Catatan yang sangat penting: dalam tim Anda harus merasa benar-benar nyaman dan mencoba bergaul dengan seluruh tim, jika tidak semuanya akan salah.

Jadi, sekarang Anda mengerti apa itu tim. Tetapi pertanyaan berikutnya yang muncul di kepala Anda (ya, ya, penulis artikel ini dapat membaca pikiran): “Dan siapa yang bertanggung jawab atas apa yang ada di tim? Apakah semua orang punya tempat sendiri? Atau apakah semua orang melakukan apa yang mereka inginkan? "

Secara alami, setiap peserta dalam tim memiliki peran dan tugasnya sendiri. Kalau tidak, alih-alih mengembangkan produk, akan ada kekacauan. Mari kita lihat peran dalam pemrograman perintah:

1. Ketua Tim:
   
   Team Leader adalah persilangan antara manajer proyek dan pengembang yang memenuhi syarat.
   
   Ada dua peran utama dalam proyek: manajerial - PM, dan teknis - Arsitek Sistem. Timlid sebagian memenuhi kedua peran, tetapi fokus tanggung jawabnya adalah pada manajemen (penekanan pada bagian teknis adalah pemimpin teknologi).
   
   “Pimpinan Tim # 1: Merawat Tim Anda. Tim harus merasa nyaman di lingkungan kerja dan termotivasi dengan baik. Selain itu, ketua tim juga memberikan pertumbuhan profesional dan karier untuk anak-anaknya, secara teratur mengadakan diskusi tentang topik di mana orang-orang tertarik untuk berkembang, dan membantu mereka dalam hal ini. ”
   
   Peran manajerial pemimpin tim mencakup tanggung jawab seperti manajemen, alokasi dan pendelegasian tugas, semua jenis evaluasi dan penjadwalan, pemantauan status proyek, serta pertemuan, komunikasi dengan pelanggan, manajemen dan semua anggota tim (pengembang, penguji, manajer).
   
   Di bawah peran teknis: partisipasi dalam penulisan dokumentasi teknis, pemilihan teknologi untuk proyek, pengembangan arsitektur, R&D, tinjauan kode, pendampingan junior, melakukan wawancara teknis, keterlibatan yang kompeten dari anggota tim baru dalam proses kerja, tanggung jawab untuk bagian teknis proyek.
   
   Hari kerja khas Timlid meliputi:
   
   
   • pertimbangan tugas baru dan distribusinya
   • berdiri bersama tim
   • aksi unjuk rasa
   • pemrograman
   • masalah arsitektur
   • ulasan kode
2. Manajer proyek:
   
   Manajer Proyek adalah seorang spesialis yang tugas utamanya adalah mengelola proyek secara keseluruhan: merancang dan memprioritaskan, menjadwalkan tugas, memantau, berkomunikasi, dan dengan cepat menyelesaikan masalah.
   
   Tanggung jawab utama dan tanggung jawab PM adalah membawa ide pelanggan untuk membuahkan hasil tepat waktu menggunakan sumber daya yang ada. Dalam kerangka tugas ini, PM perlu membangun rencana pengembangan, mengatur tim, mengatur alur kerja proyek, memberikan umpan balik antara tim dan pelanggan, menghilangkan gangguan bagi tim, dan mengontrol kualitas dan pengiriman produk tepat waktu.
   
   Tugas PM dapat diklasifikasikan sebagai taktis dan strategis. Taktis - ini adalah solusi untuk masalah sehari-hari proyek, menghilangkan hambatan dari tim. Yang strategis adalah mengoordinasikan tujuan keseluruhan proyek, jalan menuju itu, serta kecepatan gerakan.
   
   "Pernyataan sasaran utama untuk PM adalah:" Kami membutuhkan ini untuk bekerja ", yang menyiratkan bahwa tim akan memberikan hasilnya dalam jumlah waktu yang wajar dengan tingkat kualitas yang masuk akal."
3. Penguji:
   
   Penguji adalah spesialis yang terlibat dalam pengujian produk perangkat lunak untuk mengidentifikasi kesalahan dalam pekerjaannya dan koreksi selanjutnya.
   
   Tugas utama tester:
   
   
   • Kontrol kualitas produk yang dikembangkan.
   • Identifikasi dan analisis kesalahan dan masalah yang dihadapi oleh pengguna saat bekerja dengan produk perangkat lunak.
   • Pengembangan autotest dan proses regulernya.
   • Menguji pengembangan skrip.
   • Cacat mendokumentasikan ditemukan.
4. Pengembang:
   
   
   • Junior:
     Junior adalah pengembang tingkat pemula.
     
     Setelah menyelesaikan magang, seseorang berubah menjadi Juni penuh. Syarat utama untuk itu adalah kemampuan untuk secara mandiri melakukan tugas-tugas teknis. Jika sebuah proyek dibangun dalam arsitektur, itu harus segera mengimplementasikan bagian lain dari logika aplikasi yang khas. Meskipun Junior dapat membuat kesalahan dari waktu ke waktu, tidak memahami nuansa, mendiskusikan rencana implementasi dengan pemimpin tim, atau memeriksa kode yang sudah selesai dengannya.
     
     Anda perlu memahami bahwa untuk tugas-tugas yang akan diselesaikan Signor dalam sepuluh menit, Juni mungkin memerlukan tiga pendekatan setiap jam, dan dalam prosesnya, kode harus ditulis ulang sepenuhnya, menghabiskan banyak energi tambahan. Penting untuk tidak takut pada hal ini dan merasakan keseimbangan: kapan harus mendorong, mencoba menyelesaikan masalah sendiri, dan ketika, sebaliknya, berhenti membenturkan dahi Anda ke dinding, membakar waktu proyek, dan meminta bantuan. Membenarkan kurangnya kinerja Anda dengan frasa "Aku masih Juni" adalah ide yang buruk.
   • Tengah:
     
     Tengah - pengembang tingkat menengah.
     
     Persyaratan utama untuk pengembang menengah adalah kemampuan untuk secara mandiri melakukan tugas yang diberikan kepadanya. Sangat mirip dengan apa yang ditulis pada paragraf sebelumnya, kan? Namun, ada peringatan penting - kata "teknis" tidak ada di sini. Artinya, pada level baru, Anda perlu memahami persyaratan bisnis dan dapat menerjemahkannya ke dalam solusi teknis.
     
     Dengan cara ini:
     
     
     1. Pengembang menengah memahami apa yang sedang dilakukan aplikasi. Ini memungkinkan Anda untuk lebih memahami tugas, dan karenanya, lebih akurat mengevaluasinya dan mengimplementasikannya dengan lebih baik. Jika persyaratan tidak sepenuhnya mencakup skenario, pengembang yang baik akan memperhatikan hal ini pada tahap perencanaan. Dan tidak ketika aplikasi mulai crash pada tindakan pengguna yang tidak standar.
     2. Pengembang menengah akrab dengan templat dan solusi standar saat membangun aplikasi di bidangnya, memahami mengapa mereka dibutuhkan, dan tahu cara menerapkannya. Standarisasi keputusan sangat penting dalam pengembangan kode secara kolektif, karena memungkinkan orang baru untuk dengan cepat mencari tahu apa dan meminimalkan jumlah kesalahan. Memahami struktur aplikasi tipikal membuat tugas membangunnya dari awal cukup sepele, memungkinkan Anda untuk berbicara tentang prinsip-prinsip implementasi yang tepat dan untuk membedakan kode yang baik dari yang buruk.
     3. Pengembang menengah memahami bahwa tidak ada yang berfungsi. Dia tahu bagaimana berinteraksi dengan anggota tim lain: dia dapat mendiskusikan momen yang sulit dengan seorang desainer, menjelaskan persyaratan yang tidak lengkap dengan analis bisnis atau mengoordinasikan beberapa solusi teknis penting dengan arsitek proyek (jika ada) dan, tentu saja, memiliki alat yang tepat untuk pengembangan tim.
   • Senior:
     
     Senior adalah pengembang tingkat tinggi yang telah melihat banyak kode, mendapat banyak kerucut dan berhasil menarik kesimpulan yang benar dari ini. Tugas utama Signor adalah membuat keputusan teknologi yang tepat dalam proyek. Yang "tepat" adalah yang memaksimalkan manfaat bisnis dan meminimalkan biaya. Penanda yang baik tidak hanya memahami apa yang sedang dikembangkan tim, tetapi juga berpikir tentang tugas apa yang harus diselesaikan oleh aplikasi yang selesai. Mengembangkan situs untuk pelelangan, penanda tangan selalu bertanya-tanya tentang beban puncak dan mencoba untuk meramalkan upaya untuk secara kompetitif menulis ke tabel database. Dia berpikir sebelumnya tentang kemacetan sistem, tentang kemungkinan penskalaan, mengingat kerentanan dan masalah yang disebabkan oleh penggunaan alat yang tidak tepat.
     
     Spesialis seperti itu melakukan hal yang luar biasa - menyelesaikan masalah bahkan sebelum masalah itu muncul. Dari luar, itu menyerupai karunia pandangan jauh ke depan. Tetapi jika proyek Anda hidup dari api ke api, dan Anda terus-menerus harus membuang dan menulis ulang potongan kode - ini adalah gejala bahwa proyek menerima perhatian penandatanganan tidak cukup.
5. Desainer:
   
   Seorang desainer adalah orang yang mendesain. Logikanya, bukan?
   
   Pekerjaan desainer dimulai jauh sebelum piksel pertama muncul, dan berakhir lebih lambat dari yang terakhir.
   
   Kebanyakan orang terbiasa meyakini bahwa desain sebenarnya adalah seperangkat gambar, warna, dan font yang diteruskan ke perancang tata letak dan programmer untuk membuat suatu produk. Terkadang pendekatan ini berhasil, tetapi lebih sering ternyata menjadi proyek, yang kemudian memalukan untuk ditambahkan ke dalam portofolio.
   
   Faktanya adalah bahwa untuk menyelesaikan masalah itu tidak cukup untuk menggambar. Dalam prosesnya, seorang desainer yang baik melewati 4 langkah. Inilah mereka:
   
   • Memahami masalah:
     
     Pekerjaan dimulai dengan pemahaman masalah, seperti teater dengan gantungan: sampai Anda melepaskan pakaian luar Anda, Anda tidak akan melangkah lebih jauh. Jika Anda tidak mempelajari masalahnya, Anda akan mendapatkan produk yang tidak layak.
   • Cari solusi:
     
     Ketika masalah sudah jelas, saatnya mencari solusi. Dalam istilah yang sudah ada, ini semua jenis sketsa dan prototipe yang membantu membangun visi awal produk akhir.
   • Desain:
     
     Ini hanya menggambar dan memilih font. Banyak desainer mulai dari sini dan langsung menyelesaikan pekerjaan, dan hasil karya desainer tersebut dapat dilihat dalam jumlah besar di Dribble atau Behans.
   • Persetujuan:
     
     Bahkan jika Anda memiliki solusi ramping dan elegan di kepala dan di atas kertas, ini tidak berarti bahwa bagi klien itu akan terlihat sama. Jika Anda mengabaikan tahap ini dan hanya memberi klien praktik terbaik, maka paling baik mereka akan dibangun kembali sesuai dengan pemahaman Anda sendiri. Apa yang akhirnya akan tersisa setelah pengeditan klien akan sedikit seperti pekerjaan Anda.
   
   

Nah, sekarang, akhirnya, Anda terbiasa dengan semua posting dalam pengembangan tim. Di sini saya hanya mendaftar posting-posting yang terkait dengan pemrograman. Jika kita menganggap pengembangan produk perangkat lunak sebagai proyek bisnis, maka tentu saja akan ada lebih banyak peran, misalnya, akuntan, pemasar, dll.

Kesimpulan

Nah, jika Anda membaca sampai titik ini - selamat, Anda sangat keren! Tidak, yah, sungguh, otak Anda belum direbus dengan begitu banyak informasi? Saya harap tidak.

Jadi, saya harap artikel kami membantu Anda memahami semua seluk-beluk pengembangan tim. Dan Anda tidak memiliki pertanyaan lagi tentang topik ini. Dan ketika Anda datang ke perusahaan super-duper-unreal-cool-dan-terkenal dan Anda akan dipekerjakan (jika saja mereka mencoba untuk tidak menerima), maka Anda tidak akan bingung dan menunjukkan kepada atasan Anda siapa programmer utamanya. Atau mungkin Anda akan membuat perusahaan sendiri, siapa tahu ;-)

Terima kasih atas perhatian anda!

PS

Artikel ini disiapkan oleh siswa MSHP (Moscow School of Programmer) , berdasarkan kuliah dari kursus Pemrograman Industri.