Desain atau keputusan pemrograman yang paling Anda sesalkan? [Tutup]

57

Saya ingin mendengar keputusan desain seperti apa yang Anda ambil dan bagaimana hasilnya menjadi bumerang. Karena keputusan desain yang buruk, saya akhirnya harus mendukung keputusan buruk itu selamanya (saya juga punya bagian di dalamnya). Ini membuat saya sadar bahwa satu kesalahan desain tunggal dapat menghantui Anda selamanya. Saya ingin belajar dari orang yang lebih berpengalaman kesalahan apa yang telah mereka alami dan apa yang mereka pelajari dari mereka.

Saya yakin ini akan banyak membantu programmer lain dengan membantu mereka untuk tidak mengulangi keputusan itu.

Terima kasih telah berbagi pengalaman Anda.

VNarasimhaM
sumber
19
menghabiskan terlalu banyak waktu di SO !! ;)
Mitch Wheat
6
@ George: sepertinya tautan pertama Anda adalah tentang rekayasa berlebihan, yang bisa jadi terkait langsung dengan utas ini, tetapi itu bukan duplikat. Tautan kedua dan terakhir berkaitan dengan kesalahan pengkodean dan kesalahan manajemen, yang keduanya bukan merupakan duplikat dari utas ini.
Juliet
1
Ini mungkin harus dibuat menjadi wiki komunitas (ada kotak saat Anda mengedit posting).
3
Saya berharap ada cara untuk memilih untuk mengatasi penutupan. Turunkan suara penutupan?
Kieveli
5
Apa yang salah dengan semua pemilih tertutup? Jadi bagaimana jika itu bukan CW, biarkan penanya mendapatkan suara untuk mengajukan pertanyaan. Saya benar-benar tertarik dengan topik ini. Jangan biarkan CW menghalangi pertanyaan subyektif yang baik. Sheesh, SO penuh dengan screamers "CW INI".
syaz

Jawaban:

73

Mengabaikan YAGNI , lagi dan lagi ...

Jorge Córdoba
sumber
22
Benar untuk sebagian besar, tetapi ada juga orang-orang yang bisa menggunakan sedikit lebih sedikit YAGNI. Tidak ada yang ekstrim adalah tempat terbaik untuk menjadi.
Konsol 80x24
56

"Aku akan melakukannya nanti"
"Nanti" tidak pernah datang.

Duleb
sumber
8
Nanti tidak pernah datang.
Tidak pernah demikian.
Dikatakan, Jika Anda tidak punya waktu untuk melakukannya sekarang, apa yang membuat Anda berpikir Anda akan punya waktu untuk memperbaikinya nanti?
4
Kami menyebutnya "iterasi tidak pernah"
NotMe
10
Tidak ada yang permanen sebagai solusi sementara.
dietbuddha
52

C ++, beberapa warisan virtual berbentuk berlian . Anda mendapatkan idenya.

Kyralessa
sumber
19
Saya perlu membuat akun baru untuk mengunggah ini lagi ...
Kieveli
Ya ... pengalaman menyakitkan ...
Ed S.
Saya baru saja mengalami kilas balik jelek
Neil N
1
@ Mungkin itu sepertinya ide yang bagus saat itu.
6
Saya tidak tahu apa artinya itu, tetapi kedengarannya menyakitkan +1
The Disintegrator
44

Konfigurasi dalam aplikasi bagus. Terlalu banyak konfigurasi adalah mimpi buruk untuk digunakan dan dipelihara.

Travis Beale
sumber
2
Iya. Benar. Adalah idealisme untuk membuat semuanya dapat dikonfigurasi dan memberi tahu bos bahwa kita tidak perlu mengubah satu baris kode lagi.
1
Setelah menjadi pengguna yang malang terjebak dengan salah satu sistem yang sangat dapat dikonfigurasi untuk manajemen proyek kami, saya hanya bisa mengatakan, saya akan menjengkelkan Anda jutaan kali jika saya bisa.
HLGEM
Fleksibilitas yang berlebihan dalam konfigurasi biasanya karena Anda tidak dapat menjalankan kode arbitrer saat runtime, jadi Anda perlu mengantisipasi semuanya.
Ini disebut «spoftcoding» sebagai lawan dari «hardcoding»
deadalnix
42

