Bagaimana Anda bereaksi jika seseorang memberi tahu Anda bahwa kode Anda berantakan?

86

Saya seorang programmer yang baik, atau jadi saya pikir sebelumnya. Saya selalu suka memprogram. Dan saya ingin belajar banyak hal tentang pemrograman untuk menjadikan saya seorang programmer yang lebih baik. Saya belajar pemrograman selama 1 tahun dan sekarang saya bekerja sebagai programmer selama hampir 2 tahun. Jadi singkatnya, saya memiliki pengalaman pemrograman hampir 3 tahun.

Tim kami terdiri dari 5 programmer, dan 4 dari kami baru, 1 memiliki pengalaman lebih dari 3 tahun. Kami telah bekerja untuk sebuah program selama hampir satu tahun sekarang dan tidak ada yang pernah meninjau kode saya dan saya diberi halaman untuk bekerja dengannya. Kami tidak pernah memiliki tinjauan kode dan kami semua baru sehingga kami tidak tahu seperti apa kode bersih itu. Saya pikir programmer belajar sendiri?

Kami menyebarkan program kami ke program tanpa pengujian menyeluruh. Sekarang sudah ketat dan kita perlu persetujuan dan tinjauan kode terlebih dahulu sebelum kita membuat perubahan dengan kode. Untuk pertama kalinya, seseorang meninjau kode saya dan dia bilang itu berantakan.

Saya merasa sangat sedih dan terluka. Saya sangat suka pemrograman dan membuat mereka mengatakan sesuatu seperti itu benar-benar menyakitkan saya. Saya benar-benar ingin meningkatkan diri. Tapi sepertinya saya bukan programmer jenius seperti di film-film. Bisakah Anda memberi saya saran tentang bagaimana menjadi lebih baik? Pernahkah Anda mengalami sesuatu yang mengkritik kode Anda dan Anda merasa sangat terluka? Apa yang Anda lakukan pada acara itu.

teamwork code-reviews maintenance

— newbie
sumber

51

"Tapi sepertinya aku bukan programmer jenius seperti di film" . Kesalahan Anda adalah meyakini apa yang Anda lihat di film tentang pengembang perangkat lunak, peretas, dan hampir semua hal lain yang berkaitan dengan teknologi dunia nyata.

— Stephen C

160

Selamat! Mulai hari ini, Anda secara resmi adalah programmer sejati! Diberitahu bahwa Anda mengerikan adalah salah satu batu loncatan yang penting dalam profesi ini. Saya tidak dapat meremehkan ini: Setiap programmer profesional telah diberitahu sesuatu yang mereka tulis buruk pada satu titik atau yang lain, dan itu agak menyengat ketika Anda baru mengenalnya, tetapi itu benar dan Anda akan mendengarnya berkali-kali dalam kursus karier Anda! Ketahuilah, Anda baru saja bergabung dengan profesi. Pemrogram yang baik mengambil pukulan itu dan belajar untuk tidak membuat kesalahan yang sama (sebaliknya, mereka membuat kesalahan yang berbeda setiap waktu!)

— Jimmy Hoffa

15

@newbie ketika Anda baru dan Anda telah membangun sedikit ego dan tidak cukup kacau untuk menyadari Anda buruk, saya buruk, kita semua buruk dalam hal ini karena sangat sulit. Jika Anda memiliki ego yang tersisa, itu akan berjalan di samping setelah Anda melakukan lebih banyak kesalahan. Serius, angkat tangan jika Anda seorang insinyur profesional dan secara tidak sengaja menghancurkan database sebelum mengangkat tangan

— Jimmy Hoffa

14

Kecewa? Kenapa kamu akan kecewa? Mantan CTO saya memanggil saya dalam sebuah artikel yang ditulisnya (dia tidak menyebutkan nama saya secara spesifik, tetapi semua orang di tim kami tahu siapa yang dia bicarakan), dan pada kesempatan pertama saya mendapatkannya, saya mengutip artikel itu dalam salah satu jawaban saya di sini . Juga, saya pengembang jahat yang dijelaskan dalam pertanyaan ini . Saya mendorong OP untuk mengirim pertanyaan, dan saya bahkan menjawab;)

— yannis

19

Ingat orang-orang, hanya karena seseorang mengatakan kode itu buruk tidak menjadikannya benar. Setelah mendengar "kode Anda berantakan," OP layak "dan inilah sebabnya." Kemudian, analisis dapat dimulai.

— Tony Ennis

175

Yang benar adalah bahwa mungkin dalam 2 tahun ketika Anda akan melihat kode Anda saat ini, Anda akan setuju bahwa itu berantakan. Mempelajari pemrograman adalah proses yang tidak pernah berakhir dan akan selalu ada seseorang yang lebih baik daripada Anda.

Jadi, jika orang yang mengatakan bahwa kode Anda berantakan bukan hanya berarti dan itu bukan kasus lain "Saya akan melakukannya dengan lebih baik" penyakit yang umum di antara programmer, Anda harus bertanya kepadanya apa sebenarnya yang salah dengan kode Anda dan bagaimana Anda bisa memperbaikinya.

— onlineapplab.com
sumber

27

Kamu benar! Saya menertawakan kode saya 2 tahun yang lalu. Jadi saya kira saya juga akan menertawakan kode saya dua tahun dari sekarang. Saya menjadi sedikit emosional tentang hal itu. Bagaimanapun, saya akan mencoba menjadi yang lebih baik.

— pemula

5

@newbie: Ini dia. Itu yang perlu Anda ketahui. Moto saya adalah "Saya tidak pernah sebagus dua tahun dari sekarang," selama lebih dari sepuluh tahun sekarang. Dan saya belum salah. Saya tidak belajar sampai sejauh itu dalam karir saya daripada Anda. Kolega Anda telah membantu Anda.

— pdr

27

