Kaya sing dikandhakake, yen sampeyan ora isin karo kode lawas, mula sampeyan ora berkembang dadi programmer - lan aku setuju karo pendapat iki. Aku miwiti program kanggo seneng-seneng luwih saka 40 taun kepungkur, lan profesional 30 taun kepungkur, mula aku duwe akeh kesalahan. akèh. Minangka profesor ilmu komputer, aku mulang murid-muridku sinau saka kesalahane, kesalahanku, lan liya-liyane. Aku mikir iki wektu kanggo ngomong babagan kesalahanku supaya ora ilang andhap asor. Mugi padha bakal migunani kanggo wong.

Panggonan katelu - Microsoft C compiler

Guru sekolahku percaya yen Romeo lan Juliet ora bisa dianggep minangka tragedi amarga paraga kasebut ora duwe kesalahan tragis - dheweke mung tumindak bodho, kaya sing kudu ditindakake para remaja. Aku ora setuju karo dheweke banjur, nanging saiki aku weruh gandum saka rationality ing mratelakake panemume, utamané ing sambungan karo program.

Nalika aku rampung taun kapindho ing MIT, aku isih enom lan ora duwe pengalaman, ing urip lan program. Ing mangsa panas, aku magang ing Microsoft, ing tim kompiler C. Kaping pisanan, aku nindakake rutinitas kaya dhukungan profil, banjur aku dipasrahake kanggo nggarap bagian sing paling nyenengake saka compiler (kaya sing dakkira) - backend optimization . Ing tartamtu, aku kudu nambah kode x86 kanggo statements cabang.

Ditemtokake kanggo nulis kode mesin optimal kanggo saben cilik bisa, Aku mbuwang dhewe menyang blumbang headlong. Yen kapadhetan distribusi nilai dhuwur, aku mlebu tabel transisi. Yen padha duwe divisor umum, Aku digunakake kanggo nggawe meja tighter (nanging mung yen divisi bisa rampung nggunakake owah-owahan bit). Nalika kabeh nilai dadi kekuwatan loro, aku nindakake optimasi liyane. Yen sakumpulan nilai ora nyukupi kahananku, aku dibagi dadi sawetara kasus sing bisa dioptimalake lan nggunakake kode sing wis dioptimalake.

Iku ngipi elek. Pirang-pirang taun sabanjure aku dikandhani manawa programer sing marisi kodeku sengit karo aku.

Pawulangan sinau

Nalika David Patterson lan John Hennessy nulis ing Arsitektur Komputer lan Desain Sistem Komputer, salah sawijining prinsip utama arsitektur lan desain yaiku supaya kabeh bisa ditindakake kanthi cepet.

Nyepetake kasus umum bakal ningkatake kinerja kanthi luwih efektif tinimbang ngoptimalake kasus sing jarang. Ironis, kasus umum asring luwih gampang tinimbang sing jarang. Saran logis iki nganggep yen sampeyan ngerti kasus sing dianggep umum - lan iki mung bisa ditindakake liwat proses tes lan pangukuran sing ati-ati.

Ing pertahanan, aku nyoba kanggo mangerteni apa statements cabang katon ing laku (kayata carane akeh cabang ana lan carane konstanta disebarake), nanging ing 1988 informasi iki ora kasedhiya. Nanging, aku ora kudu nambah kasus khusus nalika kompiler saiki ora bisa ngasilake kode optimal kanggo conto buatan sing dakkarepake.

Aku kudu nelpon pangembang sing berpengalaman lan, bebarengan karo dheweke, mikir babagan kasus sing umum lan ditangani kanthi khusus. Aku bakal nulis kode kurang, nanging sing apik. Minangka pangadeg Stack Overflow Jeff Atwood wrote, mungsuh paling awon programmer iku programmer piyambak:

Aku ngerti sampeyan duwe niat sing paling apik, kaya kita kabeh. Kita nggawe program lan seneng nulis kode. Semono uga kita digawe. Kita mikir yen masalah apa wae bisa ditanggulangi kanthi tape tape, kruk krasan lan jiwit kode. Minangka akeh coders nglarani kanggo ngakoni, kode sing paling apik yaiku kode sing ora ana. Saben baris anyar mbutuhake debugging lan dhukungan, kudu dingerteni. Nalika sampeyan nambah kode anyar, sampeyan kudu nindakake kanthi wegah lan jijik amarga kabeh opsi liyane wis kesel. Akeh programer nulis kode akeh banget, dadi mungsuh kita.

Yen aku wis nulis kode prasaja sing nyakup kasus umum, mesthi bakal luwih gampang nganyari yen perlu. Aku ninggalake kekacoan sing ora ana sing pengin ditangani.

Panggonan kapindho: iklan ing jaringan sosial

Nalika aku kerja ing Google ing iklan media sosial (elinga Myspace?), Aku nulis kaya iki ing C++:

for (int i = 0; i < user->interests->length(); i++) {
  for (int j = 0; j < user->interests(i)->keywords.length(); j++) {
      keywords->add(user->interests(i)->keywords(i)) {
  }
}

Programer bisa langsung ndeleng kesalahan: argumen pungkasan kudu j, dudu i. Pengujian unit ora mbukak kesalahan, lan uga reviewerku. Peluncuran ditindakake, lan ing sawijining wengi kodeku menyang server lan nabrak kabeh komputer ing pusat data.

Ora ana sing ala. Ora ana sing rusak kanggo sapa wae, amarga sadurunge diluncurake global kode kasebut diuji ing siji pusat data. Kajaba SRE engineers mandheg muter bilyar kanggo nalika lan nindakake rollback sethitik. Esuke aku nampa email karo mbucal kacilakan, mbenerake kode lan nambah tes unit sing bakal nyekel kesalahan. Awit aku ngetutake protokol - yen kodeku mung bakal gagal - ora ana masalah liyane.

Pawulangan sinau

Akeh sing yakin yen kesalahan gedhe kuwi mesthi bakal biaya pemecatan pelakune, nanging ora mangkono: pisanan kabeh programer nggawe kesalahan, lan kapindho, padha arang nggawe kesalahan sing padha kaping pindho.

Nyatane, aku duwe kanca programmer sing dadi insinyur sing apik lan dipecat amarga nggawe kesalahan. Sawise iku, dheweke disewakake ing Google (lan banjur dipromosekake) - dheweke kanthi jujur ​​ngomong babagan kesalahan sing ditindakake ing wawancara, lan ora dianggep fatal.

Sing apa nyritakake babagan Thomas Watson, kepala legendaris IBM:

Pesen pemerintah sing regane kira-kira yuta dolar diumumake. IBM Corporation - utawa luwih, Thomas Watson Sr. pribadi - pancene pengin njaluk. Sayange, wakil sales ora bisa nindakake iki lan IBM ilang tawaran. Esuke, karyawan iki teka ing kantore Pak Watson lan nyelehake amplop ing mejane. Pak Watson malah ora nggagas-nggagas ngenteni pegawe lan ngerti yen iku surat pengunduran diri.

Watson takon apa salah.

Wakil sales ngandika rinci babagan kemajuan tender. Dheweke menehi jeneng kesalahan sing bisa ditindakake. Pungkasan, dheweke kandha, "Pak Watson, matur nuwun wis ngidini aku nerangake. Aku ngerti carane akeh kita needed pesenan iki. Aku ngerti sepira pentinge dheweke,” lan siap-siap lunga.

Watson nyedhaki dheweke ing lawang, nyawang dheweke ing mripate lan mbalekake amplop karo tembung: "Kepiye carane aku bisa ngeculake sampeyan? Aku mung nandur modal siji yuta dolar kanggo pendidikan sampeyan.

Aku duwe kaos sing ujar: "Yen sampeyan pancen sinau saka kesalahan, mula aku wis dadi master." Nyatane, nalika nerangake kesalahan, aku dadi dokter ilmu.

Panggonan pisanan: App Inventor API

Kesalahan sing nggegirisi nyebabake akeh pangguna, dadi kawruh umum, butuh wektu suwe kanggo mbenerake, lan ditindakake dening wong-wong sing ora bisa nggawe. Kesalahanku sing paling gedhe cocog karo kabeh kritéria kasebut.

Sing ala luwih apik

Aku maca karangan Richard Gabriel babagan pendekatan iki ing taun nineties minangka mahasiswa pascasarjana, lan aku seneng banget aku takon marang murid-muridku. Yen sampeyan ora ngelingi kanthi apik, refresh memori sampeyan, iku cilik. Esai iki mbedakake kepinginan kanggo "nyepetake" lan pendekatan "luwih becik" kanthi akeh cara, kalebu kesederhanaan.

Carane kudu: desain kudu prasaja ing implementasine lan antarmuka. Kesederhanaan antarmuka luwih penting tinimbang kesederhanaan implementasine.

Sing luwih elek, luwih apik: desain kudu prasaja ing implementasine lan antarmuka. Kesederhanaan implementasine luwih penting tinimbang kesederhanaan antarmuka.

Ayo lali babagan sedhela. Sayange, aku lali babagan iki nganti pirang-pirang taun.

Penemu Aplikasi

Nalika kerja ing Google, aku dadi bagian saka tim Penemu Aplikasi, lingkungan pangembangan online seret lan selehake kanggo pangembang Android sing kepengin banget. Iku 2009, lan kita padha cepet-cepet ngeculake versi alpha ing wektu supaya ing mangsa panas kita bisa terus kelas master kanggo guru sing bisa nggunakake lingkungan nalika mulang ing tiba. Aku sukarelawan kanggo ngleksanakake sprites, nostalgia carane aku digunakake kanggo nulis game ing TI-99/4. Kanggo sing ora ngerti, sprite minangka obyek grafis rong dimensi sing bisa mindhah lan sesambungan karo unsur piranti lunak liyane. Conto sprite kalebu pesawat ruang angkasa, asteroid, kelereng, lan raket.

Kita ngleksanakake App Inventor sing berorientasi obyek ing Jawa, mula mung ana akeh obyek ing kana. Amarga bal lan sprite tumindake padha, aku nggawe kelas sprite abstrak kanthi sifat (bidang) X, Y, Speed ​​​​(kacepetan) lan Heading (arah). Dheweke duwe cara sing padha kanggo ndeteksi tabrakan, mumbul ing pinggir layar, lsp.

Bentenane utama antarane bal lan sprite yaiku apa sing digambar - bunder sing diisi utawa raster. Wiwit aku ngleksanakake sprites pisanan, iku logis kanggo nemtokake x- lan y-koordinat pojok kiwa ndhuwur ngendi gambar dumunung.

Sawise sprites digunakake, Aku mutusaké sing aku bisa ngleksanakake obyek werni karo kode banget sethitik. Masalah mung aku njupuk rute paling gampang (saka sudut pandang saka implementer), nuduhake x- lan y-koordinat pojok kiwa ndhuwur kontur rongko werni.

Nyatane, perlu kanggo nunjukake koordinat x lan y saka tengah bunder, kaya sing diwulangake ing buku pelajaran matematika lan sumber liyane sing nyebutake bunderan.

Ora kaya kesalahanku sing kepungkur, iki ora mung mengaruhi kanca-kancaku, nanging uga jutaan pangguna App Inventor. Akeh sing padha bocah-bocah utawa anyar kanggo program. Dheweke kudu nindakake akeh langkah sing ora perlu nalika nggarap saben aplikasi sing ana bal. Yen aku kelingan kesalahanku liyane karo ngguyu, banjur iki nggawe aku kringet nganti saiki.

Aku pungkasanipun patched bug iki mung bubar, sepuluh taun mengko. "Patched", ora "fixed", amarga minangka Joshua Bloch ngandika, API langgeng. Ora bisa nggawe owah-owahan sing bakal mengaruhi program ana, kita ditambahaké OriginAtCenter property karo nilai palsu ing program lawas lan bener ing kabeh mangsa. Pangguna bisa takon pitakonan logis: sing malah mikir kanggo nempatake titik wiwitan nang endi wae liyane saka tengah. marang sapa? Kanggo siji programmer sing kesed nggawe API normal sepuluh taun kepungkur.

Piwulang sing Disinaoni

Nalika nggarap API (sing meh saben programer kudu nindakake kadhangkala), sampeyan kudu ngetutake saran paling apik sing digarisake ing video Joshua Bloch "Carane nggawe API apik lan apa iku penting banget"utawa ing dhaftar singkat iki:

• API bisa nggawa sampeyan entuk manfaat gedhe lan gawe piala.. API sing apik nggawe pelanggan baleni. Sing ala dadi ngipi elekmu.
• API umum, kaya berlian, langgeng. Menehi kabeh sampeyan: ora bakal ana kesempatan liyane kanggo nindakake kabeh kanthi bener.
• Njelaske nganggo bentuk garis API kudu ringkes - siji kaca karo kelas lan cara teken lan gambaran, njupuk munggah ora luwih saka baris. Iki bakal ngidini sampeyan gampang nyusun ulang API yen ora sampurna nalika sepisanan.
• Nerangake kasus panggunaansadurunge ngleksanakake API utawa malah nggarap spesifikasi. Kanthi cara iki sampeyan bakal ngindhari ngleksanakake lan nemtokake API sing ora bisa digunakake.

Yen aku wis nulis malah sinopsis singkat karo script Ponggawa, paling kamungkinan aku wis ngenali kesalahan lan mbenerake. Yen ora, salah sijine rekanku mesthi bakal nindakake. Keputusan apa wae sing duwe akibat sing adoh kudu dipikirake paling ora sedina (iki ditrapake ora mung kanggo program).

Judhul karangan Richard Gabriel, "Elek Luwih Luwih," nuduhake keuntungan sing dadi luwih dhisik ing pasar-sanajan produk sing ora sampurna-nalika wong liya nglampahi kalanggengan nguber sing sampurna. Nggambarake kode sprite, Aku éling sing aku malah ora kudu nulis kode liyane kanggo njaluk iku tengen. Punapa mawon sing bisa ngomong, aku grossly mistaken.

kesimpulan

Programer nggawe kesalahan saben dina, apa nulis kode buggy utawa ora pengin nyoba soko sing bakal nambah skill lan produktivitas. Mesthi, sampeyan bisa dadi programmer tanpa nggawe kesalahan serius kaya aku. Nanging ora mungkin dadi programmer sing apik tanpa ngerteni kesalahane lan sinau saka dheweke.

Aku terus-terusan nemoni siswa sing rumangsa akeh banget kesalahane lan mulane ora dipotong kanggo program. Aku ngerti carane umum sindrom impostor ing IT. Muga-muga sampeyan bakal sinau piwulang sing wis dakcathet - nanging elinga sing utama: saben kita nggawe kesalahan - isin, lucu, elek. Aku bakal kaget lan duka yen ing mangsa ngarep aku ora duwe cukup materi kanggo nerusake artikel.

Source: www.habr.com