Bagaimana cara meningkatkan pelatihan siswa mengenai rawatan? [Tutup]


18

Maintainability adalah kepentingan utama pengembangan perangkat lunak profesional. Memang, pemeliharaan hampir selalu merupakan bagian terpanjang dari siklus hidup perangkat lunak, karena berlangsung sejak rilis proyek hingga pada dasarnya akhir zaman.

Selain itu, proyek yang sedang dalam pemeliharaan merupakan sebagian besar dari keseluruhan jumlah proyek. Menurut http://www.vlegaci.com/298/interesting-statistics-%E2%80%93-number-of-programmers-in-maintenance-vs-development/ , proporsi proyek yang sedang dalam pemeliharaan sekitar 2 / 3.

Saya baru-baru ini menemukan pertanyaan ini , di mana pria itu terlihat cukup terkejut menemukan bahwa pekerjaannya terutama tentang pemeliharaan. Saya kemudian memutuskan untuk membuka diskusi (bahasa Prancis) di situs utama komunitas profesional pengembangan perangkat lunak Perancis ( http://www.developpez.com/ ). Diskusi tersebut berjudul "Apakah siswa cukup terlatih untuk menghadapi kenyataan pengembangan perangkat lunak profesional?" dan terutama tentang rawatan . Telah ditunjukkan bahwa, setidaknya di Prancis, orang tidak cukup siap untuk menghadapi pemeliharaan dalam kedua aspek itu:

  • pertahankan kode yang ada
  • buat kode yang bisa dipelihara

Pertanyaan saya di sini menggemakan diskusi ini dan bertujuan untuk menemukan cara yang baik untuk mengajarkan pemeliharaan.

  • Bagaimana kita bisa mengajarkan pemeliharaan?
  • Latihan apa yang akan Anda sarankan?
  • Jika Anda telah terlatih dengan baik tentang pemeliharaan, jenis kursus apa yang Anda ambil?

[sunting] Setelah beberapa kesalahpahaman, saya pikir saya harus mengklarifikasi pertanyaan saya. Sebagai pemimpin proyek dan pengembang perangkat lunak, saya sering bekerja dengan peserta pelatihan atau siswa yang baru lulus. Saya pernah baru lulus sendiri. Masalahnya adalah bahwa siswa biasanya tidak terbiasa dengan prinsip-prinsip seperti PADAT yang meningkatkan pemeliharaan proyek. Kami sering berakhir dengan kesulitan penting untuk membuat proyek berkembang (rawatan rendah). Apa yang saya cari di sini adalah contoh akademis konkret dari pengajaran yang sukses tentang pentingnya pemeliharaan dan bagaimana membuat kode yang lebih baik mengenai hal ini; atau kemungkinan saran untuk meningkatkan cara siswa dilatih.



PS: Lihatlah jawaban saya di sana, Anda mungkin menganggap eksperimen spageti bermanfaat
PhD

@Nupul Karena Anda seorang guru dan terlihat terlibat dalam pengajaran pemeliharaan kode, harap buat jawaban lengkap dan beri tahu kami bagaimana Anda melanjutkan: kode spageti hanya sebagian kecil darinya
Matthias Jouan

Diposting jawaban ... harap ini menambah nilai bagi Anda :)
PhD

Desain API dan proyek rawatan dalam "Rancangan API Praktis" adalah, IMHO, sebuah proyek yang sempurna untuk mengajarkan siswa tantangan rawatan (dan kompatibilitas ke belakang).
Marco

Jawaban:


8

Bagaimana kita bisa mengajarkan pemeliharaan?

Itu masalah latihan.

Cara paling mudah untuk mempraktikkannya dalam cara yang terkendali yang dapat saya pikirkan adalah dengan mensimulasikan proyek pemeliharaan tipikal sebagai berikut.

Dapatkan beberapa proyek ( Proyek A ) yang dilakukan dengan baik dan memperkenalkan beberapa masalah di atasnya: menyuntikkan beberapa bug, kumpulan kode duplikat dan mati yang baik, letakkan beberapa fitur, tes unit, dan dokumentasi di sana-sini dll. Anda bahkan mungkin memiliki dedicated nama untuk itu, seperti Project A - versi rusak .