Dari salah satu kesalahan saya, saya telah belajar bahwa normalisasi DB tidak boleh diikuti secara membabi buta. Anda bisa, dan dalam beberapa situasi Anda HARUS meratakan meja Anda.

Saya akhirnya mengelola banyak tabel (melalui model) dan kinerja tidak sebagus dengan sedikit meratakan tabel.

Eimantas
sumber
5
Saya sangat setuju ... Saya seorang insinyur perangkat lunak dan kami diminta untuk selalu menjadi normal. Dasar omong kosong. Itu hanya karena para guru belum mencoba bekerja dengan DB yang benar-benar kompleks dan bergantung pada kinerja.
8
Saya mungkin menambahkan bahwa normalisasi juga bisa sangat positif tentunya.
12
Saya pikir programmer terlalu cepat untuk melakukan denormalkan karena alasan yang tidak memadai, tetapi ya, kepatuhan terhadap aturan normalisasi adalah kesalahan besar. Secara umum, salah satu frustrasi besar saya dalam pengembangan perangkat lunak adalah ketika seseorang berkata "Kita harus melakukan X", dan ketika saya menunjukkan semua masalah ini akan menyebabkan, mereka menjawab, "Itu tidak relevan. Semua ahli sepakat bahwa X itu baik, karena itu kita harus melakukan X, selalu, tanpa pengecualian. "
4
Pendekatan saya terhadap normalisasi selalu jelas. Saya selalu menormalkan, TETAPI jika saya melihat potensi peningkatan kinerja pada sedikit perataan - saya selalu menguji dan mengukur dan dalam banyak kasus membayar untuk meratakan.
Eimantas
7
Tetapi normalisasi itu MENYENANGKAN! :) Saya serius, saya menikmati merancang struktur data. Apa yang akan saya katakan adalah bahwa sementara mudah untuk men-normalisasi skema yang dinormalisasi, kebalikannya TIDAK benar. Anda perlu TAHU aturan sebelum Anda melanggar mereka.
36

Menggunakan char tunggal dalam database untuk status, dll. Tidak ada gunanya sama sekali, overhead penggunaan char yang lebih lama () atau nvarchar2 () sangat kecil dibandingkan dengan jaringan dan penguraian yang ditimbulkan oleh panggilan SQL apa pun, namun karakternya selalu berakhir up agak dikaburkan, atau kehabisan (bukan karena status, tetapi hal-hal lain). Jauh lebih baik untuk hanya memasukkan versi yang dapat dibaca manusia, dan juga memiliki dalam model Java Anda (dalam kasus saya) enum dengan nilai yang cocok.

Saya kira ini adalah bentuk optimasi yang tidak perlu dan buta prematur. Seolah menggunakan satu arang akan menyelamatkan dunia hari ini. Terlepas dari Y / N booleans di database yang tidak mendukung booleans / bit.

Astaga
sumber
+1 Kami baru saja mengadakan pertemuan tentang masalah ini. Kami sampai pada kesimpulan yang sama.
APC
Bagaimana jika pelanggan Anda bekerja dengan singkatan seperti itu dan tidak ingin meninggalkannya?
Untuk sistem yang ada, Anda harus kompatibel (saya masih akan membuat Java enum dengan nilai yang tepat, dengan metode <code> MyEnum fromChar (char c) </code>) tentu saja. Untuk desain baru, jangan pergi ke sana!
Beberapa basis data mendukung enum, yang kompak dan mudah dibaca serta juga melayani nilai-nilai tak terduga yang terlarang dengan baik. Jika Anda bisa, gunakan itu.
Karl Bartel
2
Hampir sama buruknya: Menggunakan tipe BIT dalam MS SQL Server, sebelum menemukan bahwa itu tidak dapat menjadi bagian dari indeks.
finnw
32

Tidak mengembangkan Layer Akses Data yang tepat , dan memiliki sql di mana-mana dalam kode saya, hanya untuk mendapatkan sesuatu yang "cepat" dan berjalan. Kemudian, ketika proyek mulai berkembang, dan persyaratan berubah, itu menjadi mimpi buruk. Saya tidak tahu apa itu DAL saat itu.

