Kehidupan lengkap Java: Apa yang sebenarnya dilakukan oleh seorang arsitek perangkat lunak sepanjang hari?

Arsitek perangkat lunak memilikinya dengan mudah, atau begitu banyak pembuat kode dan insinyur percaya. Cari tahu seperti apa kehidupan kerja sehari-hari seorang arsitek dalam wawancara kehidupan Java Lengkap ini . Veteran pemrograman Java Bruce Brouwer membahas pendekatannya untuk meningkatkan aplikasi web Java lama menjadi arsitektur front-end berorientasi layanan, toolkit UI webnya yang berkembang pesat, dan mengapa dia secara umum lebih suka bekerja dengan batasan Java daripada memilih bahasa JVM yang tidak terlalu ketat.

Seperti banyak pengembang perangkat lunak, saya selalu skeptis terhadap arsitek. Terlalu sering mereka seolah-olah menuntut tentang bagaimana pekerjaan coding akan dilakukan tanpa harus hidup dengan konsekuensinya. Saya adalah orang yang pernah menulis artikel berjudul "Mengapa saya bukan seorang arsitek," dan saya dikenal sering menyindir "IDE favoritnya adalah MS Outlook."

Lalu saya bertemu Bruce Brouwer, seorang arsitek aplikasi di Gordon Food Service (GFS), distributor makanan milik keluarga yang berkantor di Michigan. Ketika saya bertemu Bruce, dia jauh ke layar komputernya, melihat kode sebenarnya. Tugasnya adalah untuk mengintegrasikan kompiler Kompas berbasis Ruby dari GFS ke dalam sebuah aplikasi yang dibangun menggunakan JRuby, dan pendekatannya terhadap pekerjaan tersebut tampak seperti abstrak. Saya tertarik.

Pekerjaan Bruce di GFS, katanya, adalah menetapkan visi untuk aplikasi web masa depan dan mendemonstrasikan visinya dengan aplikasi bukti konsep. Dia biasanya bekerja dengan tim pengembangan pada beberapa implementasi pertama peluncuran. Masalah paling mutakhir yang sedang dikerjakan Bruce, pada hari kami bertemu, adalah bagaimana memindahkan GFS melewati aplikasi web permintaan / respons tradisional ke arsitektur front-end berorientasi layanan (SOFEA), di mana semua logika presentasi ditangani di browser bukan di server.

Bruce berbagi beberapa idenya untuk mendorong melampaui arsitektur berorientasi layanan klasik (SOA) menjadi paradigma yang lebih berbasis pesan. Ide-ide ini harus dikerjakan di atas kertas, tetapi Bruce perlu dukungan dari tim teknis untuk membuatnya berhasil. Sebagai seorang arsitek, dia memberikan panduan implementasi di seluruh tim, teknologi, dan bahkan sistem lama. Perspektifnya sangat menarik, dan menurut saya layak untuk dibagikan.

Matt Heusser : Ceritakan tentang karier Anda sebagai programmer dan arsitek. Bagaimana peran Anda berubah dari waktu ke waktu? Bagaimana Anda mendekati peran Anda sebagai programmer junior versus sebagai programmer mid-career atau sebagai arsitek saat ini?

Bruce Brouwer : Setelah kuliah, saya pindah ke pekerjaan nyata pertama saya. Sejak awal, saya mendorong batas. Ada proses yang membosankan dalam memperbarui lapisan akses data aplikasi ini. Semua karyawan baru mengalami kesulitan mengerjakan proses itu. Setelah pertama kali saya, saya memutuskan untuk mengotomatiskannya. Manajemen terkesan, jadi mereka meminta saya untuk menjalankannya untuk semua tabel di database. Butuh waktu sekitar satu minggu untuk membersihkan kekacauan dari otomatisasi saya yang ternyata merupakan proses yang rusak.

Ketika saya melanjutkan karir saya, saya menemukan lebih banyak kesempatan untuk membuat segalanya lebih mudah untuk dikembangkan. Sebuah frase dengan cepat dikaitkan dengan saya: "Satu baris kode." Saya terus mendorong pekerjaan saya untuk membuat segalanya lebih sederhana bagi para pengembang. Saya tidak benar-benar senang dengan pekerjaan saya sampai Anda dapat melakukan sesuatu yang sebelumnya rumit, tapi sekarang sesederhana satu baris kode.

