Cara Berkode Lebih Cepat (Tanpa Kualitas Pengorbanan) [ditutup]

Saya telah menjadi pembuat kode profesional selama beberapa tahun. Komentar tentang kode saya pada umumnya sama: menulis kode yang bagus, teruji dengan baik, tetapi bisa lebih cepat .

Jadi, bagaimana cara menjadi pembuat kode yang lebih cepat, tanpa mengorbankan kualitas? Demi pertanyaan ini, saya akan membatasi cakupan ke C #, karena itulah yang saya kode (untuk bersenang-senang) - atau Java, yang cukup mirip dalam banyak hal.

Hal-hal yang sudah saya lakukan:

• Tulis solusi minimal yang akan menyelesaikan pekerjaan
• Tulis banyak tes otomatis (cegah regresi)
• Tulis (dan gunakan) perpustakaan yang dapat digunakan kembali untuk semua jenis hal
• Gunakan teknologi terkenal di mana mereka bekerja dengan baik (mis. Hibernate)
• Gunakan pola desain yang sesuai dengan tempatnya (mis. Singleton)

Ini semua hebat, tetapi saya tidak merasa kecepatan saya meningkat seiring waktu. Saya melakukan perawatan, karena jika saya bisa melakukan sesuatu untuk meningkatkan produktivitas saya (bahkan oleh 10%), yang 10% lebih cepat dari pesaing saya. (Bukan berarti aku punya.)

Selain itu, saya secara konsisten mendapatkan balasan ini dari manajer saya - apakah itu pengembangan Flash skala kecil atau pengembangan Java / C ++ perusahaan.

Sunting: Tampaknya ada banyak pertanyaan tentang apa yang saya maksud dengan cepat, dan bagaimana saya tahu saya lambat. Izinkan saya mengklarifikasi dengan lebih detail.

Saya bekerja di tim kecil dan menengah (5-50 orang) di berbagai perusahaan di berbagai proyek dan berbagai teknologi (Flash, ASP.NET, Java, C ++). Pengamatan manajer saya (yang mereka katakan langsung kepada saya) adalah bahwa saya "lambat."

Sebagian dari ini adalah karena sejumlah besar teman saya mengorbankan kualitas untuk kecepatan; mereka menulis kode yang bermasalah, sulit dibaca, sulit dirawat, dan sulit untuk menulis tes otomatis. Kode saya pada umumnya terdokumentasi dengan baik, dapat dibaca, dan dapat diuji.

Di Oracle, saya secara konsisten akan menyelesaikan bug lebih lambat daripada anggota tim lainnya. Saya tahu ini, karena saya akan mendapatkan komentar untuk efek itu; ini berarti bahwa pengembang lain (ya, yang lebih senior dan berpengalaman) dapat melakukan pekerjaan saya dalam waktu yang lebih singkat daripada yang saya perlukan, dengan kualitas yang hampir sama (mudah dibaca, rawatan, dan dapat diuji).

Mengapa? Apa yang saya lewatkan? Bagaimana saya bisa menjadi lebih baik dalam hal ini?

Tujuan akhir saya sederhana: jika saya dapat membuat produk X dalam 40 jam hari ini, dan saya dapat meningkatkan diri saya sehingga saya dapat membuat produk yang sama pada 20, 30, atau bahkan 38 jam besok, itu yang ingin saya ketahui - bagaimana saya sampai di sana? Proses apa yang dapat saya gunakan untuk terus meningkatkan? Saya pikir itu tentang menggunakan kembali kode, tapi sepertinya itu tidak cukup.

Saya suka pendekatan Jeff Atwood untuk ini yang dapat ditemukan di sini http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Pada dasarnya dalam artikel itu dia merujuk sebuah bagian dari buku Art & Fear oleh David Bayles dan Ted Orland. Bagian ini berbunyi:

