Permasalahan yang muncul dalam proses produksi lambat laun mendapat perhatian dari manajemen menengah dan atas. Baik Anda seorang pengembang atau arsitek, Anda harus cukup memperhatikan hal-hal berikut untuk menghindari situasi yang memalukan di masa mendatang. Anda juga dapat menggunakannya sebagai catatan pemecahan masalah.
#1. Jangan mengeksternalisasi properti konfigurasi di file properti atau file XML. Misalnya, jumlah thread yang digunakan oleh pemrosesan batch tidak diatur agar dapat dikonfigurasi di file properti. Program batch Anda dapat berjalan dengan lancar baik di lingkungan DEV atau lingkungan UAT (User Acceptance Test), tetapi setelah diterapkan pada PROD, ketika digunakan sebagai program multi-thread untuk memproses kumpulan data yang lebih besar, IOException akan dilemparkan. , baik karena versi driver JDBC yang berbeda atau karena masalah yang dibahas di #2. Jika jumlah thread dapat dikonfigurasi dalam file properti, maka akan sangat mudah untuk menjadikannya aplikasi single-thread. Kita tidak perlu lagi berulang kali menerapkan dan menguji aplikasi untuk memecahkan masalah. Metode ini juga cocok untuk mengonfigurasi URL, nomor server dan port, dll.
#2. Ukuran kumpulan data yang digunakan dalam pengujian tidak tepat. Misalnya, skenario umum selama produksi adalah hanya menggunakan 1 hingga 3 akun untuk pengujian, padahal jumlahnya harus 1.000 hingga 2.000. Saat melakukan pengujian kinerja, data yang digunakan harus nyata dan tidak dipotong. Pengujian kinerja yang tidak mendekati keadaan sebenarnya dapat menimbulkan masalah kinerja, perluasan, dan multi-threading yang tidak dapat diprediksi. Hanya dengan menguji aplikasi dengan kumpulan data yang lebih besar, Anda dapat memastikan bahwa aplikasi berfungsi dengan baik dan memenuhi SLA (standar tingkat layanan) untuk atribut non-fungsional.
#3. Secara naif percaya bahwa layanan eksternal dan internal yang dipanggil dalam aplikasi dapat diandalkan dan selalu tersedia. Tidak mengizinkan batas waktu panggilan layanan dan percobaan ulang akan berdampak buruk pada stabilitas dan kinerja aplikasi. Diperlukan pengujian pemadaman layanan yang tepat. Hal ini penting karena aplikasi saat ini sebagian besar terdistribusi dan berorientasi layanan, sehingga memerlukan layanan jaringan dalam jumlah besar. Meminta layanan yang tidak tersedia tanpa henti dapat membahayakan aplikasi Anda. Penyeimbang beban juga perlu diuji untuk memastikannya berfungsi dengan baik untuk menjaga keseimbangan setiap node.
#4. Persyaratan keamanan minimum tidak diikuti. Seperti disebutkan di atas, layanan jaringan ada di mana-mana, sehingga memudahkan peretas untuk mengeksploitasinya untuk serangan penolakan layanan. Oleh karena itu, saat menggunakan Secure Sockets Layer, Anda harus menyelesaikan verifikasi dasar dan melakukan pengujian penetrasi menggunakan alat seperti Google skipfish. Aplikasi yang tidak aman tidak hanya mengancam stabilitasnya sendiri, tetapi juga dapat berdampak negatif terhadap reputasi perusahaan karena masalah integritas data, seperti situasi di mana pelanggan "A" dapat melihat data pelanggan "B".
#5. Tidak ada pengujian kompatibilitas lintas browser. Aplikasi web saat ini sebagian besar merupakan aplikasi satu halaman kaya yang menggunakan bahasa pemrograman JavaScript dan kerangka kerja seperti Angular js. Agar situs web yang Anda bangun dapat berjalan dengan lancar di berbagai perangkat dan browser, Anda harus menerapkan desain yang sesuai. Jadi untuk memastikan aplikasi Anda berfungsi di semua perangkat dan browser, kompatibilitasnya harus diuji.
#6. Tidak mengeksternalisasikan aturan bisnis yang mungkin sering berubah. Misalnya, undang-undang perpajakan, persyaratan terkait pemerintah atau industri, taksonomi, dll. Anda dapat menggunakan mesin seperti Drools untuk memproses aturan bisnis, yang membantu Anda mengeksternalisasikan aturan bisnis ini dengan menyimpannya dalam database atau excel. Setelah perusahaan menguasai aturan-aturan bisnis ini, mereka dapat merespons dengan cepat undang-undang perpajakan atau persyaratan terkait dengan sedikit perubahan dan pengujian.
#7. Dokumen-dokumen berikut tidak disediakan
Selain COS (Conditions of Satisfaction), formulir yang dibuat oleh MindMap, ada dua formulir dokumen utama dalam pengembangan agile , 1 dan 2.
#8. Tidak memiliki rencana pemulihan bencana dan sistem pemantauan serta strategi pengarsipan yang tepat. Ketika tenggat waktu proyek semakin dekat, hal-hal ini sering kali terlewatkan karena terburu-buru dalam melaksanakan proyek. Tidak memiliki pemantauan sistem yang tepat dengan Nagios dan Splunk tidak hanya mengancam stabilitas aplikasi Anda, tetapi juga menghambat diagnostik saat ini dan upaya perbaikan di masa depan.
#9. Tidak ada desain kolom yang nyaman untuk tabel database , seperti tanggal_dibuat, tanggal_dibuat, tanggal_dibuat, tanggal_diperbarui, dan stempel waktu. Ini juga tidak menyediakan kolom catatan penghapusan yang teratur, seperti kolom 'dihapus' yang dapat mengambil 'Y' atau 'N'. Atau Anda dapat mengambil kolom 'record_status' 'Aktif' atau 'Tidak Aktif'.
#10. Kegagalan mengembangkan rencana retracement yang tepat. Akibatnya, ketika sistem gagal, tidak ada cara untuk memulihkan sistem ke kondisi stabil sebelum penerapan. Rencana ini perlu dipertimbangkan secara matang dan ditandatangani oleh tim terkait. Rencananya termasuk mengembalikan ke versi perangkat lunak sebelumnya, menghapus semua data yang dimasukkan ke dalam database dan semua entri di file properti.
#11. Kegagalan mengembangkan rencana kapasitas sebelum proyek dimulai. Saat ini, ketika menjelaskan persyaratan platform, tidak cukup hanya mengatakan "membutuhkan komputer Unix, server database Oracle, dan server aplikasi JBoss". Permintaan Anda harus tepat
#12 di bawah ini berasal dari komentar "David DeCesare" dari "java.dzone",
#12 “Jangan gunakan alat terbaik untuk pekerjaan itu.” Dalam banyak kasus, pengembang akan menggunakan bahasa atau alat yang ingin mereka pelajari dalam sistem produksi. Biasanya ini bukan pilihan terbaik. Misalnya saja menggunakan database NoSQL untuk data yang sebenarnya sudah bersifat relasional. Ingat, apa pun alat yang Anda gunakan, Anda harus mempertahankan produk Anda selama 3 hingga 5 tahun ke depan (atau bahkan lebih lama).
#13. Kurangnya cadangan pengetahuan yang memadai di 16 bidang teknis utama. Area ini mencakup mengidentifikasi dan memperbaiki 1) "masalah konkurensi", 2) masalah transaksi, dan 3) masalah kinerja. Dalam banyak wawancara, saya mengandalkan tiga aspek pengetahuan ini untuk mendapatkan kontrak baru.