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.
sumber
Jawaban:
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.
sumber
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.
sumber
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".
sumber
Kode semua orang berantakan dan tidak ada programmer yang baik.
Ada:
Mereka nyaris, jika pernah, akhirnya menjadi orang yang sama.
Dan ada programmer butthurt yang perlu tumbuh dan:
(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
AMD64
danx86
tidak dipaksa oleh kekuatan prosa Anda. Buat semuanya tetap sederhana.sumber
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).
sumber
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.
Tidak yakin film jenis apa yang Anda tonton, tetapi 90% programmer di film itu sangat palsu sehingga saya menangis di akhir urutannya.
Baca dan berlatih. Lihatlah buku-buku seperti Code Complete atau The Pragmatic Programmer . Lihat di Amazon untuk buku-buku serupa.
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.
sumber
reviews you provide
karena mengkritik orang lain bisa menjadi praktik penting untuk menjadi lebih baik dalam mengkritik kode Anda sendiri untuk menghasilkan kualitas yang lebih baik.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.
sumber
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:
sumber
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.
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 ...
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.
Pergi membuat aplikasi kesedihan untuk mengukur seberapa marah Anda dapatkan ketika Anda tidak berlaku sendiri.
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 ...
Cribbing UML Creator Grady Booch ...
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 :-)
sumber
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.
sumber
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.
sumber
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.
sumber
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;)
sumber
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.
sumber
Jawaban Jay yang merekomendasikan buku adalah jawaban yang bagus, namun sepertinya Anda sudah berada di titik balik kerja.
Lalu:
Menyajikan:
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.
sumber
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.
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.
sumber
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"?
sumber
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.
sumber
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:
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:
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.
sumber
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.
sumber
TL; DR
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:
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.
sumber