Guru keramik mengumumkan pada hari pembukaan bahwa dia membagi kelas menjadi dua kelompok. Semua yang berada di sisi kiri studio, katanya, akan dinilai hanya berdasarkan jumlah pekerjaan yang mereka hasilkan, semua yang di sebelah kanan semata-mata pada kualitasnya. Prosedurnya sederhana: pada hari terakhir kelas ia akan membawa timbangan ke kamar mandi dan menimbang pekerjaan kelompok "kuantitas": pot lima puluh pon diberi nilai "A", empat puluh pon "B", dan seterusnya. Namun, yang dinilai berdasarkan "kualitas" hanya perlu menghasilkan satu pot - meskipun pot yang sempurna - untuk mendapatkan "A". Nah, tibalah saat penilaian dan fakta aneh muncul: karya-karya dengan kualitas terbaik semuanya diproduksi oleh kelompok yang dinilai berdasarkan kuantitas. Tampaknya sementara "kuantitas"

Intinya membuat tangan Anda lebih cepat kotor dan lebih sering meningkatkan keterampilan Anda lebih baik, daripada menghabiskan waktu Anda belajar dan berteori tentang cara "sempurna" untuk melakukannya. Saran saya, terus berlatih, ikuti perkembangan teknologi, dan belajar desain.

Satu kemungkinan yang sepertinya tidak disebutkan oleh orang lain adalah Anda baik-baik saja dan manajer Anda tidak begitu baik. Bagaimana mereka mengukur produktivitas? Bisakah mereka memberi Anda contoh spesifik atau hanya persepsi umum? Sudahkah mereka memperhitungkan jumlah waktu yang dihabiskan untuk memperbaiki pekerjaan orang lain dibandingkan dengan pekerjaan Anda?

Saya telah melihat banyak orang mendapatkan pujian karena menyelesaikan pekerjaan, sementara anggota tim lainnya memperbaiki kekacauan yang mereka tinggalkan.

Sebagian besar dari apa yang orang pikir penting adalah tidak penting. Kecepatan mengetik tidak penting. Mesin atau alat yang lebih cepat tidak penting. Kami bukan juru ketik atau operator mesin. Kami adalah pekerja yang berpikir. Kami adalah pengambil keputusan .

Apa yang penting adalah menggunakan umpan balik untuk terus meningkatkan proses pengambilan keputusan Anda. Satu-satunya cara untuk melakukan ini, seperti memperoleh keterampilan lain, adalah melalui pengalaman, latihan yang bertujuan , dan umpan balik terus menerus.

• Kerjakan proyek sampingan.
• Bekerja pada proyek sumber terbuka.
• Bekerja dengan pengembang yang lebih baik dari Anda. Program pasangan!
• Ekspos diri Anda pada alat dan teknik baru. Simpan apa yang berhasil.
• Lakukan latihan pemrograman yang dirancang untuk melatih alat pembuat keputusan Anda *.
• Pantau peningkatan Anda berdasarkan metrik obyektif seperti tingkat cacat dan kecepatan, dan metrik subjektif seperti kualitas kode dan kebugaran.

Akhirnya: ingat bahwa kecepatan tanpa kualitas tidak berguna, dan sebaliknya. Untuk memaksimalkan utilitas Anda, temukan keseimbangan antara ketegangan ini.

* http://codekata.pragprog.com/

Sangat mungkin bahwa sebenarnya, Anda diminta untuk mengorbankan beberapa kualitas, untuk kecepatan yang lebih besar.

Dalam beberapa lingkungan pengembangan ¹ , sama sekali tidak sepadan dengan waktu ekstra untuk menghasilkan sesuatu yang dipoles, ketika "cukup baik" akan dilakukan.

^{1 - Saya sedang memikirkan "toolmith internal" pada khususnya, tetapi mungkin ada yang lain.}

Sepertinya Anda melakukan semua hal baik - bahwa dalam jangka menengah akan membuat Anda lebih cepat, jadi tidak jelas apakah Anda benar-benar lambat. Hanya Anda yang benar-benar tahu itu. (tetapi ini adalah kemungkinan yang sangat nyata - PeopleWare mengklaim perbedaan produktivitas hingga 10X antara pengembang untuk tugas yang sama).

Jadi saya punya beberapa saran untuk Anda:

