Bahaya projek J2EE!

Dalam pelbagai tempoh saya sebagai pemaju, pemaju kanan, dan arkitek, saya telah melihat yang baik, yang buruk, dan yang jelek ketika datang ke projek Java perusahaan! Apabila saya bertanya pada diri sendiri apa yang membuat satu projek berjaya dan yang lain gagal, sukar untuk mendapatkan jawapan yang sempurna, kerana kejayaan terbukti sukar untuk ditentukan untuk semua projek perisian. Projek J2EE tidak terkecuali. Sebaliknya, projek berjaya atau gagal dengan pelbagai peringkat. Dalam artikel ini saya ingin mengambil 10 bahaya teratas yang mempengaruhi kejayaan projek Java perusahaan dan mempamerkannya untuk anda, pembaca.

Sebilangan bahaya ini hanya melambatkan projek, yang lain adalah jalan palsu, dan yang lain secara langsung dapat merosakkan peluang kejayaan. Namun, semuanya dapat dihindari dengan persiapan yang baik, pengetahuan tentang perjalanan ke depan, dan pemandu tempatan yang mengetahui kawasannya.

Artikel ini ringkas dalam struktur; Saya akan melindungi setiap bahaya seperti berikut:

  • Nama bahaya: Satu kapal yang menggariskan bahaya
  • Fasa projek: Fasa projek di mana bahaya berlaku
  • Fasa projek terjejas: Dalam banyak kes, bahaya boleh memberi kesan buruk pada fasa projek kemudian
  • Gejala: Gejala yang berkaitan dengan bahaya ini
  • Penyelesaian: Cara untuk mengelakkan bahaya sama sekali dan bagaimana mengurangkan kesannya pada projek anda
  • Catatan: Perkara yang ingin saya sampaikan berkaitan dengan bahaya, tetapi tidak termasuk dalam kategori sebelumnya

Seperti yang dinyatakan di atas, kami akan memeriksa setiap bahaya dalam konteks proyek Java perusahaan, bersama dengan fasa-fasa pentingnya. Fasa projek merangkumi:

  • Pemilihan Vendor: Proses memilih gabungan alat terbaik sebelum anda memulakan projek J2EE anda - dari pelayan aplikasi hingga ke jenama kopi anda.
  • Reka Bentuk: Di antara metodologi air terjun yang ketat dan pendekatan "kod dan lihat," terletak reka bentuk saya: Saya membuat reka bentuk yang cukup sehingga saya dapat bergerak dengan selesa ke dalam pembangunan. Saya menganggap fasa reka bentuk saya selesai apabila saya mengetahui dengan tepat apa yang saya bina dan bagaimana saya akan membinanya. Lebih-lebih lagi, saya menggunakan templat reka bentuk untuk memastikan bahawa saya telah menanyakan semua soalan yang tepat mengenai diri saya dan penyelesaian yang saya cadangkan sebelum beralih ke pembangunan. Walau bagaimanapun, saya tidak takut untuk membuat kod dalam fasa ini; kadang-kadang itu satu-satunya cara untuk menjawab soalan mengenai prestasi, prestasi atau modulariti.
  • Pembangunan: Fasa projek di mana jumlah kerja yang dilakukan pada fasa sebelumnya akan ditunjukkan. Pilihan alat yang baik ditambah dengan reka bentuk yang baik tidak selalu bermaksud pengembangan yang sangat lancar, tetapi ia pasti membantu!
  • Stabilisasi / Uji Beban: Pada fasa ini, arkitek sistem dan pengurus projek akan memaksakan pembekuan ciri dan fokus pada kualiti binaan, serta memastikan bahawa statistik penting sistem - bilangan pengguna bersamaan, senario kegagalan, dan sebagainya - dapat dipenuhi. Walau bagaimanapun, kualiti dan prestasi tidak boleh diabaikan sehingga fasa ini. Anda tidak boleh menulis kod yang berkualiti rendah atau lambat dan membiarkannya sehingga penstabilan diperbaiki.
  • Langsung: Ini sebenarnya bukan fasa projek, ia adalah tarikh yang ditentukan. Fasa ini adalah mengenai persiapan. Di sinilah hantu kesilapan masa lalu akan kembali menghantui projek anda, dari reka bentuk dan pembangunan yang buruk hingga pilihan vendor yang buruk.

Gambar 1 menggambarkan fasa projek yang paling banyak dipengaruhi oleh sebab-sebab yang berbeza (dan terutamanya kesan mengejutkan).

