Apa saja hal-hal yang harus diperhatikan ketika bersiap untuk menyerahkan proyek?


10

Saya saat ini satu-satunya pengembang / arsitek aplikasi web yang cukup besar (ASP.NET MVC stack, kira-kira 150K + baris kode) dan akhir pengembangan ada di cakrawala. Karena itu, saya mulai berpikir tentang apa yang harus dilakukan untuk proyek tersebut dan saya ingin memastikan saya melakukan hal yang benar untuk siapa pun yang harus menjaga proyek di masa depan.

Apa saja hal-hal yang harus diperhatikan ketika bersiap untuk menyerahkan proyek ke pengembang lain atau tim pengembang pemeliharaan?

Jawaban:


12

IMHO, jika Anda hanya bisa melakukan satu hal sebelum menyerahkan proyek Anda (baik secara langsung maupun tidak langsung), saya akan merekomendasikan Anda untuk menggandakan dan tripple memeriksa apakah ia mengkompilasi apa adanya dari kontrol sumber.

Tidak tertawa, tetapi saya tidak bisa memberi tahu Anda berapa kali saya mendapatkan "terbaru" dari kontrol sumber dan gagal dikompilasi, hanya untuk mengetahui kemudian bahwa saya tidak "di kotak lama Fred" karena ternyata kodenya "hanya kompilasi pada kotak lama Fred ". Saya bahkan punya mantan majikan segera menghapus desktop saya dari kubus saya, dan menggantinya dengan "kotak tua Fred" sehingga saya bisa bekerja pada proyek yang saya kira.

Sebagai perpanjangan dari rekomendasi di atas, karena kadang-kadang mendapatkan yang terbaru tidak semua yang diperlukan untuk mengkompilasi aplikasi, saya sarankan Anda membuat README.txt dan meletakkannya di direktori root aplikasi Anda dan meletakkannya di kontrol sumber. Dokumen README ini harus berisi daftar dependensi eksternal yang tidak dapat diperiksa ke dalam kontrol sumber (jika ada), cara mengatur database, dan keanehan lain tentang siklus kompilasi, eksekusi atau penyebaran aplikasi.

Apa pun di atas dan di luar dua saran di atas hanya akan menjadi saus, tetapi IMHO dua di atas hampir diperlukan pada proyek yang lebih besar dari "Hello World".

EDIT:

Pada topik dokumentasi ...

Selama bertahun-tahun saya telah menulis dan membaca bagian adil dari dokumentasi perangkat lunak untuk tujuan memudahkan transisi pengembang. Saya akan mengatakan bahwa dokumen seperti itu jarang bernilai kertas yang mereka cetak. Pengembang (termasuk saya sendiri) jarang memikirkan bagian-bagian penting dari aplikasi saat menulis dokumen semacam itu, kami hanya cenderung memikirkan kebakaran terbaru yang kami hadapi. Di atas dan di luar fakta bahwa dokumen-dokumen ini cenderung tidak mencakup semua aspek penting dari perangkat lunak, mereka juga menjadi sangat SANGAT cepat. Setelah dokumen kedaluwarsa, pengembang di masa mendatang akan cenderung mengabaikannya alih-alih mengembalikannya agar sesuai dengan kenyataan (pikirkan persyaratan yang berubah).

Alih-alih dokumentasi semata, saya merekomendasikan tes unit. Saya tahu ini mungkin terdengar tua pada saat ini, tetapi biarkan kode melakukan pendokumentasian untuk Anda. Tes unit yang rusak sulit untuk diabaikan (dan lebih mudah dikenali) daripada dokumen Word. Selain itu, bahasa Inggris sangat tidak tepat untuk mengartikulasikan poin-poin penting dari desain perangkat lunak. Ada terlalu banyak cara untuk menafsirkan makna kalimat bahasa Inggris yang paling sederhana sekalipun, dan ini hanya menimbulkan kebingungan dan / atau bug.