1. Waktu adalah hal yang relatif, jadi mungkin masalahnya bukan kecepatan Anda yang sebenarnya tetapi persepsi waktu yang Anda berikan. Anda mungkin menyiratkan akan memakan waktu seminggu, tetapi akhirnya menghabiskan dua minggu, di mana orang lain mungkin menghabiskan 3 minggu ... tetapi Anda hanya melihat 1 minggu lambat.

2. Karena Anda sering mendapatkan umpan balik ini, mungkin waktu untuk berbicara dengan manajer Anda dan rekan kerja untuk melihat apa yang mereka katakan - pasti ada banyak yang bisa dipelajari dari mereka.

3. Lakukan pemrograman pasangan dengan pengembang "cepat" untuk melihat apakah Anda dapat menemukan perbedaannya.

Secara efektif, intinya adalah pengalaman . Untuk menjadi lebih cepat dalam apa yang Anda lakukan adalah seperti mengendarai mobil, awalnya Anda takut karena orang lain adalah pengemudi yang cepat (atau mabuk) (atau keduanya) dan Anda ingin mencapai rumah dengan selamat (dalam hal perangkat lunak, Anda ingin memastikan kode Anda berfungsi sebagaimana dikembangkan dan berfungsi dengan baik).

Selama bertahun-tahun / bulan, begitu Anda terbiasa mengemudi dan jalan bebas hambatan, Anda belajar beberapa trik di sepanjang jalan yang membuat berkendara Anda menyenangkan. Itulah yang kami sebut pengalaman. "Trik" itu (yang saya sebut ciri) adalah yang membantu.

Dalam kasus saya, saya telah belajar penggunaan nyata dari pola desain dengan pengkodean (bahkan @ rumah) dan belajar penggunaan beberapa. Jadi, ketika saya menemukan masalah yang memerlukan pola desain, saya menggunakan pengalaman masa lalu untuk melihat mana yang bekerja dan mengapa itu bekerja / tidak bekerja untuk situasi saya.

Singkatnya:

• Pengalaman menciptakan sifat-sifat yang meningkatkan kepercayaan diri dan perangkat lunak yang lebih baik.

PS: Pengalaman juga berasal dari belajar dari orang lain. Misalnya Bantuan dari SO, Pair Programming, Peer Reviews, dll. Anda tidak dapat memiliki pengalaman jika Anda tidak dapat melihat ke belakang dan belajar dari kesalahan (atau jika seseorang tidak pernah menantang usaha Anda).

Pertanyaannya adalah apakah Anda lebih murah ketika melihat total biaya jangka panjang.

Dengan kata lain, apakah perbaikan bug yang Anda buat dengan hati-hati berkualitas tinggi (termasuk kasus uji dan dokumentasi) sehingga melebihi biaya untuk mempertahankan perbaikan bug yang dilakukan oleh rekan kerja Anda yang lebih cepat?

Jika ya, maka Anda perlu membuat atasan Anda mengetahui fakta ini. Mungkin sulit untuk diperdebatkan jika mereka tidak mengukur dan memiliki data yang diperlukan untuk mengonfirmasi penilaian Anda.

Jika tidak, maka Anda harus mempertimbangkan mengapa hal ini terjadi:

• Apakah Anda terlalu berpengalaman?
• Apakah Anda menghabiskan banyak waktu untuk melakukan hal-hal yang tidak diminta yang Anda yakini ada di sana?
• Apakah Anda kesulitan menentukan kapan perbaikan selesai?
• Apakah kode Anda memiliki kualitas yang lebih rendah daripada yang Anda kira?
• Jika Anda mendekati pengembangan kode dengan cara yang berbeda karena Anda membutuhkan waktu terlalu lama untuk mempercepat cara Anda melakukannya sekarang?
• Apakah Anda menghabiskan terlalu banyak waktu untuk hal-hal seperti situs ini?

Pikirkan dan edit pertanyaan Anda dengan temuan Anda.

Semua pertanyaan yang dilakukan orang tentang apakah Anda benar-benar lambat atau tidak itu konyol. Menjadi programmer yang lebih cepat tanpa mengorbankan kualitas selalu merupakan tujuan yang baik tidak peduli seberapa lambat atau cepat Anda sudah. Ini adalah tujuan nomor 1 saya sebagai seorang programmer dan saya tidak akan pernah selesai. Saya selalu berusaha untuk menjadi lebih cepat tanpa mengorbankan kualitas, saya terobsesi dengan itu. Inilah yang telah berhasil bagi saya sejauh ini dalam urutan membantu, bersama dengan beberapa ide eksperimental di akhir:

1) Jangan pernah berhenti belajar: Pelajari semua yang Anda bisa tentang pemrograman dan menggunakan komputer secara umum. Temukan area tempat Anda lemah dan pelajarilah. Bahkan jika tampaknya sama sekali tidak terkait dengan pekerjaan Anda dan C #, saya jamin jika Anda mencarinya, Anda akan sering menemukan cara untuk menerapkannya pada apa yang Anda lakukan. Belajar juga tentang pengalaman, jadi jangan hanya membaca hal-hal tetapi cobalah dan kembangkan keterampilan Anda. Jika Anda terbiasa menggunakan Windows, cobalah Unix atau sebaliknya. Jika Anda biasanya suka menggunakan IDE, cobalah alat baris perintah dan editor teks atau sebaliknya. Jika Anda mendengar alat atau teknologi yang belum pernah Anda dengar sebelumnya atau tidak tahu banyak tentang, jangan menyerah pada godaan untuk melanjutkan. Lihatlah! Jangan takut untuk berpikir di luar kotak dan mempelajari teknologi baru eksperimental yang orang lain katakan tidak taktis;

2) Memecah proyek: Cobalah untuk memecah proyek Anda menjadi proyek mini. Cobalah untuk melakukan rilis baru setiap hari atau paling banyak sekali setiap hari. Tanyakan pada diri sendiri "Berapa jumlah minimum fungsionalitas yang dapat saya lepaskan, dan masih merilis sesuatu yang bermanfaat bagi pengguna." Ini adalah keterampilan yang akan Anda pelajari dengan melakukannya. Anda mungkin perlu meyakinkan manajer Anda untuk membiarkan Anda melakukan ini, tetapi mereka biasanya akan senang dengan hasilnya dengan cepat. Dengan melakukan ini, Anda akan mulai memperhatikan bahwa hal-hal yang Anda pikir penting untuk fitur Anda sebenarnya adalah fitur tambahan yang dapat dikembangkan nanti. Ini memungkinkan Anda dan manajer Anda untuk hanya memprioritaskan fitur yang paling penting daripada semua fitur yang terkait dengan yang sedang Anda kerjakan. Ini memungkinkan Anda untuk berpikir lebih cepat dengan menjaga pikiran Anda jernih dan fokus. Anda pada gilirannya akan memprogram lebih cepat secara sah. Manajer Anda atau setidaknya manajer manajer Anda juga cenderung menganggap bahwa Anda sekarang memprogram lebih cepat daripada yang sebenarnya karena Anda mendapatkan lebih banyak rilis. Manfaat lain yang sangat besar dari hal ini adalah bahwa Anda akan jauh lebih baik dalam memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikannya, dan manajer Anda akan menyukai Anda untuk ini. Karena Anda sudah melakukan banyak pengujian otomatis, Anda seharusnya tidak memiliki masalah melakukan rilis sering yang stabil. Anda mungkin perlu meningkatkan sistem pembuatan otomatis Anda. Saya sangat merekomendasikan membaca buku Pengiriman Berkelanjutan dalam seri Martin Fowler. Ini sulit dibaca dan karena sangat berulang, tetapi masih sangat membantu. Para manajer juga cenderung menganggap bahwa Anda sekarang memprogram lebih cepat daripada yang sebenarnya karena Anda mendapatkan lebih banyak rilis. Manfaat lain yang sangat besar dari hal ini adalah bahwa Anda akan jauh lebih baik dalam memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikannya, dan manajer Anda akan menyukai Anda untuk ini. Karena Anda sudah melakukan banyak pengujian otomatis, Anda seharusnya tidak memiliki masalah melakukan rilis sering yang stabil. Anda mungkin perlu meningkatkan sistem pembuatan otomatis Anda. Saya sangat merekomendasikan membaca buku Pengiriman Berkelanjutan dalam seri Martin Fowler. Ini sulit dibaca dan karena sangat berulang, tetapi masih sangat membantu. Para manajer juga cenderung menganggap bahwa Anda sekarang memprogram lebih cepat daripada yang sebenarnya karena Anda mendapatkan lebih banyak rilis. Manfaat lain yang sangat besar dari hal ini adalah bahwa Anda akan jauh lebih baik dalam memperkirakan berapa lama waktu yang dibutuhkan untuk menyelesaikannya, dan manajer Anda akan menyukai Anda untuk ini. Karena Anda sudah melakukan banyak pengujian otomatis, Anda seharusnya tidak memiliki masalah melakukan rilis sering yang stabil. Anda mungkin perlu meningkatkan sistem pembuatan otomatis Anda. Saya sangat merekomendasikan membaca buku Pengiriman Berkelanjutan dalam seri Martin Fowler. Ini sulit dibaca dan karena sangat berulang, tetapi masih sangat membantu. dan manajer Anda akan mencintai Anda untuk ini. Karena Anda sudah melakukan banyak pengujian otomatis, Anda seharusnya tidak memiliki masalah melakukan rilis sering yang stabil. Anda mungkin perlu meningkatkan sistem pembuatan otomatis Anda. Saya sangat merekomendasikan membaca buku Pengiriman Berkelanjutan dalam seri Martin Fowler. Ini sulit dibaca dan karena sangat berulang, tetapi masih sangat membantu. dan manajer Anda akan mencintai Anda untuk ini. Karena Anda sudah melakukan banyak pengujian otomatis, Anda seharusnya tidak memiliki masalah melakukan rilis sering yang stabil. Anda mungkin perlu meningkatkan sistem pembuatan otomatis Anda. Saya sangat merekomendasikan membaca buku Pengiriman Berkelanjutan dalam seri Martin Fowler. Ini sulit dibaca dan karena itu sangat berulang, tetapi masih sangat membantu.