Saya pikir enam bulan seharusnya banyak waktu untuk membenci kode Anda. Saya khawatir bahwa suatu hari saya mungkin menemukan kode yang saya tulis enam bulan sebelumnya dan tidak menemukan sesuatu yang saya benci tentangnya. Itu akan menjadi pertanda bahwa saya belum tumbuh sebagai seorang programmer.

— zzzzBov

37

2 tahun! Saya bisa tertawa di sore hari pada kode yang saya tulis di pagi hari.

— dan_waterworth

9

Saya juga akan mengatakan bahwa ulasan kode adalah proses yang sangat membantu. Seperti yang dinyatakan oleh jawaban ini, jika Anda seorang programmer yang baik sekali, pada waktunya Anda juga akan berpikir ini adalah kode yang mengerikan - itu wajar. Saya juga akan mengatakan bahwa peninjau kode Anda tidak mendekati proses peninjauan dengan benar. Itu seharusnya menjadi proses kritik konstruktif di mana pengetahuan ditransfer, bukan proses hukuman negatif di mana programmer yang ditinjau dibuat merasa tidak signifikan. Ini meniadakan banyak hal baik yang dapat berasal dari ulasan.

— Mattygabe

68

Jangan bangga dengan seberapa baik kode Anda. Banggalah dengan seberapa baik Anda belajar. Kemudian mengetahui bahwa kode Anda perlu ditingkatkan memberi Anda kesempatan untuk menunjukkan seberapa baik Anda dalam belajar, alih-alih muncul sebagai kritik terhadap seberapa buruk programmer Anda.

Baca http://www.perlmonks.org/?node_id=270083 jika Anda tidak tahu apa yang saya bicarakan.

— btilly
sumber

artikel yang bagus. :) jadi saya hanya berurusan dengan ego saya.

— pemula

2

@newbie Tepat. Ketika Anda menerima kritik terhadap kode Anda, itu hanya dapat membuat Anda marah jika ego Anda terikat dalam kualitas kode itu. Cerai ego Anda dari kode, dan masalahnya hilang.

— btilly

5

Saya setuju untuk bangga dengan seberapa baik Anda belajar, tetapi Anda juga harus bangga dengan cara Anda membuat kode. Jika Anda tidak bangga dengan cara Anda membuat kode, Anda tidak akan terdorong untuk menjadi lebih baik.

— Bryan Oakley

1

Dan Anda juga harus berhati-hati dalam bangga karena dapat menyebabkan masalah yang sama jika Anda sebenarnya tidak terlalu pandai dalam belajar.

— Nico Burns

Saya pikir kesombongan adalah salah satu dari 7 dosa mematikan? Ada apa dengan semua orang yang merekomendasikannya hari ini? Bagaimana kalau hanya merasa puas bahwa Anda melakukan pekerjaan dengan baik.

40

Setelah 20+ tahun saya tahu bahwa beberapa kode saya sendiri masih berantakan. Apa yang terjadi adalah membuat keputusan antara menulis kode sebaik mungkin versus menulis apa yang diperlukan untuk menyelesaikan pekerjaan. Menyelesaikan pekerjaan dalam jangka waktu yang disepakati mengalahkan pencarian tanpa akhir untuk kesempurnaan teknis kapan saja.

Kuncinya adalah belajar menerimanya. Belajarlah untuk menerima bahwa Anda bisa melakukan yang lebih baik. Belajar hidup dengan kekurangan. Belajarlah untuk menerima bahwa Anda tidak akan membuatnya sempurna saat ini, dan mungkin juga di waktu berikutnya, dan itu adalah pilihan yang disengaja karena alternatifnya tidak memberikan. Dan itu lebih buruk.

Penafian: tidak satu pun dari ini harus dibaca sebagai "kode yang buruk adalah OK".

— Maximus Minimus
sumber

2

Berjuang untuk "menyelesaikan pekerjaan" adalah berjuang untuk yang biasa-biasa saja. Anda benar, ini berfungsi dan bisa efektif - lihat saja produk-produk Cina. Tetapi berusaha untuk membuat hal-hal hebat adalah apa yang membuat pemrograman 20 tahun bernilai sebagai teman. Lihat kembali pada 20 tahun, apa yang diungkapkannya - menyelesaikan pekerjaan atau menyelesaikan pekerjaan dengan bangga?

— kingdango

9

Itu selalu tentang "menyelesaikan pekerjaan" kecuali jika Anda sedang menulis semacam proyek seni berbasis kode aneh. Menulis "kode yang baik" vs. "kode yang biasa-biasa saja" adalah pertukaran antara menyelesaikan tugas langsung dan membuat kode lebih mudah dikelola untuk menyelesaikan pekerjaan di masa depan. Mengabaikan hal ini mengarah pada perfeksionisme, yang mengarah pada tidak menyelesaikan apa pun. Kode biasa-biasa saja yang ditulis dengan cepat lebih baik daripada kode bagus yang ditulis perlahan untuk skrip satu kali.

— Steven Burnap

8

Seperti utang moneter, utang teknis segera meningkat dan belajar bagaimana mengelola utang teknis adalah salah satu keterampilan utama seorang programmer di dunia nyata. Siapa pun yang memiliki cukup waktu untuk melakukan pekerjaan yang sempurna setiap saat adalah baik luar biasa, di bawah serius bekerja, atau menipu diri sendiri.

— Mark Booth

1

Mencapai keseimbangan yang tepat mungkin sulit, terutama karena efek melanjutkan dengan desain yang biasa-biasa saja sering jauh lebih terlihat daripada yang menghabiskan terlalu banyak waktu memperbaiki desain ketika yang biasa-biasa saja telah terbukti cukup sempurna selama masa manfaatnya.

— supercat

1

