Alat pemrograman yang paling diremehkan [ditutup]

35

Kami memiliki banyak alat hebat yang banyak membantu saat pemrograman, seperti editor teks programmer, IDE, debugger, sistem kontrol versi, dll. Beberapa alat lebih atau kurang "harus memiliki" alat untuk menyelesaikan pekerjaan (misalnya kompiler) .

Masih selalu ada alat yang banyak membantu, tetapi masih tidak mendapatkan banyak perhatian, karena berbagai alasan, misalnya, ketika mereka dibebaskan, mereka berada di depan waktu mereka dan sekarang lebih atau kurang dilupakan.

Menurut Anda, jenis alat pemrograman apa yang paling diremehkan? Memotivasi jawaban Anda.

tools  developer-tools 
— Anto
sumber
3
Otak kita? - -
— Trufa
Oke, siapa yang ingin menambahkan entri Lisp? * nyengir *
— Mark C

Jawaban:

70

Bebek karet. Ya benar

http://en.wikipedia.org/wiki/Rubber_duck_debugging

Debugging bebek karet , merunduk karet , dan tes bebek karet adalah istilah informal yang digunakan dalam rekayasa perangkat lunak untuk merujuk pada metode kode debugging. Namanya adalah referensi ke cerita apokrif yang kemungkinan besar di mana seorang programmer ahli yang tidak disebutkan namanya akan menyimpan bebek karet di dekat mejanya setiap saat, dan men-debug kodenya dengan memaksa dirinya sendiri untuk menjelaskannya, baris demi baris, kepada bebek.

Untuk menggunakan proses ini, seorang programmer menjelaskan kode ke objek mati, seperti bebek karet, dengan harapan bahwa setelah mencapai sepotong kode yang salah dan mencoba menjelaskannya, programmer akan melihat kesalahan. Dalam menggambarkan apa yang seharusnya dilakukan oleh kode dan mengamati apa yang sebenarnya dilakukannya, ketidaksesuaian antara keduanya menjadi jelas ...

— Andiaz
sumber
6
Saya melakukan ini sepanjang waktu dengan suami saya. Sebagai seorang pria dukungan teknis dengan hanya sedikit kemampuan pemrograman, dia mengerti sekitar 60% dari apa yang saya katakan tetapi memaksa saya untuk menjelaskan 40% yang tidak saya mengerti juga. Jumlah kesempatan di mana ia bekerja sangat mengesankan.
— Ethel Evans
1
Kamu tertawa. Saya memiliki rekan kerja yang benar-benar memiliki bebek karet di mejanya.
— Berin Loritsch
57
Saya mencobanya, tetapi bebek karet saya sepertinya tidak bisa fokus pada masalah. Di mana saya dapat menemukan bebek karet yang berkualifikasi dengan minat asli pada pemrograman?
— Steve314
3
Saya menggunakan jurnal saya untuk ini. Terkadang saya berdiskusi cukup panjang dengan diri saya sendiri. Saya berharap bisa membuat diri saya mengerti apa yang saya maksud, kadang-kadang. Menulis ini ke dalam jurnal terkadang sangat membantu nantinya, ketika saya bertanya-tanya apa yang dipikirkan orang idiot yang menulis kode yang sedang saya kerjakan.
— Lars Wirzenius
1
@Steve: Peneliti Jepang sedang mengerjakannya, tapi saya tidak berpikir mereka dekat: youtube.com/watch?v=3g-yrjh58ms
— Rei Miyasaka
42

Pena dan buku catatan.

  1. Bekerja tanpa listrik.
  2. Portable.
  3. Gambar oranye di / di saat bosan dalam rapat
  4. Simpan informasi yang bermanfaat.
  5. Jika ditulis, orang akan lebih mementingkan itu.
  6. Orang lain dapat membacanya dan belajar.
— Sparky
sumber
Di masa lalu perusahaan besar, insinyur dan teknisi akan diberikan notebook rekayasa kosong di mana mereka akan menulis semua hal yang kita cenderung untuk memasukkan berbagai file dalam hard drive kita. Ketika notebook diisi, mereka akan dikirim ke repositori yang aman dan aman. Jika ada yang perlu memiliki akses ke catatan itu, mereka dapat memeriksa buku catatan.
— oosterwal
3
Rusia menggunakan pensil.
— Pekerjaan
@ Ayub Hah, saya masih menggunakan sebotol tinta! (... Yah, hanya untuk kaligrafi, tapi tetap saja.)
— Mateen Ulhaq
Bagaimana dengan Tablet PC?
— Mateen Ulhaq
1
@Job: ... dan vodka!
— Spoike
38