3) Gunakan teknik pomodoro dan sesuaikan / ubah apa yang tidak cocok untuk Anda. Jika Anda menggabungkan ini dengan nomor 2 di daftar ini, Anda akan mendapatkan peningkatan produktivitas BESAR.

4) Pelajari Vim. Bahkan jika Anda akhirnya menggunakan perintah ini di dalam Visual Studio via ViEmu, atau dari dalam Eclipse melalui plugin, atau dari dalam Emacs, Anda akan mendapatkan produktivitas. Cara terbaik untuk belajar Vim adalah mulai menggunakannya dan memaksakan diri untuk tidak pernah (nonaktifkan / kembali ke alat lama Anda) sampai Anda sudah menguasainya. Ini menyakitkan pada awalnya, tetapi Anda tidak akan pernah ingin kembali, dan bahkan merasa ngeri ketika Anda harus bekerja tanpanya. Beberapa akan mengatakan ini tidak akan meningkatkan kecepatan Anda banyak. Tetapi lebih cepat lebih cepat, terutama ketika membaca dan memodifikasi kode APA YANG KITA LAKUKAN, dan saya mendapati diri saya menghemat banyak waktu dengan ini pada kesempatan.

5) Yang terakhir ini belum tentu direkomendasikan karena saya tidak yakin itu ide yang bagus, dan itu sebenarnya dapat menurunkan produktivitas Anda, tetapi saya tetap akan melaluinya di luar sana. Anda dapat mencoba melakukan lebih banyak tes penerimaan dan kurang tes unit, atau mungkin setidaknya memastikan Anda melakukan beberapa pengujian penerimaan. Saya telah sukses dengan SpecFlow, tetapi saya curiga ada sesuatu yang lebih baik di luar sana. Bahkan menulis spesifikasi bisa sangat teknis, jadi Anda mungkin hanya ingin manajer / pelanggan Anda menulis versi konsep kasar terlebih dahulu sehingga Anda berubah secara signifikan, atau Anda dapat menulis semuanya sendiri dan minta mereka membaca dan OK. Ini akan membantu Anda dengan nomor 2 dari daftar ini. Juga tes penerimaan bisa lebih praktis dan membutuhkan lebih sedikit kode daripada tes unit. Ini bukan untuk mengatakan mereka menggantinya, alat yang berbeda untuk hal yang berbeda.