Tapi Anda hanya bisa melangkah sejauh ini dengan membuat alat yang lebih baik. Saya harus mulai berpikir dalam skala yang lebih besar. Saat Anda mulai bermain di dunia yang lebih besar ini, Anda perlu mendorong batasan lagi. Mungkin database SQL tidak diperlukan. Mungkin menunggu jawaban dari layanan itu bukanlah penggunaan waktu yang terbaik. Mungkin Java tidak memotongnya lagi.

Oke, poin terakhir itu agak kontroversial, tapi ini adalah pertanyaan yang saya ajukan. Tetapi hanya menanyakan pertanyaan-pertanyaan ini bukanlah pekerjaan sebenarnya dari seorang arsitek. Bahkan merancang arsitektur yang benar-benar brilian tidaklah cukup. Anda harus bisa menunjukkan kepada orang lain cara menuju ke sana, selangkah demi selangkah. Seorang arsitek perlu membumi di dunia nyata, mengalami masalah yang datang dari apa yang telah mereka rancang. Ini membutuhkan upaya teknis dan sosial.

Matt Heusser : Teknologi apa yang Anda gunakan sekarang?

Bruce Brouwer : Belum lama ini saya memutuskan untuk mengisi profil LinkedIn saya, mencantumkan semua teknologi yang sebenarnya saya gunakan. Selama upaya itu, saya mengetahui bahwa LinkedIn memiliki batas. Saya tidak mengatakan itu untuk membual, saya pikir itu adalah masalah. Ada terlalu banyak hal yang perlu Anda ketahui untuk menjadi pengembang yang baik di dunia saat ini. Kita perlu lebih baik dalam membatasi daftar alat yang kita gunakan untuk melakukan pekerjaan kita.

Sebagian besar, yang saya gunakan adalah Java dan Spring. Apa yang baru-baru ini saya kerjakan adalah mendesain masa depan pengembangan aplikasi web di GFS. GFS telah mengembangkan aplikasi web menggunakan Java EE sejak sebelum ada kerangka kerja seperti Struts atau JSF. Sekarang ada beberapa ide baru yang menantang kerangka web sisi server ini, seperti SOFEA dan desain responsif. Ya, kami dapat memasukkan ide-ide ini ke dalam infrastruktur Struts 2 saat ini yang kami miliki, tetapi sekarang saatnya untuk membuat jeda nyata antara UI dan bagian belakang. Dengan cara ini kita akan memiliki posisi yang lebih baik untuk merespons kecepatan perubahan di lapisan UI web tanpa harus membuat perubahan drastis di lapisan layanan.

"Sekarang ada beberapa ide baru yang menantang kerangka kerja web sisi server, seperti SOFEA dan desain responsif. Ya, kami dapat memasukkan ide-ide ini ke dalam infrastruktur Struts 2 saat ini, tetapi sekarang saatnya untuk membuat terobosan nyata antara UI dan bagian belakang akhir."

Untuk UI web baru ini, saya memiliki rangkaian alat yang hampir sepenuhnya baru: Angular dan Twitter Bootstrap, dan tentu saja jQuery. Apa yang saya kejar adalah membangun seluruh UI dari sumber daya statis. Tidak ada UI yang bergantung pada server yang menghasilkan konten UI dinamis apa pun. Ini perlu bekerja di Apache Web Server biasa; tanpa PHP, tidak ada Perl, tidak ada.

Sedangkan untuk lapisan layanan, GFS memiliki warisan Java yang sangat besar. Dan untuk sebagian besar, itu sebenarnya cukup bagus. GFS telah mengejar arsitektur berorientasi layanan selama bertahun-tahun, dengan memanfaatkan Spring POJO. Layanan merupakan inti dari SOFEA. JSON adalah transportasi data pilihan saat ini, dan Spring MVC memudahkan untuk mengekspos POJO ini melalui JSON. Jadi SOFEA sebenarnya sangat cocok untuk GFS.