Kalau begitu, tanpa basa-basi lagi, mari kita masuk ke 10 teratas!

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

Betul, saya akan memecahkan yang ini menjadi tiga subelemen untuk analisis yang lebih mudah.

Huraian: Tidak memahami Java

Fasa projek:

Pembangunan

Fasa projek terjejas:

Reka Bentuk, Pemantapan, Langsung

Ciri-ciri sistem yang terjejas:

Kemampuan mengekalkan, skalabiliti, prestasi

Gejala:

  • Meningkatkan fungsi dan kelas yang sudah terkandung dalam API teras JDK
  • Tidak mengetahui apa yang ada atau semua perkara berikut dan apa yang mereka lakukan (senarai ini hanya mewakili contoh topik):
    • Pengutip sampah (kereta api, generasi, inkremental, segerak, tidak segerak)
    • Apabila objek dapat dikumpulkan sampah - menggantung rujukan
    • Mekanisme warisan yang digunakan (dan pertukarannya) di Jawa
    • Kaedah over-riding dan over-loading
    • Mengapa java.lang.String(ganti kelas kegemaran anda di sini!) Membuktikan buruk prestasi
    • Semantik rujukan lulus Java (berbanding semantik nilai lulus di EJB)
    • Menggunakan ==versus melaksanakan equals()kaedah untuk bukan bayaran
    • Cara Java menjadualkan utas pada platform yang berbeza (misalnya, pra-pilihan atau tidak)
    • Benang hijau berbanding benang asli
    • Hotspot (dan mengapa teknik penalaan prestasi lama meniadakan pengoptimuman Hotspot)
    • JIT dan apabila JIT yang baik menjadi buruk (tidak disetel JAVA_COMPILERdan kod anda berjalan dengan baik, dll.)
    • API Koleksi
    • RMI

Penyelesaian:

Anda perlu meningkatkan pengetahuan anda tentang Java, terutama kekuatan dan kelemahannya. Java wujud lebih dari sekadar bahasa. Sama pentingnya untuk memahami platform (JDK dan alat). Secara konkrit, anda harus disahkan sebagai pengaturcara Java jika anda belum melakukannya - anda akan kagum betapa anda tidak tahu. Lebih baik lagi, lakukanlah sebagai sebahagian daripada kumpulan dan saling mendorong. Ia juga lebih menyeronokkan dengan cara ini. Selanjutnya, sediakan milis yang ditujukan untuk teknologi Java dan teruskan! (Setiap syarikat yang pernah saya bekerjasama mempunyai senarai ini, yang kebanyakannya mempunyai sokongan hidup kerana tidak aktif.) Belajarlah dari rakan sejawat anda - mereka adalah sumber terbaik anda.

Catatan:

Sekiranya anda atau ahli pasukan anda yang lain tidak memahami bahasa dan platform pengaturcaraan, bagaimana anda berharap dapat membangun aplikasi Java perusahaan yang berjaya? Pengaturcara Java yang kuat membawa EJB dan J2EE seperti itik ke air. Sebaliknya, pengaturcara yang lemah atau tidak berpengalaman akan membina aplikasi J2EE berkualiti rendah.

Penerangan: Tidak memahami EJB

Fasa projek:

Reka bentuk

Fasa projek terjejas:

Pembangunan, Pemantapan

Ciri-ciri sistem yang terjejas:

Penyelenggaraan

Gejala:

  • EJB yang berfungsi semasa mereka mula-mula dipanggil tetapi tidak pernah sesudahnya (terutamanya kacang sesi tanpa status yang dikembalikan ke kolam siap)
  • EJB yang tidak boleh digunakan semula
  • Tidak mengetahui apa yang bertanggungjawab oleh pembangun, berbanding dengan apa yang disediakan oleh bekas
  • EJB yang tidak sesuai dengan spesifikasi (utas api, memuatkan perpustakaan asli, cubaan melakukan I / O, dan sebagainya)

Penyelesaian:

Untuk meningkatkan pengetahuan EJB anda, luangkan hujung minggu dan baca spesifikasi EJB (versi 1.1 panjangnya 314 halaman). Kemudian baca spesifikasi 2.0 (524 halaman!) Untuk mengetahui apa yang tidak ditangani oleh spesifikasi 1.1 dan ke mana spesifikasi 2.0 akan membawa anda. Tumpukan perhatian pada bahagian spesifikasi yang memberitahu anda, pembangun aplikasi, apakah tindakan undang-undang dalam EJB. Bahagian 18.1 dan 18.2 adalah tempat yang baik untuk bermula.

