Bagaimana menerapkan proses pengembangan dengan mahasiswa

Pada pekerjaan pertama saya sebagai pengembang perangkat lunak, tim saya menggunakan agile / scrum untuk mengelola alur kerja proyek kami dan itu bekerja dengan cukup baik. Saya memiliki beberapa mentor berpengalaman yang menempatkan saya di jalur yang benar - saya berhutang banyak pada mereka. Saya bekerja di sana selama beberapa tahun, kemudian pindah ke peluang baru beberapa bulan yang lalu.

Maju cepat ke pekerjaan saya saat ini. Saya bekerja di universitas di bawah arahan seorang profesor. Karena saya di universitas, hampir setiap programmer adalah mahasiswa (murah dan berlimpah!) Bos saya memiliki pengalaman manajemen, tetapi tidak dengan pengembangan perangkat lunak, dan tim perangkat lunak tidak selalu berada di garis depan pikiran bos saya. . Kondisi ini telah menciptakan lingkungan yang sempurna untuk membuat beberapa perangkat lunak berkualitas sangat buruk. Proyek perangkat lunak tampaknya berjalan sedikit nakal, tidak memiliki pemikiran untuk mendesain, dan telah menggunakan beberapa praktik yang benar-benar menakutkan. Saya tahu segalanya bisa lebih baik.

Saya ingin menerapkan proses pengembangan untuk membantu semua orang di jalur, meningkatkan kualitas kode, dan menggunakan perangkat lunak yang lebih stabil. Saya tidak yakin harus mulai dari mana.

Saya tidak mencari, misalnya, untuk jawaban seperti "Gunakan Scrum", "Siapkan papan kanban", atau "Lihatlah tangkas!" (meskipun ide dihargai). Lebih khusus lagi, saya berharap untuk mendapatkan wawasan tentang bagaimana menerapkan proses pengembangan untuk lingkungan kerja ini . Karyawan biasanya bekerja antara 1 hingga 2 tahun sebelum pindah, umumnya tidak berpengalaman, dan rapat standup harian yang mencakup semua orang hampir tidak mungkin dijadwalkan.

Bagaimana seseorang memupuk kualitas, efisiensi, dan komunikasi di tempat kerja seperti itu?

Pembaruan: Setelah membaca beberapa jawaban dan komentar, saya pikir saya akan memberikan beberapa latar belakang tambahan.

Saya tidak akan menganggap diri saya seorang master di seni pengembangan perangkat lunak, tapi saya saya cukup berpengalaman untuk mengenali pemrograman buruk ketika aku melihatnya. Saya dapat menentukan apakah seorang pengembang berbakat atau tidak setelah menghabiskan hanya satu atau dua menit bekerja dengan mereka. Saya merasa nyaman dengan kemampuan saya sendiri untuk menemukan cara untuk menyelesaikan masalah dengan cerdas , namun, area di mana saya benar-benar tidak memiliki pengalaman adalah manajemen proyek di mana pengembang lain terlibat (itulah sebabnya saya di sini meminta Anda semua orang yang luar biasa untuk nasihat).

Saya membuatnya terdengar seperti setiap siswa yang datang ke kantor ini benar-benar tolol. Ada beberapa telur buruk di sini, tetapi sebagian besar siswa yang saya temui cerdas, ingin belajar, dan bersemangat dengan pekerjaan. Beberapa baru saja memulai, dan mereka tidak tahu apa yang tidak mereka ketahui. Dan itu tidak masalah. Ketika saya pertama kali memulai pemrograman, saya tidak lebih baik!

Dibutuhkan waktu lebih lama untuk membersihkan kesalahan daripada melakukan pra-memeriksanya. Jika Anda berurusan dengan pengembang yang (mungkin) tidak terampil atau tidak menyadari praktik yang baik, itu berarti mereka tidak dapat mengubah basis kode (master) sampai kode mereka dilihat oleh seseorang yang berpengalaman.

Anda tidak ingin penjelasan metodologi, jadi izinkan saya membaca bagian itu: gunakan tugas tangkas untuk mengatur berbagai fitur yang dapat dikembangkan secara mandiri.

