Tip untuk merencanakan penulisan ulang proyek PHP besar?

13

Saya telah memutuskan untuk sepenuhnya menulis ulang kerangka kerja PHP (Menggunakan MVC) yang telah saya kerjakan, hidup dan mati, selama bertahun-tahun. Masalah saya sampai sekarang adalah bahwa saya hanya akan datang dengan ide-ide, melemparkannya ke dalam Trac sebagai tiket, dan menambahkannya nanti - tanpa khawatir tentang desain kerangka itu sendiri. Seiring waktu ini telah menyebabkan beberapa masalah dan saya pikir penulisan ulang akan membantu, namun saya tidak yakin harus mulai dari mana dengan perencanaan itu - saya tahu saya tidak ingin menggunakan Trac, dan saya tahu saya membutuhkan lebih dari sekadar tiket dan tonggak - tapi apa lagi yang saya butuhkan?

Saya benar-benar ingin merencanakan penulisan ulang ini secara menyeluruh, saya ingin merinci setiap fitur yang saya inginkan, ke mana akan pergi, dan bagaimana ia akan terhubung ke setiap bagian lainnya - tetapi saya tidak memiliki pengalaman dengan tingkat perencanaan ini. Ada saran? Adakah program yang akan membantu? Saya mulai bosan dengan Trac, saya tidak pernah benar-benar menyukainya.

Saya tahu saya akan membutuhkan dokumen desain, tetapi apakah ada tata letak tertentu yang harus saya ikuti? Saya juga membutuhkan pelacakan bug, tiket, tonggak, dll., Tetapi di luar Trac saya juga tidak tahu apa yang baik untuk itu. Saya yakin masih ada lagi yang saya butuhkan tetapi saya tidak tahu apa, jadi bantuan apa pun akan dihargai.

php project-planning planning Jon
sumber
mengapa Anda ingin menulis ulang? Mengapa tidak melakukan refactor di tempat-tempat yang membutuhkan perbaikan? Ketika Anda menulis ulang sesuatu dari awal, kemungkinan Anda menghilangkan masalah lama untuk yang baru.
@ Gordon mungkin ditulis dengan sangat sangat buruk sehingga menulis ulang lebih baik daripada refactoring.
rightfold
Menulis ulang selalu lebih sulit daripada kelihatannya, dan saya telah mempelajarinya dengan cara yang sulit. Oh, well kali ini saya tahu apa yang saya lakukan, jadi itu akan memakan waktu setengah (kemudian berakhir lebih lama dari aslinya karena Anda over-engineer mencoba untuk memperbaiki atau mencegah kesalahan yang dibuat sebelumnya)
Davy8

Jawaban:

7

Lihat di bawah ini beberapa hal yang saya lakukan ketika mengembangkan proyek besar:

1 - Saya menggunakan alat perencanaan seperti OpenProj dan menambahkan semua fitur yang ingin saya sertakan sebagai tugas. Misalnya, saat ini saya sedang mengerjakan fitur untuk memungkinkan pengguna saya secara otomatis masuk setelah mereka mendaftar di situs saya. Saya punya tugas dalam rencana saya seperti "fitur-autologin".

2 - Saya adalah toko pengembang satu orang, jadi saya biasanya berpindah dari satu fitur ke fitur lainnya. Paket saya dibuat sedemikian rupa sehingga semua fitur berurutan. Saya tidak menginvestasikan terlalu banyak waktu untuk memperkirakan berapa banyak waktu yang saya perlukan untuk setiap fitur. Saya biasanya menganggap bahwa masing-masing akan membawa saya sehari untuk berkembang. Jika orang mengambil lebih, saya cukup memperbarui rencana dan semua tugas di masa depan bergerak sesuai.

3 - Saya menggunakan git secara ekstensif. Setiap fitur adalah cabang. Setelah saya menyelesaikan setiap fitur, saya menggabungkannya kembali ke cabang pengembangan dan membuat cabang baru untuk fitur berikutnya.

4 - Jika saya menemukan bug dalam perangkat lunak saya membuat cabang git kecil untuk memperbaikinya dan menggabungkannya kembali setelah teratasi. Saya memastikan saya memperbarui cabang pengembangan dan cabang fitur saya saat ini yang sedang saya kerjakan. Ngomong-ngomong bug menjadi tugas lain dalam rencana OpenProj saya. Sesuatu seperti "bug-salah-alamat". Dan ketika saya memasukkannya, semua fitur lainnya dipindahkan kembali di timeline.

5 - Ketika saya sedang mengembangkan, jika saya memikirkan fitur baru, saya cukup memasukkannya ke dalam paket yang menurut saya paling cocok dan menyesuaikan timeline lagi.