6) Yang ini bahkan lebih eksperimental dan kontroversial. Saya belum benar-benar melakukan ini sendiri sehingga saya tidak bisa merekomendasikannya. Pelajari dan gunakan Sistem Pemrograman Meta dari JetBrains. Gunakan itu untuk membuat alat yang digunakan manajer / pelanggan Anda untuk membuat sendiri perangkat lunak yang diinginkan. Anda bahkan mungkin dapat berhenti melakukan tes unit dan penerimaan jika Anda dapat menggunakan ini untuk membuat alat yang digunakan manajer / pelanggan Anda untuk menentukan perilaku dengan cara yang sangat mudah dan tidak berbelit-belit. Idenya bukan untuk menyingkirkan programmer. Pemrogram masih perlu menambahkan fitur baru ke alat-alat ini yang digunakan oleh pelanggan / manajer setiap kali mereka (orang-orang, bukan alat) tidak dapat dengan mudah membuat beberapa fungsi yang diinginkan. Saya percaya bahwa MPS atau alat lain yang mirip dengannya adalah jalan masa depan.

Gunakan otak Anda lebih banyak dan lakukan lebih sedikit pengujian. Sejujurnya, pengujian memiliki tempatnya, tetapi mahal.

Baca juga Pemrograman Seni Unix (online gratis, harga buku pantas)

Akhirnya, Anda mungkin tidak berada di tempat yang tepat. Pasak bundar dalam pekerjaan persegi, dll.

Pada akhirnya itu seperti sekolah: "Keluarkan apa yang diinginkan guru" menjadi "hasil yang diminta dan dibayar oleh manajemen".

Jika Anda mengambil proyek besar, selesai, dan mendapatkan jumlah baris kode "final" per jam, Anda akan menemukan bahwa kode program jauh lebih lambat daripada yang bisa Anda bayangkan.

Kami hanya berbicara beberapa baris kode sehari. Sisa waktu yang Anda habiskan untuk debugging, menulis ulang dan melakukan hal-hal programmer umum.

Anda mungkin pernah mendengar pepatah lama - jika Anda menemukan kesalahan saat mengetik, itu akan menghemat 10 kali lipat jika Anda menangkapnya saat membangun, yang 10x lebih baik daripada menangkapnya selama QA, yang 10x lebih baik daripada menangkapnya setelah rilis ..

Jadi, bagaimana Anda mempercepatnya? Saya tidak akan berkonsentrasi pada segala bentuk kecepatan pengetikan - mengurangi kesalahan dan meningkatkan "interaksi masa depan" lainnya dengan kode Anda harus menjadi investasi yang jauh lebih baik dari waktu Anda.

Kode yang mudah dibaca dan jelas sangat penting. Anda menulis kode sekali, tetapi akan dibaca puluhan kali. Menulis agar mudah dibaca akan menghemat BANYAK masalah Anda (yang juga akan menghemat banyak waktu). Jika Anda PERNAH kembali dan membaca kode Anda dan harus memikirkannya sebentar lagi, maka Anda salah melakukannya.

Pemrograman pasangan dapat mengurangi waktu QA dan, jika Anda menganggap satu programmer menghasilkan hanya beberapa baris sehari, jika dua dapat kode pada tingkat yang sama dengan satu tetapi dengan lebih sedikit kesalahan maka Anda WAY maju.

Pengkodean secara defensif (misalnya, pengecekan parameter) dapat mengurangi masalah ... Jika Anda memiliki analis / arsitek yang sangat bagus di tim Anda, maka Anda dapat menghemat waktu dengan desain awal yang baik.

Jika tidak, terus tingkatkan keterampilan desain Anda. Ketika Anda mendapatkan pengalaman, Anda akan menemukan diri Anda lebih mampu mengenali pola-pola yang tidak berfungsi dan menghindarinya, Anda akan dapat mengidentifikasi tenggang waktu lebih awal, dll.