Buat pelacak masalah dan isi dengan permintaan yang sesuai dengan kerusakan tertentu yang Anda buat. Tetapkan aturan dan praktik dasar untuk proses pengembangan - VCS berkomitmen, ulasan kode, QA dll - pertimbangkan mengambil apa yang Anda bisa dari daftar periksa yang disediakan dalam The Joel Test .

  • kursus 1.
    Perbaiki bug, tambahkan tes unit yang hilang, dokumentasi dan fitur.
  • kursus 2.
    Refactor.
  • kursus 3.
    Pemeliharaan / peningkatan proyek asli untuk digunakan oleh siswa tahun depan
    - Proyek A versi 2.0 dan Proyek A - versi 2.0 rusak , masing-masing.
    Dengan meningkatkan versi yang rusak maksud saya membuat kerusakan edukatif yang lebih baik untuk itu. :)

Dari praktik-praktik yang disebutkan di atas, berikan perhatian khusus pada ulasan kode . Ini mungkin cara yang paling efektif untuk memastikan bahwa kode mudah dipelihara, seperti yang ditunjukkan misalnya dengan jawaban teratas dalam pertanyaan terkait .

WTF per menit


11

Penafian: Saya baru saja mendapat gelar CS. Saya bukan guru.

Ini mungkin terdengar jelas, tetapi saya pikir cara terbaik untuk mengajarkan pemeliharaan kode adalah dengan meminta siswa melakukan pemeliharaan kode. Inilah yang akan saya lakukan:

  1. Ambil masalah yang cukup kompleks, dan dua implementasi yang secara semantik identik, tetapi yang satu lebih bisa dipelihara daripada yang lain.
  2. Minta sejumlah perubahan / penambahan fitur yang jauh lebih mudah diterapkan pada basis kode yang lebih baik. Setengah dari siswa harus menerapkan ini pada basis kode yang lebih dapat dipelihara, setengah lainnya pada yang kurang dapat dipelihara.
  3. Demi keadilan, Anda mungkin ingin mengulang latihan ini dengan peran terbalik.
  4. Bandingkan jumlah rata-rata perubahan yang berhasil dilaksanakan antara basis kode yang baik dan buruk, dan waktu yang dihabiskan untuk mengimplementasikannya. Mintalah siswa membagikan pengalaman mereka, mengutarakan keluhan mereka, dan secara umum berbicara tentang pekerjaan yang telah mereka lakukan.

Idenya adalah agar siswa tidak hanya bekerja dengan kode orang lain, tetapi juga membuat mereka mengembangkan apresiasi terhadap kode yang dapat dipelihara yang diharapkan akan meningkatkan keterampilan desain mereka.


+1 untuk latihan. Itu sangat mirip dengan sesuatu yang ingin saya jalankan untuk waktu yang lama; meskipun dalam versi saya, siswa akan menulis sesuatu ke spec, kemudian akan diberikan kepada orang lain (dipilih oleh saya) untuk dimodifikasi. Anda dapat mengulangi kegiatan setelah mengajar tentang pemeliharaan dan praktik yang baik, untuk menegaskan maksud Anda.
Andy Hunt

1
Anda bisa menyusun kursus mini yang sangat baik tentang perawatan berdasarkan bab "kode bau" dari Fowler's Refactoring.
mjfgates

2

Kemampu-rawatan adalah kebajikan, bukan keterampilan. Ada banyak jalan untuk membuat proyek yang dapat dipelihara, tetapi tidak ada formula yang dijamin untuk menghasilkannya.

Jika Anda menghargai kebajikan seperti kebaikan dan kemurahan hati, Anda mencari cara untuk mempraktikkan hal yang sama dalam kehidupan sehari-hari Anda. Ini sama dengan rawatan: jika Anda dan organisasi Anda menghargai rawatan, Anda akan menyimpannya di belakang pikiran Anda saat merancang dan mengimplementasikan proyek Anda. Ini akan menjadi alasan yang sah untuk menghabiskan sedikit waktu membangun sesuatu karena Anda tahu bahwa pemeliharaan dihargai. Sebaliknya, menghabiskan waktu ekstra demi keberlanjutan dalam suatu organisasi yang tidak menghargai itu tidak dianjurkan.

Jika Anda ingin mengajar orang untuk membuat hal-hal dapat dipertahankan, Anda harus mulai dengan menjelaskan bahwa organisasi Anda menghargai pemeliharaan. Tentukan dalam persyaratan untuk proyek Anda. Jadikan salah satu kriteria untuk ulasan kode yang berhasil. Singkatnya, jadikan pemeliharaan sebagai bagian dari budaya Anda .

Selanjutnya, berkeinginan untuk mencurahkan beberapa sumber daya untuk meningkatkan pemeliharaan dalam proyek Anda yang ada. Identifikasi bagian-bagian dari proyek di mana bug terus muncul, atau di mana memperbaiki bug atau membuat perubahan sangat sulit dan membutuhkan waktu lama, dan mendesain ulang atau refactor untuk memfasilitasi pemeliharaan.

