Tunjukkan kode buruk ke klien?

Seorang klien meminta saya untuk mendesain ulang situs web mereka, aplikasi ASP.NET Webforms yang dikembangkan oleh konsultan lain. Sepertinya pekerjaan yang relatif mudah, tetapi setelah melihat kode, jelas bukan itu masalahnya.

Aplikasi ini tidak ditulis dengan baik. Sama sekali. Ini sangat rentan terhadap serangan injeksi SQL, logika bisnis tersebar di seluruh aplikasi, ada banyak duplikasi, dan kode jalan buntu yang tidak melakukan apa-apa. Di atas semua itu, ia terus melempar pengecualian yang disiram, sehingga situs tampaknya berjalan dengan lancar.

Pekerjaan saya hanyalah memperbarui HTML dan CSS, tetapi sebagian besar HTML dihasilkan dalam logika bisnis dan akan menjadi mimpi buruk untuk diselesaikan. Perkiraan saya pada desain ulang lebih lama dari yang diinginkan klien. Mereka bertanya mengapa begitu lama.

Bagaimana saya bisa menjelaskan kepada klien saya betapa buruknya kode ini? Dalam pikiran mereka, aplikasi ini berjalan dengan baik dan desain ulang harus cepat sekali. Ini kata-kata saya terhadap konsultan sebelumnya. Bagaimana saya bisa memberikan contoh sederhana dan konkret yang akan dipahami oleh klien non-teknis?

Memperbarui

Terima kasih atas semua tanggapannya. Demonstrasi serangan injeksi SQL masuk akal dan saya akan demo ini dalam lingkungan uji. Itu hanya satu bagian dari banyak masalah dalam aplikasi ini. Saya sedang mencari cara untuk menjelaskan mengapa bagian lain (seperti html yang dihasilkan di lapisan data) perlu diganti dengan praktik yang lebih baik agar pembaruan html dan css terjadi. Ada banyak saran bagus di sini yang akan saya kumpulkan ketika saya berbicara dengan klien saya.

Non-techies bukan idiot (sebagian besar). Mereka dapat memahami argumen teknis jika Anda menyimpannya cukup tinggi. Pilih tugas yang menurut Anda harus sederhana, dan tunjukkan mengapa tidak.

Saya berharap perubahan ini menjadi satu kata dalam satu file. Tempat yang paling mungkin untuk mengubahnya sepertinya ada di sini, tetapi ketika saya mengubahnya di sana, itu hanya berfungsi di satu tempat, dan itu menghancurkan 7 tempat lainnya. Ketika saya memperbaiki satu, itu pecah dua tempat lagi, menyebabkan efek domino, jadi perubahan yang saya pikir seharusnya memakan waktu 10 menit akhirnya memakan waktu 2 jam. Itu hanya satu contoh. Ada banyak tugas 2 jam yang tidak terduga di sana.

Struktur kode, gaya, hutang teknis adalah satu hal yang - setidaknya pada awalnya, sampai klien mempercayai Anda - Anda harus hidup bersama.

Kerentanan keamanan adalah masalah lain.

Secara pribadi, saya akan melakukan estimasi berdasarkan pekerjaan yang diperlukan menggunakan struktur dan gaya yang ada sambil menjelaskan bahwa ada masalah signifikan dengan basis kode. Saya akan meningkatkan implikasi keamanan secara terpisah: melakukan demonstrasi peretasan pada basis data untuk mengarahkan poin pulang selama pertemuan.

Saya sangat senang melakukan ini dengan klien sebelumnya dengan sistem kartu hadiah loyalitas ketika saya menaruh £ 5000 pada kartu "saya" dan menyuruhnya memeriksa kartu itu di kasirnya.

Beberapa saran bagus di sini tentang cara menyampaikan dan mengomunikasikan hal ini kepada klien. Semoga mereka akan membayar untuk Anda.

Bendera merah utama di sini!

