Kapan pemrograman yang "tepat" tidak lagi penting?

49

Saya telah membangun game android di waktu luang saya. Ini menggunakan perpustakaan libgdx sehingga sedikit dari angkat berat dilakukan untuk saya.

Saat mengembangkan, saya dengan sembarangan memilih tipe data untuk beberapa prosedur. Saya menggunakan hashtable karena saya ingin sesuatu yang dekat dengan array asosiatif. Nilai kunci yang dapat dibaca manusia. Di tempat lain untuk mencapai hal serupa, saya menggunakan vektor. Saya tahu libgdx memiliki kelas vector2 dan vector3, tapi saya belum pernah menggunakannya.

Ketika saya menemukan masalah aneh dan mencari bantuan Stack Overflow, saya melihat banyak orang hanya mengulang pertanyaan yang menggunakan tipe data tertentu ketika yang lain secara teknis "tepat". Seperti menggunakan ArrayList karena tidak memerlukan batasan yang didefinisikan versus mendefinisikan kembali int [] dengan batas yang diketahui baru. Atau bahkan sesuatu yang sepele seperti ini:

for(int i = 0; i < items.length; i ++)
{
    // do something
}

Saya tahu itu mengevaluasi item.length pada setiap iterasi. Namun, saya juga tahu item tidak akan pernah lebih dari 15 hingga 20 item. Jadi haruskah saya peduli jika saya mengevaluasi item. Panjang pada setiap iterasi?

Saya menjalankan beberapa tes untuk melihat bagaimana kinerja aplikasi menggunakan metode yang saya jelaskan versus yang tepat, ikuti tutorial dan menggunakan tipe data yang tepat yang disarankan oleh komunitas. Hasilnya: Hal yang sama. Rata-rata 45 fps. Saya membuka setiap aplikasi di tab telepon dan galaksi. Tidak ada perbedaan.

Jadi saya kira pertanyaan saya kepada Anda adalah ini: Apakah ada ambang batas ketika itu tidak lagi menjadi masalah? Apakah boleh mengatakan - "selama pekerjaan itu selesai, saya tidak peduli?"

— Kai Qing
sumber

4

Ini pertanyaan besarnya. Cobalah membuat basis data multi-terrabyte yang disajikan hingga ke dunia nyata dengan pencarian dan agregasi dalam waktu respons subsecond dengan ribuan permintaan per menit. Masalahmu tidak cukup besar. Meskipun pendekatan Anda baik-baik saja, jika Anda mengikuti jalan menuju kesimpulan yang tak terhindarkan itu adalah pendekatan yang menyakitkan yang membutuhkan waktu untuk dijangkau.

— Jimmy Hoffa

8

Jika bahasa Anda memiliki loop FOR nyata, masalah evaluasi berganda itu tidak akan terjadi. Sayangnya, sintaks C memerlukannya, karena itu bukan benar-benar loop UNTUK; itu adalah WHILE loop yang mengenakan wig dan kacamata berhidung besar, dan itu diperlukan untuk menerima kondisi sewenang-wenang (atau tidak sama sekali) untuk penghentian loop.

— Mason Wheeler

2

Saya melihat hasil edit Anda, tetapi jika Anda mencoba membuat kasus bahwa mabuk dan gegabah tidak masalah dalam konteks apa pun kecuali berpesta pada hari Jumat malam dengan pengemudi yang ditunjuk, Anda mungkin menggonggong pohon yang salah.

— Robert Harvey

17

Bagaimana Anda tahu itu 'mengevaluasi' item. Panjang pada setiap iterasi? Kompiler cukup pintar. Dan bahkan jika itu berulang kali mengambil item.length, lalu apa? Saya benci melihat kode seperti 'int itemsLength = items.length; untuk (; i <itemsLength; ...) 'kecuali jika ada masalah kinerja yang diukur.

— kevin cline

6

Item Anda. Hal yang panjang sama sekali tidak ada hubungannya dengan "pemrograman yang tepat". Ini adalah mikro-optimasi, dan programmer yang baik tahu lebih baik daripada membuang waktu sampai mereka menjalankan profiler dan tahu di mana masalah kinerja sebenarnya . Optimalisasi mikro dan gaya pemrograman yang baik sering bertentangan, bukan hal yang sama.

— Michael Borgwardt

65

Anda menulis sebuah program untuk memecahkan masalah. Masalah itu disertai dengan serangkaian persyaratan khusus untuk menyelesaikannya. Jika persyaratan itu dipenuhi, masalahnya terpecahkan dan tujuannya tercapai.