Alat Diff tampaknya kurang digunakan ketika membandingkan output log atau data dalam file teks datar. Atau mungkin itu hanya ceruk? Sepertinya saya merasa sangat berguna dan bermanfaat untuk debugging untuk membandingkan log besar eksekusi program dan menunjukkan satu atau dua detail yang berubah.

Alat profil kinerja juga sangat baik untuk dimiliki, terutama ketika Anda menekan bottelneck kritis, tetapi tampaknya sangat sedikit orang yang mengenalnya (dan saya mengakui diri saya pada gelar dalam kategori ini).

Alat XML yang baik sangat penting - jika Anda bekerja dengan file XML lebih dari selusin baris atau skema multipel. Terkadang Anda membutuhkan lebih dari sekadar sintaks dasar yang menyoroti editor lain. Juga ketika bekerja dengan XML, belajar XSL bisa sangat berguna. Banyak kali saya melihat apa yang bisa dilakukan dalam transformasi XSL sederhana yang dilakukan dalam banyak baris dalam kode aplikasi. Meskipun untuk memperjelas: Saya tidak menyarankan bahwa XML itu sendiri adalah "alat pemrograman yang diremehkan"; Saya menyarankan bahwa nilai editor XML yang baik diremehkan, dari apa yang saya lihat.

— FrustratedWithFormsDesigner
sumber
1
++ Benar diff- benar kurang dihargai. Pada masalah pembuatan profil, Anda tidak sendirian dalam berpikir bahwa itu pasti berguna, tetapi Anda sendiri tidak tahu caranya. Periksa ini.
— Mike Dunlavey
Ya, saya sudah berpikir tentang benar-benar belajar alat profil, tetapi tidak pernah sampai pada itu
— Anto
23
+1 untuk profil, +1 untuk alat berbeda, -1 untuk alat XML. Beberapa orang, ketika dihadapkan dengan masalah, berpikir "Saya tahu, saya akan menggunakan XML." <Problem:Worsening> <Problem:TimeDescription>Now</Problem:TimeDescription> <Problem:Posessive>they have</Problem:Posessive> <Problem:Quantity>many, many</Problem:Quantity> <Problem:WorseningDescription>more problems</Problem:WorseningDescription></ProblemWorsening>
— Mason Wheeler
2
@ Alasan: XML Lucu.
— Mike Dunlavey
10
@Mason Wheeler: Saya tidak menyarankan XML sebagai alat untuk menyelesaikan masalah, saya menyarankan Good XML Tools - ketika Anda harus bekerja dengan XML, pastikan Anda memiliki editor / alat yang sangat bagus. Sesuatu yang dapat mengeksekusi query Xpath, validasi skema, transformasi, perbandingan nilai vs struktur (sejenis alat diff saya kira) dll ... Editor sederhana dengan highlighting tidak dapat memotongnya ketika sesuatu menjadi berantakan - mereka sering membuat sesuatu lebih buruk (btw saya suka kode XML Anda;)).
— FrustratedWithFormsDesigner
37

Ekspresi Reguler

Mereka sangat berguna. Mereka membantu ketika mencari melalui file log, parsing teks dll. Mereka hanya sangat berguna.

Saya merasa aneh berapa banyak orang yang saya kenal yang tidak pernah menggunakannya karena ada sedikit kurva belajar yang terkait dengan mereka. Banyak kali saya melihat orang melakukan hal-hal dengan cara yang sulit (Catatan: sebelum regex saya melakukan hal-hal dengan cara yang sulit) ketika sebuah regex sederhana bisa menurunkannya dengan cepat.