... senang saya melewati itu, meskipun saya masih melihat programmer dengan 20 tahun pengalaman "" melakukan ini.

CitizenBane
sumber
16
Tidak ingat di mana saya membacanya, tetapi ada perbedaan antara 20 tahun pengalaman, dan satu tahun pengalaman berulang 19 kali.
CaffGeek
@ Chad: Itu ada di suatu tempat dalam tulisan Joel Spolsky.
+1: Yup. Dan coba refactoring semua logika yang terikat dalam SQL itu ... Entah itu inline, SQL bentuk bebas atau procs tersimpan. [Yup - Saya tidak takut dengan perang suci itu.]
Jim G.
26

Berpikir saya bisa menjadi Arsitek, Pengembang dan PM semua di proyek yang sama.

2 bulan tidur 3 jam malam mengajari saya Anda tidak bisa melakukannya.

Craig
sumber
15
Jadi berhentilah tidur! oh, tunggu ... maksudmu BUKAN itu normal ... ?? Hmm, saya harus membuat saya orang lain di proyek ini ...
AviD
Kedengarannya seperti PM-Anda perlu pelatihan dengan perkiraan :)
21

Memilih Microsoft Foundation Classes (MFC) untuk menulis IDE Java.

Oliver Weichhold
sumber
3
Owwww. Itu akan membuat otakku sakit.
Greg D
2
Itu bukan keputusan yang buruk pada tahun 1999. AWT jelek dan lambat saat itu.
finnw
finnw - well, setidaknya masih jelek!
Niklas H
20

Itu bukan keputusan saya (saya bergabung dengan perusahaan agak kemudian) tetapi di suatu tempat saya bekerja agak terlalu jauh, termasuk menerjemahkan semua pesan log mereka.

Hasil:

  • Lebih menyakitkan untuk menambahkan logging baru
  • Lebih banyak biaya untuk terjemahan
  • Log lebih sulit dibaca setelahnya

Ups.

Jon Skeet
sumber
Saya melakukan beberapa i18n di sini, dan mencoba mencari tahu apa yang masuk ke pengguna dan apa yang masuk ke log. Saya ingin semua output yang menghadap pengguna dapat dilokalisasi, tetapi saya ingin log tetap sama. Dalam prosesnya, saya harus melakukan lebih banyak mencari tahu di mana pengecualian terjadi daripada yang saya suka.
David Thornley
1
Biar saya tebak, orang Amerika Anda? Dan jika tidak, Anda hanya berbicara bahasa Inggris? Gunakan internasionalisasi di mana entri log baru dalam bahasa Inggris, jika bahasa lain tersedia Anda menampilkan bahasa pengguna. PETUNJUK: Menggunakan kode kesalahan membantu di sini karena itu berarti Anda selalu dapat grep / memindai log apa pun bahasanya.
2
@ Jacob: Saya orang Inggris, tetapi hanya berbicara bahasa Inggris. Tapi ini untuk perusahaan di mana seluruh basis teknik berada di Inggris, sehingga memiliki file log (yang untuk tujuan diagnostik, bukan informasi yang terlihat pengguna) dalam bahasa lain hanya akan membuang-buang sumber daya. Saya setuju bahwa menggunakan kode kesalahan alih-alih teks memungkinkan terjemahan langsung - tetapi ini masih lebih berhasil daripada hanya menggunakan satu bahasa saja. Ini masalah mengurangi pekerjaan dengan mengidentifikasi di mana sesuatu yang terdengar bermanfaat sebenarnya tidak akan memberikan nilai signifikan.
Jon Skeet
10
Saya orang Swedia. Saya harus mendapatkan abad pertengahan pada siapa pun yang bahkan menyarankan bahwa kode / komentar / log harus lebih dari bahasa Inggris. Bahasa Inggris adalah bahasa yang digunakan untuk segalanya kecuali antarmuka pengguna. Segala sesuatu yang lain hanya membuat kode sulit dibaca dan didiskusikan. Menggunakan bahasa asli itu konyol karena kerangka / pustaka lain yang Anda gunakan dalam bahasa Inggris.
jgauffin
1
+1 Bahasa Inggris adalah bahasa pemrograman. Setelah diterjemahkan hanya menempatkan lapisan tambahan di mana Anda membutuhkan sedikit lapisan dan kejelasan sebanyak mungkin.
20