Itu dia.

Sekarang, alasan praktik terbaik diamati adalah karena beberapa persyaratan berkaitan dengan rawatan, pengujian, jaminan kinerja, dan sebagainya. Akibatnya, Anda memiliki orang-orang sial seperti saya yang membutuhkan hal-hal seperti gaya pengkodean yang tepat. Tidak perlu banyak upaya untuk melewati T dan dot I Anda, dan itu merupakan sikap hormat kepada mereka yang harus membaca kode Anda nanti dan mencari tahu apa fungsinya.

Untuk sistem yang besar, pengekangan dan disiplin semacam ini sangat penting, karena Anda harus bermain baik dengan orang lain untuk menyelesaikan semuanya, dan Anda harus meminimalkan utang teknis sehingga proyek tidak runtuh karena bebannya sendiri.

Di ujung lain dari spektrum adalah utilitas satu kali yang Anda tulis untuk memecahkan masalah tertentu sekarang, utilitas yang tidak akan pernah Anda gunakan lagi. Dalam kasus itu, gaya dan praktik terbaik sama sekali tidak relevan; Anda meretasnya bersama, menjalankannya, dan melanjutkan dengan hal berikutnya.

Jadi, seperti halnya banyak hal dalam pengembangan perangkat lunak, itu tergantung.

— Robert Harvey
sumber

1

Saya cenderung setuju. Di tempat kerja saya tidak mengajukan pertanyaan, itu disilangkan dan bertitik. Tetapi pertimbangkan bahwa banyak hal yang saya lakukan untuk pekerjaan adalah satu hal yang benar-benar tidak perlu dipertahankan. Melewati tren semacam itu. Aplikasi ulang tahun, hal-hal yang datang dan pergi. Semuanya layak di sana, tetapi sebenarnya tidak perlu.

— Kai Qing

21

Seseorang dapat membuat kasus yang didisiplinkan setiap saat membuatnya lebih mudah untuk didisiplinkan ketika Anda harus. Beberapa orang mengajukan pertanyaan tentang Stack Overflow tanpa pernah menekan tombol shift, menggunakan alasan bahwa mereka dapat menyampaikan ide-ide mereka secara memadai tanpa itu, dan bahwa bahasa Inggris adalah sesuatu yang cair dan berevolusi pula. Saya menemukan tidak ada yang lebih menyebalkan, kecuali mungkin penulis virus yang berpikir waktu CPU saya bebas.

— Robert Harvey

2

@ KaiQing Seseorang harus memberi Anda aplikasi warisan 5mloc yang lahir secara pascal dan porting maju sejak itu, setelah upaya pertama Anda untuk menambah atau mengubah fungsi apa pun pada aplikasi ini, Anda akan segera menyadari mengapa praktik terbaik ada dan tercerahkan.

— Jimmy Hoffa

5

@ KaiQing, Angry Birds harus berjalan di beberapa platform, dan jika permainan hang selama 2 detik x% dari penonton akan menyerah, yang berarti lebih sedikit dolar untuk orang-orang Angry Birds. Saya yakin Anda itu ditulis dengan sangat, sangat hati-hati. Mungkin ini menjawab pertanyaan Anda. Jika kodenya hanya untuk Anda, siapa yang peduli dengan apa yang Anda lakukan? Jika ada uang atau waktu orang lain dipertaruhkan maka Anda lebih baik sangat, sangat berhati-hati.

— Charles E. Grant

2

@ KaiQing Tidak ada yang bisa memberi tahu Anda ambang untuk itu, itu variabel dari proyek ke proyek dan pada setiap proyek dari waktu ke waktu. Jumlah variabel yang mempengaruhi ambang batas antara sistem yang dapat dipelihara dan tidak bergantung pada: LOC, Basis pengguna, Basis pengembang, Jenis aplikasi (kriptografi vs kasar vs driver), kekokohan fitur, persyaratan redundansi, kekritisan perangkat lunak (server email vs perangkat pendukung kehidupan vs. widget jam), platform yang didukung, Teknologi tumpukan, Jumlah data yang ditransaksikan atau dianalisis, kendala audit historis dan banyak lagi hal-hal yang mempengaruhi seberapa buruk kode

— Jimmy Hoffa

18

Ada kutipan kuno yang bijak: "Jangan mengikuti jejak orang-orang bijak di masa lalu. Carilah apa yang mereka cari." Ada alasan untuk semua aturan pengkodean 'benar'. Mengetahui mengapa aturan itu ada lebih penting daripada mengetahui apa aturan itu.