Ini benar-benar menyedihkan saya sebagai "menyelesaikan pekerjaan" dan "kesempurnaan teknis" tidak perlu menjadi dunia yang terpisah yang Anda gambarkan. Secara pribadi, saya tidak merasa puas atas sepotong kode saya yang telah dirilis yang sepenuhnya shonky dan dengan cara itu karena kendala waktu dan, seperti yang Anda katakan, untuk "menyelesaikan pekerjaan" .

— crmpicco

39

Kode semua orang berantakan dan tidak ada programmer yang baik.

Ada:

programmer yang mengirim cepat,
programmer yang selalu mengirimkan kode yang benar secara semantik,
programmer yang selalu datang dengan solusi optimal, dan algoritma tercepat,
programmer yang kodenya mudah dilihat.

Mereka nyaris, jika pernah, akhirnya menjadi orang yang sama.

Dan ada programmer butthurt yang perlu tumbuh dan:

tanyakan apa yang salah,
tidak memberikan komentar secara pribadi, sebagai ukuran nilai mereka sebagai manusia;
menyadari bahwa ada pedoman sintaksis dalam tim, dan mereka harus diikuti, dan mereka sewenang - wenang, sehingga mereka tidak dimaksudkan untuk dibahas ad mual , karena tidak ada solusi optimal, atau kata akhir;
lebih baik mengomentari kode mereka;
lebih baik mengomentari kode mereka; (sic)
menemukan lebih mudah untuk debug, kurang pandai, solusi untuk tugas-tugas sederhana, duniawi;
mengambil kelas dalam SQL
(saya akan mengirim setengah dari populasi dunia ini untuk mengambil kelas dalam SQL, hanya untuk berada di sisi yang aman)

Ini bukan seni, ini kerajinan.
Kami anggap Anda pintar: Anda memprogram komputer, sial.
Tetap AMD64dan x86tidak dipaksa oleh kekuatan prosa Anda. Buat semuanya tetap sederhana.

— ZJR
sumber

3

Benar-benar tertawa terbahak-bahak. sangat baik. roflcopters

— kingdango

1

AMD64 dan x86 tidak dipaksa oleh kekuatan prosa Anda. - Sangat luar biasa.

— Sam Brinck

+1 untuk mengambil kelas di SQL

— HLGEM

28

Seseorang yang mengatakan kode Anda berantakan tidak konstruktif, meskipun itu benar. Apakah mereka memberi Anda alasan mengapa itu berantakan? Seperti, metode terlalu panjang, tanggung jawab bercampur, terlalu banyak percabangan, dll. Jujur, kode apa pun yang saya tulis setahun yang lalu akan saya katakan omong kosong karena saya telah belajar banyak sejak itu. Jadi jangan merasa sedih tentang hal itu. Saya akan lebih khawatir jika Anda masih suka membaca kode yang Anda tulis sebelumnya.

Semakin bersih basis kode Anda, semakin sedikit waktu yang Anda habiskan untuk melawan basis kode untuk memecahkan masalah yang diberikan. Setahun adalah saat yang tepat karena Anda dapat merasakan sakitnya keputusan desain yang Anda buat sebelumnya dalam proyek ini.

Pada proyek saya saat ini, kami telah refactored beberapa kali karena kami merasa lebih nyaman dengan tumpukan teknologi kami. Ini harus didorong dan Anda harus membuat catatan tugas yang memakan waktu lebih lama daripada yang seharusnya karena basis kode saat ini.

Sudahkah Anda membaca beberapa bagian kode lama yang Anda tulis? Anda mungkin dapat melihat hal-hal yang ingin Anda lakukan secara berbeda sekarang atau refactor.

Juga ketika Anda menyebutkan kurangnya pengujian, ini selalu sesuatu untuk dilihat. Pada proyek kami, kami tidak memiliki pengujian otomatis dan sebagai hasilnya banyak kode yang digabungkan. Bahkan jika Anda tidak menulis unit / integrasi / tes apa pun secara teratur, melakukannya sebentar akan membuat Anda terbiasa membuat kode Anda lebih modular (dan akibatnya, lebih sedikit berantakan).

— Kriptik
sumber

26

Saya merasa sangat sedih dan terluka. Saya sangat suka pemrograman dan membuat mereka mengatakan sesuatu seperti itu benar-benar menyakitkan saya. Saya benar-benar ingin meningkatkan diri.

Itu bagus. Itu jauh lebih baik daripada memiliki reaksi seperti "reviewer saya tidak tahu apa yang dia bicarakan", "reviewer saya terlalu pemilih" atau hanya "reviewer saya tidak suka saya" dan mengabaikannya. Sikap ini adalah hal yang baik.

Tapi sepertinya saya bukan programmer jenius seperti di film-film.

Tidak yakin film jenis apa yang Anda tonton, tetapi 90% programmer di film itu sangat palsu sehingga saya menangis di akhir urutannya.

Bisakah Anda memberi saya saran tentang bagaimana menjadi lebih baik?

Baca dan berlatih. Lihatlah buku-buku seperti Code Complete atau The Pragmatic Programmer . Lihat di Amazon untuk buku-buku serupa.

Pernahkah Anda mengalami sesuatu yang mengkritik kode Anda dan Anda merasa sangat terluka? Apa yang Anda lakukan pada acara itu ..

Mengapa kamu merasa terluka? Aku merasa kecewa pada diriku sendiri karena telah menjadi orang tolol. Saya menggunakan motivasi itu untuk membersihkan kode saya dan memastikan saya tidak membuat kesalahan yang sama lagi . Hal terakhir yang ingin saya lakukan adalah tidak belajar darinya. Anda telah dijatuhkan sekali, jangan biarkan itu terjadi lagi karena alasan yang sama.

Tidak ada programmer yang terlahir sempurna, atau bahkan dekat. Semakin banyak kode tulisan Anda, semakin banyak ulasan yang Anda dapatkan dan ulasan yang Anda berikan , akan membuat Anda menjadi programmer yang lebih baik.

— Jay
sumber

2