Menemukan Kembali Roda

Shyju
sumber
19

Melakukan desain terlalu banyak . Membuat banyak diagram UML, terutama diagram Sequence untuk setiap operasi tunggal, yang sebagian besar pada akhirnya tidak berguna. Pada akhirnya ternyata sejumlah besar waktu dapat dihemat dengan melewatkan desain / diagram yang tidak perlu dan memulai pengkodean secara langsung.

Jahanzeb Farooq
sumber
Jika pertanyaannya adalah, "Apa keputusan desain atau pemrograman yang paling disesalkan yang pernah Anda buat?" sebagai lawan dari kesalahan yang kami buat sendiri, saya menempatkan "UML" di bagian atas daftar saya. Tepat di bawah "registri Windows".
2
UML bagus untuk didiskusikan di antara anggota tim, tetapi ketika sampai pada desain kemudian menerapkan sesuai dengan desain, itu selalu berakhir buruk. Ini adalah semacam impian beberapa perusahaan, tetapi sebenarnya, penulisan perangkat lunak secara definitif tidak berfungsi seperti itu. +1!
deadalnix
17

Pelanggan yang percaya tahu apa yang mereka inginkan dan kemudian melakukan terlalu banyak sebelum memeriksanya.

Anders
sumber
15

Keputusan desain terburuk saya? Kembali pada tahun 1980-an saya sedang mengerjakan sebuah proyek di mana kami mendapat ide cemerlang untuk membuat semacam templat untuk layar entri data kami yang akan ditafsirkan pada saat dijalankan. Bukan keputusan yang buruk: itu membuat layar input mudah dirancang. Pada dasarnya hanya membuat file yang menyerupai layar entri data, dengan beberapa kode khusus untuk mengidentifikasi apa yang merupakan label vs apa yang merupakan bidang input, dan untuk mengidentifikasi apakah bidang input alfa atau numerik. Kemudian saya memutuskan untuk menambahkan beberapa kode khusus ke file-file ini untuk mengidentifikasi validasi apa yang harus dilakukan. Kemudian saya menambahkan lebih banyak kode untuk memungkinkan pembangunan bersyarat layar, bidang X hanya termasuk ketika beberapa kondisi benar, dll. Kemudian saya menambahkan lebih banyak kode untuk melakukan beberapa pemrosesan input yang sederhana. Dll Akhirnya kami telah mengubah templat layar kami menjadi bahasa pemrograman baru, lengkap dengan ekspresi, struktur kontrol, dan pustaka i / o. Dan untuk apa? Kami melakukan banyak pekerjaan untuk menemukan kembali FORTRAN. Kami memiliki rak yang penuh dengan kompiler untuk bahasa yang dirancang lebih baik dan diuji lebih baik. Jika kami mencurahkan banyak upaya untuk membangun produk di mana kami benar-benar memiliki keahlian, perusahaan itu mungkin masih dalam bisnis saat ini.

Jay
sumber
Itu lucu dan tragis :)
Yang menyedihkan adalah bahwa pendekatan ini kadang-kadang cara terbaik untuk pergi. Pelanggan dapat memilih "layar dapat diubah pada saat itu juga" atau "layar melakukan segalanya termasuk membuat teh" tetapi tidak keduanya!
3
Saya tidak keberatan menggunakan template atau kode generik lainnya. Kesalahannya adalah mengubah sepotong kode generik menjadi bahasa-dalam-bahasa.
Saya telah melihat hal yang tepat ini dilakukan ... pada tahun 2004! Semua logika bisnis tersebar di sekitar lima belas tabel konfigurasi dengan beberapa upaya setengah matang pada "bahasa" dinamis yang dilemparkan ke dalam ukuran yang baik (lihat Aturan Kesepuluh Greenspun)!
1
Bukankah maksud Anda COBOL daripada FORTRAN?
finnw
15

Penerapan YAGNI yang terlalu bersemangat (yang disebut Desain oleh Pencacahan dalam Jebakan Pengembangan Berorientasi Objek ) di lingkungan di mana setiap orang yang berakal sehat dapat mengatakan bahwa persyaratannya pasti akan berubah. Dan berubah berulang kali.