Jika klien meminta Anda untuk tidak melakukan perubahan apa pun selain dari apa yang telah Anda setujui (HTML dan CSS), saya akan meneruskan proyek ini dan menarik tawaran saya.

Bahkan dengan tinjauan tertulis dan dikomunikasikan dengan baik dari semua kelemahan dan masalah keamanan, kewajiban potensial terlalu besar bagi saya untuk merasa nyaman. Bahkan jika klien tidak pernah mengambil tindakan hukum atau menuntut perbaikan setelah peretasan atau pelanggaran; nama dan reputasi Anda masih melekat pada karya!

Anda mungkin kehilangan jauh lebih banyak daripada yang bisa Anda dapatkan.

Jelaskan dan mungkin tunjukkan cacat
itu. Jika itu adalah kata-kata Anda, itu semua yang Anda katakan hanya udara panas sejauh yang mereka ketahui. Setelah Anda menunjukkan kepada mereka bagaimana aplikasi mereka dapat disalahgunakan melalui injeksi SQL, maka tiba-tiba Anda adalah orang yang bisa dipercaya. Anda akan membutuhkan kredibilitas untuk melakukan negosiasi ulang. Dan ini cukup pengubah permainan untuk memberikannya kepada Anda.

Beramallah sehubungan dengan pendahulu Anda.
Itu tidak berarti berpura-pura bahwa kesalahan tidak ada, tetapi jika Anda merasa direndahkan maka Anda kehilangan kredibilitas. Jangan katakan sepatah kata pun tentang programmer kecuali mungkin untuk memberinya manfaat dari keraguan. Fokus pada kode, bukan koder. Membuat mereka merasa bahwa Anda adalah "orang baik" akan memberi Anda lebih banyak waktu luang dalam negosiasi. Dan "orang baik" tidak pernah mengatakan hal-hal jahat. Ketika menjelaskan kesalahan keamanan yang ada (seperti kerentanan injeksi SQL) ke klien, saya lebih suka mengatakan sesuatu seperti ini:

Keamanan aplikasi web adalah bidang yang berkembang pesat. Banyak alat dan teknik pengembangan yang dipelajari orang bahkan hari ini berkembang sebelum sebagian besar eksploitasi ini dipahami dengan baik. Agar tetap terdepan dalam perkembangan keamanan, Anda harus mengikuti bidang ini dengan sangat dekat dan kadang-kadang bahkan mengubah seluruh gaya pengembangan Anda. Kebanyakan programmer tidak melakukan ini.

Itu dia. Bukan kata-kata jahat yang diucapkan tentang pengembang; dia hanya "kebanyakan programmer" yang berarti dia berada di perusahaan yang cukup bagus. Dan sekarang Anda telah menunjukkan bahwa Anda bukan "kebanyakan programmer" yang memberi Anda kredibilitas sedikit lebih dan mungkin alasan bagi mereka untuk membayar Anda lebih banyak uang.

Negosiasikan pengaturan baru
Setelah klien memahami bahwa aplikasinya terbuka untuk disalahgunakan oleh publik, dia akan menginginkannya diperbaiki. Anda mungkin adalah orang yang akan dimintanya untuk memperbaikinya. Anda mungkin atau mungkin tidak menginginkan pekerjaan itu, jadi pikirkan baik-baik sebelum Anda berbicara dengan mereka.

Paling tidak, Anda ingin lebih banyak waktu untuk menyelesaikan pekerjaan yang telah mereka berikan kepada Anda. Anda telah cukup membuat mereka lengah dengan hal-hal kerentanan yang mereka mungkin tidak akan menahan Anda untuk perkiraan awal Anda. Tetapi pastikan klien tahu siapa Anda dan tidak akan memperbaiki sebagai bagian dari pengaturan ini.