Memberi +1 untuk menyatukannya bersama dan reviews you providekarena mengkritik orang lain bisa menjadi praktik penting untuk menjadi lebih baik dalam mengkritik kode Anda sendiri untuk menghasilkan kualitas yang lebih baik.

— Jimmy Hoffa

2

"90% programer di film itu sangat palsu sehingga aku menangis di akhir urutannya." 90%? Film apa yang kamu tonton? : PI belum melihat satu film yang secara akurat menggambarkan apa yang kami lakukan. Dan kemudian ada "Swordfish" dan "Hari Kemerdekaan" ...

— Nik Bougalis

Ditempatkan dengan baik dan ringkas begitu!

— kingdango

16

Salah satu hal terbaik bagi saya untuk menjadi pengembang adalah bahwa setiap hari adalah proses pembelajaran. Akan selalu ada seseorang di luar sana yang tidak tahu sesuatu yang Anda lakukan, dan akan selalu ada seseorang yang tahu sesuatu yang Anda tidak tahu. Saya tentu saja tidak akan menganggap diri saya berada di mana pun kecuali pada tingkat pemula / junior, tetapi saya menghargai kritik apa pun yang saya dapat selama itu dibenarkan dan diberikan dengan hormat.

Sebuah analogi yang mungkin cocok berkaitan dengan periode waktu di mana saya menjadi guru menulis di universitas, serta ketika saya mengambil bagian dalam kursus menulis kreatif. Menulis kode, untuk semua maksud dan tujuan, sama seperti menulis puisi, esai, cerita pendek, atau novel. Setiap individu memiliki cara sendiri untuk melakukannya, tetapi pada saat yang sama, bahkan penulis terbaik (atau, dalam hal ini, pengembang) membuat kesalahan atau membiarkan segala sesuatunya lolos dari celah. Kita sering gagal memperhatikan hal-hal ini karena kita menjadi terbiasa dengan suara kita sendiri (atau sekali lagi, dalam hal ini, gaya kode).

Sama seperti di bidang apa pun, ada orang yang dianggap ahli. Jika orang-orang itu tidak ada, kita tidak akan memiliki siapa pun untuk belajar. Anggap orang ini benar-benar ahli, saya akan mendengarkan apa yang dia katakan dan bertanya apa yang akan dia sarankan agar kamu perbaiki kode Anda. Namun, jangan pernah lupa bahwa dia bukan satu-satunya yang dapat memberikan bantuannya; kami memiliki nasib baik bahwa banyak sumber daya seperti SE / SO ada.

— Paul
sumber

9

" Akan selalu ada seseorang di luar sana yang tidak tahu sesuatu yang Anda lakukan, dan akan selalu ada seseorang yang tahu sesuatu yang Anda tidak tahu " - mengagumkan; +1.

— Maximus Minimus

Ya, dan saya ingin belajar semua yang saya bisa

— pemula

@ mh: Saya ingin menambahkan bahwa orang bijak umumnya akan belajar lebih banyak dari kesalahan daripada dari menjadi benar. Itu bukan untuk mengatakan bahwa seseorang harus mencoba melakukan kesalahan tentang hal-hal, tetapi alih-alih seseorang tidak harus berkecil hati tentang hal itu asalkan seseorang mengambil keuntungan dari kesempatan untuk belajar.

— supercat

10

Kekacauan agak subyektif. Hal terbaik yang dapat Anda lakukan adalah bertanya kepada orang itu (atau laporan ulasannya): mengapa itu berantakan? (dari sudut pandang mereka, yaitu)

Mereka pasti akan menjawab Anda dan Anda akan dapat:

Argumen menentangnya (jika Anda memiliki alasan yang bagus untuk melakukannya, tentu saja)
Merasa sangat bahagia, karena Anda baru saja mempelajari sesuatu yang baru dan kode masa depan Anda pasti akan menjadi lebih hebat karena Anda sekarang tahu bagaimana membuatnya menjadi kurang berantakan berkat saran mereka.

— Akhir
sumber

Dia tidak berkomentar :( Tapi ini kode saya -> codereview.stackexchange.com/questions/18719/…

— newbie

menurut Anda mengapa itu berantakan?

— pemula

7

@newbie: Kalau begitu resensi itu tidak terlalu baik. Bagaimana seorang pembuat kode dapat memperbaiki sesuatu tanpa mengetahui apa masalahnya (bahkan bukan petunjuk!)?

— Omega

1

Oke terima kasih ... Saya juga bukan programmer jquery. Saya seorang programmer java ....

— newbie

1

Hanya kode saya yang tersedia untuknya saat itu. Ngomong-ngomong, kau benar, aku akan menanyakan lebih detail tentang itu. Terima kasih :)

— pemula

8

Fakta bahwa Anda khawatir adalah pertanda baik. Mari kita mulai dengan itu. Anda menyebut Anda suka program, tetapi apakah Anda suka menjadi programmer profesional? Ada perbedaan besar antara penggemar dan profesional. Sebagai seorang profesional, Anda akan terus-menerus diawasi untuk produk pekerjaan Anda.

Our team is composed of 5 programmers, and 4 of us are new

Fakta bahwa Anda telah bekerja dua tahun tanpa konfrontasi memberi tahu saya bahwa Anda bekerja dalam pekerjaan yang sangat santai, yang tidak begitu baik jika Anda benar-benar ingin maju sebagai seorang profesional. Pikiran Anda, beberapa programmer terbaik di dunia bekerja untuk yayasan Linux dan yakinlah bahwa mereka tidak diperlakukan dengan baik ketika mereka membuat kesalahan kecil ... apalagi 'kode berantakan'.

Untuk tinjauan singkat tentang beberapa pedoman pengkodean yang cukup standar, Standar Kontributor Komunitas Linux harus memberi Anda gambaran tentang tingkat tanggung jawab yang ingin dicapai untuk produk Anda. Lihat MENDAPATKAN KODE YANG BENAR.