Namun, bagian yang menantang adalah visi membuat UI web itu benar-benar statis. Untuk membuat aplikasi web yang bagus dan cepat membutuhkan beberapa alat lain. Saya menggunakan Kompas untuk mengelola CSS. Untuk JavaScript, saya menggunakan kompiler Google Closure, yang memiliki fitur peta sumber yang mengagumkan. Lemparkan beberapa persyaratan lain untuk perusak cache dan membuatnya mudah untuk dikembangkan dan tiba-tiba Anda memerlukan solusi build lengkap untuk sesuatu yang akhirnya menjadi hanya sekumpulan file teks.

Ada beberapa alat mengesankan yang telah mulai menjawab tantangan ini. Saya sangat terkesan dengan Grunt dan Yeoman dan saya bahkan membuat lemparan ke GFS untuk meninggalkan Maven demi Yeoman; setidaknya untuk UI web. Saya mendapat kesan bahwa membuang Maven mungkin terlalu jauh untuk alat yang bahkan belum berumur satu tahun. Jadi saya mulai membuat plugin Maven untuk menggabungkan semua ini. Ada plugin Maven untuk menangani Compass dan Closure, tetapi mereka tidak memberikan solusi lengkap yang bahkan dapat memodifikasi pengembangan HTML versus produksi dan juga menyediakan fungsionalitas pemuatan ulang langsung. Ini benar-benar pengalaman yang luar biasa menulis plugin Maven ini, yang tentunya dibuat di Java.

Mungkin sebentar lagi saya akan bisa meyakinkan manajemen untuk mengizinkan saya mengembalikan ini ke komunitas open source.

Matt Heusser : Berapa lama Anda menjadi arsitek? Apa yang Anda kerjakan setahun yang lalu?

Bruce Brouwer : Saya telah menjadi arsitek aplikasi selama delapan tahun sekarang. Saya beralih dari programmer senior menjadi arsitek ketika saya pindah ke GFS.

Proyek besar saya sebelumnya, yang saya kerjakan setahun yang lalu, adalah transisi ke Google Apps. Ini juga merupakan pengalaman belajar yang nyata bagi saya. Saya mendapat ide bagus untuk menyinkronkan kalender lama dengan Google Kalender selama masa transisi. Saya menggunakan Google API dari Java bersama dengan Spring Integration untuk mewujudkan semuanya. Setidaknya untuk sementara. Setelah beberapa gangguan serius, saya harus mengakui bahwa risikonya tidak sebanding. Menjadi arsitek dan pengembang proyek itu membantu saya menjaga dunia nyata dalam perspektif.

"Kami harus membuat batasan tentang apa yang pantas dan tidak pantas untuk digunakan Google ketika berintegrasi dengan sistem kami yang ada. Ini bisa sulit ketika Anda dipaksa untuk meredam antusiasme itu."

Google menghadirkan dunia kemungkinan baru ke GFS. Kami baru mulai merasakan dampaknya dalam cara kami merancang sistem kami. Saya sudah memiliki banyak percakapan dengan orang-orang yang ingin menggunakan Google karena ini adalah mainan baru yang mengilap. Kami harus membuat garis di pasir untuk apa yang pantas dan tidak sesuai untuk menggunakan Google saat mengintegrasikan dengan sistem kami yang ada. Ini bisa menjadi sulit ketika Anda dipaksa untuk meredam antusiasme itu.

Matt Heusser : Sebagai seorang arsitek, Anda telah mencapai tingkat yang hanya dicapai oleh sebagian kecil pemrogram. Apakah Anda memiliki saran untuk programmer yang memulai karir mereka?

Bruce Brouwer : Saya senang ketika pemrogram baru memiliki ide untuk menantang status quo saat ini. Biasanya mereka ingin menggunakan alat baru untuk mempermudah tugas. Saat hal ini terjadi, saya dapat membantu mereka melihat gambaran yang lebih besar. Seringkali itu berarti menunjukkan masalah dengan membawa alat itu. Membicarakan masalah terkadang memaksa programmer baru untuk membuka mata terhadap masalah yang lebih besar.

Jadi saran saya untuk programmer baru adalah terus maju dan menantang beberapa ide. Temukan programmer atau arsitek senior yang dapat Anda gunakan sebagai mentor dan menyuarakan ide Anda. Kemungkinan idenya tidak akan berjalan dengan baik tetapi Anda akan belajar banyak dengan mencari tahu mengapa Anda salah, bukan hanya karena Anda salah. Tetapi ingat juga, bahwa programmer dan arsitek senior dapat menderita miopia dan Anda mungkin menemukan ide yang layak untuk dikejar.

