Wiwit awal 2018, aku wis nyekel posisi timbal / bos / pangembang utama ing tim - sebut wae sing dikarepake, nanging sing penting aku tanggung jawab kanggo salah sawijining modul lan kabeh pangembang sing kerja. ing. Posisi iki menehi perspektif anyar babagan proses pangembangan, amarga aku melu luwih akeh proyek lan luwih aktif melu nggawe keputusan. Bubar, thanks kanggo loro kahanan iki, dumadakan aku temen maujud carane akeh ukuran pangerten mengaruhi kode lan aplikasi.
Titik sing dakkarepake yaiku kualitas kode (lan produk pungkasan) ana hubungane karo kepiye ngerti wong sing ngrancang lan nulis kode babagan apa sing ditindakake.
Sampeyan bisa uga mikir saiki, "Matur nuwun, Kap. Mesthine, luwih becik ngerti apa sing sampeyan tulis ing umum. Yen ora, sampeyan uga bisa nyewa klompok kethek kanggo mencet tombol sembarang lan ninggalake iku ing. Lan sampeyan pancen bener. Dadi, aku rumangsa ngerti yen sampeyan kudu duwe ide umum babagan apa sing sampeyan lakoni. Iki bisa disebut tingkat nul pangerten, lan kita ora bakal njelasno ing rinci. Kita bakal nliti kanthi rinci babagan apa sing kudu dingerteni lan kepiye pengaruhe ing keputusan sing sampeyan lakoni saben dina. Yen aku wis ngerti prekara-prekara kasebut, mula bakal nylametake aku akeh wektu sing boros lan kode sing bisa dipertanyakan.
Senajan sampeyan ora bakal weruh baris siji saka kode ing ngisor iki, Aku isih pracaya sing kabeh ngandika kene wigati banget kanggo nulis kualitas dhuwur, kode ekspresif.
Tingkat pangerten pisanan: Yagene ora bisa?
Pangembang biasane tekan level iki ing awal karire, kadhangkala tanpa bantuan saka wong liya - paling ora ing pengalamanku. Bayangake sampeyan nampa laporan bug: sawetara fungsi ing aplikasi ora bisa digunakake, kudu didandani. Kepiye sampeyan bakal nerusake?
Skema standar katon kaya iki:
- Temokake potongan kode sing nyebabake masalah (carane nindakake iki minangka topik sing kapisah, aku nutupi ing buku babagan kode warisan)
- Gawe owah-owahan ing cuplikan iki
- Priksa manawa bug wis didandani lan ora ana kesalahan regresi
Saiki ayo fokus ing titik kapindho - nggawe owah-owahan ing kode kasebut. Ana rong pendekatan kanggo proses iki. Kaping pisanan yaiku nyelidiki apa sing kedadeyan ing kode saiki, ngenali kesalahan lan ndandani. Kapindho: mindhah kanthi aran - nambah, ngomong, +1 menyang statement kondisional utawa daur ulang, ndeleng yen fungsi dianggo ing skenario sing dikarepake, banjur nyoba liyane, lan ing ad infinitum.
Pendekatan pisanan bener. Minangka Steve McConnell nerangake ing bukune Code Complete (sing dianjurake banget), saben-saben kita ngganti kode kasebut, kita kudu bisa prédhiksi kanthi yakin carane bakal mengaruhi aplikasi kasebut. Aku ngutip saka memori, nanging yen bugfix ora bisa kaya sing dikarepake, sampeyan kudu kuwatir lan sampeyan kudu takon kabeh rencana tumindak sampeyan.
Kanggo ngringkes apa wis ngandika, kanggo nindakake bug fix apik sing ora degrade kualitas kode, sampeyan kudu ngerti loro kabeh struktur kode lan sumber saka masalah tartamtu.
Pangerten tingkat kapindho: Kenapa bisa?
Tingkat iki dipahami kanthi intuisi luwih sithik tinimbang sing sadurunge. Aku, nalika isih dadi pangembang anyar, sinau matur nuwun marang bosku, lan banjur bola-bali nerangake inti saka perkara kasebut marang wong anyar.
Wektu iki, ayo bayangake sampeyan nampa rong laporan bug bebarengan: sing pertama babagan skenario A, sing nomer loro babagan skenario B. Ing skenario loro kasebut, ana sing salah. Mulane, sampeyan kudu ngatasi bug pisanan. Nggunakake prinsip sing dikembangake kanggo level 1 pangerten, sampeyan gali jero kode sing cocog karo masalah kasebut, ngerteni sebabe aplikasi kasebut tumindak kaya ing Skenario A, lan nggawe pangaturan sing cukup kanggo ngasilake asil sing dikarepake. . Kabeh dadi apik.
Banjur sampeyan pindhah menyang skenario B. Sampeyan mbaleni skenario ing upaya kanggo provoke kesalahan, nanging-surprise! - saiki kabeh mlaku kaya sing dikarepake. Kanggo konfirmasi guess sampeyan, batalaken owah-owahan sing digawe nalika nggarap bug A, lan bug B bali maneh. Bugfix sampeyan ngrampungake loro masalah kasebut. Bejo!
Sampeyan ora ngetung babagan iki. Sampeyan wis teka munggah karo cara kanggo ndandani kesalahan ing skenario A lan ora ngerti apa iku bisa kanggo skenario B. Ing tataran iki, iku banget nggodho mikir sing loro tugas wis kasil rampung. Iki cukup logis: tujuane kanggo ngilangi kesalahan, ta? Nanging karya durung rampung: sampeyan isih kudu ngerteni sebabe tumindak sampeyan mbenerake kesalahan ing skenario B. Apa sebabe? Amarga bisa uga nggarap prinsip sing salah, banjur sampeyan kudu golek dalan liyane. Ing ngisor iki sawetara conto kasus kasebut:
- Amarga solusi kasebut ora cocog karo kesalahan B, kanthi njupuk kabeh faktor, sampeyan bisa uga ora ngerti fungsi C rusak.
- Bisa uga ana bug katelu sing ana ing endi wae, sing ana gandhengane karo fungsi sing padha, lan bugfix sampeyan gumantung kanggo operasi sistem sing bener ing skenario B. Kabeh katon apik saiki, nanging ing sawijining dina bug katelu iki bakal diweruhi lan didandani. Banjur ing skenario B kesalahan bakal kelakon maneh, lan iku apik yen mung ana.
Kabeh iki nambah kekacauan ing kode lan bakal tiba ing sirahmu - paling kamungkinan ing wayahe paling ora cocog. Sampeyan kudu nglumpukake kemauan kanggo meksa sampeyan nggunakake wektu kanggo ngerti sebabe kabeh bisa ditindakake, nanging pancen pantes.
Tingkat pangerten katelu: Apa sebabe?
Wawasan anyarku ana hubungane karo level iki, lan bisa uga sing bakal menehi manfaat paling apik yen aku wis teka ing ide iki sadurunge.
Kanggo nggawe iku luwih cetha, ayo kang katon ing conto: modul sampeyan kudu digawe kompatibel karo fungsi X. Sampeyan ora utamané menowo karo fungsi X, nanging sampeyan marang sing kompatibel karo sampeyan kudu nggunakake framework F. Liyane modul sing nggabungake karo X bisa persis karo wong.
Kode sampeyan ora ana hubungane karo kerangka F wiwit dina pisanan urip, mula ora gampang banget kanggo ngetrapake. Iki bakal duwe jalaran serius kanggo sawetara bagéan saka modul. Nanging, sampeyan nggawe pangembangan dhewe: sampeyan nglampahi minggu nulis kode, nguji, nggulung versi pilot, entuk umpan balik, ndandani kesalahan regresi, nemokake komplikasi sing ora dikarepake, ora ketemu tenggat wektu sing disepakati, nulis kode liyane, nguji, entuk komunikasi umpan balik, mbenerake kesalahan regresi - kabeh iki kanggo ngleksanakake framework F.
Lan ing sawetara titik sampeyan dumadakan éling - utawa Mungkin krungu saka wong - sing Mungkin framework F ora bakal menehi kompatibilitas karo fitur X ing kabeh. Mungkin kabeh wektu lan gaweyan wis sijine ing rampung salah kanggo sing.
Ana kedadeyan sing padha nalika nggarap proyek sing aku tanggung jawab. Yagene iki kedadeyan? Amarga aku wis sethitik pangerten apa fungsi X lan carane related kanggo framework F. Apa aku kudu wis rampung? Takon wong sing menehi tugas pangembangan kanggo nerangake kanthi jelas carane tumindak sing dituju ndadékaké asil sing dikarepake, tinimbang mung mbaleni apa sing wis ditindakake kanggo modul liyane utawa njupuk tembung kasebut yen iki fitur X kudu ditindakake.
Pengalaman proyek iki ngajari aku supaya nolak miwiti proses pangembangan nganti kita duwe pangerten sing jelas babagan kenapa kita dijaluk nindakake perkara tartamtu. Nolak langsung. Nalika sampeyan nampa tugas, impuls pisanan yaiku langsung njupuk supaya ora mbuwang wektu. Nanging kabijakan "beku proyek nganti kita mlebu kabeh rincian" bisa nyuda wektu boroske kanthi pesenan gedhene.
Malah yen padha nyoba kanggo meksa sampeyan, kanggo meksa sampeyan miwiti karya, sanajan sampeyan ora ngerti nyoto kanggo iki, nolak. Pisanan, goleki sebabe sampeyan diwenehi tugas kasebut, lan mutusake apa iki dalan sing bener kanggo tujuan kasebut. Aku kudu sinau kabeh iki kanthi cara sing angel - muga-muga contoku bakal nggawe urip luwih gampang kanggo wong sing maca iki.
Tingkat pemahaman kaping papat: ???
Ana tansah liyane sinau ing program, lan aku pracaya aku wis mung kegores lumahing topik pangerten. Apa tingkat pangerten liyane sing wis ditemokake sajrone pirang-pirang taun nggarap kode? Apa keputusan sing sampeyan lakoni sing nduwe pengaruh positif marang kualitas kode lan aplikasi? Keputusan apa sing salah lan mulang sampeyan pelajaran sing penting? Nuduhake pengalaman sampeyan ing komentar.
Source: www.habr.com