Akhirnya, indoktrinasi pengembang baru ke dalam budaya pemeliharaan Anda dengan menugaskan mereka ke tim yang sudah mempraktikkannya setiap hari. Tidak ada cara yang lebih baik untuk membantu seseorang mengadopsi nilai selain memberi mereka banyak contoh dan panduan yang baik.


1
Saya mengalami kesulitan memahami downvote di sini. Anda dapat melafalkan desain perangkat lunak dari Alkitab pilihan Anda sebanyak yang Anda inginkan, tetapi masalah utama adalah bahwa pengembang sering mendapat kesan bahwa itu tidak masalah karena tidak ada yang peduli untuk memberi mereka alternatif yang lebih baik dari apa yang telah mereka lakukan. . Jika Anda tidak menanamkan siswa dengan rasa penting untuk terus-menerus meragukan kualitas pekerjaan yang mereka hasilkan dan mempertanyakan keputusan yang mereka buat, maka saya benar-benar meragukan seberapa banyak kursus tentang pemeliharaan yang terbukti bermanfaat bagi mereka.
Filip Dupanović

@ FilipDupanović Setuju. Melangkah lebih jauh, meskipun orang mengeluhkan kurangnya kesiapan lulusan baru dengan gelar CS, saya tidak berpikir masalah ini mengejutkan atau unik untuk pemrograman. Tentu saja ada perbedaan antara lulusan baru dan pekerja berpengalaman: seseorang memiliki pengalaman! Program gelar yang bagus dalam bidang apa pun adalah konseptual, bukan kejuruan. Hanya pengalaman yang akan mengajarkan lulusan baru untuk menerapkan konsep yang telah mereka pelajari dan bekerja secara efektif di pekerjaan apa pun yang mereka jalani.
Caleb

1

Saya tidak suka istilah Maintainable dalam kaitannya dengan pengembangan perangkat lunak. Kenyataannya adalah bahwa semua perangkat lunak dapat dipelihara karena dapat dikenakan pekerjaan pemeliharaan, sehingga masalah sebenarnya adalah apakah perangkat lunak itu mahal atau tidak mahal untuk dipelihara, secara relatif. Saya tahu ini kedengarannya seperti pernyataan yang sangat menyolok di awal jawaban, namun poin saya akan menjadi lebih jelas dalam sekejap.

Masalah dengan gelar IT yang utama dalam pengembangan perangkat lunak adalah bahwa mereka benar-benar hanya mengajarkan siswa minimum yang paling tidak perlu diketahui siswa tentang menulis perangkat lunak. Keterampilan dan pengetahuan profesional diperoleh melalui pembelajaran yang dilakukan dalam beberapa tahun pertama setelahnyamemenuhi syarat untuk gelar. Ini adalah ketika seorang lulusan mulai bekerja pada proyek-proyek yang benar-benar penting bagi pelanggan, dalam lingkungan di mana ada tekanan besar untuk melakukan, dan harapannya adalah untuk menciptakan produk dengan standar profesional. Sayangnya, banyak perusahaan tidak mendorong budaya di mana standar profesional dalam perangkat lunak dipertahankan, dan mereka berakhir dengan proyek-proyek yang ternyata mahal untuk dikembangkan dan dipelihara sebagai hasilnya. Sayangnya untuk lulusan kami, mereka belajar banyak kebiasaan buruk di lingkungan seperti itu di tahun-tahun awal karir mereka, dan itu bisa lama sebelum mereka belajar bagaimana mengatasi kebiasaan-kebiasaan ini ... jika memang ada.

Anda akan lebih baik mengajar siswa cara menulis kode yang bersih, dan bagaimana mengidentifikasi masalah dalam perangkat lunak yang biasanya berakhir dengan hutang teknis . Lihatlah ke buku-buku tentang Clean Code , Refactoring , dan Pengembangan Perangkat Lunak Bersandar sebagai titik awal sebagai tempat untuk memulai, dan ajarkan siswa untuk menulis tes unit sebelum kode implementasi untuk memastikan ada cakupan tes yang tinggi. Ajari siswa untuk mengenali pola yang digandakan dan berulang dalam kode mereka, dan bagaimana cara memperbaiki kode untuk menghapus duplikasi tersebut. Bantu siswa untuk memahami dan menerapkan prinsip-prinsip seperti SOLID dan KERING. Yang paling penting, singkirkan ide ini bahwa kemampuan untuk mempertahankan kode adalah sesuatu yang dilakukan hanya berdasarkan pada desain dan implementasi kode, dan sebagai gantinya menanamkan rasa keahlian dan kualitas dalam produksi perangkat lunak sejak awal, berusaha untuk perbaiki kode yang diterapkan untuk meminimalkan dampak utang teknis dan dengan demikian menjaga biaya pemeliharaan perangkat lunak seminimal mungkin.


