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


144

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.


4
Apakah orang lain membuat kode lebih cepat daripada Anda dengan kualitas yang sama? Jika tidak, arahkan ke catatan pemeliharaan Anda dan laporan bug untuk menunjukkan bahwa kecepatan bukanlah masalah.
Michael K


1
Untuk mencoba memenangkan perlombaan, beberapa akan memilih kuda tercepat mereka dan mengalahkan mereka untuk melaju lebih cepat. Ada pertanyaan?
Paul

24
Saya tidak punya jawaban untuk Anda tetapi saya punya sesuatu yang dapat membuat Anda merasa lebih baik. Betapapun lambatnya Anda sebagai seorang programmer, betapapun tidak efisiennya Anda, manajer Anda jauh, jauh lebih buruk. Orang bodoh macam apa yang mengatakan, "Hei, Bob, kau terlalu lamban" tanpa membantumu untuk berkembang? Mungkin juga memberitahu Anda Anda terlalu pendek. Itu bukan kepemimpinan, itu hanya heckling. Saya kira saya punya saran: cari pekerjaan dengan manajer yang kompeten, yang akan bekerja dengan Anda untuk mengatasi kekurangan Anda.
Malvolio

1
Semua jawaban membuat saya tidak bahagia. Jika Anda hanya ingin langkah noob-> biasa-biasa saja maka mungkin melakukan satu hal tidak apa-apa. Tapi ahli biasa-biasa saja selalu membutuhkan untuk belajar segalanya. Anda perlu mempelajari VCS Anda, editor Anda, bahasa pemrograman Anda dan kerangka kerja Anda secara mendalam. Anda perlu mengulangi langkah-langkah sulit dan menarik yang dapat Anda lakukan tanpa berpikir. Dan kemudian Anda perlu menemukan cara untuk menerapkan konteks, seperti perbedaan antara kebutuhan pelanggan dan kebutuhan rekan kerja Anda, bagaimana suasana hati sehari-hari Anda memengaruhi kemampuan Anda untuk membuat kode / desain / diskusi. Jika Anda ingin 1 hal lakukan ini: pelajari semuanya.
erikbwork

Jawaban:


158

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.


12
Apakah analogi ini tidak menyiratkan bahwa tembikar menghasilkan tumpukan pot sampah sebelum menghasilkan yang berkualitas? Bisakah Anda melakukannya dalam lingkungan profesional, dengan segala nurani? Dan bagaimana dengan mereka yang belajar dan berteori kemudian menyelesaikan pekerjaan sebelum batas waktu?
pdr

4
Saya setuju dengan 20 pot sampah untuk pengalaman pemrograman hobi. Itu membantu saya dengan pengalaman pemrograman profesional saya juga; selain itu, harus mulai dari suatu tempat.
ashes999

23
Saya hanya memilih untuk melihat ini untuk nilai permukaan, "latihan membuat sempurna." Jangan melihat terlalu jauh ke dalamnya;)
chrisw

6
Saya tidak suka jawaban ini karena terlalu mudah diambil dengan cara yang salah, sama seperti "prototipe sekali pakai" yang sepertinya tidak pernah dibuang.
Rudolf Olah

2
Saya merasa aneh bahwa begitu banyak orang memiliki masalah dengan ini. Ini hampir analogi yang sempurna untuk proses pengembangan berulang. Anda membangun sesuatu dengan cepat untuk memenuhi persyaratan, memperbaiki bug dan refactor sampai benar dan cukup baik. Jika Anda tidak membangun perangkat lunak dengan cara ini, Anda benar-benar perlu mencobanya. Perenungan dan menatap pusar jauh lebih efektif daripada menyelesaikan sesuatu dan membiarkan orang menggedornya.
JimmyJames

72

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.


1
Ini mungkin sebagian besar masalah. Melihat hal itu dalam retrospeksi, sepertinya terlalu kebetulan bahwa saya selalu dibandingkan dengan orang-orang yang bekerja di perusahaan saya bertahun-tahun lebih lama daripada yang saya miliki. Hmm ...
ashes999