Untuk lebih jauh pernyataan itu, Anda harus belajar merangkul ulasan karena sebagian besar perangkat lunak yang baik ditinjau secara menyeluruh. Ini mendukung Hukum Linus yang menyatakan ...

"Jika ada cukup banyak pengulas, semua masalah mudah dipecahkan."

Secara pribadi, saya telah melihat pengembang yang sangat terampil, bertanggung jawab, dan dapat diandalkan mendapatkan kapak untuk sesuatu yang sederhana seperti lupa untuk meninggalkan komentar ... jadi jika seseorang memberi tahu Anda kode Anda berantakan maka mungkin itu ... Selesaikan ... Refactoring. Itu bagian dari pertunjukan.

I feel so sad and hurt.

Pergi membuat aplikasi kesedihan untuk mengukur seberapa marah Anda dapatkan ketika Anda tidak berlaku sendiri.

Anda menjawab masalah Anda ... Anda Jangan Mengujinya!

Setelah melihat komentar yang Anda buat menyatakan bahwa Anda adalah pengembang java, saya hampir kesal. Jadi jika saya memahami Anda dengan benar, Anda mengatakan bahwa Anda dan tim pengembangan Anda bekerja di toko java dan tidak memiliki kerangka uji untuk aplikasi Anda ...

Di sanalah terletak Gosok

"Kami menyebarkan program kami ke program tanpa pengujian menyeluruh."

Cribbing UML Creator Grady Booch ...

Insinyur perangkat lunak amatir selalu mencari sihir, beberapa metode sensasional atau alat yang aplikasinya menjanjikan untuk membuat pengembangan perangkat lunak sepele. Ini adalah tanda insinyur perangkat lunak profesional untuk mengetahui bahwa tidak ada obat mujarab seperti itu.

Alistair Cockburn memberikan banyak informasi di situsnya tentang penggunaan metodologi lincah untuk meningkatkan kinerja dan kualitas untuk Anda dan tim Anda.

Salah satu aspek terpenting pemrograman {dan kehidupan} adalah mengetahui kekuatan dan kelemahan Anda. Jika Anda tidak mengerjakan kelemahan Anda, Anda tidak akan memiliki keterampilan yang lengkap.

Outro ... Kamu baik-baik saja - Jangan merengek. Maju terus dalam mengembangkan keahlian Anda dan biarkan hasrat Anda untuk pemrograman terus berlanjut. Semoga berhasil :-)

— Eddie B
sumber

5

Jangan biarkan emosi Anda menghalangi peningkatan kode Anda. Tujuan dari tinjauan kode adalah untuk menemukan masalah, jadi Anda tidak perlu terlalu terkejut jika ada beberapa. Yang mengatakan, mereka juga tidak seharusnya menjadi sesi coder-bashing.

Mereka juga seharusnya tidak hanya mengatakan 'Ewwww' dan membiarkannya begitu saja. Selalu ada alasan mengapa ada sesuatu yang salah dalam pemrograman. Misalnya, salah jika meninggalkan banyak kode yang dikomentari di semua tempat, tetapi itu salah karena mengacaukan kode dan membuatnya lebih sulit untuk dibaca, bukan karena seseorang mengatakan demikian dalam sebuah buku.

Kode Anda bukan Anda. Ingat bahwa.

— Michael Shaw
sumber

4

Saya akan menjadi kontol di sini dan memberi nasihat berdasarkan .. yah, yang jelas. Jelas, kode Anda berantakan atau pertanyaan yang akan Anda tanyakan adalah "MENGAPA seseorang mengatakan kode saya berantakan?" Tapi Anda tidak menentang anggapan itu. Anda hanya bertindak terluka dan terus terang mungkin ada menangis tetapi tidak ada perasaan ketika datang ke membenarkan pemrograman.

Tapi sungguh, mengapa kamu bertanya? Anda tahu kode Anda payah atau Anda akan mengajukan pertanyaan lain. Jika seseorang memberi tahu saya kode web back-end saya berbau, saya akan tertawa dan berkata "oke ada apa dengan itu?" Jika mereka memberi tahu saya tentang JavaScript saya, saya akan memberi mereka programmer sosial yang setara dengan bibir gemuk dan saya tidak akan pernah meminta nasihat tentang bagaimana bereaksi karena pelacur kecil itu jelas! @ # $ Ing salah.

Miliki apa yang Anda kuasai. Dan maksud saya benar-benar bertanggung jawab untuk itu. karena hanya perlu satu kesalahan untuk beberapa twit untuk menebak-nebak Anda. Jangan meminta izin untuk menjadi baik. Ketahuilah barang-barang Anda. Tamat.

— Erik Reppen
sumber

Amin. Dan mengetahui barang-barang Anda butuh ... yah ... upaya untuk memastikan Anda tahu barang-barang Anda. Tapi pastikan untuk melepaskan kerahmu, itulah yang dilakukan semua anak elit hari ini. : /

— kingdango

Ya, saya pikir saya baru saja memberi saran di tempat lain tentang para dev yang lebih berpengalaman menjadi yang pertama mengakui bahwa mereka salah. Saya bisa mengacaukan banyak kepribadian.

— Erik Reppen

4

Ingat ini: Kode terburuk yang pernah Anda lihat adalah milik Anda!

Jeff Atwood dari codinghorror.com menulis banyak tentang topik ini, Anda mungkin ingin memulai di sini: http://www.codinghorror.com/blog/2009/07/nobody-hates-software-more-than-software-developers.html

Jika Anda ingin meningkatkan, mulailah membaca hal-hal tentang gaya pengkodean, pola, alur kerja, pada dasarnya semua yang Anda bisa lakukan. Juga pelajari lebih banyak bahasa pemrograman, lihat bagaimana mereka melakukan hal-hal. Jika Anda melakukan OOP, baca ini: http://en.wikipedia.org/wiki/Design_Patterns