Ada aturan bahwa Anda tidak boleh melakukan tes yang bisa berulang kali dihitung ulang dalam for for loop seperti itu. Dalam kasus-kasus bahwa aturan diciptakan untuk memperbaiki (di mana kinerja akan sangat berbeda), masuk akal. Dalam hal ini, hanya ada satu jawaban yang benar. Dalam contoh Anda, diketahui bahwa tidak ada perbedaan kinerja dan tidak mungkin ada lebih dari beberapa lusin iterasi. Dalam hal ini, ada dua jawaban yang benar, baik untuk menerapkan aturan, karena itu sederhana dan tidak akan menyakiti apa pun dan dapat membantu membentuk kebiasaan yang baik, atau mengabaikan aturan, karena tidak ada perbedaan kinerja yang perlu dikhawatirkan.

Saya lebih suka jawaban benar pertama, dan Anda tampaknya lebih suka yang kedua. Anda tidak salah tentang itu. Saya pikir Anda salah dalam ide tentang pemrograman yang 'tepat'. Ini bukan tentang mengikuti serangkaian aturan yang dipilih secara acak yang tidak membantu Anda dan tidak memiliki tujuan. Anda tidak memperbaiki loop for dalam contoh ini sebenarnya mengikuti aturan yang sangat baik terhadap optimasi prematur.

Pemrograman yang tepat dan benar adalah tentang mengikuti aturan yang baik yang masuk akal dengan cara yang cerdas.

— Michael Shaw
sumber

Saya tidak akan mengatakan saya lebih suka yang kedua. Seseorang mengedit posting saya untuk menghapus bagian tentang membuat saya membuat game android ini hampir seluruhnya mabuk (hanya untuk bersenang-senang) dan sebagai hasilnya saya terkejut melihat pilihan mabuk saya tidak membuat perbedaan pada kinerja. Saya mengganti beberapa kelas aneh dengan yang tepat untuk diuji. Saya setuju bahwa mengetahui aturan ada lebih penting daripada mengetahui apa aturannya ...

— Kai Qing

Selain itu, ide saya tentang pemrograman "yang tepat" adalah puncak dari opini berulang dari komunitas stackoverflow, serta kumpulan programmer yang datang dan pergi di perusahaan tempat saya bekerja. Beberapa dengan gelar CI, beberapa belajar sendiri. Ada pendapat umum untuk mendasarkan hal-hal dan saya cenderung setuju dengan apa yang dikatakan semua orang secara kolektif sebelum hanya memutuskan bahwa satu cara adalah benar dan satu cara salah. Terima kasih telah berpartisipasi.

— Kai Qing

1

Jika kedengarannya seperti saya memberi tahu Anda karena melanggar aturan, maka saya mengucapkannya dengan buruk. Tak satu pun dari hal-hal yang Anda bicarakan lakukan adalah hal-hal yang akan saya tolak. Saya mencoba menunjukkan bahwa "roh hukum" lebih penting daripada "surat hukum".

— Michael Shaw

Heh, tidak, aku tidak berpikir kamu menyuruhku pergi. Saya hanya komunikatif. Saya menanyakan pertanyaan ini karena suatu alasan dan saya senang banyak orang merespons tanpa memilihnya.

— Kai Qing

10

Cara yang tepat untuk melihat ini adalah hasil yang semakin berkurang: membandingkan manfaat tambahan dari pengembangan program dengan biaya pengembangan tambahan.

Pengembalian yang berkurang ditetapkan saat manfaat marjinal kurang dari waktu / upaya marjinal.

Bisakah Anda membuat kasus bisnis untuk items.lengthkeluar dari forlingkaran? Secara ekonomi, dapatkah perubahan itu membenarkan waktu yang dihabiskan untuk mencoba membenarkannya? Karena tidak ada perbedaan dalam pengalaman pengguna, Anda tidak akan pernah mendapatkan apa pun untuk pengukuran waktu yang dihabiskan (selain pelajaran yang berguna untuk diingat). Pengguna tidak akan menyukai program lebih dari yang mereka lakukan, dan lebih banyak salinan tidak akan dijual, sebagai akibat dari perubahan itu.

Ini tidak selalu mudah untuk dievaluasi, karena kasus-kasus bisnis dipenuhi dengan hal-hal yang tidak diketahui dan risiko, dan dengan demikian rentan untuk menjadi mangsa faktor-faktor yang tidak dipertimbangkan yang hanya akan menjadi jelas di belakang. Perubahan yang diajukan bisa sepenuhnya nontrivial, sehingga membuat perbedaan besar.