— barrem23
sumber
8
Ingatlah bahwa Ekspresi Reguler bukan pisau tentara Swiss, sekalipun bagus jika diterapkan dengan benar.
— Anto
10
Sangat berguna - tetapi sering disalahgunakan, yang mengarah ke kode misterius yang tidak dapat dipelihara. Pepatah lama "sekarang Anda memiliki dua masalah" memang memiliki dasar dalam kenyataan.
— Steve314
4
RegExes adalah pisau tentara Swiss: Alat yang memadai untuk banyak pekerjaan cepat, meskipun mungkin bukan alat yang tepat untuk membangun seluruh rumah.
— JasonTrue
4
Hmm, entah kenapa aku selalu mendapat kesan regex masih jauh dari diremehkan. Terlalu sering saya melihat orang meraih regex di mana split / for-loop sederhana sudah mencukupi atau ketika regex bukan jawabannya (mis. Parsing xml / html).
— MAK
Saya telah melihat kedua fenomena: Regex? Hal-hal itu tidak dapat dibaca / lamban / masukkan merendahkan di sini dan "Apa cara terbaik untuk mem-parsing (memasukkan tata bahasa yang benar-benar tidak biasa) dengan satu regex?"
— JasonTrue
24

Rekan tim Anda. Ketika Anda tidak memiliki ide yang menarik dan lupa untuk bergabung dengan tim Anda, Anda tidak akan pernah mendengar kekhawatiran atau ide mereka tentang mengapa itu tidak berhasil atau mengapa itu bisa lebih baik.

Saya mengatakan ini, karena mudah untuk berpikir bahwa pemrograman adalah beberapa hal antisosial yang dilakukan orang di sudut dengan ide-ide cemerlang mereka. Orang yang berpikir ini meremehkan nilai tim dan rekan satu timnya dalam membantu membuat ide / proyek tenggelam / berenang.

— Doug T.
sumber
Rekan setim yang baik tidak pernah bisa dinilai terlalu tinggi. Sebagian besar perangkat lunak dan perangkat keras dapat.
— Tipe Anonim
19

Google. Ada beberapa masalah yang belum dipecahkan dan didokumentasikan. Kueri Google yang disesuaikan dengan baik dapat menghemat banyak waktu bagi semua orang.

— Adam Crossland
sumber
13
Alat yang bagus tapi saya tidak yakin saya akan menyebutnya diremehkan, setidaknya tidak lagi (mungkin saya akan setuju 9 atau 10 tahun yang lalu).
— FrustratedWithFormsDesigner
12
Maaf, tapi Google diremehkan? Paling tidak Google
— ditaksir
2
Saya tahu saya tahu! Tapi alasan saya untuk mengatakan bahwa itu adalah terlalu rendah adalah salah satu yang saya kira Anda akan setuju dengan: setidaknya 75% dari pertanyaan yang ditanyakan di StackOverflow mudah dijawab dengan Google, ya? Jelas, sampai taraf tertentu diremehkan jika banyak orang yang tidak menggunakannya. Jika alasan saya cacat, saya akan menghapus jawaban saya.
— Adam Crossland
3
@Adam Crossland: 75% bersikap baik. Saya pikir ini lebih tinggi dari itu.
— S.Lott
1
@adam @ s.lott jadi saya kira intinya adalah bahwa Google tidak digunakan dengan benar. Dengan itu saya setuju. Begitu banyak pertanyaan yang dapat dijawab (tidak perlu ditanyakan) jika orang tahu cara menggunakan Google dengan benar. Salam.
— eestein
16

Jauh dan jauh alat yang paling tidak dihargai untuk menemukan "bottlenecks" adalah Ctrl+ Catau tombol "Jeda", di debugger.

Periksa paragraf terakhir dari posting ini , dan posting ini , dan posting ini , sebagai permulaan.

Berkali-kali saya melihat / mendengar orang mengatakan "Programnya terlalu lambat! Apa yang bisa saya lakukan? Saya mencoba profiler (jika mereka tahu), tetapi saya tidak mengerti apa yang dikatakannya. Adakah yang punya dugaan? Tolong! " Yah, tebakan hanya itu. Apa yang selalu saya lakukan, dan yang lainnya juga, adalah menjalankannya, menyela, dan memeriksa tumpukan panggilan. Jika masalahnya benar-benar buruk, bingo , itu tepat di depan Anda. Jika masalahnya hanya ringan, Anda melakukannya beberapa kali. Apa pun yang muncul pada lebih dari satu sampel, yang dapat Anda hindari, adalah hambatan yang dapat Anda perbaiki.

Ya, ini umpan balik, tetapi berhasil.