Biasanya pengembang (Anda) lebih suka mengulang semuanya dari awal. Dan dalam kasus seperti ini, itu bahkan bisa menjadi pilihan. Tetapi bahkan kemudian, klien akan menginginkan sesuatu yang dapat menjaga bisnisnya berjalan sampai aplikasi baru dibangun. Ini berarti bahwa meskipun Anda memulai dari awal, Anda mungkin masih harus sedikit memperbarui aplikasi lama.

Saya memulai ini sebagai komentar, karena pada awalnya saya pikir itu samping, tapi mungkin sebenarnya tidak.

Saya sepenuhnya akan mendokumentasikan segala sesuatu yang menurut Anda harus dirancang ulang, dan mengapa (apa yang terjadi jika mereka tidak melakukan perubahan), dan perkiraan untuk memperbaiki masalah tersebut. Saya akan sangat teliti dengan apa pun yang Anda anggap sebagai risiko keamanan.

Saya akan melakukan ini sebelum menyentuh kode apa pun , dan pastikan bahwa klien Anda memiliki salinan laporan ini, lebih disukai dengan semacam cap waktu. Mungkin butuh waktu, tetapi juga akan melindungi Anda jika salah satu dari risiko keamanan ini membuahkan hasil. Bahkan lebih baik jika Anda bisa mendapatkan sesuatu yang ditandatangani yang mengatakan bahwa mereka menerima dokumen.

Tentu, Anda dapat mengarahkan kontrol sumber ke kode asli yang Anda warisi jika itu memang terjadi, tetapi akan jauh lebih mudah untuk menunjuk ke dokumen ini dan berkata, dengan cara yang lebih profesional, "Lihat? Sudah saya katakan."

Dokumen ini dapat menjadi titik awal diskusi lebih lanjut, dan bahkan dapat digunakan oleh klien Anda untuk mendapatkan "orang yang tepat" untuk memberikan izin untuk melakukan beberapa atau semua perubahan.

Yang sedang berkata, begitu klien memahami risiko, menyeringai dan menanggungnya jika mereka mengatakan untuk melakukan pekerjaan itu, atau pergi.

Ingatlah bahwa klien akan meminta bantuan Anda untuk menjaga aplikasi mereka. Adalah tugas Anda sebagai seorang profesional untuk menunjukkan masalah yang Anda temukan dengan aplikasi mereka. Klien sepertinya tidak tahu masalah ini ada dan mereka harus disadarkan. Jelaskan masalah ini dengan cara yang dapat mereka pahami dan biarkan mereka memutuskan bagaimana mereka ingin melanjutkan.

Gunakan contoh dunia nyata untuk menggambarkan masalah ini, seperti mobil mogok atau mesin cuci yang perlu diperbaiki. Intinya adalah menggunakan contoh-contoh yang sudah mereka kenal. Untuk menjelaskan injeksi SQL, saya hanya akan menunjukkan apa itu dan mengapa itu menjadi masalah.

Pada akhirnya Anda ingin menyampaikan bahwa Anda peduli akan keberhasilan aplikasi yang diminta untuk Anda kerjakan.

Saya suka menggunakan analogi yang bisa dihubungkan dengan klien. Jumlah pekerjaan yang saya lakukan dimuka dalam memenangkan pekerjaan akan tergantung pada jumlah uang yang ingin dihabiskan klien ($ 100 jauh berbeda dari $ 20.000). Perhatikan saya katakan "berniat". Estimasi pribadi Anda tentang nilai yang terlibat tidak banyak berarti jika Anda tidak mendapatkan apa yang Anda minta.

Dalam situasi Anda - sekali lagi tergantung pada uang - saya mungkin menggambar kotak dengan satu garis keluar dari masing-masing sisi dan berkata kepada klien "Ini adalah bagaimana Anda memvisualisasikan perangkat lunak sekarang. Data masuk di satu ujung dan keluar di sisi lain, semua terlihat bagus dan bersih dan sederhana ". "Ini adalah perangkat lunak yang menurut Anda terlihat seperti di dalam" dan kemudian gambar garis ketiga yang menghubungkan dua garis di dalam kotak.