Saya sudah membaca jawaban Anda dengan perhatian, dan juga artikel Anda tentang "dipertahankan", dan saya harus mengatakan bahwa saya hampir sepenuhnya setuju dengan Anda. Saya telah membaca beberapa buku yang Anda sebutkan, dan menggunakan - atau membuat orang menggunakan - prinsip-prinsip seperti SOLID setiap hari di tempat kerja (saya bukan seorang guru btw). Tapi saya pikir jawaban Anda sedikit di luar topik. Saya akan mengedit pertanyaan saya untuk mencoba menjelaskan apa yang saya cari.
Matthias Jouan

1
Anda membuat poin yang baik, tetapi juga adil untuk mengatakan bahwa satu proyek lebih atau kurang dapat dipertahankan daripada yang lain. Kata-kata yang diakhiri dengan -able atau -ible bisa absolut atau relatif, dan tampaknya cukup jelas bahwa OP menggunakannya dalam arti relatif.
Caleb

0

Saya pikir cara terbaik untuk mempelajari keterampilan semacam ini adalah dengan melakukan tinjauan kode dan memasangkan program. Selama ulasan kode, staf yang berpengalaman dapat menunjukkan bagaimana membuat kode lebih dapat dikelola (biasanya dengan membuatnya lebih mudah dibaca) dan membenarkan mengapa pilihan tertentu dapat membuat kode lebih dapat dikelola.

Pemrograman pasangan adalah cara yang lebih baik untuk mengajarkan hal semacam ini, karena memberikan pengalaman langsung kepada staf yang kurang berpengalaman dalam memelihara kode dengan seseorang yang sudah tahu bagaimana melakukannya dengan baik.

Ada juga beberapa buku hebat yang bisa Anda baca tentang menulis kode yang bersih dan dapat dikelola. Kode Bersih muncul di pikiran.

Sulit untuk mendapatkan pengalaman ini melalui akademisi karena siswa jarang memodifikasi basis kode besar. Sebagian besar keterampilan ini akan berasal dari pembelajaran di tempat kerja, dan ulasan kode dan pemrograman pasangan benar-benar dapat memfasilitasi pembelajaran ini.


1
Meskipun pemrograman berpasangan merupakan cara belajar yang sangat baik dari pengembang yang lebih terampil, dan membaca buku-buku Robert C. Martin jelas mengubah hidup saya, pertanyaannya lebih pada cara belajar akademis murni: bagaimana siswa dapat lebih siap sebelum mereka sampai ke dunia profesional pengembangan perangkat lunak.
Matthias Jouan

1
-1: @ saran suszterpatt terdengar jauh lebih baik.
Jim G.

0

Kode yang baik = Kurang pemeliharaan dan Mudah untuk meningkatkan / menambah fitur.

Kode buruk = mimpi buruk pemeliharaan

Pada dasarnya kita harus menyampaikan poin kepada siswa bahwa "setiap kali ada kode jelek dalam suatu proyek, pengembang baru yang akan bergabung dengan perusahaan karena penulis asli kode akan menderita dan bagaimana perangkat lunak terpengaruh . "

Jadi salah satu cara terbaik untuk mengajarkan siswa tentang pemeliharaan perangkat lunak adalah dengan menunjukkan contoh kode baik dan buruk dan meminta mereka untuk menambahkan fitur dan kemudian mengajar mereka bahwa menulis kode yang baik tidak hanya untuk kepuasan diri tetapi untuk membuat mudah bagi orang-orang yang akan mempertahankan kode.

Olahraga:

1) Memiliki kode buruk pra-tertulis (misalnya) kode duplikat, metode mengatakan "untuk menghitung pembayaran hipotek" ditulis di 9 tempat dalam suatu proyek.

Mintalah siswa untuk meningkatkan fitur untuk "menambahkan biaya tambahan 1,2% ke semua pembayaran hipotek".

Sekarang siswa akan melihat rasa sakit menemukan dan memperbaiki kode di semua 9 tempat. Ada banyak kemungkinan ia tidak dapat menemukan semua 9 tempat "pembayaran hipotek" dihitung.

2) Sekarang tunjukkan kode Baik yang memiliki metode ini yang menghitung pembayaran hipotek di satu-satunya tempat . tunjukkan kepada siswa bahwa betapa mudahnya meningkatkan kode yang ditulis dengan baik dan jelaskan kepadanya bagaimana hal itu meningkatkan pemeliharaan kode / proyek.

