Bahaya proyek J2EE!

Dalam berbagai masa jabatan saya sebagai pengembang, pengembang senior, dan arsitek, saya telah melihat yang baik, yang buruk, dan yang buruk dalam hal proyek Java enterprise! Ketika saya bertanya pada diri sendiri apa yang membuat satu proyek berhasil dan yang lainnya gagal, sulit untuk mendapatkan jawaban yang sempurna, karena kesuksesan terbukti sulit untuk didefinisikan untuk semua proyek perangkat lunak. Proyek J2EE tidak terkecuali. Sebaliknya, proyek berhasil atau gagal dengan tingkat yang berbeda-beda. Pada artikel ini saya bertujuan untuk mengambil 10 bahaya teratas yang mempengaruhi keberhasilan proyek Java enterprise dan menampilkannya untuk Anda, pembaca.

Beberapa dari bahaya ini hanya memperlambat proyek, beberapa adalah jalan yang salah, dan yang lainnya dapat langsung merusak kesempatan untuk sukses. Namun, semua bisa dihindari dengan persiapan yang baik, pengetahuan tentang perjalanan ke depan, dan pemandu lokal yang mengetahui medan.

Artikel ini sederhana dalam struktur; Saya akan membahas setiap bahaya sebagai berikut:

  • Nama bahaya: Garis satu baris yang menguraikan bahaya
  • Fase proyek: Fase proyek di mana bahaya terjadi
  • Fase proyek yang terpengaruh: Dalam banyak kasus, bahaya dapat berdampak langsung pada fase proyek selanjutnya
  • Gejala: Gejala yang berhubungan dengan bahaya ini
  • Solusi: Cara untuk menghindari bahaya sama sekali dan cara meminimalkan pengaruhnya terhadap proyek Anda
  • Catatan: Poin yang ingin saya sampaikan yang berhubungan dengan bahaya, tetapi tidak cocok dengan kategori sebelumnya

Seperti disebutkan di atas, kami akan memeriksa setiap bahaya dalam konteks proyek Java perusahaan, bersama dengan fase pentingnya. Fase proyek meliputi:

  • Pemilihan Vendor: Proses memilih alat campuran terbaik sebelum Anda memulai proyek J2EE Anda - dari server aplikasi hingga merek kopi Anda.
  • Desain: Di antara metodologi waterfall yang ketat dan pendekatan "kode dan lihat," terletak pada desain saya: Saya melakukan desain yang cukup sehingga saya dapat bergerak dengan nyaman ke dalam pengembangan. Saya menganggap fase desain saya selesai ketika saya tahu persis apa yang saya bangun dan bagaimana saya akan membangunnya. Selain itu, saya menggunakan templat desain untuk memastikan bahwa saya telah menanyakan semua pertanyaan yang benar tentang diri saya dan solusi yang saya usulkan sebelum beralih ke pengembangan. Namun, saya tidak takut membuat kode dalam fase ini; terkadang itu satu-satunya cara untuk menjawab pertanyaan tentang kinerja atau modularitas.
  • Pengembangan: Fase proyek di mana jumlah pekerjaan yang dilakukan pada fase sebelumnya akan ditampilkan. Pilihan alat yang bagus ditambah dengan desain yang bagus tidak selalu berarti pengembangan yang sangat mulus, tetapi itu pasti membantu!
  • Stabilisasi / Pengujian Beban: Dalam fase ini, arsitek sistem dan manajer proyek akan memberlakukan pembekuan fitur dan fokus pada kualitas pembuatan, serta memastikan bahwa statistik vital sistem - jumlah pengguna bersamaan, skenario kegagalan, dan sebagainya - bisa bertemu. Namun, kualitas dan kinerja tidak boleh diabaikan hingga tahap ini. Memang, Anda tidak dapat menulis kode berkualitas buruk atau lambat dan membiarkannya sampai stabilisasi diperbaiki.
  • Live: Ini sebenarnya bukan fase proyek, ini adalah tanggal yang ditetapkan di atas batu. Fase ini adalah tentang persiapan. Di sinilah hantu kesalahan masa lalu akan kembali menghantui proyek Anda, dari desain dan pengembangan yang buruk hingga pilihan vendor yang buruk.

Gambar 1 mengilustrasikan fase proyek yang paling dipengaruhi oleh berbagai penyebab (dan khususnya efek sampingan).

Baiklah, tanpa basa-basi lagi, mari selami 10 besar!