— Mike Dunlavey
sumber
Seseorang seharusnya tidak meremehkan instrumen tumpul. Jelas ini bukan jawaban yang selalu tepat, tetapi bisa saja. Sebut saja pendekatan urutan pertama, yang akan disempurnakan oleh profiler nyata jika diperlukan.
— Kristof Provost
@ Kristof: Sangat menggoda untuk berpikir begitu, dan ada masalah yang tidak dapat ditangani, dan ada kasus di mana sampel tidak mudah didapat, tetapi profiler tidak dapat menangani kasus itu juga, kecuali untuk jenis tertentu, seperti Zoom , dan meskipun begitu mereka sebenarnya tidak lebih baik dalam arti menuntun Anda langsung ke masalah.
— Mike Dunlavey
@ Kristof: Ini jenis masalah penghentian acak yang tidak bagus - di mana jika Anda mengambil snapshot tepat waktu dan mempelajarinya, Anda tidak dapat memberi tahu alasan apa yang dilakukannya. Contoh: pemrosesan berdasarkan pesan, di mana Anda tidak dapat mengetahui dari mana pesan itu dikirim atau mengapa atau seberapa sering. Contoh lain: protokol asinkron, di mana pesan dipertukarkan, dan sepertinya kita selalu menunggu orang lain. Untuk pemrosesan yang sinkron, profiler dapat mengukur lebih baik, tetapi berhenti secara acak lebih baik dalam menemukan .
— Mike Dunlavey
14

Menurut Anda, jenis alat pemrograman apa yang paling diremehkan? Memotivasi jawaban Anda.

Kompiler.

Kebanyakan orang tidak meluangkan waktu untuk memahami apa yang dilakukan oleh kompiler pilihan mereka. Mereka hanya merasa bahwa itu membuat kode menjadi program yang dapat dijalankan dan sejauh itulah yang mereka lakukan. Pada sebagian besar yang modern, ada beberapa konfigurasi yang dapat Anda masukkan ke dalamnya membuatnya melakukan apa yang Anda butuhkan. Berikut ini sebuah contoh, saya yakin setengah pengembang di kantor Anda tidak tahu bagaimana mengatur peringatan sebagai tingkat kesalahan (dengan asumsi itu benar-benar ada). Opsi apa yang harus Anda miliki untuk menghasilkan simbol debug? Optimalisasi mana (atau level berapa) yang Anda inginkan. Daftarnya berlanjut.

— Kevin
sumber
3
@ Kevin: dan saya akan menambahkan cara untuk menulis kode agar kompiler melakukan pemeriksaan untuk Anda (untuk bahasa yang diketik secara statis). Sebagian besar pengembang menggunakan jenis rak (seperti string) untuk mewakili semua jenis info, di mana mereka dapat menentukan jenis yang sederhana namun tidak kompatibel untuk data yang tidak terkait ... dan memiliki kompiler yang tidak mereka ganggu ketika menyampaikan argumen.
— Matthieu M.
@ Matthieu M Itu juga poin yang bagus. Banyak orang lupa cara mudah untuk membantu Anda.
— kemiller2002
3
Setiap peringatan kompiler adalah hadiah yang berharga. Jangan abaikan mereka! Minta lebih banyak! -Teror harus menjadi kewajiban.
— Kristof Provost
@ Kristof: -pedantic -Wall -Wextra -Werror... meskipun itu bisa sulit untuk membangun apa pun kemudian: p
— Matthieu M.
Mungkin hanya saya, tetapi jika "setengah dari para devs" tidak tahu bagaimana dengan simbol debug "tidak berlebihan, itu cukup menakutkan.
— kizzx2
10

Otakmu. Alat-alat lain tidak akan memiliki banyak makna tanpa itu.

— jnevelson
sumber
4
Saya telah membuat sebagian besar milik saya tidak dapat digunakan pada kesempatan tertentu.
— David Thornley
3
"kurang lebih dilupakan": -S
5
Saya akan mengatakan itu diremehkan. Terlalu banyak orang selalu mencari jalan pintas sehingga mereka tidak perlu berpikir. Tidak ada pengganti untuk akal sehat dan logika, dan alat tidak bisa menggantikannya.
— jnevelson
2
Saya setuju dengan Jonathan, otaknya sering diremehkan. Kenyataannya, terlalu banyak programmer yang mengandalkan sedikit trik yang mereka tahu alih-alih melangkah keluar dari kotak dan kadang-kadang menulis sebuah test case dan alat tes yang dipesan khusus (murah dan kotor, membuang kelas) untuk menyelidiki masalah yang ada. Saya memiliki banyak kesempatan memberikan para pengembang cara untuk melampaui keadaan berpikir mereka dan menyelesaikan masalah mereka dengan tidak lebih dari beberapa pertanyaan.
— asoundmove
1
Beberapa komentar membuat saya mengubah pendapat saya, +1 :)
— Anto
10

