Emas Hammer

Antipattern Nama: Golden Hammer

Disebut Juga Sebagai: Old Yeller, Kepala-in-pasir

Kebanyakan Skala Berlaku: Aplikasi

Refactored Nama Solusi: Perluas wawasan Anda

Refactored Solusi Jenis: Proses

Akar Penyebab: Ketidaktahuan, Pride, Narrow-Mindedness

Angkatan seimbang: Manajemen Alih Teknologi

Anekdot Bukti: "Saya memiliki palu dan segala sesuatu yang lain adalah paku." "Database kami adalah arsitektur kita." "Mungkin kita tidak seharusnya menggunakan macro Excel untuk pekerjaan ini setelah semua."

Latar belakang
   Ini adalah salah satu antipatterns paling umum di industri. Sering, vendor, khususnya database vendor, akan menganjurkan menggunakan rangkaian produk tumbuh sebagai solusi untuk sebagian besar kebutuhan organisasi. Mengingat biaya awal mengadopsi solusi database tertentu, penjual seperti sering memberikan ekstensi untuk teknologi yang terbukti bekerja dengan baik dengan produk-produknya dikerahkan dengan harga sangat berkurang.

Bentuk umum
   Sebuah tim pengembangan perangkat lunak telah memperoleh tingkat kompetensi yang tinggi dalam larutan atau vendor produk tertentu, yang disebut di sini sebagai Golden Hammer. Akibatnya, setiap usaha produk atau perkembangan baru dipandang sebagai sesuatu yang terbaik diselesaikan dengan itu. Dalam banyak kasus, Golden Hammer ketidaksesuaian untuk masalah, tetapi sedikit usaha dikhususkan untuk mengeksplorasi solusi alternatif.

Ini hasil antipattern dalam penyalahgunaan dari alat disukai atau konsep. Pengembang dan manajer merasa nyaman dengan pendekatan yang ada dan tidak mau belajar dan menerapkan salah satu yang lebih cocok. Hal ini ditandai oleh umum "database kami adalah arsitektur kami" mind-set, sangat umum di masyarakat perbankan dunia.

industri
   Arsitektur sistem digambarkan oleh produk tertentu, suite aplikasi, atau alat penjual set.
Pengembang debat persyaratan sistem dengan analis sistem dan pengguna akhir, sering menganjurkan persyaratan yang mudah ditampung oleh alat tertentu dan mengarahkan mereka jauh dari daerah di mana alat diadopsi tidak cukup.

Pengembang menjadi terisolasi dari industri. Mereka menunjukkan kurangnya pengetahuan dan pengalaman dengan pendekatan alternatif.

Persyaratan tidak sepenuhnya terpenuhi, dalam upaya untuk meningkatkan investasi yang ada.
Produk yang ada mendikte desain dan arsitektur sistem.
Perkembangan baru sangat bergantung pada produk vendor tertentu atau teknologi.
Penyebab khas
Beberapa keberhasilan telah menggunakan pendekatan tertentu.
Investasi yang besar telah dibuat dalam pelatihan dan / atau memperoleh pengalaman dalam produk atau teknologi.

Kelompok terisolasi dari industri, perusahaan lain.
Ketergantungan pada fitur produk proprietary yang tidak tersedia di produk industri lainnya.
"Tongkol jagung" mengusulkan solusi (lihat tongkol jagung antipattern).
Dikenal Pengecualian
Golden Hammer antipattern kadang-kadang bekerja:


   Jika produk yang mendefinisikan kendala arsitektur adalah solusi strategis dimaksudkan untuk jangka panjang; misalnya, menggunakan database Oracle untuk penyimpanan persisten dan dibungkus prosedur untuk akses yang aman ke data yang tersimpan.
Jika produk merupakan bagian dari vendor suite yang menyediakan untuk sebagian besar kebutuhan 