Bahaya 1: Tidak memahami Java, tidak memahami EJB, tidak memahami J2EE

Benar, saya akan memecah yang ini menjadi tiga subelemen untuk analisis yang lebih mudah.

Deskripsi: Tidak memahami Java

Fase proyek:

Pengembangan

Fase proyek yang terpengaruh:

Desain, Stabilisasi, Langsung

Karakteristik sistem yang terpengaruh:

Pemeliharaan, skalabilitas, kinerja

Gejala:

  • Mengimplementasikan kembali fungsionalitas dan kelas yang sudah ada dalam API inti JDK
  • Tidak mengetahui apa saja atau semua hal berikut ini dan apa fungsinya (daftar ini hanya mewakili contoh topik):
    • Pengumpul sampah (kereta api, generasi, inkremental, sinkron, asinkron)
    • Kapan objek bisa dikumpulkan sampah - referensi yang menjuntai
    • Mekanisme pewarisan digunakan (dan pengorbanannya) di Jawa
    • Metode over-riding dan over-loading
    • Mengapa java.lang.String(gantikan kelas favorit Anda di sini!) Terbukti buruk untuk performa
    • Semantik referensi pass-by dari Java (versus semantik nilai pass-by di EJB)
    • Menggunakan ==versus menerapkan equals()metode untuk nonprimitif
    • Bagaimana Java menjadwalkan utas pada platform yang berbeda (misalnya, pre-emptive atau tidak)
    • Benang hijau versus benang asli
    • Hotspot (dan mengapa teknik penyetelan kinerja lama meniadakan pengoptimalan Hotspot)
    • JIT dan ketika JIT yang baik menjadi buruk (tidak disetel JAVA_COMPILERdan kode Anda berjalan dengan baik, dll.)
    • API Koleksi
    • RMI

Larutan:

Anda perlu meningkatkan pengetahuan Anda tentang Java, terutama kekuatan dan kelemahannya. Java ada jauh lebih dari sekedar bahasa. Sama pentingnya untuk memahami platform (JDK dan alat). Secara konkret, Anda harus mendapatkan sertifikasi sebagai programmer Java jika Anda belum melakukannya - Anda akan kagum betapa banyak yang tidak Anda ketahui. Lebih baik lagi, lakukan sebagai bagian dari kelompok dan dorong satu sama lain. Ini juga lebih menyenangkan. Selanjutnya, buat milis yang ditujukan untuk teknologi Java dan pertahankan! (Setiap perusahaan tempat saya bekerja memiliki daftar ini, yang sebagian besar mendukung kehidupan karena tidak aktif.) Belajar dari pengembang sejawat Anda - mereka adalah sumber daya terbaik Anda.

Catatan:

Jika Anda atau anggota lain dari tim Anda tidak memahami bahasa pemrograman dan platformnya, bagaimana Anda bisa berharap untuk membangun aplikasi Java enterprise yang sukses? Pemrogram Java yang kuat menyukai EJB dan J2EE seperti bebek ke air. Sebaliknya, programmer yang buruk atau tidak berpengalaman akan membuat aplikasi J2EE yang berkualitas buruk.

Deskripsi: Tidak memahami EJB

Fase proyek:

Rancangan

Fase proyek yang terpengaruh:

Pembangunan, Stabilisasi

Karakteristik sistem yang terpengaruh:

Pemeliharaan

Gejala:

  • EJB yang berfungsi ketika mereka dipanggil pertama kali tetapi tidak pernah setelah itu (terutama kacang sesi tanpa status yang dikembalikan ke kumpulan siap)
  • EJB yang tidak dapat digunakan kembali
  • Tidak tahu apa yang menjadi tanggung jawab pengembang, dibandingkan dengan apa yang disediakan wadah
  • EJB yang tidak sesuai dengan spesifikasi (utas api, memuat pustaka asli, mencoba melakukan I / O, dan sebagainya)

Larutan:

Untuk meningkatkan pengetahuan EJB Anda, luangkan waktu di akhir pekan dan baca spesifikasi EJB (versi 1.1 memiliki panjang 314 halaman). Kemudian baca spesifikasi 2.0 (524 halaman!) Untuk mengetahui apa yang tidak dibahas oleh spesifikasi 1.1 dan ke mana spesifikasi 2.0 akan membawa Anda. Berkonsentrasi pada bagian spesifikasi yang memberi tahu Anda, pengembang aplikasi, apa saja tindakan hukum di EJB. Bagian 18.1 dan 18.2 adalah tempat yang baik untuk memulai.