Bagus tua:

print

Terkadang debugger atau profiler atau diagram alir UML berguna. Dan terkadang mereka membuatmu gila. Saya selalu menemukan diri saya kembali menggunakan pernyataan cetak (atau melacak atau NSLog atau apa-apa-Anda) hanya untuk memastikan kode saya melakukan apa yang saya pikir itu lakukan ketika saya pikir itu melakukannya.

— JRW
sumber
Saya pikir ini tergantung pada bahasa dan debugger. Jenis-jenis debugger yang ditawarkan oleh sebagian besar IDE yang layak saat ini untuk bahasa populer memungkinkan Anda melakukan banyak hal lebih mudah daripada mencetak pernyataan.
— Billy ONeal
8

Skrip lama polos ... tidak peduli berapa banyak bahasa generasi berikutnya yang kami kembangkan, kami masih sangat bergantung pada skrip juga sebagian besar tugas sehari-hari dapat dicapai dengan menulis beberapa baris skrip.

— Gaurav Sehgal
sumber
1
Lihat .. Saya tidak setuju dengan yang ini. Ya, skrip dapat mengotomatisasi beberapa tugas. Tetapi seringkali mereka dibawa jauh melampaui titik indra ke titik di mana mereka hanya menjadi tombak besar spageti.
— Billy ONeal
1
Benar, skrip besar mengerikan untuk dilihat dan orang mungkin menggunakan perl atau python untuk itu. Meskipun mereka masih hebat dalam menyelesaikan pekerjaan kecil.
— Gaurav Sehgal
@Billy Gunakan python. Masalah Spaghetti terpecahkan :)
— Evan Plaice
7

Pena dan papan tulis.

Anda tidak dapat mengalahkan teknologi rendah ketika mencoba menjelaskan sesuatu.

— Andy Lowry
sumber
3
Jawaban
— rangkap
Mungkin jawaban duplikat, tetapi menghasilkan suara saya terpisah untuk papan tulis.
— Carson Myers
Hmm, cukup yakin itu bukan duplikat ketika saya membuatnya, sangat aneh. Saya akan mengubahnya ke Pena dan Papan Tulis.
— Andy Lowry
5

Perl dan bahasa scripting lainnya. Bagus untuk tugas yang agak terlalu rumit untuk alat GUI seperti Agen Ransack.

— kevin cline
sumber
1
Saya tidak yakin mereka diremehkan ...
— Anto
3
Pasti diremehkan ... terutama Perl. Itu adalah lang. dirancang dengan sangat baik dengan motto tetap hal-hal sederhana ... dengan demikian, itu tak ternilai untuk tugas cepat yang hanya perlu dilakukan.
— Benteng
@Rook: Saya tidak yakin bagaimana bahasa dengan lebih dari 100 operator dapat dianggap "sederhana". Berguna, mungkin. Tapi bukan "sederhana".
— Billy ONeal
@ Billy - Sederhana tidak mengecualikan kuat. Saya menemukan kalkulator sederhana. Saya tidak tahu setengah dari 300 fungsi yang saya miliki, tetapi itu tidak mengurangi kesederhanaannya.
— Benteng
4

Pintasan keyboard yang memungkinkan pemulihan ulang yang cepat, sering, dan aman. Mempelajari cara mengekstrak (atau sebariskan dll) variabel, metode, konstanta, atau kelas dengan menekan beberapa tombol pada dasarnya mengubah cara saya membuat kode. Anda hanya akan sering refactor (yaitu cukup) ketika biayanya minimal, sehingga membuat pintasan ini sifatnya penting untuk menulis dan memelihara kode yang baik sejauh yang saya ketahui.

Jadi secara umum, gunakan alat yang bagus (IDE / editor) dan pelajari cara mendapatkan sebagian besar fitur yang mereka sediakan.

Pengujian unit dan TDD berikutnya, untuk menjaga kode Anda dapat diuji dan mencegah takut refactoring.

Gunakan ini dan Anda akan dengan mudah bergerak menuju penulisan kode yang dapat dipelihara yang sesuai dengan prinsip KERING dan mendokumentasikan diri.

— Alb
sumber
4