Juga berbicara dengan programmer lain dan melakukan pemrograman pasangan atau menonton kode orang lain.

Membuat kesalahan tidak bisa dihindari, mengulanginya adalah.

— Lucas Hoepner
sumber

Itu adalah sentimen yang baik (favorit saya terkait karena saya selalu memulai dengan mengasumsikan bahwa masalah dengan aplikasi adalah kesalahan saya) tetapi sayangnya ternyata tidak, kode terburuk yang pernah Anda lihat mungkin bukan milik Anda sendiri .. ... tidak jika Anda cukup pintar untuk berada di sini dan untuk bertanya tentang hal itu di tempat pertama ...

— Murph

4

Sebagian besar waktu Anda harus mengatakan "Terima kasih" kepada orang yang mengatakan ini kepada Anda.

Kemungkinannya adalah mereka peduli dengan profesi mereka, mereka peduli dengan pekerjaan mereka, mereka peduli dengan tim mereka dan mereka peduli dengan Anda.

Mungkin sulit menerima kritik. Jangan marah karenanya. Pikirkan tentang apa yang mereka coba sampaikan kepada Anda dan jangan biarkan emosi Anda menjadi lebih baik dari Anda.

Saya sudah pemrograman untuk waktu yang lama (30 tahun) dan gaya dan kode saya meningkat sepanjang waktu (saya harap). Satu-satunya cara saya mengetahui peningkatannya adalah ketika orang lain memberi tahu saya atau jika saya kembali dan meninjau kode saya.

Coba lihat kode yang Anda tulis di awal karir Anda. Seperti apa penampilan Anda sekarang? Apakah terlihat sebagus yang Anda pikir ketika Anda menulisnya;)

— Fortyrunner
sumber

3

Pertama-tama, Anda harus memahami bahwa pemrograman adalah proses berulang, seperti menulis artikel atau buku. Pertama Anda menulis "konsep kasar" dari program Anda, hanya untuk membuatnya bekerja. Pada tahap ini, kode Anda akan berantakan. Jadi, Anda refactor untuk membuat kode bersih. Kemudian Anda profil dan lihat apa yang Anda perlu optimalkan untuk membuatnya cepat. Caranya adalah dengan terus-menerus memperbaiki, jika tidak kekacauan akan tumbuh. Anda harus membersihkan kode Anda secara teratur, sama seperti Anda harus membersihkan rumah Anda.

Ulasan kode sangat penting. Anda harus melihat kode Anda oleh setidaknya satu pasang mata lainnya. Ketika Anda menghabiskan waktu berjam-jam untuk melihat kode Anda, Anda terbiasa dengan hal itu, dan Anda dapat dengan mudah melewatkan bug atau bau kode yang mungkin langsung disadari rekan kerja Anda.

Juga, tindakan menjelaskan kode Anda kepada orang lain adalah cara yang bagus untuk melihat apakah Anda melewatkan sesuatu. Ini seperti membaca kertas yang Anda tulis keras-keras. Otak Anda memproses informasi audio dan visual dengan cara yang berbeda, dan Anda dapat menemukan kekurangan dalam penalaran Anda dengan mengganti modalitas. Juga, jika Anda menjelaskan kode Anda kepada rekan kerja, dan ada sesuatu yang tidak masuk akal baginya, itu adalah indikasi yang baik bahwa Anda harus memperbaiki kode Anda.

Ketika melakukan review kode, sangat penting bagi penulis dan reviewer untuk memeriksa ego mereka di pintu. Tujuannya adalah membuat kode lebih baik. Jadi pengkaji harus menghormati, dan penulis harus tetap berpikiran terbuka. Ingat, rekan kerja Anda adalah orang yang harus menjaga kode Anda, jadi itu harus jelas bagi mereka. Jika peninjau tidak memahami apa yang variabel lakukan, ganti nama itu. Jika peninjau tidak dapat memahami apa yang dilakukan oleh blok kode, ubah menjadi fungsi dengan nama deskriptif. Terlepas dari apa yang Anda pikirkan, jika rekan kerja Anda tidak dapat memahami kode Anda, itu tidak baik.

Berbicara tentang refactoring, Anda benar-benar harus memiliki kerangka kerja unit test, karena tanpanya, Anda tidak dapat melakukan refactor.

Akhirnya, saya sangat merekomendasikan membaca "Kode Bersih" oleh Robert C. Martin. Ini akan memberi tahu Anda mengapa kode Anda berantakan, dan apa yang dapat Anda lakukan untuk membersihkannya.

— Dima
sumber

3

Bisakah Anda memberi saya saran tentang bagaimana menjadi lebih baik?

Jawaban Jay yang merekomendasikan buku adalah jawaban yang bagus, namun sepertinya Anda sudah berada di titik balik kerja.

Lalu:

Tim kami terdiri dari 5 programmer, dan 4 dari kami baru, 1 memiliki pengalaman lebih dari 3 tahun. Kami telah bekerja untuk sebuah program selama hampir satu tahun sekarang dan tidak ada yang pernah meninjau kode saya dan saya diberi halaman untuk bekerja dengannya.

Menyajikan:

Sekarang sudah ketat dan kita perlu persetujuan dan tinjauan kode terlebih dahulu sebelum kita membuat perubahan dengan kode.

Sepertinya perusahaan / tim / departemen Anda sedang belajar secara keseluruhan, dalam hal manajemen proyek dan tim serta pemrograman. Mulai meninjau kode adalah peluang bagus untuk meningkatkan di hampir semua bidang jika diberi perhatian yang tepat.

Gunakan ini sebagai kesempatan; dengan asumsi Anda melakukan peer review (dengan pengembang lain di tim Anda) menyarankan kepada mereka bahwa proses ini penting dan semua orang bisa belajar darinya.