Catatan:

Jangan melihat dunia EJB melalui mata penjual anda. Pastikan anda mengetahui perbezaan antara spesifikasi yang mendasari model EJB dan kaedah tertentu. Ini juga akan memastikan bahawa anda dapat memindahkan kemahiran anda ke vendor lain (atau versi) mengikut keperluan.

Penerangan: Tidak memahami J2EE

Fasa projek:

Reka bentuk

Fasa projek terjejas:

Pembangunan

Ciri-ciri sistem yang terjejas:

Penyelenggaraan, skalabiliti, prestasi

Gejala:

  • Reka bentuk "Semuanya adalah EJB"
  • Pengurusan transaksi secara manual dan bukannya menggunakan mekanisme yang disediakan oleh kontena
  • Pelaksanaan keselamatan tersuai - platform J2EE mungkin mempunyai seni bina keselamatan yang paling lengkap dan bersepadu dalam pengkomputeran perusahaan, dari persembahan hingga akhir; jarang digunakan untuk kemampuan sepenuhnya

Penyelesaian:

Ketahui komponen utama J2EE dan apa kelebihan dan kekurangan yang dibawa oleh setiap komponen. Meliputi setiap perkhidmatan secara bergilir; pengetahuan sama dengan kekuatan di sini.

Catatan:

Hanya pengetahuan yang dapat menyelesaikan masalah ini. Pembangun Java yang baik menjadikan pemaju EJB yang baik, yang pada gilirannya berada pada kedudukan yang ideal untuk menjadi guru J2EE. Semakin banyak pengetahuan Java dan J2EE yang anda miliki, semakin baik anda akan merancang dan melaksanakannya. Perkara akan mula disediakan untuk anda pada waktu reka bentuk.

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

Fasa projek:

Reka bentuk

Fasa projek terjejas:

Pembangunan

Ciri-ciri sistem yang terjejas:

Penyelenggaraan, skalabiliti, prestasi

Gejala:

  • EJB yang terlalu besar
  • Pembangun yang tidak dapat menjelaskan apa yang dilakukan EJB mereka dan hubungan antara mereka
  • EJB, komponen, atau perkhidmatan yang tidak boleh digunakan semula apabila sepatutnya
  • EJB memulakan transaksi baru apabila transaksi yang ada akan dilakukan
  • Tahap pengasingan data ditetapkan terlalu tinggi (dalam usaha untuk selamat)

Penyelesaian:

Penyelesaian untuk kejuruteraan yang berlebihan datang langsung dari metodologi pengaturcaraan ekstrim (XP): reka dan kod minimum minimum untuk memenuhi keperluan dari pengisian, tidak lebih. Walaupun anda perlu mengetahui keperluan masa depan, misalnya keperluan beban rata-rata masa depan atau tingkah laku sistem pada waktu pemuatan puncak, jangan cuba menebak bagaimana sistem akan kelihatan seperti di masa depan. Di samping itu, platform J2EE menentukan ciri-ciri seperti skalabilitas dan failover sebagai tugas yang harus ditangani oleh infrastruktur pelayan untuk anda.

Dengan sistem minimum, terdiri dari komponen kecil yang dirancang untuk melakukan satu perkara dan melakukannya dengan baik, tahap penggunaan semula bertambah baik, begitu juga kestabilan sistem. Lebih-lebih lagi, pemeliharaan sistem anda semakin kuat dan keperluan masa depan dapat ditambah dengan lebih mudah.

Catatan:

Selain penyelesaian yang disenaraikan di atas, gunakan corak reka bentuk - mereka meningkatkan reka bentuk sistem anda dengan ketara. Model EJB sendiri menggunakan corak reka bentuk secara meluas. Sebagai contoh,

Home

antara muka setiap EJB adalah contoh corak Finder and Factory. Antaramuka jarak jauh EJB bertindak sebagai Proksi untuk pelaksanaan kacang sebenarnya dan merupakan pusat keupayaan wadah untuk memintas panggilan dan memberikan perkhidmatan seperti pengimbangan beban yang telus. Abaikan nilai corak reka bentuk dengan bahaya anda.