Catatan:

Jangan melihat dunia EJB melalui mata vendor Anda. Pastikan Anda mengetahui perbedaan antara spesifikasi yang mendasari model EJB dan spesifikasi tertentu. Ini juga akan memastikan bahwa Anda dapat mentransfer keahlian Anda ke vendor lain (atau versi) sesuai kebutuhan.

Deskripsi: Tidak memahami J2EE

Fase proyek:

Rancangan

Fase proyek yang terpengaruh:

Pengembangan

Karakteristik sistem yang terpengaruh:

Pemeliharaan, skalabilitas, kinerja

Gejala:

  • Desain "Semuanya adalah EJB"
  • Manajemen transaksi manual alih-alih menggunakan mekanisme yang disediakan penampung
  • Implementasi keamanan khusus - platform J2EE mungkin memiliki arsitektur keamanan yang paling lengkap dan terintegrasi dalam komputasi perusahaan, dari presentasi sampai ke ujung belakang; itu jarang digunakan dengan kemampuan penuhnya

Larutan:

Pelajari komponen utama J2EE dan apa keuntungan dan kerugian yang dibawa setiap komponen ke tabel. Tutupi setiap layanan secara bergiliran; pengetahuan sama dengan kekuatan di sini.

Catatan:

Hanya pengetahuan yang bisa memperbaiki masalah ini. Pengembang Java yang baik akan menjadi pengembang EJB yang baik, yang pada gilirannya diposisikan secara ideal untuk menjadi guru J2EE. Semakin banyak pengetahuan Java dan J2EE yang Anda miliki, semakin baik Anda dalam desain dan implementasi. Hal-hal akan mulai masuk ke tempatnya untuk Anda pada waktu desain.

Bahaya 2: Rekayasa berlebihan (ke EJB atau tidak ke EJB)

Fase proyek:

Rancangan

Fase proyek yang terpengaruh:

Pengembangan

Karakteristik sistem yang terpengaruh:

Pemeliharaan, skalabilitas, kinerja

Gejala:

  • EJB berukuran besar
  • Pengembang yang tidak dapat menjelaskan apa yang dilakukan EJB mereka dan hubungan di antara mereka
  • EJB, komponen, atau layanan yang tidak dapat digunakan kembali pada saat yang seharusnya
  • EJB memulai transaksi baru ketika transaksi yang sudah ada akan dilakukan
  • Tingkat isolasi data disetel terlalu tinggi (sebagai upaya untuk mengamankan)

Larutan:

Solusi untuk rekayasa berlebihan datang langsung dari metodologi pemrograman ekstrem (XP): desain dan kode minimum untuk memenuhi persyaratan dari pelingkupan, tidak lebih. Meskipun Anda perlu menyadari persyaratan di masa mendatang, misalnya persyaratan beban rata-rata di masa mendatang atau perilaku sistem pada waktu pemuatan puncak, jangan mencoba menebak-nebak seperti apa tampilan sistem di masa mendatang. Selain itu, platform J2EE mendefinisikan karakteristik seperti skalabilitas dan failover sebagai tugas yang harus ditangani infrastruktur server untuk Anda.

Dengan sistem minimal, terdiri dari komponen kecil yang dirancang untuk melakukan satu hal dan melakukannya dengan baik, tingkat penggunaan kembali meningkat, seperti halnya stabilitas sistem. Selain itu, daya rawat sistem Anda semakin kuat dan persyaratan masa depan dapat ditambahkan dengan lebih mudah.

Catatan:

Selain solusi yang tercantum di atas, terapkan pola desain - pola tersebut meningkatkan desain sistem Anda secara signifikan. Model EJB sendiri menggunakan pola desain secara ekstensif. Misalnya, file

Home

antarmuka setiap EJB adalah contoh pola Finder dan Pabrik. Antarmuka jarak jauh dari EJB bertindak sebagai Proxy untuk implementasi kacang yang sebenarnya dan merupakan pusat kemampuan container untuk mencegat panggilan dan menyediakan layanan seperti penyeimbangan beban transparan. Abaikan nilai pola desain dengan risiko Anda sendiri.