Pada garis dasar ini akan menjadi ulasan cepat dengan hasilnya "yeah looks ok". Dengan sedikit usaha yang lebih fokus, Anda dapat memantulkan ide satu sama lain, "ya itu berhasil, tetapi Anda bisa mendekatinya dengan cara ini, yang akan membuat tujuan Anda lebih jelas ...". Buat catatan untuk masa depan meskipun kode tersebut dianggap ok untuk digunakan.

Jika ini akan berhasil, Anda perlu membuat tim dan manajer Anda berada di pihak, yang seringkali berarti menjelaskan manfaatnya kepada mereka. Bagi pengembang lain, ini adalah kesempatan untuk belajar. Bagi manajer Anda, ini adalah kesempatan untuk meningkatkan keterampilan tim dengan sedikit biaya, oleh karena itu menciptakan keluaran a) dengan nilai lebih atau b) lebih cepat c) dengan biaya perawatan lebih sedikit (biasanya masalah besar!).

Ini adalah perubahan budaya, yang tidak bisa Anda paksa sendiri, tetapi Anda dapat membantu mendorong hal-hal ke arah yang benar!

Jangan lupa, ini semacam perubahan budaya yang bisa sangat bermanfaat bagi organisasi; manajer yang baik akan menyadari bahwa Anda bekerja untuk membuat seluruh tim lebih baik, sesuatu yang berharga.

— Mat
sumber

3

Bisakah Anda memberi saya saran tentang bagaimana menjadi lebih baik? Pernahkah Anda mengalami sesuatu yang mengkritik kode Anda dan Anda merasa sangat terluka? Apa yang Anda lakukan pada acara itu.

Jawabannya dapat ditemukan di perusahaan generasi baru. Saya pernah ke perusahaan seperti Google dan FaceBook dan saya melihat bahwa jika Anda mengikuti proses Agile / Scrum secara religius, maka Anda dapat menulis kode yang lebih baik dan meningkatkannya setiap sprint.

How to be better?

Jawabannya adalah refactoring berkelanjutan. Alat pengembangan modern seperti studio visual memiliki banyak alat yang membantu Anda dalam proses ini. Jika Anda mengikuti proses pengembangan perangkat lunak Scrum, lalu katakan misalnya, Anda menulis kode buruk dalam sprint cycle 1 dan seseorang menunjukkan selama ulasan itu buruk, maka dalam sprint 2, Anda memiliki kesempatan untuk memperbaiki kode tersebut.

Masalah-masalah ini terjadi pada awalnya karena kurangnya proses yang baik. Jadi solusinya adalah menciptakan proses pengembangan perangkat lunak yang baik untuk tim Anda dan mempraktikkan refactoring berkelanjutan.

— Avinash Kumar
sumber

3

Saya akan berterima kasih kepada mereka atas umpan baliknya, dan kemudian meminta mereka untuk menjelaskan apa yang membuatnya buruk dan bagaimana hal itu harus diperbaiki.

Jika Anda setuju orang yang memberikan umpan balik itu masuk akal, pertimbangkan untuk membuat perubahan di masa depan. Tapi ingat, hanya karena seseorang mengatakan itu tidak berarti itu benar.

Bisakah Anda memberikan contoh spesifik tentang apa yang disebut "berantakan"?

— Tony Ennis
sumber

Perasaan kadang-kadang bisa sulit, tetapi ini tentu saja bagaimana saya berharap saya akan bereaksi.

— Thomas Padron-McCarthy

3

Pertama seseorang mengatakan kode Anda berantakan sangat kabur dan subyektif. Ini dapat berarti hal yang berbeda bagi orang yang berbeda. Inilah alasannya; ada dua hal berbeda yang harus diperhatikan.

Struktur

Struktur kode Anda diatur oleh bahasa, standar industri, dan standar perusahaan. Jelas ada faktor-faktor lain juga.

Ini adalah jenis kesalahan yang serat, alat uji, dan produk serupa dirancang untuk diidentifikasi. Mereka didefinisikan dengan baik dan Anda atau alat Anda dapat membuat keputusan yang objektif tentang validitas / kebenarannya.

Gaya

Meskipun struktur / aturan standar untuk kode, setiap pengembang memiliki gaya tertentu dalam cara mereka menulis dan mendekati masalah atau tugas. Lakukan pemeliharaan kode di lingkungan tim mana pun dan seiring waktu Anda akan dapat menebak siapa yang menulis kode berdasarkan gaya. Anda juga akan mengembangkan gaya Anda sendiri dan itu akan berubah saat Anda mendapatkan pengalaman dan mempelajari keahlian Anda.

Jadi, kapan saja seseorang mengatakan kode Anda berantakan, Anda perlu memahami jika mereka berbicara tentang struktur atau gaya . Mereka adalah dua hal yang sangat berbeda; struktur objektif sedangkan gaya mutlak subjektif.

Yang sedang berkata, setiap umpan balik konstruktif dari programmer lain bisa sangat berharga bagi Anda. Semua terserah Anda dan bagaimana Anda menerima kritik. Lama-kelamaan Anda akan mengetahui pendapat siapa yang perlu dipertimbangkan dibandingkan siapa yang akan mengambil sebutir garam.

Ketika Anda maju dalam karir Anda, Anda akan melihat kembali kode Anda sendiri dan melihat hal-hal yang dapat Anda lakukan secara berbeda, lebih baik, lebih bersih, dan lebih cepat. Itu semua adalah bagian dari proses belajar dan melihat kesalahan masa lalu Anda sendiri merupakan indikasi nyata bahwa Anda mengasah dan meningkatkan keterampilan Anda.

Jangan biarkan sedikit kritik meredam semangat Anda. Ambil apa yang Anda bisa darinya dan jika itu bermakna dan berharga, tambahkanlah ke dalam gudang pengetahuan Anda.

— Stephen
sumber

3