Saya harap ini membantu. Sepertinya Anda memiliki proyek menarik di depan Anda. Semoga berhasil!

jdias
sumber
10

Jika Anda akan menulis ulang lengkap, mengapa tidak mempertimbangkan juga jika Anda harus menggunakan php? Perubahan / peningkatan teknologi mungkin menjadi katalis yang Anda inginkan untuk meningkatkan desain / skalabilitas / pemeliharaan, dll ...

NWS
sumber
3
Juga, pertimbangkan kerangka kerja yang ada mungkin lebih cocok daripada menciptakan Kerangka Penggunaan Sekali Lagi.
S.Lott
1
@ S.Lott - apa yang salah dengan membuat Framework sekali pakai jika ia dirancang untuk memenuhi penggunaan tunggal itu lebih baik daripada yang lainnya?
Anonim
1
@ Chris Bridgett: Dunia mungkin tidak membutuhkan kerangka kerja yang sangat terspesialisasi. Ini bisa menjadi "gangguan yang menarik". Buang-buang waktu yang menyenangkan. Seringkali, kerangka kerja yang ada melakukan pekerjaan dengan baik. "Menjahit" dalam kerangka tujuan khusus sering kali berasal dari kegagalan untuk memahami kerangka kerja yang sudah ada dan sudah ada. Seringkali, kerangka kerja yang ada lebih aman, lebih dapat diandalkan dan lebih cepat. Seringkali, kerangka kerja yang ada sudah didebug. Seringkali, kerangka kerja yang ada lebih dipahami oleh anggota tim lainnya.
S.Lott
@ S.Lott: Saya menulis ini untuk beberapa situs yang saya miliki, dan desainnya diatur sedemikian rupa sehingga tidak ada kerangka kerja lainnya. Saya juga tidak berencana untuk merilisnya untuk sementara waktu, jika pernah. re: TheLQ: Itu adalah salah satu pemikiran pertama saya, namun tidak ada bahasa web lain yang memiliki jangkauan yang dilakukan PHP selain .NET. Python akan lebih disukai, namun pengaturannya pada server cPanel (yang sayangnya membuat banyak dunia web hosting), sangat merepotkan.
Jon
1
@ S.Lott Saya sudah membaca tentang Symfony, CakePHP dan CodeIgniter sejak posting, dan hal nomor satu yang membuat saya tidak menggunakannya - adalah bahwa semua tampaknya membabi buta menempel pada MVC, dan mengabaikan penggunaan kembali. Desain saya saat ini (Dan masa depan, jika saya menulis ulang) adalah MVC dalam satu folder (folder 'modul'), dengan tampilan di sana namun yang diinginkan pengguna (Bernama example.module.view.php), serta tema folder, di mana desainer dapat membuat tema mereka sendiri yang mengesampingkan tampilan yang ada. Ini penting bagi saya, dan tidak ada kerangka kerja utama yang melakukan hal ini tanpa banyak peretasan - yang mengganggu saya.
Jon
10

Saya akan menyarankan untuk refactor berat sebagai gantinya

Masalah yang Anda antisipasi di sini:

Saya benar-benar ingin merencanakan penulisan ulang ini secara menyeluruh, saya ingin merinci setiap fitur yang saya inginkan, ke mana akan pergi, dan bagaimana ia akan terhubung ke setiap bagian lainnya - tetapi saya tidak memiliki pengalaman dengan tingkat perencanaan ini. Ada saran? Adakah program yang akan membantu? Saya mulai bosan dengan Trac, saya tidak pernah benar-benar menyukainya.

adalah hal yang sangat sulit. Ini pada dasarnya adalah model Air Terjun dengan segala keburukannya. Berikut adalah beberapa bukti anekdot untuk masalah dengan pendekatan 'penulisan ulang hebat', yang sampai pada kesimpulan: Anda mungkin tidak akan mengantisipasi masalah dengan benar, dan berakhir dengan kekacauan lain yang ingin Anda tulis ulang dari awal. Bukan karena Anda jahat, tetapi karena tidak mungkin mendapatkan sesuatu yang besar dalam satu kesempatan.

Ketika Anda mulai refactor, Anda dapat menulis tiket individual dan Anda dapat terus menggunakan proyek ini. Kuncinya di sini adalah untuk mengidentifikasi perubahan kecil yang mengarah pada desain yang lebih baik secara keseluruhan.