BTW, saya menyukai pendekatan Anda untuk mengekspos para siswa pada pemeliharaan perangkat lunak.


-1

@mattmattj: Karena ada BANYAK jawaban dan tautan yang saya poskan memiliki beberapa petunjuk yang baik, saya akan menambahkan sesuatu yang mudah-mudahan bukan pengulangan dari jawaban yang sudah diposting.

Pertama, seseorang HARUS mendefinisikan "pemeliharaan" - tidak ada definisi tunggal yang diterima oleh semua - mirip dengan arsitektur perangkat lunak. Jadi pilih salah satu yang Anda rasa paling penting, semuanya mencakup dan nyatakan dalam 3-4 baris maksimal. Kemudian Anda dapat berbicara tentang beberapa metrik seperti - waktu untuk mengingat kembali / memahami kode Anda sendiri (atau orang lain), jumlah WTFs per menit / jam dll. Biarkan itu tetap ringan (lucu) - yang akan membuat mereka lebih mudah menerima apa yang Anda miliki untuk mengatakan setelah itu.

Beberapa latihan (mungkin terdengar sedikit tumpang tindih dengan beberapa respons, maafkan itu)

Bagilah kelas menjadi dua - berikan satu bagian tugas pengkodean sederhana yang perlu dilakukan dalam 1-2 hari. Maks. Batas waktu yang sulit. Mereka harus menyelesaikan pekerjaan dalam segala keadaan - pedoman - "kode kerja" yang mereka anggap cocok. Untuk kelompok siswa lainnya tugas yang sama tetapi dengan daftar konvensi (penamaan) dan beberapa pedoman tentang desain dan bagaimana poin akan dikurangi jika tidak diikuti. Ini BUKAN curang, walaupun terdengar seperti itu;) Sekarang minta mereka bertukar kode yaitu grup 1 sekarang bekerja pada apa yang grup 2 lakukan dan sebaliknya. Sekarang sarankan modifikasi untuk tugas pengkodean asli dan minta mereka melakukannya dalam jangka waktu yang sama. Kumpulkan kembali dan tanyakan kepada mereka seberapa mudah / sulitnya dan buka lantai untuk diskusi / pendapat. Intinya pasti akan mencapai rumah - peluang tinggi 50% dari kelas akan senang dan merasa mudah dan 50% merasa sulit. Anda juga dapat meminta mereka untuk mengerjakan hal mereka sendiri setelah 3 minggu dan melihat apakah mereka dapat melakukannya dalam 1 hari;)

(Pelintiran yang baik adalah Anda menulis potongan kode yang sama dengan cara yang berbelit-belit dan memberikannya kepada kelas untuk modifikasi bersama dengan mereka sendiri)

Di sinilah Anda meletakkan fondasi kemampuan pemeliharaan - setiap baris kode yang dimodifikasi / diperbarui akan menghabiskan uang perusahaan. Semakin mudah membaca dan mengingat kode semakin baik / cepat modifikasi yang akan membantu mengurangi waktu ke pasar. Sangat penting dalam ruang teknologi serba cepat saat ini. Pemeliharaan adalah kunci untuk evolusi sistem yang efisien.

Penting untuk memahami perbedaan antara pengembangan greenfield dan brownfield - tidak setiap proyek atau sistem akan dibuat dari awal (agak sulit untuk menemukan atau menjadi bagian dari proyek "dari awal"). Menjelaskan bahwa bidang itu "secara inheren" berwarna coklat dan Anda harus menghabiskan waktu membentuknya saat Anda pergi bersama dengan fase akhirnya ketika itu tumbuh "di luar kendali" (hanya mungkin bila arus terlalu banyak dan 'tidak dapat dipelihara'). Semakin cepat mereka menerima itu semakin baik. Ini sulit karena pemrograman secara inheren kreatif tetapi meningkatkan kode orang lain tidak dianggap seperti itu - putar sekitar. Kreativitas ada kemampuan untuk memahami kode dan kemudian menerapkan kreativitas "Anda" untuk meningkatkannya - jika dipelihara dengan lebih baik, Anda akan dapat lebih meningkatkannya secara kreatif di masa mendatang.

Jangan ragu untuk merujuk pada analogi spageti di tautan di atas ... semoga ini membantu memukul beberapa poin. Jawaban lain membantu mengisi kekosongan dan harus membantu Anda dengan pengajaran! Semoga berhasil!


@Downvoter - silakan tinggalkan komentar untuk meningkatkan peluang memperbaiki pos :)
PhD
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.