Matt Heusser : Siapa pelanggan Anda? (Atau, untuk meminjam kalimat dari Bobs di "Office Space": Apa yang akan Anda lakukan di sini?)

Bruce Brouwer : Saya tidak benar-benar mendukung pelanggan mana pun secara langsung dalam artian akan ada fokus bisnis langsung. Saya sebenarnya ditempatkan di sisi infrastruktur IS, bersama dengan DBA dan admin server. IS lainnya benar-benar memiliki fokus untuk melayani area bisnis tertentu. Mungkin tampak aneh untuk menempatkan pengembang Java di infrastruktur, tetapi ini memungkinkan saya untuk fokus pada masalah yang memiliki fokus arsitektur yang lebih besar daripada yang mungkin dimiliki orang lain. Sementara orang lain mencoba untuk bekerja melalui proses bisnis, saya lebih fokus pada teknologi yang digunakan untuk menyelesaikan masalah semua orang dengan cara yang dapat digunakan kembali.

Orang sering meminta saya untuk membantu proyek lain; terkadang untuk waktu yang lama. Ini membantu saya tetap membumi di dunia nyata. Ini juga membantu saya menyebarkan ide-ide baru ke seluruh tim pengembangan lainnya. Saya telah menemukan bahwa ketika saya diminta untuk berperan sebagai arsitek proyek, pengaruh saya terbatas pada lebih banyak pengembang yunior; sebenarnya lebih bermanfaat bagi saya untuk berkontribusi pada proyek lain yang sudah memiliki arsitek, karena saya dapat mendorong ide-ide saya dengan orang-orang yang lebih berpengaruh di bagian organisasi mereka.

Matt Heusser : Berapa lama Anda memprogram di Java? Bagaimana Anda melihat bahasa dan pemrograman Java itu sendiri berubah selama bertahun-tahun?

Bruce Brouwer : Saya tidak terlalu menganggap serius Java sampai Java 1.3. Jadi, itu akan menjadi sekitar 13 tahun. Tetapi bahkan kemudian, Java tidak benar-benar menjadi kesenangan untuk berkembang sampai 1.5 hadir dengan generik. Ada begitu banyak kegunaan yang baik dari generik, dan kebanyakan orang sepertinya tidak menggunakannya di luar framework koleksi Java.

Dulu ketika saya mulai dengan Java, kami menulis hampir semuanya sendiri. Seiring waktu, saya telah melihat bagaimana seluruh dunia telah menggunakan Java, terutama di komunitas open source. Ledakan open source itu adalah perubahan terpenting yang saya alami selama berkarir di pemrograman Java. Itu adalah sesuatu yang benar-benar belum cocok dengan bahasa lain sampai saat ini.

Matt Heusser : Bicaralah dengan saya tentang menggunakan JRuby di GFS. Apa pendapat Anda tentang bahasa JVM; haruskah kita semua menjadi pemrogram Clojure sekarang?

Bruce Brouwer : JRuby benar-benar sarana untuk mencapai tujuan di Gordons. Kompas benar-benar implementasi Sass pertama di luar sana dan kebetulan ditulis di Ruby. Saya juga menggunakan Rhino dan Groovy juga di JVM. Saya telah melihat betapa kuat dan cakapnya bahasa-bahasa lain ini, begitu pula Java.

Bahasa lain seperti Scala, dan Anda menyebut Clojure, mendapatkan popularitas belakangan ini. Meskipun Anda dapat melakukan hal yang sama di Scala dengan sesuatu seperti setengah kode Java, saya yakin keterbacaan bisa lebih cepat menderita daripada di Java. Beberapa waktu yang lalu, saya melihat sejumlah kontraktor dengan stiker di laptop mereka yang bertuliskan "Mengetik bukanlah hambatan." Saya sangat setuju. Memikirkan masalah dan menjelaskannya kepada orang berikutnya lebih penting daripada menemukan cara cerdas untuk mengurangi jumlah baris kode yang Anda tulis. Jangan salah paham, mempertahankan lebih sedikit kode lebih baik daripada lebih banyak kode, tetapi harus jelas apa yang sedang terjadi.