Jenis pemikiran pengurangan-pengembalian bisa berarti perburuan alasan untuk tidak mengambil tindakan, dan menghindari mengambil risiko, yang di belakang mungkin terbukti menjadi serangkaian peluang yang terlewatkan.

Tetapi kadang-kadang jelas ketika tidak melakukan sesuatu. Jika beberapa bagian dari pembangunan tampaknya memerlukan keajaiban ekonomi terjadi hanya untuk membayar biaya pembangunan (impas), itu mungkin ide yang buruk.

— Kaz
sumber

Ditulis dengan sangat baik. Dalam kasus saya tidak pernah direncanakan pengembalian. Setiap pengembalian mungkin insidentil tetapi tidak boleh diberhentikan karena saya pikir beberapa keberhasilan terbesar dimulai sebagai cacing. Dalam hal pekerjaan klien, di mana tidak ada begitu banyak uang yang dipertaruhkan karena mungkin hanya ada kejengkelan jika aplikasi hang atau sesuatu menjadi ketidaknyamanan kecil, itu adalah ambang batas yang lebih tebal. Jika tolok ukur terlihat bagus, tetapi kode diketahui bukan yang paling efisien, maka tidak akan ada orang yang datang untuk mengauditnya sebelum waktu perkembangan kode dan mungkin meminta migrasi, bagaimanapun ... sulit untuk mengatakannya.

— Kai Qing

Memang. Kami tidak selalu dapat membuat semacam kasus objektif. Tidak semua orang menghargai program dengan cara yang sama. Misalkan utilitas utama dalam program adalah kesenangan dalam mengerjakannya. Itu mungkin tidak bermanfaat bagi orang lain dan tidak ada yang akan membayar untuk perbaikan (jika bahkan ada pengguna selain programmer), tapi itu cukup untuk membenarkan memperbaikinya dengan cara apa pun.

— Kaz

Dua kata yang berguna untuk ditambahkan ke jawaban Anda yang ditulis dengan sangat baik - "Investasi Spekulatif" - Anda melakukannya karena Anda berspekulasi akan ada pengembalian di masa depan.

— mattnz

@ mattnz - apa yang Anda katakan benar karena tidak ada yang melakukan sesuatu tanpa imbalan, bahkan jika pengembaliannya adalah tawa yang baik. Hampir semua proyek pribadi saya dilakukan untuk humor. Hampir semua dari mereka membuat cukup untuk membenarkan persyaratan mereka. Tidak satu pun dari mereka yang memungkinkan saya untuk berhenti.

— Kai Qing

Tepatnya, semuanya. Jadi pertama-tama kita menentukan apa yang kita harapkan dari menulis program ini, atau terus melakukannya. Sesuatu itu bisa "menghabiskan waktu sedemikian rupa sehingga menyenangkan". Tetapi bahkan kemudian, kita dapat berpikir: mengerjakan hal ini dan itu dalam program ini dan itu cara terbaik untuk mencapai yang paling menyenangkan, atau apakah kita menempatkan waktu ke dalam sesuatu yang lain.

— Kaz

3

Ketika Anda seharusnya tidak peduli kode Anda menjadi "layak"

Jika Anda berhasil menjawab tujuan bisnis, dan mempertahankannya seiring waktu dengan overhead yang rendah. (pengguna tidak melihat sumber sebelum mereka membayar Anda)
MVP / POC - Jika menulis kode yang tepat berarti membuang waktu untuk sebuah konsep sebelum Anda tahu cara menghasilkan uang dari itu (jika Anda menghabiskan bertahun-tahun dan 45 juta dolar untuk menulis aplikasi Anda dan akhirnya menutup toko karena tidak memiliki pasar, tidak ada yang peduli bagaimana yang layak adalah kode)
Ketika memiliki situasi yang mengancam jiwa (mis. Manusia purba prototipe 1 adalah peretasan yang kotor, tetapi itu membuatnya keluar dari gua kan?)
atau jika Anda tidak tahu bagaimana menulis kode yang tepat (jika seseorang berhasil mencari nafkah dengan menulis kode yang tidak tepat, dalam pengangguran hari ini, saya katakan, lebih baik menulis kode yang buruk daripada menjadi tunawisma)
jika Anda hanya tahu apa yang Anda lakukan atau pikirkan, Anda bisa lolos dengan berpura-pura melakukannya

Kapan menulis kode yang tepat