Bahaya lain yang selalu saya peringatkan: menggunakan EJB untuk kepentingannya. Bukan hanya beberapa bahagian aplikasi anda dapat dimodelkan sebagai EJB ketika tidak seharusnya, seluruh aplikasi anda mungkin menggunakan EJB tanpa keuntungan yang dapat diukur. Ini adalah kejuruteraan yang terlalu tinggi, tetapi saya telah melihat servlet yang sangat baik dan aplikasi JavaBean dipecah, direka semula, dan dilaksanakan menggunakan EJB tanpa alasan teknikal yang baik.

Bahaya 3: Tidak memisahkan logik persembahan dari logik perniagaan

Fasa projek:

Reka bentuk

Fasa projek terjejas:

Pembangunan

Ciri-ciri sistem yang terjejas:

Kemampuan mengekalkan, kebolehpanjangan, prestasi

Gejala:

  • JSP yang besar dan tidak berat sebelah
  • Anda mendapati diri anda mengedit JSP apabila logik perniagaan berubah
  • Perubahan keperluan paparan memaksa anda mengedit dan menggunakan semula EJB dan komponen backend yang lain

Penyelesaian:

Platform J2EE memberi anda peluang untuk memisahkan logik persembahan dari navigasi dan kawalan, dan akhirnya dari logik perniagaan. Ini disebut seni bina Model 2 (lihat Sumber untuk artikel yang bagus). Sekiranya anda telah terjebak dalam perangkap ini, diperlukan dos refactoring yang ketat. Anda sekurang-kurangnya harus mempunyai potongan menegak tipis yang sebahagian besarnya serba lengkap (iaitu, bagaimana saya memesan widget adalah potongan terpisah dari cara saya menukar nama pengguna atau kata laluan saya). Gunakan sistem tersirat sistem anda ini untuk membuat refleksi secara berperingkat.

Catatan:

Menggunakan reka bentuk yang konsisten bersama dengan kerangka UI (taglibs misalnya) juga akan membantu memastikan bahawa anda mengelakkan masalah pemisahan logik pada projek anda. Jangan repot-repot membina kerangka GUI lain untuk keperluan anda sendiri, terdapat terlalu banyak implementasi yang baik. Nilai masing-masing secara bergantian dan pakai kerangka yang paling sesuai dengan keperluan anda.

Bahaya 4: Tidak menggunakan tempat anda berkembang

Fasa projek:

Pembangunan

Fasa projek terjejas:

Penstabilan, Selari, Hidup

Ciri-ciri sistem yang terjejas:

Kewarasan anda

Gejala:

  • Peralihan pelbagai hari atau seminggu ke sistem langsung
  • Risiko yang terlibat dalam siaran langsung adalah besar, dengan banyak senario penggunaan yang tidak diketahui dan utama tidak diuji
  • Data dalam sistem langsung tidak sama dengan data dalam penyusunan pembangunan atau penstabilan
  • Ketidakupayaan menjalankan binaan mesin pemaju
  • Tingkah laku aplikasi tidak sama dalam persekitaran pengembangan, penstabilan, dan pengeluaran

Penyelesaian:

Penyelesaian untuk Danger 4 bermula dengan menduplikasi persekitaran pengeluaran dengan setia di persekitaran pembangunan anda. Kembangkan pada persiapan yang sama seperti yang anda rancangkan untuk hidup - jangan berkembang di JDK 1.3 dan Red Hat Linux apabila anda merancang untuk menjalani siaran langsung di JDK 1.2.2 dan Solaris 7. Selanjutnya, jangan berkembang pada satu pelayan aplikasi dan siaran langsung pada yang lain. Juga, dapatkan snapshot data dari pangkalan data pengeluaran dan gunakan untuk pengujian, jangan bergantung pada data yang dibuat secara buatan. Sekiranya data pengeluaran sensitif, jangan peka dan muatkannya. Data pengeluaran yang tidak dijangka akan rosak:

  • Peraturan pengesahan data
  • Tingkah laku sistem yang diuji
  • Kontrak antara komponen sistem (EJB-EJB dan EJB-pangkalan data khususnya)

Yang paling teruk, masing-masing akan menghasilkan pengecualian, petunjuk kosong, dan tingkah laku yang belum pernah anda lihat sebelumnya.

Catatan:

Pembangun sering meninggalkan keselamatan sehingga penstabilan ("Ya, skrin berfungsi, sekarang mari kita tambahkan item pengesahan pengguna."). Elakkan perangkap ini dengan mencurahkan masa yang sama untuk melaksanakan keselamatan seperti yang anda lakukan untuk logik perniagaan.