Jika Anda (sulit) mengkodekan semuanya persis dengan persyaratan saat ini — sembari mengalahkan siapa pun yang mengatakan "tidak bisakah ini lebih generik?" dengan palu YAGNI Anda — dan kemudian persyaratannya berubah secara drastis (tetapi dengan cara yang bisa diantisipasi secara wajar), maka itu bisa menjadi perbedaan antara mengambil 2 minggu untuk beradaptasi, vs mengambil 20 menit.

UPDATE: Untuk memperjelas, ini adalah contoh fiktif yang tidak terlalu jauh dari apa yang terjadi. Stack Overflow dirancang untuk mendukung lencana, tetapi anggaplah mereka hanya bisa memikirkan empat lencana pada awalnya. Hanya empat, jumlah yang sangat kecil, sehingga mereka membuat hardcode dukungan untuk empat lencana di seluruh logika di situs. Dalam database, di info pengguna, di semua kode tampilan. Karena "Kamu tidak akan membutuhkan" lencana yang tidak bisa kamu pikirkan, kan? Misalkan kemudian situs itu ditayangkan, dan orang-orang mulai menyarankan lencana baru. Setiap lencanaperlu waktu hingga dua minggu untuk menambahkan, karena ada banyak hardcoding yang bisa diubah di semua tempat. Tapi tetap saja, "Ya tidak akan perlu" lencana lebih dari daftar hari ini, jadi tidak pernah ada refactoring untuk mendukung koleksi umum lencana. Apakah koleksi generik seperti ini akan membutuhkan waktu lebih lama? Tidak banyak, jika ada.

YAGNI adalah prinsip yang berharga, tetapi seharusnya tidak (ab) digunakan untuk memaafkan desain yang buruk dan hardcoding yang tidak pantas. Ada keseimbangan, dan dengan pengalaman, saya yakin saya sedang mendekatinya.

Konsol 80x24
sumber
1
Ya dan tidak, dapatkah Anda memprediksi arah mana yang akan berubah? Saya memiliki pengalaman sistem rumit yang terbukti sangat tidak memadai untuk penggunaan kembali pertama, yang tidak sesuai dengan kemurahan hati yang diprediksi ...
Benjol
^ ya, saya lebih suka berurusan dengan YAGNI daripada omong kosong itu.
Jadi Anda pikir Anda harus menghabiskan 2 minggu di muka?
finnw
4
Contoh itu sama sekali bukan YAGNI. KERING adalah bagian dari YAGNI, dan tanpanya Anda tidak dapat tetap responsif terhadap perubahan.
3
Stephan, contohnya menunjukkan ungkapan frasa yang kasar dan tidak tepat, yang merupakan poin saya. KERING (dengan varian OAOO) juga merupakan prinsip yang baik, tetapi cukup terpisah: c2.com/cgi/wiki?OaooBalancesYagni . Namun, saya tidak dapat menemukan apa pun di mana pun untuk mendukung klaim Anda bahwa "KERING adalah bagian dari YAGNI." Mustard cocok dengan hotdog, tetapi itu tidak berarti mustard adalah bagian dari hotdog. Jika Anda bisa mengklarifikasi, mungkin dengan referensi, mungkin saya akan mengerti.
Konsol 80x24
15

Sumber daya manusia yang tidak kompeten

Mencoba membuat sesuatu yang benar dan hebat dengan orang yang salah!
Bahkan jika mereka dalam peran sebagai PM ego berlebihan (yang agak terlalu umum terutama di perusahaan besar di mana ketidakmampuan mereka dapat bertahan untuk waktu yang lebih lama).