Jika itu akan memiliki dampak bisnis yang signifikan, mis. Kinerja akan berdampak pada pendapatan, atau mencegah penjualan
Jika tidak tepat mempertahankan kode menjadi masalah bisnis (biaya perawatan tinggi)
Jika Anda seorang programmer yang dikenal bekerja pada proyek open source besar
Sama dengan perusahaan besar yang menyumbang perpustakaan internal kepada dunia
Jika Anda ingin menunjukkan pekerjaan Anda sebagai portofolio dalam wawancara di masa depan

— Eran Medan
sumber

1

Sayangnya ada satu lagi di daftar tidak peduli untuk menjadi layak yang banyak orang diberkati untuk tidak tahu: Ketika seorang klien memuntahkan sistem lama ke dalam perawatan Anda dan memberitahu Anda bahwa mereka perlu itu dilakukan dalam seminggu. Kadang-kadang waktu dan / atau anggaran tidak memungkinkan untuk pengkodean yang tepat dan perhatian Anda pada proyek lebih dari rahmat daripada transaksi bisnis. Sebagai contoh, jika kode mereka menggunakan metode yang sudah usang tetapi membutuhkan beberapa perbaikan (berbicara dalam skenario web). Tidak bisa memperbaiki semuanya. Harus kotor.

— Kai Qing

"Jika tidak tepat mempertahankan kode menjadi masalah bisnis (biaya perawatan tinggi)." Ambang batas ini sebenarnya jauh lebih rendah daripada yang dipercayai oleh sebagian besar pengembang yang tidak berpengalaman. Menulis kode padat sering membayar sendiri kembali dalam beberapa jam, bukan hari atau bulan.

— PeterAllenWebb

2

Apakah kinerja menjadi perhatian utama Anda? Itukah yang ingin Anda maksimalkan?

Jika demikian, ada pelajaran mendasar untuk dipelajari, dan jika Anda melakukannya, Anda akan menjadi salah satu dari sedikit.

Jangan mencoba "berpikir" apa yang harus Anda lakukan untuk membuatnya lebih cepat - itu dugaan. Jika Anda bertanya "Haruskah saya menggunakan kelas wadah ini atau yang itu?", Atau "Haruskah saya menempatkan lengthdalam kondisi loop?", Anda seperti seorang dokter yang melihat seorang pasien dan mencoba untuk memutuskan perawatan apa yang akan diberikan tanpa benar-benar mempertanyakan atau memeriksa pasien.

Itu menebak. Semua orang melakukannya, tetapi itu tidak berhasil.

Sebaliknya, biarkan program itu sendiri memberi tahu Anda apa masalahnya. Ini contoh terperinci.

Apakah Anda melihat perbedaannya?

— Mike Dunlavey
sumber

Saya akan mengatakan bahwa satu-satunya kekhawatiran saya adalah bahwa dalam pengujian saya, saya perhatikan tidak ada perbedaan kinerja antara penggunaan tipe data yang tidak tepat dan tepat untuk skenario yang ditentukan. Seperti dalam saran Anda, saya membebani kelas dengan lebih banyak data untuk melihat apakah terlalu sedikit untuk membuat perbedaan. Pada akhirnya, keduanya tampil sama. Memang, saya hanya membuat game tipe RPG dasar. Ini tidak seperti perangkat lunak perbankan atau sesuatu yang kompleks. Tapi itu membuat saya bertanya-tanya apakah akan lebih baik bagi bisnis untuk tidak sepantasnya sepanjang waktu.

— Kai Qing

Karena kinerja adalah urusan Anda, Anda harus bertanya kepada program apa yang seharusnya Anda lihat, bukan menanyakan apakah pertanyaan Anda sebelumnya membuat perbedaan. Silakan klik tautan ini, dan lakukan apa yang dikatakannya. Ini akan memberi tahu Anda apa sebenarnya program yang menghabiskan waktu, dan itu akan memberi tahu Anda bagaimana membuatnya lebih cepat.

— Mike Dunlavey

Nah, kinerja adalah dasar saya untuk prosedur interogasi, tidak harus menjadi perhatian. Saya tidak mencari patokan per katakan. Hanya mengamati bahwa kode yang tidak efisien tidak membuat perbedaan kinerja. Pada dasarnya transparan bagi pengguna seberapa efisien atau tidak efisiennya program tersebut, oleh karena itu membuat keprihatinan untuk profil seperti itu tidak relevan. Memang, saya harus memiliki perhatian untuk melakukan tolok ukur di tempat pertama, tetapi sebagian besar rasa ingin tahu. Dan jika produk selesai dan terasa lambat maka ya, seorang profiler masuk akal. Terima kasih atas tautannya

