Asumsi pemrograman yang lama dan salah [ditutup]

Saya sedang melakukan penelitian tentang kesalahan umum dan asumsi buruk yang dibuat oleh insinyur perangkat lunak junior (dan mungkin senior).

Apa asumsi Anda yang paling lama dipegang yang akhirnya dikoreksi?

Sebagai contoh, saya salah mengerti bahwa ukuran bilangan bulat bukan standar dan sebagai gantinya tergantung pada bahasa dan target. Agak memalukan untuk menyatakan, tapi itu dia.

Jujur saja; keyakinan teguh apa yang Anda miliki, dan kira-kira berapa lama Anda mempertahankan asumsi itu? Ini bisa tentang algoritma, bahasa, konsep pemrograman, pengujian, atau apa pun tentang pemrograman, bahasa pemrograman, atau ilmu komputer.

Untuk waktu yang lama saya berasumsi bahwa semua orang memiliki penguasaan super dari semua konsep pemrograman (pola desain, bahasa baru terbaru, kompleksitas komputasi, ekspresi lambda, apa saja).

Membaca blog, Stack Overflow, dan buku pemrograman sepertinya selalu membuat saya merasa bahwa saya berada di belakang kurva pada hal-hal yang harus diketahui oleh semua programmer secara intuitif.

Saya telah menyadari dari waktu ke waktu bahwa saya secara efektif membandingkan pengetahuan saya dengan pengetahuan kolektif banyak orang, bukan satu individu dan itu adalah standar yang cukup tinggi bagi siapa pun. Sebagian besar programmer di dunia nyata memiliki cache pengetahuan yang diperlukan untuk melakukan pekerjaan mereka dan memiliki lebih dari beberapa bidang yang mereka lemah atau sama sekali tidak tahu.

Bahwa orang tahu apa yang mereka inginkan.

Untuk waktu yang lama saya pikir saya akan berbicara dengan orang-orang, mereka akan menggambarkan masalah atau alur kerja dan saya akan memasukkannya ke dalam kode dan mengotomatiskannya. Ternyata setiap kali itu terjadi, apa yang mereka pikir mereka inginkan sebenarnya bukan yang mereka inginkan.

Sunting: Saya setuju dengan sebagian besar komentar. Ini bukan jawaban teknis dan mungkin bukan yang dicari si penanya. Itu tidak hanya berlaku untuk pemrograman. Saya yakin itu bukan asumsi saya yang paling lama dipegang, tetapi itu adalah hal yang paling mengejutkan yang saya pelajari dalam 10 tahun singkat yang telah saya lakukan ini. Saya yakin itu murni kenaifan bagi saya tetapi cara otak saya / terhubung dan pengajaran dan pengalaman yang saya miliki sebelum memasuki dunia bisnis membuat saya percaya bahwa saya akan melakukan apa yang saya jawab; bahwa saya akan dapat menggunakan kode dan komputer untuk memperbaiki masalah orang.

Saya kira jawaban ini mirip dengan Robin tentang pemahaman non-programmer / peduli tentang apa yang saya bicarakan. Ini tentang mempelajari bisnis sebagai proses interaktif, lincah, berulang. Ini tentang mempelajari perbedaan antara menjadi monyet kode pemrograman dan menjadi pengembang perangkat lunak. Ini tentang menyadari bahwa ada perbedaan antara keduanya dan untuk menjadi sangat baik di lapangan, itu bukan hanya sintaks dan kecepatan mengetik.

Sunting: Jawaban ini sekarang adalah komunitas-wiki untuk menenangkan orang-orang yang kesal dengan jawaban ini yang memberi saya perwakilan.

Yang saya tahu di mana masalah kinerja tanpa profil

Bahwa saya seharusnya hanya memiliki satu titik keluar dari fungsi / metode.

Orang non-programer itu mengerti apa yang saya bicarakan.

Perangkat lunak bugfree itu mungkin.

Variabel anggota pribadi itu pribadi untuk instance dan bukan kelas.

Saya pikir pengetikan statis duduk diam di keyboard Anda.

Bahwa Anda dapat sepenuhnya memahami masalah sebelum mulai berkembang.