Robert Koritnik
sumber
1
Saya mengerti rasa sakit Anda :(
13

Setiap kali saya membuat hutang teknis, menulis kode prosedural, melewati tes menulis, dll karena saya terburu-buru. Hampir tak terelakkan saya menemukan ini menciptakan rasa sakit bagi saya di jalan.

TrueWill
sumber
13

Menggunakan SQL Server Intergration Services (SSIS).

Saya tidak berharap itu pada musuh terburuk saya.

Setelah membangun beberapa paket SSIS selama dua bulan terakhir, hanya untuk mengetahui bahwa paket yang saya kembangkan tidak dapat didistribusikan & dan tidak dapat dipekerjakan. Khususnya di lingkungan berlisensi non-web, bukan SQL Server.

Ini adalah situasi yang sangat buruk, ketika Anda memiliki kurang dari 48 jam untuk menulis ulang paket SSIS Anda dalam kode POCO .NET murni atau melewatkan tenggat waktu yang ditargetkan.

Saya heran bahwa saya bisa menulis ulang tiga paket SSIS (yang membutuhkan waktu dua bulan untuk menguji dan mengembangkan), dalam waktu 12 jam dalam kode .NET murni, dengan OLEDB Adapters dan SQL Adapaters.

SSIS tidak dapat didistribusikan dan tidak akan menjalankan paket dari mesin klien jika tidak memiliki lisensi SQL Server yang diinstal di atasnya (Khususnya DTSPipeline.dll). Ini bagus untuk diketahui di muka. Saya melihat disclaimer sekarang (dalam cetakan kecil) di MSDN. Itu tidak ada gunanya ketika Anda memiliki contoh kode di seluruh internet menggunakan kode hanya mesin SQL-LICENSED. Pada dasarnya, Anda harus membuat layanan web yang akan berbicara dengan server SQL Anda, untuk menjalankan paket SSIS Anda secara terprogram. Anda tidak dapat menjalankannya dari kode .NET murni, kecuali jika Anda memiliki lisensi SQL yang diinstal pada mesin yang menjalankan. Seberapa tidak realistis itu? Apakah Microsoft benar-benar mengharapkan SSIS untuk digunakan dari mesin yang memerlukan instalasi SQL server? Benar-benar buang-buang waktu dua bulan.

Perusahaan saya tidak akan pernah lagi menggunakan SSIS karena tulisan "gotcha" kecil ini.

D3vtr0n
sumber
Mungkin Anda harus menghindari menggunakan perangkat lunak "cetak" sama sekali! Talend misalnya adalah IDE ETL open-source.
+1: Yup. Pengalaman pengembangan SSIS juga merupakan mimpi buruk. Mungkin ada setidaknya setengah lusin cara yang lebih baik untuk melakukan ETL.
Jim G.
11

Tidak mendefinisikan mekanisme / model penyebaran sedini mungkin.

Austin Salonen
sumber
10

Melemparkan beberapa telur paskah 'lucu' ke dalam beberapa kode yang saya tulis sebelum pergi berlibur selama 2 minggu. Saya pikir saya akan menjadi satu-satunya orang yang membacanya ketika saya kembali, itu akan membuat saya tertawa dan siap untuk menulis ulang kode itu.

Tidak perlu dikatakan, bos saya tidak terkesan ketika dia memeriksanya saat saya pergi, dan dia bahkan kurang terkesan ketika salah satu 'telur paskah' melibatkan wajahnya yang lucu di kartun ASCII.

Mmmmmm ...

Daniel May
sumber
1
IMO, itu "Kerja bagus Pak!"
18
Baru-baru ini, saya diejek oleh tim saya untuk melacak pesan seperti, "tambah tabel nilai mereka!" Saya bilang lihat, mereka membuat saya bekerja di Talk Like A Pirate Day, mereka pantas mendapatkan apa yang mereka dapatkan.
3
Arr, loggs Anda sedang mencari keel'haulin!
10

Menggunakan Tema ASP.Net ketika folder CSS biasa hanya akan baik-baik saja.

Phil.Wheeler
sumber
Lol pada itu, ya!
1
Jawaban ini dapat disingkat menjadi "Menggunakan ASP.NET"
finnw
Skin berguna untuk mengatur CssClass default.
Min
8

Mengambil jalan cepat untuk membuat beberapa kode berfungsi, bukan jalan yang benar (agak umum, tetapi kami akan menyebutnya abstraksi dan karena itu jawaban yang 'benar').

Padi
sumber
7

Perusahaan saya memiliki model pengembangan seperti air terjun, di mana pengguna bisnis dan analis bisnis kami akan menentukan persyaratan untuk proyek. Pada salah satu proyek "besar" kami, kami mendapat setumpuk persyaratan, dan saya perhatikan sejumlah persyaratan berisi detail implementasi , khususnya informasi yang berkaitan dengan skema basis data kami yang digunakan oleh sistem akuntansi kami.

Saya berkomentar kepada pengguna bisnis bahwa implementasi adalah domain saya , seharusnya tidak tercantum dalam persyaratan. Mereka tidak mau mengubah persyaratan mereka karena, bagaimanapun, mereka adalah BISNIS, dan hanya masuk akal bagi akuntan untuk merancang perangkat lunak akuntansi. Sebagai pengembang rendahan yang terlalu jauh dalam jajak pendapat totem, saya dibayar untuk melakukan alih - alih berpikir . Sebanyak yang saya perjuangkan, saya tidak bisa membujuk mereka untuk menulis ulang persyaratan - ada terlalu banyak dokumen dan birokrasi di sekitar perubahan yang terlalu merepotkan.

Jadi, saya memberi mereka apa yang mereka minta. Paling tidak, ini agak berfungsi , tetapi database dirancang dengan aneh:

  • Banyak normalisasi yang tidak perlu. Catatan tunggal yang berisi 5 atau 10 bidang dibagi menjadi 3 atau 4 tabel. Saya bisa mengatasinya, tetapi secara pribadi saya ingin semua bidang 1: 1 ditarik ke dalam satu tabel.

  • Banyak denasionalisasi yang tidak pantas. Kami memiliki tabel yang menyimpan data faktur yang menyimpan lebih dari data faktur. Kami menyimpan sejumlah flag lain-lain dalam tabel InvoiceData, bahkan jika flag tersebut tidak terkait secara logis dengan tabel InvoiceData, sehingga setiap flag memiliki nilai kunci Primary yang di-hardcoded dan semua bidang lainnya dibatalkan dalam tabel InvoiceData. Karena bendera direpresentasikan sebagai catatan dalam tabel, saya menyarankan menarik bendera ke tabelnya sendiri.

  • Banyak lagi denasionalisasi yang tidak pantas. Flag aplikasi-lebar tertentu disimpan sebagai kolom dalam tabel yang tidak pantas, sehingga mengubah flag aplikasi memerlukan pembaruan setiap catatan dalam tabel.

  • Kunci primer berisi metadata, sehingga jika kunci utama varchar diakhiri dengan "D", kami menghitung faktur menggunakan satu set nilai, jika tidak kami menghitungnya dengan set lain. Akan lebih masuk akal untuk menarik metadata ini ke dalam kolom terpisah, atau menarik himpunan nilai untuk dihitung ke dalam tabel lain.

  • Kunci asing sering kali mengarah ke lebih dari satu tabel, sehingga kunci asing yang diakhiri dengan "M" dapat ditautkan ke tabel akun hipotek kami, sedangkan kunci asing yang diakhiri dengan "A" mungkin menautkan ke tabel akun otomatis kami. Akan lebih mudah untuk membagi data menjadi dua tabel, MortageData dan AutoInsuranceData.

Semua saran saya ditembak jatuh dengan banyak ratapan dan kertakan gigi. Aplikasi ini berfungsi seperti yang dirancang, dan sementara itu adalah bola lumpur yang besar, semua peretasan jahat, kasing khusus, dan aturan bisnis aneh didokumentasikan secara sarkastik dan lucu dalam kode sumber.

Juliet
sumber
3
Ya ampun, semoga CV Anda bagus dan terkini untuk pelarian cepat sebelum bola besar lumpur menyerah pada gravitasi!
Benjol
7

Berpegang teguh pada teknologi yang lebih lama karena tampaknya terlalu merepotkan untuk membiarkan klien Anda memutakhirkan ke versi .NET framework baru, tetapi sebenarnya akan membutuhkan lebih banyak waktu pengembangan untuk membuat perangkat lunak karena Anda tidak dapat memanfaatkan beberapa komponen (hemat waktu) dari versi kerangka kerja yang lebih baru.

Tom van Enckevort
sumber
+1: Yup - Saya pernah ke sana ... Dan segera setelah saya menyadari bahwa n00b tidak akan ditingkatkan, saya mulai merencanakan pelarian saya ke padang rumput yang lebih hijau.
Jim G.
Dan begitulah, baru pensiun bulan depan!
tanaman merambat
6

Kembali di universitas saya sedang mengerjakan proyek desain senior saya. Pria lain dan saya sedang menulis sistem pelacakan bug berbasis web. (Tidak ada yang inovatif, tetapi kami berdua ingin mendapatkan pengalaman web.) Kami melakukan hal itu dengan Java servlets, dan itu bekerja dengan cukup baik, tetapi untuk beberapa alasan konyol, alih-alih memilih untuk menggunakan Pengecualian sebagai mekanisme penanganan kesalahan kami, kami memilih untuk menggunakan kode kesalahan.

Ketika kami mempresentasikan proyek kami untuk nilai dan salah satu staf pengajar bertanya, "Jika Anda harus melakukannya lagi, apa yang akan Anda lakukan secara berbeda?" Saya langsung tahu jawabannya: "Saya akan menggunakan pengecualian, untuk itulah mereka ada di sana."

Greg D
sumber
Ahhh, kegembiraan karena menciptakan kembali roda! :-) Itu lucu.
Saya menyebutnya cacat disengaja, hanya agar Anda dapat memperbaikinya di iterasi berikutnya.
whatnick
2
Pengecualian hanya untuk menangani pengecualian. Terlalu banyak orang menyalahgunakan pengecualian dengan mengubah segalanya menjadi pengecualian.
@ jacob - Saya setuju dengan sentimen Anda bahwa pengecualian harus digunakan untuk hal-hal yang dapat Anda prediksi (yaitu kondisi luar biasa) tetapi dari apa yang saya lihat (dan bukan menjadi programmer Java) Java tampaknya menggunakan pengecualian untuk semua yang ada di bawah matahari. Jadi tidak menggunakan pengecualian dalam kode Java dapat dianggap bertentangan dengan aliran bahasa.
6

