Hai, sekarang saya akan memberi tahu Anda apa yang akan terjadi pada proyek yang menjanjikan, jika sejak awal saya beralih ke solusi siap pakai ala Wordpress, Open Cart dan CMS apa pun, berpikir bahwa ini adalah MVP. Saya akan didasarkan pada pengalaman tiga bulan bekerja di salah satu proyek di GitHub yang selama 8 bulan sebelumnya tidak menjatuhkan komitmen tunggal di cabang produksi.
Resep untuk VP / OC / CMS yang membengkak ke orbit geostasioner
1. Pilih CMS yang sudah jadi
Dalam hal apapun jangan panggil arsitek dan lupakan tentang layanan mikro dan arsitektur yang disesuaikan dengan kebutuhan Anda. Tugas kami adalah memastikan bahwa Anda dapat memutar panel admin 5 menit setelah pengembang mengaktifkan PC, dan tidak membuat pengembangan yang mudah dikelola. MVP yang benar harus seluruhnya terdiri dari solusi turnkey. Bagaimanapun, dalam proyek kami plugin tidak akan pernah konflik dan sudah dirancang untuk banyak intensitas apa pun.
2. Melarang mendokumentasikan apa pun
Tidak satu cm pun perlu didokumentasikan. Larang mendokumentasikan apa pun. Terutama modifikasi kernel. Lagi pula, setelah 3 bulan freelancer berubah menjadi penjaga pengetahuan sakral tentang cara kerja pangsit zamrud ini, dan dengan teknik magis memulai server, yang, secara alami, adalah satu, dan tidak ada yang menciptakannya kembali sejak pemasangan awal kit utilitas. Kunci untuk manajemen yang layak adalah ketergantungan pada karyawan dan, tentu saja, pada satu server yang berfungsi.
3. Panggil GURU!
Setelah perbaikan untuk konflik antara 234 dan 417 plugin mulai memakan waktu setidaknya 10 kali lebih banyak daripada pengenalan fungsi baru, cara yang tepat adalah mencari GURU, berdasarkan pengalaman, yang dengan mudah akan membuat ulang (menulis ulang) kode kecil dalam seminggu, dan 500 plugin berikutnya akan menggantikan tempatnya. Ngomong-ngomong, saya "beruntung" berada dalam peran seorang guru yang mengubah teknologi, dan karena itu ini adalah sejarah medis yang nyata.
4. Proyek Anda harus terdiri dari satu bidang tanggung jawab
Kami dengan aman dan sadar menggunakan layanan microser sejak awal, dan setelah 5 bulan, saatnya untuk menyewa seorang programmer baru. Dan biarkan dia bertanggung jawab atas tata letak. Nah, sedikit lebih untuk backend, karena kita memiliki mereka dicampur. Nah, untuk database, karena cara menjawab backend tanpa database. Baiklah, mari kita bertanggung jawab atas perbaikan. Dan lebih banyak ... dan lebih banyak ... dan lebih banyak lagi ...
5. Trello + Jira + Slack + Excel + ... + Skype
Berkat yang baik dan satu setengah ribu plug-in yang SUDAH ada, ada 5 kesalahan setiap hari, resolusi yang membutuhkan 2 hari. Kecepatan penulisan fitur berkurang secara eksponensial. Jelas, kita terlempar untuk sementara waktu dikembangkan. Dan Anda perlu memperkenalkan manajer tugas ketiga. (Ya, proyek klinis biasanya memiliki dua manajer tugas). Trello, Jira dan Excel hanyalah fondasi kontrol. Beberapa penyihir juga menggunakan manajer tugas intra-perusahaan, menyematkan pesan obrolan dan instruksi mendadak yang tidak direncanakan.
6. Transkrip konferensi suara
Pengembang mengarahkan kami, dan oleh karena itu semua konferensi suara untuk persetujuan perbaikan bug perlu diarsipkan, disimpan di cloud dan didengarkan secara teratur. Lagipula, selalu tentang pengembang ...
Kiat 1: Pengujian berhasil - segera membuang solusi yang sudah jadi dan menulis arsitektur yang sesuai.
Tip 2: Jika Anda bukan hanya startup yang termotivasi dan Anda memiliki sumber daya atau strategi keuangan, maka pastikan untuk memasukkannya dari awal dengan menulis. Pokoknya, berikan masalah ini kepada profesional atau direktur teknis. (Penting bahwa ini adalah seorang programmer, dan bukan seorang profesor dari lembaga penelitian, jika tidak Anda tidak akan mendapatkan kartu punch)
Bagaimana jika SUDAH dan Anda bertanggung jawab?- Menulis ulang.
Bagaimana jika SUDAH dan Anda tidak bertanggung jawab?- Menjelaskan esensi masalah kepada manajemen dan menulis ulang.
PS Proyek ini menggunakan Yii2, tetapi bahkan dengan itu ada masalah ini. Apa yang terjadi pada WP adalah bencana sama sekali.
PPS Alasannya, tentu saja, adalah ketidakmampuan manajemen, meskipun arsitektur monolitik juga tidak menonjol.