Lalu saya menggambar kotak lain sama seperti yang pertama dengan jalur input dan output di luar, kecuali kali ini saya akan mengatakan "Inilah yang terlihat seperti perangkat lunak di dalam kotak sekarang." dan kemudian untuk menghubungkan dua garis kali ini saya akan menggambar tumpukan acak spaghetti, mungkin dengan istirahat dan bergabung dan coretan.

Akhirnya saya akan berkata, "Sekarang yang Anda minta saya lakukan adalah ini ..." dan menggambar bentuk sederhana di dalam kotak pertama mungkin setengah lingkaran kecil menyentuh garis dan kemudian berkata "tetapi untuk melakukan itu, saya ' Saya harus melakukan ini ... "dan menggambar tornado yang tampak seperti bentuk spiral di sekitar garis dan melanjutkan ..." untuk mengatasi semua ini ..... "dan arahkan ke spageti di kotak lain.

Saya akan berpikir bahwa akan mengarahkan titik pulang dalam waktu sekitar 2 menit. Jika mereka bersikeras Anda tetap melakukannya, maka dokumentasikan seperti yang disebutkan di atas.

Bagaimana saya bisa menjelaskan kepada klien saya betapa buruknya kode ini?

Mungkin Anda dapat menggunakan analogi seperti pipa ledeng di sebuah rumah yang seiring waktu, setelah perbaikan dan remodel, menjadi sangat tidak pasti dan digabungkan sehingga ketika memperbaiki satu hal, memengaruhi dan mungkin merusak sesuatu yang lain yang kemudian perlu diperbaiki dan tidak ada cara bagi Anda untuk mengetahuinya semua tempat yang ini akan terjadi.

Ini kata-kata saya terhadap konsultan sebelumnya, jadi bagaimana saya bisa benar-benar memberikan contoh sederhana dan konkret yang akan dipahami oleh klien non-teknis?

Anda benar, itu bertentangan dengan visual apa pun yang dibuat oleh konsultan sebelumnya di kepala mereka. Saran saya adalah melakukan apa yang Anda minta, memberikan contoh sederhana dan konkret. Karena ini adalah desain ulang, perlihatkan bagaimana sebuah fragmen HTML yang didefinisikan dalam kode yang dikompilasi ditampilkan dengan sisa halaman HTML dan bagaimana perubahan yang mempengaruhi atau tidak, sisa halaman. Mungkin kode terkompilasi yang sama membuat markup setelah menerapkan beberapa aturan "bisnis". Tunjukkan perbedaannya.

Ini adalah masalah yang sulit dan SANGAT umum. Semoga beruntung.

Jujur dan jujur.

Tetapi yang paling penting jangan mengambil pekerjaan yang tidak akan memenuhi harapan Anda. Kebanyakan orang tidak menyadari bahwa seorang kontraktor dapat memecat seorang klien, mereka dapat dan harus jika pekerjaan itu lebih banyak masalah daripada nilainya.

Inilah analogi yang telah saya gunakan (walaupun saya tidak menjamin keefektifannya): Bayangkan situs web mereka adalah mesin fisik, seperti mesin cetak mekanik yang entah bagaimana menerima input.

Mereka mungkin menganggap mesin tersebut memiliki komponen yang melakukan X dan yang lain yang melakukan Y. Pada kenyataannya, itu adalah 20 atau lebih mesin yang kebanyakan mirip. Beberapa dari mereka tidak lagi melakukan apa-apa, semuanya berusaha membentuk fungsi yang sudah dilakukan orang lain dan tidak ada seorang pun selain konsultan sebelumnya yang pernah melihat sesuatu yang persis seperti mereka sebelumnya.