Sebagai contoh: Anda menyebutkan, Anda tidak memiliki MVC, tetapi Anda mau. Sebagai langkah pertama, Anda bisa mengambil satu file PHP, dan, dengan asumsi mixup biasa, sortir, sehingga di atas Anda memiliki semua akses-db, perhitungan, dll, di bagian bawah Anda memiliki "templating" ( tiket pertama, untuk setiap file). Sebagai langkah kedua, Anda bisa merangkum semua komponen templating ini ke dalam fungsi, yang dapat melewati parameternya. (lebih banyak tiket). Selesai? Selamat, Anda menyelesaikan V di MVC.

keppla
sumber
Saya akan memperhitungkannya, terima kasih. Juga hanya untuk menjernihkan - saya menggunakan MVC sekarang.
Jon
@ Jon: Ya, juga, contoh saya diasumsikan halaman khas, tidak ada kerangka kerja. Tapi saya pikir, mutatis mutandis, jawaban saya tidak disangkal oleh itu. Satu hal yang tidak saya sebutkan: refactoring itu menyenangkan. Sangat menyenangkan melihat omong kosong total menjadi sesuatu yang indah :)
keppla
3

Pertimbangkan untuk menggunakan kerangka kerja yang ada. CakePHP, Zend Framework, CodeIgniter dan Symfony adalah yang dikenal untuk PHP. Jika mereka memenuhi kebutuhan ratusan atau ribuan pengguna, saya yakin mereka dapat memenuhi kebutuhan Anda.

Jika Anda mau belajar / menggunakan sesuatu selain PHP - Django (Python) dan Rails (Ruby) cukup banyak kerangka kerja terkemuka untuk aplikasi web konvensional.

Itu, tentu saja, kecuali jika Anda ingin pengalaman membuat kerangka kerja - yang, saya dapat tambahkan, memiliki nilai yang jauh lebih rendah di pasar (daripada mengetahui cara menggunakan kerangka kerja yang ada dan didukung dengan baik).

Yam Marcovic
sumber
1

Yang saya nikmati menggunakan Redmine sebagai pelacak jadwal. ITU menangani masing-masing item dengan sangat baik, bersama dengan menjadi jauh lebih ramah pengguna (menurut saya) daripada trac.

Mengenai penulisan ulang Anda, penting untuk terlebih dahulu memahami Anda tidak akan pernah mengantisipasi setiap fitur / ekstensi baru yang dapat muncul, jadi untuk mencoba dan menulis aplikasi Anda sefleksibel mungkin. Menggunakan banyak kerangka kerja MVC yang dimiliki PHP dapat membantu meningkatkan ini; Namun beberapa kerangka kerja ini juga memberi Anda lubang jika arsitektur DB Anda tidak fleksibel sejak awal (Cake). Saya benar-benar akan fokus untuk membuat hal-hal seabstrak yang Anda bisa, dan setiap kali Anda melihat sesuatu yang sulit dikodekan tanyakan pada diri sendiri untuk apa dan mengapa tidak bisa disimpan dalam DB.

Sungguh desain DB membantu menjawab begitu banyak pertanyaan dan masalah, dan di sinilah saya melihat pentingnya utama bagaimana aplikasi Anda berinteraksi; jadi saya akan merekomendasikan menghabiskan sebagian besar waktu menganalisis bagaimana data disimpan, dan bagaimana DB Anda terstruktur.

Petrogad
sumber
1

Sebagai perangkat lunak pelacakan masalah, JIRA memang hebat, tetapi sangat mahal. Alat bagus lain yang saya gunakan adalah Eventum. Gratis.

Tetapi bagian yang paling penting adalah memiliki ide bagus tentang apa yang Anda butuhkan. Pertama, Anda harus mengumpulkan persyaratan untuk aplikasi Anda, untuk memiliki perasaan keseluruhan tentang apa yang Anda inginkan dan selengkap mungkin.

Berdasarkan hal itu Anda akan membuat persyaratan perangkat lunak, itu adalah pendekatan yang lebih teknis di mana Anda akan menjelaskan modul-modul yang akan menjadi bagian dari aplikasi Anda, fungsi dan sub-fungsi, objek, kelas, antarmuka mereka, hampir semuanya.

Dengan mengetahui Anda akan memiliki pemahaman yang baik tentang kompleksitas aplikasi dan garis-garis kode yang dibutuhkan, sehingga Anda dapat membuat perkiraan dan membuat jadwal. Sangat penting untuk memiliki jadwal dan tenggat waktu, atau Anda mungkin berakhir tidak pernah menyelesaikannya.

Semoga ini bisa membantu


sumber
Jira sangat murah untuk kurang dari 10 pengguna. Biayanya $ 10 dan $ 10 untuk amal.
sixtyfootersdude