Pengujian unit menawarkan manfaat berikut:

  • Pengembang menjadi klien pertama dari kode tersebut. Semakin cepat bug ditangkap, semakin murah untuk memperbaikinya. Bug dapat ditangkap sebelum membangun, menginstal, atau penyebaran .
  • Pengujian mengubah perspektif Anda pada kode. Apakah desainnya jelas? Apakah ini menangani kasing sudut?
  • Efek Hawthorne akan meningkatkan kualitas, hanya dengan mengumumkan bahwa suatu tim menerbitkan metrik kualitas / pengujian.
  • Bahkan jika tes tidak dicek ke dalam kontrol sumber, mereka bisa menjadi cara yang bagus untuk menjelajahi dan mempelajari medan baru.
  • Peluang bug lebih sedikit!
— Michael Easter
sumber
4

Pembuat kode

Pembuat kode dapat membuat kode efisien dan bebas bug dalam jumlah besar dari definisi sederhana. ORMPenggunaan tipe adalah yang paling jelas untuk membuat kelas akses data, tetapi ada banyak kegunaan yang lebih potensial.

Dukungan pembuatan kode tampaknya masih dalam tahap awal baik dari sudut pandang programmer maupun kerangka kerja, tapi saya yakin ini adalah sesuatu yang akan semakin banyak kita lihat. Di .NET Anda dapat mulai mencoba-coba hal-hal CodeDOM .

— konrad
sumber
Saya suka menulis generator kode, bukan hal termudah untuk mendapatkan yang benar, tapi oh sangat berguna.
— Zachary K
3

Saya banyak menggunakan AgentRansack . Ini sangat membantu mencari melalui ribuan file dengan sangat cepat. Ini telah menghemat banyak waktu saya, tetapi saya tidak tahu banyak programmer yang tahu atau menggunakannya.

— JakeRadakovich
sumber
3

Metode Formal.

http://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X

http://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800/ref=pd_sim_b_1

Sulit untuk melebih-lebihkan pentingnya mereka. Setiap loop dan setiap pernyataan if dimulai sebagai sebuah ide yang membutuhkan semacam "bukti". Kebanyakan programmer melakukan pembuktian ini sebagian besar waktu di kepala mereka. Anda bertanya apa yang dilakukan pernyataan if dan mereka dapat mengartikulasikan - dengan jelas dan logis - apa pilihannya dan mengapa pilihannya lengkap, konsisten, dan eksklusif.

Tetapi beberapa hanya menebak secara acak. Mereka membutuhkan lebih banyak bantuan dan metode formal bisa menjadi jenis bantuan yang mereka butuhkan.

Itu hanya aljabar (dan kalkulus) untuk kode. Tidak ada yang terlalu rumit atau canggih.

— S.Lott
sumber
Saya telah menemukan mereka sering berguna untuk mendapatkan hal-hal sederhana dengan benar sehingga saya dapat mengandalkannya saat men-debug hal-hal yang lebih rumit. Pengalaman saya adalah bahwa metode formal cukup baik menghilangkan bug halus, hanya menyisakan yang mencolok yang mudah tertangkap dengan pengujian.
— David Thornley
3

Pola desain fisik seperti meninggalkan kursi untuk berlari cepat di bawah sinar matahari dan udara segar menjaga otak kita tetap berjalan pada keangkeran puncak.

— Joe Chrysler
sumber
3

Nah itu Half Life 2 (masukkan game favorit Anda di sini). Jika saya mendapat masalah saya tidak bisa menyelesaikannya, saya hanya berhenti dan mulai bermain dengan permainan favorit saya dan tiba-tiba solusinya muncul di pikiran saya. Jadi jujur ​​saja itu bukan permainan atau sesuatu seperti itu tetapi melakukan sesuatu yang lain . Saya sering melihat orang duduk di masalah selama berjam-jam tanpa menyelesaikannya dan semua yang harus mereka lakukan adalah membuat otak mereka offline untuk waktu yang singkat.

— Adam Arold
sumber
3

Stack Overflow - bantuan ahli cepat ketika Anda terjebak

situs tanya jawab untuk programmer profesional dan antusias. Ini dibuat dan dijalankan oleh Anda sebagai bagian dari jaringan Stack Exchange situs Q&A. Dengan bantuan Anda, kami bekerja sama untuk membangun perpustakaan jawaban terperinci untuk setiap pertanyaan tentang pemrograman ...

— agas
sumber
+1, tapi tidak terlalu diremehkan lagi
— MAK
4
bahkan mungkin melebih-lebihkan, atau setidaknya digunakan secara berlebihan
— Anto
3