software.
Solusi refactored
   Solusi ini melibatkan aspek filosofis serta perubahan dalam proses pembangunan. Secara filosofis, sebuah organisasi perlu mengembangkan komitmen untuk eksplorasi teknologi baru.


   Tanpa komitmen seperti itu, bahaya mengintai dari overreliance pada teknologi atau alat khusus vendor set ada. Solusi ini membutuhkan pendekatan dua arah: A komitmen yang lebih besar oleh manajemen dalam pengembangan profesional pengembang mereka, bersama dengan strategi pembangunan yang membutuhkan batas-batas perangkat lunak eksplisit untuk memungkinkan migrasi teknologi.


   Sistem perangkat lunak perlu dirancang dan dikembangkan dengan batas-batas yang jelas yang memudahkan replaceability komponen perangkat lunak individu. Sebuah komponen harus melindungi sistem dari fitur proprietary dalam pelaksanaannya.


   Jika sistem ini dikembangkan dengan menggunakan software batas eksplisit, antarmuka yang membentuk batas-batas menjadi titik di mana perangkat lunak yang digunakan dalam pelaksanaan dapat digantikan dengan implementasi baru, tanpa mempengaruhi komponen lain dalam sistem. Standar industri, seperti spesifikasi OMG IDL, adalah alat yang sangat berharga untuk menggabungkan batas software yang kaku antara komponen.


   Selain itu, pengembang perangkat lunak harus up to date pada tren teknologi, baik di dalam domain organisasi dan di industri perangkat lunak pada umumnya. Hal ini dapat dicapai melalui beberapa kegiatan yang mendorong pertukaran ide teknis. Misalnya, pengembang dapat membangun kelompok untuk membahas perkembangan teknis (pola desain, standar muncul, produk baru) yang dapat mempengaruhi organisasi di masa depan.


   Mereka juga dapat membentuk klub studi pustaka untuk melacak dan mendiskusikan publikasi baru yang menggambarkan pendekatan inovatif untuk pengembangan perangkat lunak. Dalam prakteknya, kami telah menemukan buku paradigma klub studi untuk menjadi cara yang sangat efektif untuk bertukar ide dan pendekatan baru.


   Bahkan tanpa buyin manajemen penuh, pengembang dapat membangun jaringan informal dari orang teknologi berpikiran untuk menyelidiki dan melacak teknologi baru dan solusi. Konferensi industri juga merupakan cara yang bagus untuk menghubungi orang-orang dan vendor dan tetap informasi ke mana industri menuju dan apa solusi baru yang tersedia untuk pengembang.


   Di sisi manajemen, langkah lain yang berguna adalah untuk mengadopsi komitmen untuk membuka sistem dan arsitektur. Tanpa itu, pengembang sering mendapatkan sikap yang mencapai hasil jangka pendek dengan cara apapun yang diperlukan dapat diterima. Meskipun ini mungkin diinginkan dalam jangka pendek, hasil di masa depan menjadi bermasalah karena bukan membangun di atas dasar yang kuat dari kesuksesan masa lalu, upaya yang dikeluarkan pengerjaan ulang software masa lalu untuk menyesuaikan diri dengan tantangan baru.


   Fleksibel, kode dapat digunakan kembali membutuhkan investasi dalam pengembangan awal, jika manfaat jangka panjang tidak akan tercapai Juga, bahaya overreliance pada teknologi tertentu atau alat penjual set risiko potensial dalam pengembangan produk atau proyek. In-house program penelitian yang mengembangkan bukti-konsep prototipe yang efektif untuk menguji kelayakan menggabungkan teknologi open kurang berisiko menjadi upaya pembangunan.


   Cara lain manajemen-tingkat menghilangkan atau menghindari Golden Hammer antipattern adalah untuk mendorong mempekerjakan orang-orang dari berbagai daerah dan dari latar belakang yang berbeda. Tim manfaat dari memiliki pengalaman dasar yang lebih luas untuk memanfaatkan dalam mengembangkan solusi. Mempekerjakan tim database yang yang anggotanya semua memiliki pengalaman dalam menggunakan produk database yang sama sangat membatasi kemungkinan ruang solusi, dibandingkan dengan tim yang sama yang memiliki pengalaman meliputi berbagai solusi teknologi database.


   Akhirnya, manajemen harus secara aktif berinvestasi dalam pengembangan profesional pengembang perangkat lunak, serta pengembang reward yang mengambil inisiatif dalam meningkatkan pekerjaan mereka sendiri.


Variasi
   Sebuah variasi umum Golden Hammer terjadi ketika seorang pengembang menggunakan konsep software favorit obsesif. Sebagai contoh, beberapa pengembang belajar satu atau dua dari pola GOF dan menerapkannya semua tahap analisis perangkat lunak, desain, dan implementasi.


   Diskusi tentang maksud atau tujuan tidak cukup untuk bergoyang mereka dari mengakui penerapan struktur pola desain dan kekuatan-pas digunakan di seluruh seluruh proses pembangunan. Pendidikan dan mentoring diperlukan untuk membantu orang menjadi sadar pendekatan lain yang tersedia untuk sistem perangkat lunak konstruksi.