1
+1 untuk file readme. Saya sebenarnya memiliki dua dari mereka dalam proyek pada saat ini, satu jenderal "ini adalah apa yang saya pikirkan ketika saya menulis konsep ini" dan satu lagi yang hanya daftar semua dependensi eksternal dan plug-in jQuery yang ada di tempat bersama dengan garis ke tempat saya mendapatkannya. Kompilasi jelas adalah sesuatu yang saya harus periksa lagi.
rjzii

@ Rob, VM seringkali merupakan ide yang baik ketika mencoba menentukan apakah kode Anda dapat dikompilasi di lingkungan yang bersih. Instal Windows dan Visual Studio dengan bersih, kemudian jalankan hanya dengan menginstal item yang disebutkan dalam readmefile Anda . Jika kode mengkompilasi dan menjalankan Anda sudah siap.
Jason Whitehorn

Jangan lupa dokumentasi!
Moshe

@Jason - Saya bisa melakukan itu kembali dalam keadaan yang hampir sama (dua mesin pengembangan, satu dengan Parallels Desktop) tetapi beberapa perpustakaan baru telah ditarik ke dalam proyek sejak saat itu.
rjzii

1
@ Moshe - Dokumentasi adalah bagian yang sebenarnya paling saya khawatirkan. Saya telah menulis kode seperti yang saya inginkan, tetapi saya tidak yakin dokumen tambahan apa yang harus saya tulis untuk melengkapi kode dan dokumen readme dasar.
rjzii

1

Inilah sebabnya mengapa komentar tidak berbau kode. Ini juga mengapa kita harus mendokumentasikan kode kita.

Anda harus memastikan bahwa Anda memiliki dokumentasi yang kuat. Ada beberapa program yang dapat menghasilkan dokumentasi dari komentar tergantung pada format komentar dan bahasa pemrograman.

Pertimbangkan informasi apa yang Anda inginkan tentang perpustakaan atau basis kode ketika mengambil alih. Mintalah seorang teman yang merupakan programmer untuk memberikan pandangan cepat dan melihat apakah mereka menemukan pertanyaan yang jelas.

Semoga berhasil!


1

Pastikan kode Anda dikompilasi & dikemas dalam bentuk akhir hanya dengan satu perintah / klik.

Saya tidak dapat menjawab pertanyaan itu. Apa sajakah hal yang harus diperhatikan ketika bersiap untuk menyerahkan proyek? cukup, jadi saya harus menuliskan ini lagi.

Saya sangat rewel tentang kompilasi satu-klik ini , karena saya sudah menghabiskan banyak waktu untuk mencari tahu bagaimana sebenarnya mengkompilasi atau mengemas proyek yang hanya perlu saya perbaiki satu bug kecil. Saya mulai memasukkan sedikit skrip batch / bash ke proyek saya untuk mengemas ZIP, JAR, atau EAR akhir.

Selain itu saya menambahkan README.txt ke direktori root yang menjelaskan desain keseluruhan , bagian-bagian kompleks dan lingkungan proyek (dalam hal komunikasi dengan departemen atau orang lain).

Saya mencoba untuk menjaga README.txt ini kecil , karena tidak ada yang membaca 200+ halaman dokumen spesifikasi jika yang ingin Anda lakukan hanyalah memperbaiki bug, kompilasi dan kemaslah. Detail implementasi didokumentasikan dalam unit test , jadi tidak perlu menuliskan semuanya lagi di buku ...


0

Daftar periksa handoff default saya:

  1. Lihat salinan bersih dari VCS
  2. Uji coba, uji coba penyebaran
  3. Ubah nama repo pakar menjadi repo-cadangan
  4. Tes membangun lagi
  5. Instal salinan baru server aplikasi dari zip
  6. Verifikasi server mengatur catatan
  7. Uji penyebaran lagi
  8. Pastikan tidak ada tes unit yang dinonaktifkan
  9. Pindai komentar untuk empat kata kata, hapuslah

Jika ada yang rusak, saya akan memperbaikinya sebelum diserahkan. Tidak ada yang dapat membuat seseorang memulai, kemudian memeriksa proyek, membangun, dan menjalankan hari Anda mendapatkan proyek.

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.