Mulai gunakan cabang fitur, sehingga semua orang bekerja di cabang yang terpisah. Ketika tugas selesai, pengembang tidak dapat menggabungkan kode mereka ke cabang master. Jika Anda menggunakan Git, mereka masih bisa meluncurkan permintaan tarik. Jika tidak, gunakan metode apa pun untuk melacak tugas jadi (/ cabang) yang disukai Anda.

Lalu kita menuju proses review . Pertanyaan Anda agak kabur adalah apakah ada juga pengembang berpengalaman yang penilaiannya bisa dipercaya lebih dari siswa. Jadi izinkan saya menguraikan dua cara berikut:

Jika ada pengembang berpengalaman, tugas mereka dengan meninjau kode tugas yang sudah selesai. Jika bagus, mereka bisa menggabungkannya ke cabang master. Jika tidak, mereka dapat memperbaiki sendiri atau memberikan umpan balik kepada pengembang tentang apa yang perlu ditingkatkan.

Jika tidak ada pengembang berpengalaman, maka Anda akan selalu mengalami masalah. Jika tidak ada yang menemukan kode yang baik dari kode yang buruk, tidak mungkin untuk menjaga kualitas kode.
Yang terbaik yang dapat Anda lakukan adalah mengadakan rapat peninjauan, di mana pengembang hadir dan menjelaskan implementasinya di depan pengembang lainnya. Meskipun ini tidak dapat menjamin untuk mencegah setiap masalah (mis. Jika semua pengembang memiliki kesalahpahaman yang sama tentang praktik yang baik, itu masih akan mencegah sebagian besar masalah (misalnya jika setidaknya satu pengembang memiliki ide yang tepat dan dapat mengartikulasikannya; atau ketika masalah muncul dari pengembang memahami masalah secara berbeda satu sama lain)

Bagaimana seseorang memupuk kualitas, efisiensi, dan komunikasi di tempat kerja seperti itu?

• Kualitas - Tinjau kode oleh pengembang yang berpengalaman. Dengan tidak adanya pengembang yang berpengalaman, buatlah ulasan grup untuk setidaknya mencakup basis Anda sebaik mungkin.
• Efisiensi - Jika Anda mengatur tugas independen dengan benar, Anda meminimalkan orang yang harus menunggu satu sama lain. Dalam lingkungan di mana tidak semua orang tersedia pada saat yang sama, saya menganggap Anda sedang berurusan dengan banyak penundaan "menunggu orang A". Tindak lanjuti pengembang yang tidak membuat kemajuan, hanya untuk memeriksa apakah mereka membutuhkan bantuan atau bahkan membiarkan mereka melampiaskan frustrasi mereka (frustrasi tersebut dapat mengungkapkan kesalahpahaman tentang masalah yang bisa dihindari).
• Komunikasi - Tetapkan kebijakan pintu terbuka sehingga pengembang dapat meminta bantuan, umpan balik, atau inspirasi kepada seseorang. Dengan tidak adanya mentor yang berkualifikasi, cobalah untuk memfasilitasi interaksi tim (Anda tentu saja masih dapat melakukan ini bahkan jika Anda memiliki mentor yang tersedia, tetapi pentingnya melakukannya meningkat tanpa adanya mentor). Terutama dalam situasi di mana orang bekerja dari jarak jauh dan pada jadwal yang berbeda, pengembang seringkali tidak dekat dengan rekan kerja mereka dan cenderung tidak berkomunikasi di antara mereka sendiri. Bahkan beberapa pertemuan sosial dapat melakukan keajaiban untuk meningkatkan komunikasi terkait pekerjaan di waktu lain.

Hal terbesar untuk lingkungan semacam itu di mana orang baru dan cenderung pergi adalah ulasan kode wajib.

Mereka membantu menyebarkan pengetahuan tentang apa yang harus dilakukan. Mereka membantu mencegah kode terburuk dari masuk ke basis kode. Mereka mempromosikan konsistensi dalam implementasi.

Karena dengan banyak pergantian dan pengalaman, komunikasi lebih penting daripada biasanya.

Lebih banyak ide daripada solusi, tetapi temukan satu bagian penting dari basis kode yang berisi fitur dan elemen serupa untuk memproyeksikan yang mungkin dilakukan oleh siswa Anda dan membersihkannya dengan SANGAT bagus. Satu masalah besar dengan pengembang baru adalah mereka tidak tahu norma dan konvensi basis kode, dan mereka akan melihat kode lain untuk mendapatkan ide bagaimana mengaturnya sendiri. Memiliki banyak pengembang baru yang bekerja di basis kode yang berantakan berarti mereka akan melihat kekacauan dan berpikir itu dapat diterima atau cara terbaik untuk melakukan sesuatu. Praktik buruk kemudian melanggengkan diri mereka sendiri bahkan dalam lingkungan pergantian yang tinggi.

Dengan memiliki setidaknya satu bagian kode yang ditulis dengan baik (atau bahkan hanya satu file), Anda dapat memberi tahu pengembang siswa Anda untuk menggunakannya sebagai contoh praktik terbaik. Katakan kepada mereka Anda akan senang jika mereka dapat menulis kode yang mirip dengan itu, dan banyak dari kode lainnya mungkin bukan contoh yang baik dari cara yang tepat untuk melakukan sesuatu.

Menambahkan komentar atau dokumentasi lain dengan penjelasan tentang mengapa hal-hal dilakukan dengan cara tertentu juga akan membantu pengembang baru untuk mempercepat lebih cepat dengan praktik kode yang lebih baik.

Integrasi berkelanjutan -

Ini adalah kerangka kerja praktis dan konseptual untuk implementasi alat, keterampilan, dan proses tim secara bertahap dan fleksibel.

CI adalah ide alur kerja dari menulis kode ke penyebaran. Tugas-tugas ini secara konseptual dan sebenarnya independen.

CI adalah otomatisasi, khususnya. Ini memiliki implikasi mendalam untuk kualitas dan produktivitas, mulai dari titik di mana kode diketik di layar.

• Implementasi tugas CI dapat diatasi secara independen, rinci, dan bersamaan. Fokus dapat bergeser sesuai kebutuhan.
• Jangan memperkenalkan alat CI sup-ke-kacang
  • Anda akan terganggu oleh proses dan cenderung menutupi keterampilan tugas yang dienkapsulasi.
• Perkenalkan hal-hal berdasarkan ledakan

• Berharap menjadi agen perubahan penuh waktu. Menjadi pemimpin; bukan hanya manajer, bukan hanya pembuat kode senior.

• Bersikap strategis

  • Cawan Suci CI adalah hands-off, kompilasi untuk penerapan otomatisasi. Mereka tidak bisa FUBAR jika mereka tidak bisa menyentuhnya.
  • Pelatihan dan materi pelatihan.
    • Proses dokumen.
    • Buat Manual Programmer , biarkan berkembang secara organik.
    • Wajib.
    • Eksplorasi menguraikan penargetan keterampilan khusus dan basis kode itu sendiri.
  • Tanamkan nilai-nilai programmer profesional, seperti:
    • TDD benar-benar menciptakan kualitas
    • Ulasan kode mencakup semua artefak: komentar, kode yang dikomentari, tes unit, dll.
    • "Aku malu berapa banyak bug yang ditemukan"
    • Objektivitas tidak tertahan oleh rasa kepemilikan kode pribadi dan rasa takut "menyinggung" pemilik.

• Bersikaplah taktis

  • Tugas CI diskrit sendiri dapat diotomatisasi, misalnya komit kontrol versi memicu tes kompilasi dan unit.
  • Aturan yang diberlakukan secara otomatis, seperti pemformatan kode.
    • Waspadalah terhadap minutia yang terlalu banyak menyinggung. Alat akan mulai diabaikan. Memodulasi penegakan aturan sehingga tidak berlebihan.
  • Segera laksanakan Pengembangan Berbasis Tes
  • Prioritaskan dan tekankan setiap perubahan
    • Jangan menganggap lompatan pengetahuan dan keterampilan utama terjadi begitu saja.
  • Jangan biarkan urgensi untuk menumbangkan implementasi yang tepat
  • Pimpin perubahan dan ikuti terus
    • Orientasi pria baru dan beberapa pelatihan minimal diperlukan.
    • Pelatihan eksplisit dan panduan jelas untuk hal-hal baru
    • Latih setidaknya untuk beberapa standar minimum, nosional,. Tidak harus benar-benar formal tetapi berjalan secara acak melalui YouTube bukanlah pelatihan. Verifikasi secara pribadi - lagi-lagi hindari formalitas.
  • Jadilah peninjau kode, tinjau semua kode.
    • Bimbing secara eksplisit perbaikan bug yang menantang dan bagikan pengalaman belajar yang penting.
  • Fleksibilitas yang kaku. Maaf, harus mengatakannya. Tapi itu benar.
• Ciptakan budaya
  • Miliki harapan profesional
  • Alat standar
  • Tekankan pembelajaran di atas metrik produksi
  • Jadilah seorang mentor
  • Saat memperkenalkan perubahan, cukup bergantung pada inisiatif individu "untuk membuatnya" secara halus merongrong pengembangan tim. Identitas tim yang kohesif mencakup kesamaan: alat, pengetahuan, dan tingkat keterampilan. Rasa saling menghormati tumbuh sejauh masing-masing anggota merangkul tesis sebagai nilai yang layak. Pemimpin tim adalah modelnya, tidak terhindarkan; jangan mencontohkan sikap dan harapan "apa pun".

Jalan Menuju Kualitas

• Pengujian unit

  • kunci Pengembangan Test Driven
    • Membaca seluruh buku tentang itu tidak perlu
    • Ini harus menjadi yang paradigma coding
    • Sebagai pemimpin Anda harus terus melakukannya sampai semua orang membuat "unit menguji lompatan iman." Paradigma itu bergeser dari "Saya menulis kode dua kali!" untuk merangkul produktivitas luar biasa.
  • Pengujian unit adalah wajib di toko kami. Tetapi banyak yang tidak melakukannya karena mereka tidak mau. Kurangnya keyakinan manajemen mengirim pesan bahwa unit test tidak benar-benar berfungsi.
    • Jadi unit test terlalu sering diabaikan selama tinjauan kode, yang memungkinkan tes yang salah, tidak efektif, dan bermasalah ke dalam basis kode. Pengujian unit lesu akan menghancurkan seluruh upaya.

• Kontrol versi

  • Saya akan mengutamakan ini tetapi pengujian unit lebih mudah untuk memulai
  • jangan tunda inisiatif lain karena kontrol versi tidak mudah
  • Buat rencana kontrol versi.
    • Anda harus menuliskannya.
    • Lakukan ini bahkan jika itu sederhana seperti "membuang segala sesuatu di bagasi dan tidak ada percabangan."

• Ulasan Kode

  • Ini memiliki potensi terbesar untuk meningkatkan kualitas kode secara detail.
  • Gunakan proses 2 ulasan.
    • Saya sangat terkejut pada berapa banyak bug yang menangkap review 2.
    • Percaya tapi verifikasi. Jalankan kodenya. Mengapa Anda harus mengatakan ini? Lihat tepat di atas.
    • Awalnya Anda akan menjadi satu-satunya peninjau. Mintalah tim menonton Anda mengulas "langsung." Mereka tidak akan pernah belajar berpikir sebaliknya.
    • Anda akan segera menjadi reviewer kedua. Sebagai jaminan keterampilan individu minta mereka meninjau; akhirnya sama-sama pengulas. Anda tentu akan selalu melihat kode, tanpa kecuali.

• Refactoring

  • Ini adalah disiplin formal yang berbeda.
  • Refactoring: Meningkatkan desain kode yang ada oleh Martin Fowler
    • Resep refactoring yang dikodifikasikan yang memastikan perubahan kode bebas bug yang diinduksi.
    • Mulailah perpustakaan profesional dengan buku ini.
  • Selain formalitas, perkenalkan secara ad hoc melalui ulasan kode

• Tangkap lingkungan Anda

  • Konfigurasi alat dasar: kontrol versi, IDE, alat CI, OS, dll.
  • Kode sumber, dokumentasi, konfigurasi harus disinkronkan dalam kontrol versi.

Sepatah Kata Tentang Proses

Agile (dan sub-genre seperti Scrum): Lupakan. "Kamu gesit, kamu tidak gesit." Lihat ini oleh Dave Thomas, salah satu penandatangan asli Agile Manifesto .

• The Corruption of Agile - Wawancara dari Dr. Dobbs Journal
• Agile sudah mati (kelincahan hidup lama)
• Agile sudah mati - Sebuah keynote konferensi.

Karena timnya kecil dan tidak berpengalaman, perasaan pedas saya berbunyi ketika saya melihat alat integrasi tim seperti Visual Studio Team Services. Pengalaman saya terbatas di sini tapi saya merasakan pemaksaan proses yang kaku, berlebihan, dan kaku. Saya tahu banyak menggunakan hal-hal ini untuk efek yang besar tetapi berhati-hatilah berpotensi membeli solusi mencari masalah.

Sepatah Kata Tentang Alat

Hanya aku. Bukan dari "alat-alat perangkat lunak terbaik sekarang ..." pot-umpan madu pot.

Jenkins

Alat integrasi CI. Berbasis web, banyak digunakan. Pada dasarnya, melalui GUI web Anda dapat mengonfigurasi dan mengotomatiskan berbagai tugas dan urutan eksekusi seperti kompilasi, menjalankan pengujian unit, memperbarui kontrol versi. Ini sangat A-La Carte sehingga sangat cocok untuk lingkungan CI Anda yang baru lahir.

Kontrol Versi

Saya lebih suka Mercurial daripada Git. Posting blog ini adalah alasan saya memilih Mercurial: Git adalah MacGyver, Mercurial adalah James Bond

Subversi itu bagus. Mercurial & Git memiliki arsitektur berbeda yang lebih unggul dari Subversion.

Lingkungan Pengembangan Terpadu

Berikut ini adalah pertimbangan besar jika semua orang menggunakan alat pengkodean yang berbeda: Tidak Ada Hal Seperti Teks Biasa

Sepatah Kata tentang Perpustakaan Profesional

Internet luas, dangkal, dan tidak terorganisir.

• Kode Lengkap oleh Steve McConnell
  • Buat semua orang membaca sepertiga tengah.
  • Memiliki lampiran buku profesional yang disarankan.
• Refactoring: Meningkatkan desain kode yang ada
  • Resep refactoring yang dikodifikasikan yang memastikan perubahan kode bebas bug yang diinduksi.
• Kegagalan Perangkat Lunak. Tidak ada rekomendasi khusus tetapi harus berupa cerita berhadapan dengan risalah.

Saya mengusulkan untuk menggunakan metodologi lain untuk mengelola proses Anda, karena seperti yang Anda katakan itu tidak mungkin untuk menjadwalkan pertemuan (yang sangat penting untuk scrum!). Masih tidak ada yang buruk untuk membuat konsep yang baik sehingga semua orang tahu apa yang terjadi (mungkin menggunakan prototipe vert juga) dan menggunakan model air terjun. Bagaimanapun, komunikasi adalah bagian terbesar dari pekerjaan.

Saya akan mendorong Anda untuk menggunakan kontrol sumber jika Anda belum melakukannya. Ini memungkinkan Anda untuk melihat apa yang telah diperiksa oleh setiap pengembang dan memungkinkan kemunduran di mana bug diperkenalkan.

Saya akan membuat semacam test suite. Ini bisa berupa tes-driven-development di mana Anda menulis tes untuk setiap fungsi yang Anda komit, atau itu bisa menjadi cara otomatis untuk menjalankan aplikasi Anda dan meminta mereka untuk menampilkan hasilnya ke file yang dapat dibandingkan dengan yang diinginkan keluaran. Jika ini dijalankan setelah setiap komit, atau dijalankan setidaknya sekali per malam, Anda akan menemukan regresi dengan cepat.

Hal terakhir yang akan saya lakukan adalah menerapkan 2 kebijakan: 1) semua build harus memiliki peringatan yang disetel ke kesalahan dan semua kesalahan dihidupkan 2) Semua kode harus melalui penganalisa statis tanpa menghasilkan kesalahan atau peringatan sebelum dilakukan. Saya bahkan akan membuat ini tindakan pra-komitmen. 2 hal ini akan menjaga kode agar tidak bertambah mengerikan dengan berbagai cara umum. (Mereka tidak menangkap semuanya, tetapi mereka banyak menangkap.)

Ini juga akan mempersiapkan siswa Anda untuk seperti apa pekerjaan di "dunia nyata" dan menanamkan beberapa kebiasaan yang cukup baik di dalamnya.