"Lihat alat ini di sini yang mem-parsing variabel posting dan kemudian mengirimkan komponen ini ke lubang kelinci jika-elses? Tidak hanya ada satu ini, ada satu di setiap halaman (atau apa pun), beberapa dari mereka membersihkan input dan beberapa tidak (atau semua tidak) dan tanpa membaca semuanya saya tidak tahu yang mana. "

Satu hal yang belum benar-benar disebutkan adalah bahwa Anda mungkin hanya melangkahi apa yang sebenarnya diinginkan klien Anda dari Anda dalam kasus ini. Overachieving itu bagus dan bisa memberi Anda banyak kepuasan kerja. Tetapi jika klien tidak peduli, mengira kinerja saat ini "cukup baik" dan hanya menginginkan beberapa pembaruan kecil, mungkin tidak mungkin untuk membujuk mereka untuk melakukan investasi besar pada Anda untuk memeriksa basis kode.

Pada titik itu, Anda mungkin perlu memutuskan apakah akan berpegang pada prinsip dan menolak untuk mengambil pekerjaan yang akan memaksa Anda untuk melampirkan nama baik Anda pada kekacauan kode yang memalukan atau apakah Anda dapat menahan diri, masuk, menyelesaikan pekerjaan dengan beberapa lakban, dan keluar dengan pembayaran Anda.

Jika Anda memutuskan untuk melanjutkan pekerjaan lakban, pastikan untuk mendokumentasikan, mendokumentasikan, mendokumentasikan, dan setransparan mungkin. Hal terakhir yang Anda inginkan adalah disalahkan atas kesalahan yang terjadi di masa depan yang merupakan akibat dari kesalahan aplikasi yang Anda peringatkan kepada klien, tetapi klien memutuskan tidak cukup penting untuk ditangani saat itu.

Sejauh risiko injeksi SQL pergi, seperti yang orang lain katakan Anda harus dapat menunjukkan bahaya itu kepada mereka dengan cara yang menunjukkan risiko tanpa benar-benar melakukan sesuatu yang merusak dalam produksi. Tetapi sekali lagi, jika mereka melihatnya dan tidak cukup peduli untuk membayar Anda untuk memperbaikinya, Anda telah melakukan ketekunan dengan niat baik dalam kasus ini.

Ini adalah saus noob untuk datang ke suatu proyek dan menyarankan penulisan ulang hal pertama, melakukan beberapa bagian kecil dari modifikasi dan menggunakannya untuk menggambarkan betapa jauh lebih sederhana dan lebih murah itu bisa . Maka Anda memiliki kasus yang dapat diperlihatkan tentang mengapa peningkatan biaya pengembangan yang lebih bersih akan mengarah pada biaya perawatan yang lebih rendah dan pengembangan yang lebih cepat dalam jangka panjang mengingat sedikit biaya sisi font.

Jangan pernah lupa bahwa pada dasarnya Anda meminta mereka untuk membayar Anda untuk membuat hidup Anda lebih mudah, dalam pikiran mereka hanya perlu menemukan 'pria' yang dapat X fitur dengan biaya Y dan memperbesar kompleksitas proyek Anda mungkin hanya menghilangkan peluang untukmu. Ini adalah jalan yang sulit ketika Anda sebulan menulis ulang dan Anda bertemu dengan pengembang asli hanya untuk menyadari seluruh aplikasi ditulis dalam jendela yang sangat dikontrak oleh pengembang yang sepenuhnya memahami semua kompromi yang dibuat. Jika aplikasi secara internal terlihat mengerikan tetapi berfungsi secara eksternal dengan baik, seperti yang Anda katakan, sangat mungkin ini akan terjadi. Seringkali hutang teknis dalam basis kode adalah produk dari kendala sumber daya dimana kode dikembangkan dan jika mereka tidak membangun tim dan malah membuat kontrak ...

Aku hanya bilang