Meskipun penting untuk mengenali kapan kode Anda sendiri berantakan (perasaan yang sangat khas di antara programmer, terutama ketika mereka menjadi lebih berpengalaman dan kode mereka yang lebih tua bertambah), bahkan lebih penting untuk mendengarkan ketika orang lain memberi tahu Anda.

Hanya ada begitu banyak masalah yang dapat Anda kenali dalam kode Anda sendiri, karena itu diproduksi dalam kendala pengetahuan pemrograman Anda saat ini.

Peninjauan kode adalah kesempatan belajar yang penting karena kemungkinan memaparkan Anda pada pengetahuan baru yang tidak Anda miliki saat mengerjakan kode (jika tidak, Anda akan menggunakannya dan tidak akan ada kekacauan).

Saya pikir ada dua bagian untuk memproses umpan balik negatif.

1. Tentukan sifat masalah yang diangkat dan apa yang harus Anda pelajari darinya

Ketika saya meninjau atau meminta kode saya ditinjau, saya mengurutkan informasi tentang masalah kode dalam keranjang seperti ini:

melanggar persyaratan teknologi keras
- salah polos (tidak berfungsi atau melakukan untuk persyaratan)
- akan gagal dalam keadaan lain (perubahan lingkungan / konfigurasi)
- menggunakan fungsi yang sudah usang dan akan rusak di masa mendatang
melanggar praktik terbaik industri, kurang dalam hal-hal seperti
- menggunakan pendekatan yang terbukti untuk masalah tertentu
- kinerja
- kompatibilitas mundur
- kemudahan perawatan
- gaya pengkodean
- dokumentasi
melanggar praktik terbaik di tempat kerja
- sama dengan industri, tetapi lebih spesifik untuk perusahaan / kolega dan dapat berbeda dari industri secara detail
tidak sejalan dengan keahlian pribadi
- dapat ditingkatkan dalam beberapa cara, menurut pendapat orang yang mengulas

Perhatikan bahwa ini berkisar dari hal-hal yang sangat objektif ("ini akan pecah ketika digunakan ke server produksi kami") hingga hal-hal yang sangat subyektif ("Saya tidak suka bagaimana Anda menamakan variabel").

2. Tentukan perubahan (jika ada) mana pada kode yang akan dibuat sebagai hasil tinjauan

Setelah informasi diproses, muncul keputusan apakah dapat ditindaklanjuti dan jika kode harus diubah. Ini belum tentu keputusan Anda, pendapat Anda mungkin atau mungkin tidak masalah tergantung pada pihak yang terlibat dan spesifik situasi Anda (senioritas, dll). Tetapi kemungkinan hasil yang kira-kira adalah:

mengatasi masalah secara penuh
- memperbaiki rusak
- format ke gaya pengkodean yang diperlukan
- dan seterusnya
datang untuk berkompromi jika masalah harus diatasi sama sekali atau sebagian, karena mungkin ada
- tidak ada sumber daya (seperti waktu atau anggaran)
- tidak perlu (hanya akan mencapai peningkatan yang tidak signifikan, stabilitas kompromi, dll)
memahami bahwa masalah yang diangkat tidak valid
- umpan balik (terutama dari kategori opini subyektif) bisa sangat berbahaya dan tidak boleh dilakukan secara membabi buta

Anda telah belajar bahwa rasanya menyakitkan untuk mendapatkan umpan balik negatif dan sangat baik mungkin menyakitkan setiap saat di masa depan. Namun Anda harus belajar betapa pentingnya kesempatan belajar dan bagaimana proses ini membantu Anda meningkatkan secara profesional dan tempat kerja Anda untuk mencapai basis kode yang lebih baik.

— Jarang
sumber

1

Yah, jangan merasa hancur. Akhirnya Anda akan belajar dari kesalahan. Setelah Anda selesai dengan masalah ini, Anda dapat berbicara dengan pria sehingga membuatnya merasa bahwa Anda ingin meningkat. Cobalah untuk lebih banyak mendengarkan dan sedikit berdebat.

Saya telah melalui situasi ini dan saya bisa mengerti.

— Hisyam
sumber

0

TL; DR

Bagaimana Anda bereaksi jika seseorang memberi tahu Anda bahwa kode Anda berantakan?

Langsung saya, "terlalu lama tidak membaca (semua jawaban - permintaan maaf, mudah-mudahan saya akan menemukan waktu untuk nanti dan mengedit / mengubah ini jika perlu)" jawaban / tip:

Ulasan Peer lama yang bagus. Tanyakan kru yang berbeda dengan mentalitas kolektif yang berbeda, tingkat keahlian dan / atau tingkat agresivitas untuk meninjau kode Anda.
Hanya untuk menguraikan sedikit tentang apa yang saya maksud dengan kelompok rekan "berbeda": diaspora StackExchange mungkin adalah kelompok yang paling terkenal, profesional dan terhormat karena kesulitan relatif untuk menjadi bagian darinya dibandingkan dengan, katakanlah, Reddit. Reddit cenderung sangat agresif dalam sub-reddits yang lebih populer - tetapi anehnya subreddit pemrograman cukup ramah (dari apa yang saya alami).

Contoh bagus, mungkin yang terbaik, contoh dari tipe mentalitas gangsta agresif dan gangsta adalah kerumunan Forum XDK, dan trofi terburuk dari yang terburuk saya berikan kepada CyanogenMod untuk forum Android / populasi saluran IRC.

Itu sedikit lebih lama dari yang saya maksudkan; maksud saya seharusnya - mendapatkan ulasan yang beragam, tetapi fokus pada mendapatkan kritik jujur dari orang-orang yang mengetahui perdagangan mereka, dan tahu apa itu kritik konstruktif . Oh, dan dapat mengambil segala bentuk kritik tanpa membiarkannya membuat Anda kecewa. Rule of thumb: jika Anda mulai mendengar komentar serupa mengenai hal yang bisa saling menguntungkan dengan komentar, maka lakukan introspeksi yang lebih menyeluruh.

— skopp
sumber