Jika itu masalahnya, saran saya adalah mengajukan dua pertanyaan pertama secara langsung dan melihat respons apa yang Anda dapatkan, ambil dari sana
pdr

16
betapa sangat benar, begitu sering saya temui manajer yang menyatakan saya tidak kompeten ketika proyek yang saya hasilkan dalam produksi secara sistematis menghasilkan satu atau dua urutan besarnya lebih sedikit panggilan dukungan daripada pekerjaan yang setara dari tim lain. Banyak yang gagal melihat gambaran yang lebih besar. Metrik membantu sebanyak itu gangguan. Biasanya manajer semacam itu akan mencoba untuk membuat game sistem sedemikian rupa sehingga statistik mereka terlihat bagus.
Newtopian

Ini lebih merupakan komentar daripada jawaban. Secara pribadi saya selalu ingin menjadi lebih cepat dan lebih efisien sebagai pembuat kode, terlepas dari apa yang dipikirkan orang lain. Pasti ada banyak hal untuk dibahas pada topik.
Andres Canella

@AndresCanella Setiap jawaban dalam pertanyaan ini pada dasarnya adalah komentar panjang. Anda benar, ada banyak hal untuk dibahas. Ini sebenarnya bukan format yang baik untuk diskusi (juga tidak dimaksudkan untuk itu). Tapi itu adalah pertanyaan yang bagus untuk memulai, itulah sebabnya mengapa ditutup dan ditandai sebagai Komunitas Wiki - yang mana tidak ada yang mendapat poin reputasi - daripada dihapus.
pdr

39

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/


Bisakah Anda menyarankan situs / istilah lain ke google? Saya pikir menangani satu tantangan aneh seminggu mungkin membuat otak saya bergerak dalam dimensi yang berbeda.
ashes999


1
Bagian di awal tidak masuk akal. Apa pun yang membuat Anda lebih cepat membuat Anda lebih cepat. Jika setidaknya sebagian waktu Anda dihabiskan untuk mengetik, maka meningkatkan kecepatan mengetik Anda akan membuat Anda lebih cepat. Jika setidaknya sebagian waktu Anda dihabiskan untuk menunggu komputer, maka komputer yang lebih cepat akan membuat Anda lebih cepat. Ketika Anda sedang berusaha untuk menjadi secepat mungkin dan terus meningkat, tidak ada yang harus dilupakan.
still_dreaming_1

12
Hal-hal kecil seperti mengetik dan kecepatan komputer membuat perbedaan besar. Ini karena efek samping yang tidak terduga. Ketika Anda harus menunggu komputer Anda, kebanyakan orang menjadi frustrasi dan beberapa bahkan menjadi terganggu. Kombinasi frustrasi dan gangguan adalah pembunuh produktivitas besar. Hal serupa berlaku untuk mengetik. Jika Anda cepat dalam mengetik, itu mungkin berarti Anda sudah benar-benar pandai mengetik, dan Anda mungkin tidak terlalu memikirkan mengetik. Ini membebaskan mata dan otak Anda untuk fokus pada tugas yang dihadapi, penambah produktivitas yang sangat besar.
still_dreaming_1

@ INTPnerd saya setuju. Jika Anda menghabiskan waktu memikirkan bagaimana kata "throw" muncul di layar Anda ("Saya perlu memindahkan mouse ke sana, lalu klik, maka saya perlu menemukan 't' di keyboard saya") otak Anda juga tidak punya waktu untuk pertimbangkan keputusan aktual.
erikbwork

25

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

Dalam beberapa lingkungan pengembangan 1 , 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.


5
Itulah yang saya simpulkan dari pekerjaan awal saya - yang lain menulis kualitas yang jauh lebih rendah, dengan biaya sangat cepat. Itu tumit achilles saya; Saya merasa sangat sulit untuk menulis kode buruk yang saya tahu akan menggigit saya nanti.
ashes999