Bukan pilihan metode saya, tetapi menciptakan XSLT untuk mengonversi file XML berbasis baris menjadi laporan HTML berbasis kolom.

Ini hanya bekerja di IE, benar-benar mustahil untuk memecahkan kode cara kerjanya. Setiap kali kami perlu mengembangkannya, sangat sulit dan butuh waktu lama.

Pada akhirnya, saya digantikan oleh skrip C # kecil yang melakukan hal yang sama.

JDunkerley
sumber
Saya sudah melakukannya juga. Saya menerapkan mesin templating email menggunakan XSL dan merasa sulit untuk membaca dan memelihara.
TrueWill
Ya. Mengganti pohon besar file XSLT seseorang dengan beberapa fungsi VB.NET sederhana. Sangat memuaskan, terutama ketika permintaan perubahan pelanggan berikutnya yang datang tidak mungkin dilakukan di XSLT.
Saya telah menemukan bahwa sebagian besar programmer menganggap XSLT pilihan yang buruk, hanya karena mereka tidak mendapatkannya . Ini sangat berguna untuk sejumlah kecil masalah, jauh lebih efisien daripada banyak solusi lainnya. Di sisi lain, itu digunakan CARA terlalu sering, dan sebagian besar BUKAN dalam set kecil masalah ...
AviD
6

mencoba menggunakan semua teknologi baru (untuk mempelajari teknologi baru) meskipun itu bahkan memerlukan ..

oscar
sumber
5

Saya tidak mengambil cukup waktu untuk menilai model bisnis. Saya melakukan apa yang diminta klien, tetapi 6-12 bulan kemudian kami berdua sampai pada kesimpulan bahwa hal itu seharusnya dilakukan secara berbeda.

OMG Ponies
sumber
4

Merancang tanpa spesifikasi.

Sam
sumber
3
Spesifikasi tidak selalu mungkin
Seharusnya "Menerapkan solusi tanpa bertanya kepada pelanggan apakah itu yang mereka inginkan"; yang biasanya berarti Anda mengikuti spesifikasi.
dietbuddha
3

Saya menerapkan sub-bagian aplikasi sesuai dengan persyaratan.

Ternyata persyaratannya kembung dan berlapis emas, dan kode saya dirancang berlebihan. Seharusnya saya merancang sub-bagian saya hanya untuk bekerja dengan apa yang saya tambahkan pada saat itu, tetapi berencana untuk menambahkan semua hal lainnya tanpa menyertakan dukungan umum untuk itu sejak awal.

Kieveli
sumber