— Kai Qing

2

Pertanyaan Anda adalah "selama pekerjaan itu selesai, saya tidak peduli?"

Jawaban saya adalah, "Anda tidak pernah tahu apa yang akan terjadi pada kode Anda." Saya telah terlibat dalam banyak proyek yang dimulai dengan "hei, izinkan saya menulis hal cepat ini untuk mengatasi masalah pengguna." Tulis itu, letakkan di sana, jangan pernah pikirkan lagi.

Suatu kali, hal yang saya tulis berubah menjadi "oh, sekarang seluruh departemen pengguna ingin menggunakan kode itu," yang sebelum saya bisa berbalik menjadi "seluruh perusahaan menggunakan kode itu dan sekarang saya harus membuktikan bahwa ia akan bertahan dalam audit dan ada tinjauan kode 20 orang dijadwalkan untuk besok dan beberapa wakil presiden telah menjualnya kepada pelanggan kami. "

Saya menyadari Anda "hanya menulis game android di waktu luang Anda" tetapi Anda tidak pernah tahu apakah game itu akan lepas landas dan menjadi tiket Anda menuju ketenaran dan kekayaan. Lebih buruk lagi, game itu bisa menjadi tiket Anda untuk keburukan karena terus menabrak ponsel orang. Apakah Anda ingin menjadi orang yang mendapat tawaran pekerjaan karena anak-anak seseorang tidak bisa berhenti memainkan permainan Anda di ponsel mereka, atau Anda ingin menjadi orang yang difitnah di papan pesan seperti ini?

— Dan Perkins
sumber

1

Jawabannya adalah itu tidak pernah penting, dan itu selalu penting ....

Itu tidak pernah penting karena pemrograman, layak atau tidak, adalah cara untuk mencapai tujuan, bukan tujuan itu sendiri. Jika tujuan itu dicapai tanpa pemrograman "yang benar" itu bagus (dari perspektif bisnis, sering kali yang terbaik adalah jika tujuan itu dapat dicapai tanpa pemrograman).

Itu selalu penting karena pemrograman yang tepat adalah alat yang akan membantu Anda dalam mencapai tujuan Anda. Cara yang tepat dalam melakukan sesuatu hanyalah pengakuan bahwa melakukannya dengan cara lain menyebabkan lebih banyak rasa sakit dalam jangka panjang daripada menghemat.

Yang menjawab pertanyaan kapan Anda bisa mengabaikannya - ketika Anda yakin bahwa cara lain akan lebih mudah dalam jangka panjang (mungkin karena tidak akan ada jangka panjang).

Satu alat biasanya dilakukan secepat dan kotor yang Anda bisa, dengan sedikit atau tidak ada pengecekan error atau validasi lainnya, tanpa pencatatan pengecualian, kode cut-n-paste dengan perubahan kecil atau bahkan tanpa perubahan alih-alih fungsi generik, dan sebagainya .

Hanya hati-hati: kadang-kadang aplikasi yang cepat dan kotor itu hidup sendiri, yang berarti semua jalan pintas membuat Anda ...

— jmoreno
sumber

1

"tidak pernah" dan "selalu" saling membatalkan. Menjadikan jawaban Anda baik dan buruk.

— Tulains Córdova

@ user1598390: pembatalan satu sama lain adalah intinya. Batalkan dogma, dan Anda merasa seperti itu berguna. Dan Anda akan salah dan belajar dari itu.

— jmoreno

Saya ingin mengatakan saya setuju dengan Anda, tetapi saya tidak akan membawanya terlalu ekstrem. Saya tidak berpikir satu kali sering hanya dimuntahkan, lolos dari pengujian atau debugging. Hanya karena itu tidak dioptimalkan dan dirancang dengan sempurna tidak membuatnya menjadi kurang produk jika kinerja dan stabilitas tidak terpengaruh oleh jalan pintas. Yang pada akhirnya poin saya dan mengapa saya bertanya-tanya mengapa semua orang membuat bau seperti pengkodean contoh yang tidak top of the line. Ini sering terjadi pada stackoverflow.

— Kai Qing

@ KaiQing: Pengujian dan debugging terjadi tentu saja, tetapi umumnya terbatas pada apa yang ada saat ini - jadi misalnya jika prosesnya mungkin gagal dengan file yang memiliki pengkodean UTF, dan tidak ada file yang sedang Anda kerjakan lakukan, Anda tidak menguji itu. Optimalisasi harus dilakukan ketika masalah kinerja telah diidentifikasi. Adapun mengapa bau di atas non-atas contoh pengkodean baris pada SO - Saya pikir itu adalah fungsi dari tujuan situs. Ini bertujuan untuk menjadi sumber daya permanen, kode dalam jawaban (dan bahkan pertanyaan) dengan demikian dipandang seolah-olah mereka akan menjadi templat yang digunakan orang lain.