Sudahkah Anda mempertimbangkan untuk melakukan audit terperinci atas diri Anda saat bekerja? Entah pelacakan pena dan kertas tentang bagaimana Anda menghabiskan waktu Anda atau menggunakan sesuatu seperti Rescue Time untuk melacak diri Anda.

Setelah Anda lebih tahu persis BAGAIMANA Anda menghabiskan waktu Anda, Anda bisa mendapatkan ide yang lebih baik tentang apa yang perlu ditingkatkan dan memfokuskan upaya Anda di sana.

Idealnya Anda dapat menantang beberapa rekan kerja Anda untuk melakukan ini juga, membandingkan hasil Anda, dan mendapatkan ide dari satu sama lain. Anda mungkin memiliki beberapa kekuatan yang bisa mereka manfaatkan juga.

Mungkin Anda mengetahui bahwa Anda menghabiskan terlalu banyak waktu pada bagian dari proses Anda yang bisa otomatis atau hanya bahwa Anda memiliki banyak gangguan selama bagian hari tertentu dan bagian lain dari hari itu tenang, maka Anda dapat merencanakan tugas Anda di sekitar itu, dll.

Atau mungkin Anda mengetahui bahwa pengujian membutuhkan waktu lebih lama daripada yang Anda pikirkan dan Anda harus memikirkan kembali persepsi Anda bahwa itu membuat Anda lebih cepat.

Jika tidak ada yang lain itu memberi Anda beberapa tolok ukur yang dapat Anda lawan.

Dari daftar Anda, Anda baik-baik saja.

Jika kolega Anda membuat kode dengan nomor CRAP yang lebih tinggi, mereka akan lebih cepat. CRAP adalah metrik bernama komikal yang menggabungkan kompleksitas siklomatik dan cakupan Tes.

Jangan menulis kode yang lebih CRAP daripada yang Anda harus. ;)

Satu-satunya perubahan yang saya sarankan untuk Anda adalah menggunakan perpustakaan, jangan menulisnya kecuali:

1. Perusahaan Anda menjual perpustakaan
2. Anda telah refactored kode berulang ke perpustakaan

Anda membaca dan melakukan dan itu bagus. Tapi Anda mungkin terjebak berpikir tentang kode procuedural atau OO, Sudahkah Anda mengekspos diri Anda pada pemrograman Fungsional (katakanlah Haskell?) Dan Prolog?

Untuk mempertajam teknik pemrograman OO Anda, sudahkah Anda bermain dengan Smalltalk / Squeak?

Dan akhirnya, teori. Apakah Anda setidaknya memiliki pemahaman dasar tentang teori graf? (Beberapa program bekerja dengan pohon, DAG atau hanya grafik polos di beberapa titik. Jaringan adalah grafik)

Saya akan mengutip Paman Bob :

Satu-satunya cara untuk bergerak cepat adalah berjalan dengan baik.

Setiap kali Anda mulai tergoda untuk bertukar kualitas demi kecepatan, Anda melambat. Setiap saat.

- "Mediementitas Kendaraan", Robert C. Martin

Sejauh yang saya tahu itu:

1. baik
2. cepat
3. murah

Sebagai seorang manajer, Anda dapat memilih 2.

Jangan khawatir tentang komentar Anda dengan cepat. Sebagai sesama pembuat kode, saya lebih suka mempertahankan kode yang dipikirkan dengan baik dan ditulis dengan baik daripada sesuatu yang ditampar bersama.

Hal-hal utama yang dapat saya pikirkan adalah sebagai berikut

• Tingkatkan kecepatan mengetik Anda.
• Gunakan alat yang memberikan keuntungan produktivitas. Misalnya ReSharper.
• Mesin atau alat yang lebih cepat. Seperti lebih banyak RAM atau solid state drive.

Saya yakin ada beberapa hal yang dapat Anda lakukan di bidang keterampilan pengkodean juga, tetapi sepertinya Anda sudah menguasai semua hal itu. Hal-hal yang saya sebutkan di atas biasanya diabaikan oleh pengembang.

Anda bisa mengikuti kursus mengetik cepat. Saya tidak tahu apakah mengetik lebih cepat itu masalah, tetapi "pengkodean terlalu lambat" bisa disebabkan oleh kecepatan mengetik yang lambat.

