Proses Pengembangan Ruby on Rails


8

Kami adalah tim kecil yang akan mulai mengembangkan versi lokal aplikasi web AS yang sukses di Korea, menggunakan RoR.

Pertanyaan kami adalah: Proses apa yang akan Anda rekomendasikan untuk kami gunakan dalam mengembangkan aplikasi?

Haruskah kita mulai dengan model data? Tampilan dalam HTML lalu mengkodekannya? Ambil satu fitur, kembangkan, lalu tambahkan fitur tambahan seperlunya?

Beberapa detail tentang proyek ini:

  1. itu adalah aplikasi web untuk pemilik usaha kecil
  2. ini mencakup fitur admin-dokumen admin-dokumen-pelaporan-dasbor-pengguna-crm yang biasanya dimiliki oleh sebagian besar aplikasi biz kecil
  3. ukuran tim awalnya 2 orang: seorang programmer dan seorang desainer / guru CSS (hanya satu coder)
  4. tingkat pengalaman adalah sedang. pengetahuan yang baik tentang Git, Ruby, Rails dan XHTML / CSS, kurang berpengalaman dengan masalah penyebaran. ini adalah proyek pertama dari jenisnya yang kami lakukan bersama sebagai sebuah tim

Jawaban:


2

Saya akan merekomendasikan pola pengembangan yang didorong oleh perilaku,

Jika Anda tidak terbiasa, izinkan saya memberi Anda ikhtisar:

Mulai dari mur dan baut "elevator pitch" aplikasi ..

"Apa yang kita bangun ini? Nilai apa yang dibawanya?"

Dan kemudian pilih persyaratan minimum absolut "fitur" dan mulai "menentukan" itu .. id 'merekomendasikan menggunakan Mentimun: http://cukes.info/ dan Rspec: http://rspec.info/ untuk menggambarkan fitur bagaimana harus berperilaku .. menjalankan tes / spesifikasi dan melihatnya gagal ..

Kemudian selami dan mulai mengimplementasikan fitur dan saksikan tes lulus 1 oleh 1 ..

Ketika fitur ini selesai (semua tes lulus) ulangi proses .. pindah ke "fitur" persyaratan minumum berikutnya dan seterusnya ..

Adapun fokus beban kerja pada fitur gedung Anda bersama, programmer bekerja pada perilaku dan desainer bekerja pada tampilan dan nuansa sampai keduanya bekerja dengan sempurna bersama-sama ..


Terima kasih! ada rekomendasi tentang tutorial / buku bagus tentang rspec / mentimun yang tidak akan membuat kita macet dengan detailnya?
Kai EV

Saya sedang mencari hal yang sama belum lama ini .. Jangan salah dengan "the rspec book": pragprog.com/titles/achbd/the-rspec-book Saya pikir hal penting tentang BDD adalah membuatnya bekerja untuk Anda .. Ketika saya mulai, saya menghabiskan begitu banyak waktu untuk mengkhawatirkan betapa cantiknya test suite itu sehingga saya tidak pernah menyelesaikan pekerjaan. Juga screencast hebat dari ryan bates ini sangat membantu: railscasts.com/episodes/155-beginning-with- mentimun
Daniel Upton

0

Masalah terbesar yang Anda miliki adalah mengelola pembaruan dari produk utama - Anda harus menggabungkan perubahan Anda ke dalamnya jika Anda ingin mengikuti rilis mereka. Semua faktor lain adalah IMHO tidak relevan.

Jadi, pastikan Anda mengambil produk utama, lalu buat salinannya untuk dikerjakan. Saat mereka merilis versi baru, perbarui sumber asli Anda dengan versi mereka dan kemudian Anda dapat melihat perubahan yang telah mereka buat dan menggabungkannya ke versi Anda. Refactoring produk adalah masalah yang sangat besar - jangan lakukan itu, karena setiap file baru membuat hal-hal sulit untuk melihat di mana perubahan dari yang asli terjadi. Ini juga lebih mudah jika Anda dapat menyimpan perubahan di file terpisah.

Kalau tidak, untuk mengembangkan saya akan melakukan fitur demi fitur, Anda kemudian memiliki cara yang baik untuk mengujinya berfungsi sebelum pindah ke fitur berikutnya. Mencoba melakukan semuanya secara bersamaan jauh lebih sulit. Pertahankan sistem pengujian agar Anda dapat melepaskan setiap fitur ke dalamnya dan memastikannya berfungsi (mis. Pada kotak yang bukan milik pengembang)


ulang proses dev - kami mendengar Anda! tampaknya setuju dengan nas merekomendasikan Daniel sehingga kami akan melakukannya saat Anda melamar. namun tidak yakin kami sepenuhnya memahami paragraf manajemen pembaruan ... apakah Anda merujuk pada tantangan pasca pemasangan untuk menambah / mengubah fitur? mengapa sistem kontrol sumber yang sederhana tidak menangani perubahan ini?
Kai EV
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.