Itu masalah mudah untuk dipecahkan. Anda perlu mengubah lingkungan perangkat lunak Anda. Anda perlu bekerja di lingkungan di mana melakukannya dengan benar lebih dihargai daripada menyelesaikannya dengan cepat. Ada pekerjaan di luar sana di mana itu penting.
Michael Shaw

Setelah bekerja di lingkungan di mana keduanya sama-sama dihargai, di antara semua yang melakukannya dengan benar - mereka yang melakukannya dengan lebih cepat mengalahkan mereka yang melakukannya dengan lebih lambat. Dan saya pikir saya berada di grup terakhir.
ashes999

2
oke, dalam hal ini, mungkin karena strategi yang Anda gunakan untuk menulis, menguji dan men-debug kode. tanyakan apakah Anda dapat memasangkan program dengan programmer "cepat" dan melihat bagaimana mereka mengatur proses pemikiran mereka?
Michael Shaw

1
@ ashes999: Dengan latihan dan pengalaman dan kesabaran Anda akan berpindah dari grup yang terakhir ke grup yang sebelumnya. Tidak ada pil ajaib untuk diminum yang akan mengubah Anda dalam semalam.
FrustratedWithFormsDesigner

12

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.


8

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).


Saya sangat berharap ini bukan jawaban yang tepat; Saya sudah menghabiskan banyak waktu luang saya coding, dan saya berharap ada sesuatu yang saya hilang yang akan memberi saya keunggulan yang signifikan.
ashes999

@ ashes999, ok! dengan coding waktu luang, apakah Anda meninjau pekerjaan Anda? Maksud saya adalah, harus ada waktu untuk bekerja pada optimasi kode dan memahami itu. Kita semua dapat kode, tetapi berapa kali kita memberi waktu untuk optimasi diri kita sendiri?
Buhake Sindi

@ TEG Saya mengulasnya di antara proyek; misalnya. jika saya mengkodekan sesuatu dengan cara tertentu pada proyek # 1, pada proyek serupa # 2, saya mungkin akan merefleksikan kekurangan desain dan banyak refactor.
ashes999

@ Eash - "refactor a lot" berarti Anda memiliki tenggang waktu di sana karena desain awal Anda tidak optimal. Jika bos Anda tidak tahu Anda memiliki masalah untuk menjelaskan ke mana perginya jam. Jika bos tahu, Anda memiliki masalah untuk menjelaskan mengapa desain Anda tidak ditinjau oleh rekan kerja yang berpengalaman.

@TRA maaf, saya seharusnya sudah ditentukan - pada proyek hobi saya banyak refactor. Di tempat kerja, saya melakukan refactor ringan, atau membuat tugas yang terlihat sehingga manajer saya tahu saya sedang melakukan refactoring.
ashes999

8

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.


8

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.


5

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".


3
Pengujian membuat saya lebih cepat, bukan lebih lambat. Lebih sedikit pengujian berarti lebih banyak regresi tidak bertumpuk lebih lama dan lebih sulit untuk diperbaiki, karena Anda tidak dapat mengambil lompatan besar dalam kode karena takut akan "sesuatu mungkin rusak."
ashes999

pengujian otomatis untuk saya adalah bau kode. Itu berarti kode itu tidak cukup sederhana.
Christopher Mahan

6
Jika kode Anda sangat sederhana sehingga tidak perlu tes maka itu tidak melakukan sesuatu yang menarik.
Rein Henrichs

Bagaimana kamu tahu, tepatnya? Oh, anggap lagi ... Saya akan mengarahkan Anda ke Rule of Modularity: Tulis bagian-bagian sederhana yang dihubungkan oleh antarmuka yang bersih. (dari The Art of Unix Programming)
Christopher Mahan