— jmoreno

1

Atau bahkan sesuatu yang sepele seperti ini:

for(int i = 0; i < items.length;i ++) {
     // do something 
}

Saya tahu itu mengevaluasi item.length pada setiap iterasi. Namun, saya juga tahu item tidak akan pernah lebih dari 15 hingga 20 item. Jadi haruskah saya peduli jika saya mengevaluasi item. Panjang pada setiap iterasi?

Sebenarnya dalam kode akhir, items.length tidak akan dievaluasi dalam setiap iterasi karena kompilator mengoptimalkannya. Dan bahkan jika tidak, panjang adalah bidang publik di objek array; mengaksesnya tanpa biaya.

Jadi saya kira pertanyaan saya kepada Anda adalah ini: Apakah ada ambang batas ketika tidak lagi layak? Apakah boleh mengatakan - "selama pekerjaan itu selesai, saya tidak peduli?"

Itu benar-benar tergantung pada apa yang Anda harapkan dari produk akhir Anda; perbedaan antara produk rata-rata dan produk hebat bergantung pada detail. Mobil seperti Tata Nano dan mobil seperti Mercedes S "menyelesaikan tugasnya" - ini membawa Anda dari satu tempat ke tempat lain. Perbedaannya bergantung pada detail: tenaga mesin, kenyamanan, keselamatan dan lainnya. Ini sama dengan produk apa pun yang ada, termasuk produk perangkat lunak; misalnya mengapa orang membayar ke Oracle, IBM atau Microsoft untuk basis data Oracle, DB2 atau MS SQL Server karena MySQL dan Postgre gratis?

Jika Anda ingin memperhatikan detail dan mendapatkan produk berkualitas tinggi Anda harus peduli tentang hal ini (dan tentang hal-hal lain, tentu saja).

— m3th0dman
sumber

Saya pikir saya tidak setuju dengan itu. Dalam posting saya, saya menyebutkan tidak ada perbedaan dalam kinerja. Itu akan menyarankan tidak ada produk rata-rata atau besar, tetapi keseimbangan yang sama meskipun ada kekurangan. Namun, saya setuju dengan pernyataan Anda, jika ada proyek khusus yang sangat penting yang kami semua gunakan sebagai pembanding. Tetapi secara abstrak, pengamatan umum adalah bahwa dalam proyek anonim ini, kelas yang jelas tidak efisien memiliki kinerja yang sama dengan yang dioptimalkan. Jadi, apakah boleh mengambil sikap malas pada ini atau berdebat untuk kesempurnaan setiap saat?

— Kai Qing

@ Kai Qing Kelas tunggal tidak (atau tidak seharusnya) membuat banyak perbedaan. Saya mengatakannya: jika Anda mengharapkan produk Anda menjadi produk berkualitas tinggi, maka perhatikan detail (bahkan jika itu berarti sedikit kemungkinan optimasi atau desain yang hati-hati); di sisi lain jika satu-satunya yang Anda inginkan adalah sistem fungsional maka mungkin Anda tidak harus membayar banyak perhatian pada detail kecil.

— m3th0dman

Ya, Anda benar itu seharusnya tidak membuat perbedaan walaupun hanya sedikit perawatan yang ditempatkan dalam desainnya. Tapi itu bisa membuat perbedaan tergantung pada tujuannya atau jika secara umum tujuannya berubah dari waktu ke waktu dan menjadi sesuatu yang tidak dimaksudkan. Melihat itu sebelumnya, tapi saya hanya bersinggungan di sini. Agar adil, suatu produk bisa berkualitas tinggi tanpa harus lebih dari fungsional.

— Kai Qing

1

Jika Anda memprogram di rumah untuk diri sendiri maka mungkin Anda dapat memotong beberapa sudut; dan ketika Anda bereksperimen dan mencoba hal-hal ini sepenuhnya dibenarkan.

Namun berhati-hatilah. Dalam contoh yang Anda berikan, sebenarnya tidak perlu memotong sudut itu, dan Anda harus berhati-hati. Ini bisa memulai tren dan kebiasaan buruk yang Anda lakukan di rumah bisa masuk ke kode Anda di tempat kerja. Jauh lebih baik untuk berlatih dan memperbaiki kebiasaan baik di rumah dan membiarkan mereka meresapi kode Anda di tempat kerja. Itu akan membantu Anda dan itu akan membantu orang lain.