Orang Cerdas Selalu Lebih Cerdas dari Saya.

Saya benar-benar bisa menyalahkan diri sendiri ketika saya melakukan kesalahan dan sering disuruh mencela diri sendiri. Saya biasa melihat dengan kagum pada banyak pengembang dan sering berasumsi bahwa karena mereka tahu lebih banyak dari saya di X , mereka tahu lebih banyak dari saya.

Ketika saya terus mendapatkan pengalaman dan bertemu lebih banyak orang, saya mulai menyadari bahwa seringkali, sementara mereka tahu lebih banyak dari saya dalam subjek tertentu, mereka tidak selalu lebih pintar dari saya / Anda.

Moral dari cerita ini: Jangan pernah meremehkan apa yang bisa Anda bawa ke meja.

Untuk waktu yang lama saya berpikir bahwa Pemrograman Buruk adalah sesuatu yang terjadi di pinggiran .. bahwa Melakukan Hal dengan Benar adalah norma. Saya tidak begitu naif hari ini.

Saya pikir saya harus bergerak ke arah abstrak sebanyak mungkin. Saya mendapat hit di kepala utama dengan ini, karena terlalu banyak sedikit terjalin fungsionalitas.

Sekarang saya mencoba menjaga hal-hal sesederhana dan terpisah mungkin. Refactoring untuk membuat sesuatu menjadi abstrak jauh lebih mudah daripada memprediksi bagaimana saya perlu mengabstraksikan sesuatu.

Jadi saya pindah dari mengembangkan kerangka kerja yang mengatur semuanya, ke potongan-potongan fungsionalitas yang menyelesaikan pekerjaan. Tidak pernah menoleh ke belakang, kecuali ketika saya berpikir tentang waktu saya dengan naif berpikir saya akan menjadi orang yang mengembangkan hal besar berikutnya.

Perempuan itu menemukan programmer komputer itu seksi ...

Bahwa kualitas perangkat lunak akan menghasilkan penjualan yang lebih besar. Terkadang tidak tetapi selalu.

Bahwa semua bahasa (sebagian besar) diciptakan sama.

Untuk waktu yang lama saya pikir bahwa bahasa pilihan tidak benar-benar membuat banyak perbedaan dalam kesulitan proses pengembangan dan potensi keberhasilan proyek. Ini jelas tidak benar.

Memilih bahasa yang tepat untuk pekerjaan itu sama pentingnya / kritis dengan keputusan proyek tunggal lainnya yang dibuat.

Rasio komentar / kode yang besar adalah hal yang baik.

Butuh beberapa saat untuk menyadari bahwa kode harus mendokumentasikan diri. Tentu, komentar di sana-sini sangat membantu jika kode tidak dapat dibuat lebih jelas atau jika ada alasan penting mengapa sesuatu sedang dilakukan. Tapi, secara umum, lebih baik menghabiskan waktu mengubah nama variabel komentar. Lebih bersih, lebih jelas dan komentar tidak "tidak sinkron" dengan kode.

Pemrograman itu tidak mungkin.

Tidak bercanda, saya selalu berpikir bahwa pemrograman adalah hal yang mustahil untuk dipelajari, dan saya selalu menjauhinya. Dan ketika saya mendekati kode, saya tidak pernah bisa memahaminya.

Kemudian suatu hari saya hanya duduk dan membaca beberapa tutorial dasar pemula, dan bekerja dengan cara saya dari sana. Dan hari ini saya bekerja sebagai programmer dan saya suka setiap menitnya.

Untuk menambahkan, saya tidak berpikir pemrograman itu mudah, itu sebuah tantangan dan saya suka belajar lebih banyak dan tidak ada yang lebih menyenangkan daripada menyelesaikan beberapa masalah pemrograman.

"On Error Resume Next" adalah semacam penanganan kesalahan

Perangkat lunak pemrograman itu membutuhkan dasar yang kuat dalam matematika yang lebih tinggi.

Selama bertahun-tahun sebelum saya mulai menulis kode, saya selalu diberitahu bahwa untuk menjadi programmer yang baik, Anda harus mahir dalam aljabar, geometri, kalkulus, trigonometri, dll.