Bahaya lain yang terus saya peringatkan: menggunakan EJB untuk kepentingannya. Tidak hanya beberapa bagian dari aplikasi Anda yang dimodelkan sebagai EJB padahal seharusnya tidak, seluruh aplikasi Anda mungkin menggunakan EJB untuk keuntungan yang tidak terukur. Ini adalah rekayasa berlebihan yang dilakukan secara ekstrem, tetapi saya telah melihat servlet yang sangat baik dan aplikasi JavaBean terkoyak, didesain ulang, dan diimplementasikan menggunakan EJB tanpa alasan teknis yang baik.

Bahaya 3: Tidak memisahkan logika presentasi dari logika bisnis

Fase proyek:

Rancangan

Fase proyek yang terpengaruh:

Pengembangan

Karakteristik sistem yang terpengaruh:

Rawatan, diperpanjang, kinerja

Gejala:

  • JSP yang besar dan berat
  • Anda mendapati diri Anda mengedit JSP saat logika bisnis berubah
  • Perubahan persyaratan tampilan memaksa Anda untuk mengedit dan menerapkan ulang EJB dan komponen backend lainnya

Larutan:

Platform J2EE memberi Anda kesempatan untuk memisahkan logika presentasi dari navigasi dan kontrol, dan terakhir dari logika bisnis. Ini disebut arsitektur Model 2 (lihat Sumber untuk artikel yang bagus). Jika Anda telah jatuh ke dalam perangkap ini, diperlukan dosis refactoring yang kaku. Anda setidaknya harus memiliki potongan vertikal tipis yang sebagian besar berdiri sendiri (yaitu, cara saya memesan widget adalah bagian yang terpisah dari cara saya mengubah nama pengguna atau kata sandi saya). Gunakan organisasi implisit sistem Anda untuk melakukan refaktorisasi secara bertahap.

Catatan:

Menggunakan desain yang konsisten dalam hubungannya dengan kerangka kerja UI (taglib misalnya) juga akan membantu memastikan bahwa Anda menghindari masalah pemisahan logika pada proyek Anda. Jangan repot-repot membangun kerangka GUI lain untuk kebutuhan Anda sendiri, ada terlalu banyak implementasi bagus yang tersedia. Evaluasi masing-masing secara bergiliran dan terapkan kerangka kerja yang paling sesuai dengan kebutuhan Anda.

Bahaya 4: Tidak diterapkan di tempat Anda berkembang

Fase proyek:

Pengembangan

Fase proyek yang terpengaruh:

Stabilisasi, Paralel, Langsung

Karakteristik sistem yang terpengaruh:

Kewarasan Anda

Gejala:

  • Transisi beberapa hari atau seminggu ke sistem live
  • Risiko yang terlibat dalam siaran langsung sangat besar, dengan banyak skenario penggunaan utama yang tidak diketahui dan tidak diuji
  • Data dalam sistem langsung tidak sama dengan data dalam pengembangan atau penyiapan stabilisasi
  • Ketidakmampuan untuk menjalankan build di mesin pengembang
  • Perilaku aplikasi tidak sama dalam lingkungan pengembangan, stabilisasi, dan produksi

Larutan:

Solusi untuk Danger 4 dimulai dengan menduplikasi lingkungan produksi dengan tepat di lingkungan pengembangan Anda. Kembangkan pada pengaturan yang sama persis dengan yang Anda rencanakan untuk ditayangkan - jangan kembangkan di JDK 1.3 dan Red Hat Linux ketika Anda berencana untuk meluncurkannya di JDK 1.2.2 dan Solaris 7. Lebih lanjut, jangan mengembangkan di satu server aplikasi dan ditayangkan di server lain. Selain itu, dapatkan cuplikan data dari database produksi dan gunakan untuk pengujian, jangan mengandalkan data yang dibuat secara artifisial. Jika data produksi sensitif, desensitisasi dan muat. Data produksi yang tidak terduga akan rusak:

  • Aturan validasi data
  • Perilaku sistem yang teruji
  • Kontrak antara komponen sistem (khususnya EJB-EJB dan database EJB)

Yang terburuk dari semuanya, masing-masing akan menghasilkan pengecualian, petunjuk nol, dan perilaku yang belum pernah Anda lihat sebelumnya.

Catatan:

Pengembang sering kali meninggalkan keamanan hingga stabilisasi ("Ya, layar berfungsi, sekarang mari tambahkan hal validasi pengguna."). Hindari jebakan ini dengan mencurahkan jumlah waktu yang sama untuk menerapkan keamanan seperti yang Anda lakukan untuk logika bisnis.