Saya akan berperan sebagai advokat setan di sini (agak seperti apa yang dikatakan @khrome: "Anda tidak membayar klien untuk membuat hidup Anda lebih mudah"). Saya bahkan akan mengatakan bahwa kasus yang Anda sampaikan terlalu berat sebelah karena Anda menggambarkan kasus tersebut secara umum. Kebanyakan konsultan yang masuk ke proyek baru akan menyinari yang sebelumnya ... Saya tidak mengatakan itu yang Anda lakukan di sini, tetapi sampai kita melihat contoh, saya tidak bisa begitu saja mengambil kata-kata Anda untuk itu.

Yang mengatakan, saya akan mencoba untuk mengatasi masalah kepada Anda poin demi poin:

• Suntikan SQL . OK, jadi saya kira programmer menggunakan rangkaian string alih-alih query parameter dan / atau prosedur tersimpan. Ini sangat mudah untuk diperbaiki terutama di ADO.NET ... Saya pribadi akan menyebutkannya kepada klien tetapi tidak membuat terlalu banyak masalah.
• HTML dihasilkan dalam logika bisnis dan akan menjadi mimpi buruk untuk disortir . OK, kawan, ini adalah salah satu di mana Anda memberi saya lebih banyak detail. Kecuali jika Anda menggunakan MVC, ini adalah kecenderungan untuk terjadi ... tapi itu tidak selalu merupakan hal yang buruk ... itu salah satu hal di mana sebagian besar programmer akan mengatakan " goto itu buruk; tidak pernah menggunakannya" tetapi Anda tahu apa? Saya telah menggunakan goto di mana itu masuk akal! Jadi, apakah Anda yakin mereka tidak menggunakan kelas pembantu yang kebetulan berbagi namespace yang sama dengan kode bisnis DLL? Sekali lagi, tidak sulit untuk diisolasi.
• logika bisnis tersebar di seluruh aplikasi, ada banyak duplikasi, dan kode jalan buntu yang tidak melakukan apa-apa. . Dan? Klien hanya meminta Anda untuk mengubah HTML / CSS. Mengapa Anda peduli dengan masalah ini?
• itu terus melempar pengecualian yang disiram, sehingga situs tampaknya berjalan lancar . Sekali lagi, sangat kabur. Pengecualian adalah normal dalam aplikasi apa pun, itu sebabnya kami telah mencoba / menangkap klausa dalam kode kami. Kecuali mereka muncul di UI dan merusak pengalaman pengguna (seperti menampilkan HTTP 500 yang tidak perlu), saya tidak berpikir ini adalah sesuatu yang harus Anda pedulikan, baik ..

Jadi singkatnya, saya akan menyarankan Anda untuk mengambil jalan raya. Jika Anda pikir itu tidak sepadan dengan waktu Anda dan Anda ingin menulis ulang dengan mengorbankan klien Anda, maka menjauhlah dari pekerjaan. Serius, pada akhirnya, klien membayar waktu Anda untuk membuat semuanya bekerja dengan jumlah paling sedikit $$$.

Dalam pengalaman bertahun-tahun saya di bidang ini, saya selalu mengatakan bahwa programmer terbaik yang saya temui adalah mereka yang dapat membuat sistem stabil dengan menulis jumlah kode paling sedikit , bukan dengan menulis ulang semuanya .

Sunting: Saya sudah melihat bahwa jawaban saya bukan yang paling populer (saya sudah mengharapkan ini) tetapi saya siap dengan jawaban saya. Saya mengedit ini untuk membuatnya kurang snarky. ;-)

Tentu saja serangan injeksi SQL dan kelemahan fungsional lainnya dalam aplikasi diutamakan, tetapi Anda juga dapat "menunjukkan" kualitas dan praktik kode yang buruk. Dengan alat metrik kode, Anda dapat menunjukkan dengan jelas seberapa buruk kode tersebut dan menunjukkan kepadanya berapa banyak ini akan bertambah biaya untuk setiap perubahan di masa depan dan perbaikan bug. Saya tidak terbiasa dengan lingkungan .net tapi saya yakin ada beberapa yang dapat dijemput.