Saya pikir Anda mungkin memiliki sesuatu, di sana, Christopher. Di sinilah tempat abu menghabiskan banyak waktu, misalnya "membunuh". Terlalu banyak hal adalah hal yang buruk. Dalam hal ini, kecuali jika Anda memperbaiki kode untuk sistem kontrol penerbangan, Anda mungkin ingin memikirkan kembali jumlah pengujian yang Anda lakukan. Atau pergi ke bidang semacam itu.
user21007

5

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.


3

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.


3

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)


Banyak poin bagus di sini. Saya membutuhkan perpustakaan karena saya memerlukan fitur untuk game X (mis. Penyimpanan Silverlight di beberapa sesi permainan saya), dan saya dapat mengatakan bahwa itu akan kami butuhkan nanti - atau itu hanya kode abstrak (seperti pencarian jalur) yang tidak ada hubungannya dengan permainan saya. Saya memiliki latar belakang comp-sci, jadi saya sudah melakukan prosedural, OO, fungsional, dan yang lainnya (Prolog). Teori grafik, ya; rekursi grafik kedalaman-pertama yang saya gunakan sangat sering, cukup aneh.
ashes999


3

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.


2

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.


Saya berada di level yang sama dengan rekan kerja saya mengenai hal-hal ini (mungkin saya memiliki keunggulan dalam kecepatan mengetik); mereka masih lebih cepat, entah bagaimana. Pengalaman, mungkin?
ashes999

1
Di atas minimum minimum "berburu dan mematuk", kecepatan mengetik bukanlah faktor pembatas.

2
Anda mungkin sejajar dengan mereka dalam memiliki alat (misalnya, Resharper), tetapi apakah Anda tahu cara menggunakannya secara efektif? Saya telah melihat banyak orang menginstal Resharper dan kemudian tidak belajar cara menggunakan 80% dari fitur. Untuk itu, pastikan Anda memahami semua fitur refactoring dan pintasan Visual Studio. Saya mendapatkan keunggulan 2-3% dari orang lain di kantor saya hanya dari menjaga tangan saya pada keyboard sepanjang hari. Tikus lambat :)
EZ Hart

@EZ Hart: Poin yang sangat bagus. Beberapa IDE modern (saya sedang memikirkan Eclipse, dari atas kepala saya) memiliki alat yang sangat kuat untuk refactoring, mencari referensi kode (seperti di mana kelas atau metode yang dirujuk, tidak hanya di mana teks "myMethod" muncul) ). Untuk beberapa fitur "canggih" ini, perlu menghabiskan 5 menit untuk mempelajarinya agar dapat mengelola basis kode dengan lebih efisien.
FrustratedWithFormsDesigner

Kita semua level. Tidak ada dari kita yang memiliki alat :)
ashes999

2

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!


Itu bukan garis waktu; rekan kerja lainnya dapat melakukan pekerjaan yang sama lebih cepat. Mungkin itu pengalaman. +1 untuk kecepatan mengetik; Saya bisa mengetik sekitar 100WPM, jadi bukan itu juga.
ashes999

@ ashes999: dan jika orang yang dapat melakukan pekerjaan yang sama lebih cepat lebih berpengalaman, maka Anda mungkin akan mendapat manfaat paling banyak dari lebih banyak pengalaman dengan sistem yang dimaksud. Pengalaman membutuhkan waktu ...
FrustratedWithFormsDesigner

generator kode adalah anugerah campuran. Mereka mungkin menghemat waktu Anda, tetapi jika Anda harus menghabiskan terlalu banyak waktu pada kode yang dihasilkan, penghematan dapat berubah menjadi kerugian yang tidak dapat dikelola.

2

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.


2

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.


Jadi, Anda mengatakan bahwa Anda baik-baik saja? Menarik. :)
sum1stolemyname

sebenarnya itu adalah efek samping dari metode pelacakan waktu yang saya coba untuk sementara waktu ( davidseah.com/tools/ett/alpha ). Ternyata beberapa tren data yang menarik dan tidak terduga ketika saya mulai melihatnya melampaui bagian pelacak waktu. Itu setelah saya belajar tentang pomodoro, GTD dan semacamnya.
Newtopian

0

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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.