Bagaimana dengan pembuat kode? Terkadang kode berulang. Refactoring dapat menghapus sebagian dari itu, tetapi bahkan kemudian Anda mungkin memiliki panggilan berulang ke fungsi refactored yang sama. Bergantung pada data dan kode tempat Anda bekerja, pembuat kode (ditulis dalam Excel, Perl, Java, apa pun ...) mungkin menghemat banyak waktu. Dan menggunakan alat penghasil kode untuk pengembangan UI biasanya tidak perlu repot.

Dan akhirnya, mungkin metriknya salah. Pernahkah Anda menganggap bahwa Anda mengkode pada kecepatan fasteset yang mungkin diberikan segala sesuatu yang lain, dan bahwa garis waktu terlalu pendek, membuat Anda tampaknya menjadi pembuat kode lambat?

Berdasarkan hasil edit dalam pertanyaan Anda, sepertinya Anda bisa mengambil rute dari beberapa rekan kerja Anda dan meretas bersama solusi tercepat yang akan bekerja - dan dokumentasi dan QA terkutuk!

Atau ... dapatkan lebih banyak pengalaman dan praktik di bidang tertentu sehingga Anda tahu basis kode dan API dengan baik sehingga Anda bisa membuat kode solusi dalam tidur Anda. Ini bisa dilakukan tetapi membutuhkan lebih banyak waktu. Jika pengembang lain yang lebih cepat dari Anda dikenal lebih senior dan lebih berpengalaman maka hanya ada satu hal yang harus dilakukan - Anda harus menjadi lebih senior dan berpengalaman!

Saya keberatan dengan pandangan OP "kualitas yang dikorbankan untuk kecepatan".

Coders profesional (programmer) harus memenuhi 3 objek:
1) Kode harus berjalan sebagaimana dimaksud
2) Pengiriman harus tepat waktu
3) Memiliki kualitas yang baik, dokumentasi, dll.
4) Lainnya dll.

Saya pikir, OP disalahkan sebagai lambat mungkin karena OP tidak selesai tepat waktu.

Ini adalah tangkapan 22 yang sulit untuk dilewati. Meskipun Anda mungkin masih kurang pengalaman dan sejumlah pengetahuan dalam banyak aspek sudah lebih cepat daripada kebanyakan orang, masalahnya adalah lebih sulit untuk mengukur .

Secara pribadi yang terbaik yang dapat Anda lakukan pada saat ini adalah mengukur diri sendiri. Berikan diri Anda umpan balik tentang bagaimana Anda bekerja, mungkin perubahan sederhana dalam kebiasaan kerja Anda dapat membuat Anda lebih produktif.

Saya menemukan surat-surat menggerogoti lebih dari yang saya kira hanya karena gangguan. Sekarang saya hanya menjawab surat dua kali sehari dan mendapatkan hampir 1 jam produktivitas beberapa hari. Cobalah metode seperti pomodoro , saya menggunakannya sebagai alat ukur. Secara berkala (15 menit) saya akan mencatat apa yang saya lakukan pada saat itu. Ini memungkinkan saya untuk melihat bagaimana hari-hari saya disusun dan apa yang dapat saya lakukan untuk memaksimalkan efisiensi.

Keuntungan Squeak untuk pengkodean cepat jauh lebih dari sekadar "mengasah keterampilan OOP seseorang." Ada alasan mengapa GUI modern, serta IDE, ditemukan di Smalltalk, belum lagi JUNIT adalah pelabuhan SUNIT ke Jawa, istilah "OOP" diciptakan untuk menggambarkan Smalltalk, dll., Dll.

Seseorang harus selalu menggunakan bahasa dan lingkungan yang paling cocok untuk apa pun yang ingin dicapai, tetapi untuk prototipe umum, setidaknya, saya akan mencocokkan mencicit terhadap apa pun, dengan kemungkinan pengecualian HyperCard, dan bahkan itu akan memerlukan pembandingan untuk melihat mana yang sebenarnya lebih cepat mengingat bahwa ada fasilitas seperti kartu yang dibangun ke dalam mencicit.