Saya pikir itu adalah Notepad / TextPad / program pengeditan teks sederhana. Setiap orang memiliki waktu ketika mereka membutuhkan perbaikan cepat yang tidak memerlukan pembukaan IDE dan hanya perlu mengedit cepat. Dan semua komputer memiliki semacam program pengeditan teks sederhana.

— Peter Mortensen
sumber
2

Meminta dan alwaysAssert()fungsi yang baik . IMHO ini lebih penting daripada tes unit, karena tes unit hanya dapat menemukan bug dalam kasus tertentu yang Anda pikir akan diuji. Jika programmer yang sama menulis kode dan tes, dia mungkin akan kehilangan kasus tepi yang sama di keduanya. Selain itu, kadang-kadang pengujian unit tidak praktis karena lingkungan di mana komponen berfungsi dan / atau data yang dioperasikannya terlalu rumit untuk menghasilkan kasus uji yang dibuat-buat.

Keindahan penegasan terletak pada kemampuan mereka untuk mendokumentasikan asumsi dan mengujinya pada input yang tidak dibuat-buat . Jika salah satu dari asumsi ini salah, kode Anda gagal dengan keras alih-alih "berfungsi" tetapi menghasilkan hasil yang sedikit salah. Itu juga gagal lebih dekat ke akar masalah daripada itu tanpa menegaskan. Dalam praktiknya, jika Anda secara eksplisit menyatakan asumsi yang cukup tentang sepotong kode dan semua asumsi ini benar maka kode tersebut biasanya benar.

Satu keluhan umum tentang menegaskan adalah bahwa mereka dapat dimatikan. IMHO setiap bahasa atau pustaka standar harus memiliki alwaysAssert()fungsi atau persamaan kasar yang melakukan hal yang sama asserttetapi tidak dapat dimatikan. Ini dapat digunakan untuk memeriksa asumsi dalam bidang kode non-kinerja yang kritis, di mana manfaat mematikan konfirmasi diabaikan.

— dsimcha
sumber
Sepakat. Namun sayangnya sederhana, namun efisien, alat seperti ini sering kurang dihargai.
— Peter Mortensen
2

Kunci F1. - Berguna untuk program yang tidak Anda kenal dan untuk program yang sedang Anda kerjakan. (Dengan asumsi bahwa itu adalah aplikasi besar.)

Kuat untuk menyaring masalah adalah pengguna melaporkan bug berdasarkan interpretasi mereka tentang bagaimana perangkat lunak seharusnya bekerja. Tentu saja, bisa jadi desainnya sendiri cacat. Tapi itu cerita lain.

— Jeremy Edwards
sumber
2
Baik diremehkan dan juga kurang diterapkan.
— Tipe Anonim
Sangat diremehkan oleh pengembang aplikasi yang Anda gunakan saat ini; dengan demikian bantuan tersebut mengandung sedikit atau tidak ada informasi berguna.
— colek
2

Berbagai utilitas inti UNIX, tetapi utamanya finddan sesekali grepatau ed. Kemampuan untuk menemukan hal-hal di sarang file yang dalam sangat berharga, terutama ketika Anda tiba-tiba mewarisi basis kode dan harus memperbaikinya. Bahkan jika kode tersebut didokumentasikan dengan baik, Anda mungkin harus berburu, dan pemahaman yang kuat tentang findmembunuhnya.

— kojiro
sumber
2

Keingintahuan

Sebut saja "Teka-teki pemrograman." Apa alat dibandingkan dengan orang yang menggunakannya? Keinginan untuk mengetahui bagaimana dan mengapa sesuatu berfungsi atau tidak berhasil memperluas pengetahuan seseorang lebih dari alat spesifik apa pun dan itu benar di luar pemrograman.

— Thomas
sumber
1

Ekor

Ekor dapat digunakan untuk memantau file keluaran log program secara realtime. Telah sangat membantu ketika mengembangkan untuk sistem yang tidak menyediakan cara lain untuk membaca log.

Contoh program adalah;

— Pernyataan
sumber
Mac OS X adalah sistem UNIX. Tidak perlu menyebutkannya secara terpisah.
— rightfold
0

Saya bergabung bersama generator grafik panggilan Perl sekali. Itu sangat berguna, tetapi gagal pada kode non-prosedural atau out-of-file rutin.

— Paul Nathan
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.