Contoh
   Sebuah contoh umum dari Golden Hammer antipattern adalah lingkungan database-centric tanpa arsitektur tambahan kecuali yang disediakan oleh vendor database. Dalam lingkungan seperti itu, penggunaan database tertentu diasumsikan bahkan sebelum analisis berorientasi objek telah dimulai. Dengan demikian, siklus hidup perangkat lunak sering dimulai dengan penciptaan entitas-hubungan (ER) diagram yang dihasilkan sebagai dokumen persyaratan dengan pelanggan.


   Ini sering merusak, karena diagram ER akhirnya digunakan untuk menentukan persyaratan database; dan merinci struktur subsistem sebelum pemahaman dan pemodelan sistem menganggap bahwa dampak dari kebutuhan pelanggan yang sebenarnya pada desain sistem minimal.


   Pengumpulan persyaratan harus memungkinkan pengembang sistem untuk memahami kebutuhan pengguna untuk sejauh bahwa perilaku eksternal dari sistem solusi dipahami oleh pengguna sebagai kotak hitam dibayangkan, banyak sistem yang dibangun untuk memenuhi kebutuhan pengguna tanpa menggunakan database sama sekali. Namun, dengan Golden Hammer antipattern berlaku, kemungkinan seperti didiskontokan depan, yang mengarah ke setiap masalah menggabungkan elemen basis data.


   Seiring waktu, organisasi dapat mengembangkan beberapa produk database-centric yang bisa dilaksanakan sebagai sistem yang independen. Database berkembang menjadi dasar untuk interkoneksi antara aplikasi, dan mengelola distribusi dan akses bersama untuk data. Selain itu, banyak masalah pelaksanaan ditangani melalui menggunakan database fitur eksklusif yang berkomitmen migrasi masa depan untuk paralel pengembangan teknologi database implementasi.


   Di beberapa titik, mungkin perlu untuk beroperasi dengan sistem yang baik tidak berbagi arsitektur database-centric yang sama atau diimplementasikan menggunakan database yang berbeda yang mungkin tidak mengizinkan akses tak terbatas ke informasi mereka. Tiba-tiba, pengembangan menjadi sangat mahal karena unik, koneksi tujuan khusus dibangun untuk "jembatan" antara sistem yang unik. Namun, jika beberapa pemikiran diberikan kepada masalah sebelum situasinya menjadi terlalu jauh keluar dari tangan, kerangka kerja umum dapat dikembangkan, di mana produk-produk yang dipilih untuk daerah tertentu yang dipilih berdasarkan spesifikasi antarmuka standar, seperti CORBA, DCOM, atau TCP /AKU P.


Contoh lain adalah perusahaan asuransi dengan beberapa sistem cerobong asap warisan yang memutuskan di pindah ke client / server yang Microsoft Access harus menjadi bagian penting dari solusi untuk ketekunan. Seluruh front end dari sistem call center yang architected sekitar versi awal dari produk ini. Setelah itu, masa depan sistem sepenuhnya dibatasi oleh jalan pengembangan produk database karena keputusan arsitektur yang buruk. Tak perlu dikatakan, sistem berlangsung kurang dari enam bulan.


Solusi terkait
   Aliran lava. Antipattern ini terjadi ketika Golden Hammer antipattern diterapkan selama beberapa tahun dan banyak proyek. Biasanya, bagian yang lebih tua didasarkan pada versi sebelumnya dari Golden Hammer yang didelegasikan kepada terpencil, bagian yang jarang digunakan dari aplikasi secara keseluruhan. Pengembang menjadi enggan untuk memodifikasi bagian ini, yang membangun dari waktu ke waktu dan menambah ukuran keseluruhan aplikasi sementara melaksanakan fungsi yang jarang, jika pernah, digunakan 

oleh pelanggan.
   Vendor Lock-In. Vendor lock-in adalah ketika pengembang aktif menerima dukungan vendor dan dorongan dalam menerapkan Golden Hammer antipattern. Sebuah proyek software secara aktif berkomitmen untuk mengandalkan pendekatan vendor tunggal dalam merancang dan menerapkan sistem berorientasi objek.