Setiap pemrograman yang Anda lakukan dan setiap pemikiran yang Anda lakukan tentang pemrograman adalah latihan. Buat itu berharga, kalau tidak akan kembali dan menggigit Anda.

Lihatlah sisi baiknya. Anda telah menanyakan hal ini, jadi mungkin Anda sudah mengetahui poin yang saya sampaikan.

— Daniel Hollinrake
sumber

1

Ya, saya sadar tetapi inti pertanyaannya adalah sebagian besar dalam konteks yang lebih kecil dan terkandung tampaknya tidak ada alasan untuk menjadi begitu tepat. Dalam semua tahun pemrograman saya, benar-benar belum ada banyak yang merayap kembali untuk menggigit kita. Saya ragu bahwa kita sangat pantas. Saya pikir itu bahasa dan harapan berubah seperti perangkat lunak normal. Beberapa kurang dari yang lain. Tetapi pada akhirnya, ketidakefisienan satu proyek hanya dapat direalisasikan ketika proyek tersebut di masa lalu dan tidak lagi penting. Itu membuatnya sulit untuk membenarkan sakit kepala karena begitu kaku.

— Kai Qing

Itu poin yang adil. Aturan hari ini bisa menjadi batasan besok. Saya tidak menikmati diberi tahu apa yang harus dilakukan, tetapi saya menghormati orang lain yang telah pergi sebelumnya dan telah belajar dengan cara yang sulit. Kadang-kadang meskipun menarik untuk mengetahui aturan apa yang berguna dan apa yang sudah melewati tanggal penjualannya.

— Daniel Hollinrake

1

Jika pembuat furnitur membuat perabot yang akan digunakan di mana kualitasnya tidak terlalu penting atau di mana kualitasnya tidak diperhatikan, haruskah mereka tetap berusaha membuat potongannya lurus, dan melakukan pekerjaan yang tepat dengan menggabungkan potongan-potongan itu?

Banyak orang melihat perangkat lunak sebagai keahlian. Apa yang kita bangun tidak hanya menjalankan fungsi, itu harus dapat diandalkan, dipelihara, kuat. Membuat perangkat lunak semacam itu membutuhkan keterampilan, dan keterampilan itu berasal dari latihan.

Jadi, meskipun pilihan konstruksi perulangan untuk apa yang Anda kerjakan hari ini mungkin tidak masalah, fakta bahwa Anda berusaha untuk menggunakan konstruksi yang tepat setiap saat, seiring waktu, akan menjadikan Anda seorang programmer yang lebih baik.

— Bryan Oakley
sumber

Saya telah menemukan contoh dalam pemrograman di mana kode tidak perlu dirawat atau melakukan di luar kebutuhan. Seperti utilitas kios untuk pameran dagang atau acara yang sangat spesifik dan tidak mungkin digunakan kembali. Dalam hal permainan saya sendiri - saya adalah satu-satunya yang mempertahankannya, sehingga argumen itu mungkin bukan yang paling berlaku. Saya masih memiliki keraguan tentang perspektif umum tentang "programmer yang lebih baik" karena kepatuhan yang ketat terhadap pedoman, pemeliharaan, dan penggunaan tipe data yang tepat dapat menjadi penghalang untuk tidak menyelesaikan proyek. Jika kode berfungsi seperti yang diharapkan, mengapa menyempurnakannya?

— Kai Qing

Bahkan jika perangkat lunak yang Anda bangun right_now tidak perlu dipelihara, menulis perangkat lunak seolah-olah itu memperkuat keterampilan pengkodean Anda. Ketika akhirnya Anda harus menulis kode yang bisa dipelihara, Anda akan dapat melakukannya dengan lebih mudah.

— Bryan Oakley

Saya harus menulis kode yang bisa dipelihara setiap saat. Hanya dalam beberapa kasus tidak harus begitu. Namun, saya punya banyak pengalaman jadi saya biasanya tahu kapan dan di mana harus mengambil jalan pintas. Maksud dari posting ini adalah untuk hanya membangkitkan pembicaraan tentang ambang batas yang tepat dan ceroboh untuk tujuan apa pun. Contoh saya hanya menyikat ringan karena contoh yang diberikan sebagian besar tidak berbahaya dalam aplikasi yang lebih kecil. Namun, jika saya menulis perangkat lunak bank saya tidak akan pernah begitu ceroboh.

— Kai Qing