Sepuluh tahun kemudian dan saya hanya sekali harus melakukan sesuatu yang siswa kelas delapan tidak bisa.

Itu mengoptimalkan == penulisan ulang dalam bahasa assembly.

Ketika saya pertama kali benar-benar mengerti assembly (berasal dari BASIC), sepertinya satu-satunya cara untuk membuat kode berjalan lebih cepat adalah menulis ulangnya di assembly. Butuh beberapa tahun untuk menyadari bahwa kompiler bisa sangat baik dalam optimasi dan terutama dengan CPU dengan prediksi cabang dll. Mereka mungkin dapat melakukan pekerjaan yang lebih baik daripada yang dapat dilakukan manusia dalam jumlah waktu yang wajar. Selain itu, menghabiskan waktu untuk mengoptimalkan algoritme cenderung memberi Anda kemenangan yang lebih baik daripada menghabiskan waktu mengonversi dari bahasa tingkat tinggi ke rendah. Juga bahwa pengoptimalan prematur adalah akar dari semua kejahatan ...

• Bahwa eksekutif perusahaan peduli dengan kualitas kode.
• Garis yang lebih sedikit lebih baik.

Saya akan mengatakan bahwa menyimpan elemen tahun tanggal sebagai 2 digit adalah asumsi yang menimpa seluruh generasi pengembang. Uang yang dihembuskan ke Y2K cukup mengerikan.

Apa pun selain penyisipan / gelembung semacam itu hanyalah sihir gelap.

XML itu akan menjadi format data yang benar-benar interoperable dan dapat dibaca manusia.

C ++ itu entah bagaimana secara intrinsik lebih baik daripada semua bahasa lain.

Ini saya terima dari seorang teman beberapa tahun di depan saya di perguruan tinggi. Saya menyimpannya untuk waktu yang memalukan (saya memerah sekarang). Itu hanya setelah bekerja dengannya selama 2 tahun atau lebih sebelum saya bisa melihat celah untuk apa itu.

Tidak ada - dan tidak ada - yang sempurna, selalu ada ruang untuk perbaikan.

Saya percaya bahwa membuat program akan persis seperti apa yang diajarkan di kelas ... Anda duduk dengan sekelompok orang, membahas masalah, mencari solusi, dll. Sebaliknya, dunia nyata adalah "Inilah masalah saya, saya perlu diselesaikan, pergi "dan sepuluh menit kemudian Anda mendapatkan yang lain, sehingga Anda tidak punya waktu nyata untuk merencanakan solusi Anda secara efisien.

Saya pikir pola desain arus utama itu luar biasa, ketika diperkenalkan di kelas CS. Saya telah memprogram sekitar 8 tahun sebagai hobi sebelumnya, dan saya benar-benar tidak memiliki pemahaman yang kuat tentang cara membuat abstraksi yang baik.

Pola desain terasa seperti sihir; Anda bisa melakukan hal-hal yang sangat rapi. Kemudian saya menemukan pemrograman fungsional (via Mozart / Oz, OCaml, kemudian Scala, Haskell, dan Clojure), dan kemudian saya mengerti bahwa banyak dari pola-pola itu hanya pelat baja, atau kompleksitas tambahan, karena bahasanya tidak cukup ekspresif.

Tentu saja hampir selalu ada semacam pola, tetapi mereka berada pada level yang lebih tinggi dalam bahasa ekspresif. Sekarang saya telah melakukan beberapa pengkodean profesional di Jawa, dan saya benar-benar merasakan sakit ketika saya harus menggunakan konvensi seperti pola pengunjung atau perintah, daripada pencocokan pola dan fungsi urutan yang lebih tinggi.

Selama beberapa tahun pertama saya pemrograman saya tidak mengerti bahwa 1 Kbyte secara teknis 1024 byte, bukan 1000. Saya selalu sedikit bingung dengan kenyataan bahwa ukuran file data saya tampak sedikit berbeda dari apa yang saya harapkan dari mereka. menjadi.

Kondisi itu memeriksa seperti:

if (condition1 && condition2 && condition3)

dilakukan dalam urutan yang tidak ditentukan ...

Pemrograman saya akan lebih cepat dan lebih baik jika saya melakukannya sendiri.