it-swarm-id.com

Bagaimana cara menjadi programmer "lebih cepat"?

Evaluasi pekerjaan terakhir saya hanya mencakup satu titik lemah: ketepatan waktu. Saya sudah mengetahui beberapa hal yang dapat saya lakukan untuk meningkatkan ini tetapi yang saya cari adalah beberapa hal lagi.

Apakah ada yang punya tips atau saran tentang apa yang mereka lakukan untuk meningkatkan kecepatan output mereka tanpa mengorbankan kualitasnya?

Bagaimana Anda memperkirakan garis waktu dan menaatinya? Apa yang Anda lakukan untuk menyelesaikan lebih banyak dalam periode waktu yang lebih singkat?

Setiap umpan balik sangat dihargai, terima kasih,

142
Nick Gotch

Matikan komputer. Ambil pensil dan kertas. Sketsa desain Anda. Tinjau dengan rekan-rekan Anda. Kemudian tulis kodenya.

190
gatorfax

Beberapa ide...

  • Hindari penyepuhan emas - lakukan hanya apa yang diminta dari Anda (dalam hal persyaratan)
  • Memahami persyaratan bisnis dan melakukannya dengan benar pertama kali
  • Pahami sepenuhnya lingkungan dan alat Anda
  • Menjadi pengetik yang fantastis, gunakan pintasan keyboard alih-alih mouse
  • Ambil pendekatan berulang dan bangun cek kewarasan untuk memastikan Anda berada di jalan yang benar
  • Jangan menemukan kembali roda, pertimbangkan menggunakan kembali pekerjaan sebelumnya dan pekerjaan orang lain
  • Hilangkan gangguan, jangan terus memeriksa email, melihat keluar, berbicara dengan rekan kerja, dll.
  • Jangan terlalu memaksakan diri - kenali kapan Anda perlu istirahat
149
Mayo

Keinginan Anda untuk menjadi programmer "lebih cepat" dengan sendirinya patut dipuji. Namun, tidak tepat waktu tidak berarti Anda lambat, itu berarti proyek itu direncanakan dengan buruk. Menjadi seorang programmer "yang lebih cepat" tidak akan membantu; itu hanya berarti Anda akan lebih cepat melewati tenggat waktu.

Anda (dan tim Anda) melakukan salah satu kesalahan berikut (atau semuanya):

  • meremehkan pekerjaan yang perlu dilakukan;
  • hilang persyaratan besar atau karya arsitektur selama perencanaan;
  • membingungkan perkiraan pekerjaan dengan perkiraan kalender dan tidak memperhitungkan hal-hal seperti rapat/telepon/overhead lainnya;

Ada beberapa cara Anda dapat mengatasi salah satu dari tiga di atas. Tetapi sebelum Anda bisa memperbaiki salah satunya, Anda perlu tahu mengapa semuanya berjalan seperti itu. Lakukan postmortem pada dua atau tiga perkiraan proyek terakhir vs waktu aktual yang diambil dan mencari tahu kemana waktu tambahan pergi.

Saya akan mengulanginya lagi - lambat dalam menulis kode tidak akan menyebabkan melewati tenggat wakt, jika Anda telah merencanakannya dengan benar untuk memperhitungkan fakta itu.

132
Franci Penov

Sungguh, pelajari editor Anda. Jika Anda menggunakan IDE pastikan Anda menggunakan semua fitur yang ditawarkan. Dapatkan lembar contekan untuk mempelajari pintasan keyboard untuk editor pilihan Anda. Jika Anda menggunakan pengaturan Shell pintas untuk direktori yang umum digunakan

89
slashnick

"Apakah ada yang punya tips atau saran tentang apa yang mereka lakukan untuk meningkatkan kecepatan output mereka tanpa mengorbankan kualitasnya?"

Banyak, banyak orang berusaha untuk kualitas "akhir" dengan mengorbankan sesuatu yang (a) sederhana, (b) dapat diandalkan dan (c) benar.

Cara paling penting untuk mempercepat pengembangan Anda adalah untuk menyederhanakan apa yang Anda lakukan sehingga benar-benar sesederhana mungkin.

Kebanyakan orang yang memiliki masalah dengan pengiriman tepat waktu memberikan cara, terlalu banyak. Dan alasan yang diberikan seringkali konyol. Mereka sering persyaratan hanya dirasakan, bukan persyaratan aktual.

Saya telah mendengar banyak orang memberi tahu saya apa yang pelanggan "harapkan". Ini adalah kebijakan yang buruk.

Bangun hal yang paling sederhana. Jika pelanggan membutuhkan lebih banyak, bangun lebih banyak. Tapi bangun dulu hal yang paling sederhana.

38
S.Lott

Hindari memoles kode Anda dengan sempurna, hanya membuatnya bekerja. Itu yang diharapkan bisnis.

Namun seringkali, peningkatan kecepatan menyiratkan kualitas pengorbanan.

32
user8685

Penggunaan kembali - Saya mencoba memfaktorkan bit pintar dari proyek sebelumnya, jadi saya bisa menggunakannya lagi dalam usaha masa depan. Selalu layak bertanya pada diri sendiri, "bisakah saya menggunakan ini lagi suatu hari nanti?"

29
Phil Jenkins

Tetap sederhana.

Jika Anda menggunakan TDD, Anda harus mengikuti "merah, hijau, refactor":

  1. Tulis tes yang gagal (merah). (Seringkali untuk fungsi kode Anda belum punya.)
  2. Melakukan kejahatan pengkodean yang mengerikan untuk membuat tes Anda lulus (hija). Hardcode jika perlu.
  3. Refactor, mungkin memecahkan tes untuk sementara waktu, tetapi secara keseluruhan meningkatkan desain.
24
bryanbcook

Unduh semua bahasa/dokumentasi perpustakaan Anda secara lokal ke komputer Anda, lalu cabut kabel jaringan Anda/matikan Wi-Fi .

Tidak mencoba menjadi lucu di sini. Ini sangat membantu saya!

22
mcjabberz

Perhatikan ketika Anda terlalu lama membaca Stack Overflow. Alasan "Kompilasi" hanya bekerja begitu lama. :)

20
Matthew Jones

Hindari berpindah tugas terlalu sering. Gangguan dan pengalihan tugas dapat mematikan sehari, bahkan jika Anda menggunakan alat seperti Mylyn untuk mengelola tugas Anda.

Mencari tahu perincian (mis., 30 menit) dan hanya mengerjakan hal-hal yang terkait dengan tugas yang ada. Hal lain (laporan bug baru, email tentang masalah lain, masalah prosedural yang tidak terkait) tertunda setidaknya sampai "pos pemeriksaan berikutnya". Pastikan untuk menonaktifkan pemberitahuan email yang muncul sehingga Anda tidak akan terjebak.

Ini sangat efektif jika Anda memiliki teman di tim Anda yang akan memberi tahu Anda jika semuanya benar-benar meleleh dan membutuhkan perhatian segera.

20
Uri

Lakukan dengan benar, cara terbaik, pertama kali. Jika itu berarti Anda harus berhenti dan memikirkannya sebentar sebelum mulai, maka lakukanlah. Bekerja 90% dari waktu.

14
ck01
14
AJ Johnson

Saya lakukan besok .

Getting Things Done juga sangat membantu.

Aku punya rentang perhatian yang pendek, jadi buku-buku ini membantuku tetap fokus ... apa yang aku lakukan lagi?

12
Matthew Jones

Latihan dan kerja keras.

Anda perlu meluangkan waktu dan upaya. Ketika Anda menjadi lebih nyaman dan percaya diri dengan alat apa pun yang Anda gunakan, kecepatan dan kreativitas harus diikuti.

Jika Anda ingin meningkatkan keterampilan tertentu, mungkin juga membantu untuk merancang latihan yang memungkinkan Anda bekerja secara khusus untuk itu. Jika kelambatan Anda dalam fase desain, cobalah mencari masalah desain untuk bekerja secara online. Mengulangi latihan yang sama akan membuat Anda menyelesaikannya lebih cepat dan melatih kecepatan. Saya pribadi suka latihan algoritma TopCoder untuk berlatih kecepatan pemrograman semata. Mereka juga memiliki tantangan desain, tetapi saya belum mencobanya.

12
DisplacedAussie

Pelajari tentang The Zone, pelajari cara memasukkan diri Anda ke dalamnya, dan pelajari cara mengenali ketika Anda tidak berada di dalamnya.

Setelah saya "di zona" saya sangat produktif dan kode mengalir keluar dari saya, seringkali saya bisa menyelesaikan 2 atau 3 hari pengkodean dalam 1 hari. Tetapi saya menemukan bahwa seringkali sulit untuk sampai ke tempat itu, saya menemukan diri saya menunda-nunda, menjadi terganggu oleh hal-hal lain (Stack Overflow misalnya).

Kutipan dari trik-apa-yang-Anda-gunakan-untuk-mendapatkan-diri-di-zona

11
Dustin Getz

Mengetahui IDE dan kerangka kerja Anda dengan baik. Harus beralih ke Google untuk setiap hal kecil membutuhkan waktu.

10
Mike Hall
9
ZeroCool

Sebelum Anda mulai berkembang:

  • Logout dari kotak surat Anda
  • Matikan semua IM klien
  • Dengan sopan minta teman sebaya untuk memberi Anda waktu untuk berkonsentrasi
  • Tentu saja, berhentilah berselancar di Internet

Setiap kali Anda terganggu, Anda akan melambat karena butuh waktu bagi pikiran Anda untuk kembali ke jalur dengan pikirannya. Saya telah mendengar angka-angka bahwa untuk setiap gangguan, dibutuhkan pikiran manusia 5-10 menit untuk kembali ke proses pemikiran sebelum interupsi. Dengan banyak waktu per interupsi, tidak perlu membuang banyak waktu sepanjang hari.

Orang-orang di perusahaan kami telah benar-benar mengambil waktu di kalender mereka dan kemudian pindah ke ruang konferensi kosong selama beberapa jam setiap hari.

8
dhable

Pelajari perkembangan Anda IDE masuk dan keluar. Pelajari tombol pintas. Pelajari cara menggunakan mouse lebih sedikit. Saya merasa ini menghemat banyak waktu bagi saya.

7
D3vtr0n

Apakah Anda lebih lambat dari kolega Anda, atau perkiraan Anda lebih optimis?

7
pjc50

Untuk menghasilkan perangkat lunak lebih cepat, saya telah menemukan hal terbaik untuk dilakukan adalah mempelajari runtime API Anda sebaik mungkin. Jangan mengetik daftar logika ketika ekstensi LINQ akan dilakukan; jangan membangun banyak pendengar acara saat mengikat akan bekerja, dll.

Sejauh estimasi, itu datang dengan pengalaman. Anda dapat menggunakan perangkat lunak estimasi di luar sana untuk membantu Anda mengetahui estimasi yang lebih baik.

Secara pribadi, saya menemukan dengan pengembang tingkat junior, ambil apa pun perkiraan awal mereka dan kalikan dengan 2, lalu gandakan. Ini akan menjelaskan semua pembelajaran, rapat, waktu yang terbuang, dll. Pengembang tingkat yang lebih senior cenderung bekerja pada faktor 2 di atas perkiraan mereka.

Sering kali, pertanyaannya bukan apakah perkiraan Anda salah. Apakah akun perkiraan Anda untuk semua hal yang benar? Apakah Anda memberikan perkiraan dan jadwal dalam hal upaya pengkodean atau dalam hal waktu kalender? Pikirkan sepanjang waktu di hari Anda dan seberapa banyak yang sebenarnya, koding yang produktif vs. pertemuan, pembelajaran, debugging, dll.

7
James Schek

Dua hal yang mungkin tersirat, tetapi saya belum melihat di antara jawaban di sini yang meningkatkan produktivitas adalah:

  • Gunakan beberapa jenis skrip build dan deployment. Mengkompilasi, menyebarkan, me-restart aplikasi-server dan seperti itu tidak menyedot waktu atau fokus, itu harus menjadi jenis sekali klik.

  • Memiliki semacam kontrol versi. Harus kode tanpa bisa mengembalikan perubahan seperti mencoba berjalan di atas telur

7
Buhb

Beberapa ide muncul di pikiran:

  1. Dapatkan pendapat lain tentang perkiraan Anda - Apakah ada pengembang lain yang bisa Anda tanyakan seperti "Hei, apakah Anda pikir Anda bisa menyelesaikan fitur semacam ini dalam jangka waktu ini?" Gagasannya adalah bahwa masukan orang lain mungkin membantu akurasi dalam beberapa kasus karena seseorang mungkin mencatat banyak hal yang Anda lewatkan dalam membuat perkiraan.

  2. Asah keterampilan estimasi Anda - Mulailah melacak seberapa jauh Anda pada estimasi dan mengapa Anda tidak aktif: Apakah item pekerjaan lain yang menyebabkan tenggat waktu tidak terpenuhi? Apakah Anda secara konsisten meremehkan betapa rumitnya sesuatu itu? Apakah Anda memberikan seluruh waktu ketika itu tidak praktis, mis. apa yang ditanyakan cukup samar sehingga hanya membuat prototipe akan memakan waktu berminggu-minggu dan kemudian harus ada evaluasi ulang dari apa lagi yang harus dilakukan? Melakukan hal ini mungkin paling membantu dalam membangun keterampilan itu sehingga jika Anda mengatakan sesuatu akan memakan waktu x jam, Anda dapat memiliki keyakinan akan hal itu karena Anda telah melakukannya berulang kali. Cara alternatif untuk menyatakan ini hanyalah latihan, latihan, latihan.

Memang Anda mungkin sudah mempertimbangkan ini, tetapi saya hanya berpikir ada baiknya menyatakan ini untuk orang-orang lain di luar sana yang mungkin tidak mempertimbangkan ide-ide ini.

7
JB King
  1. Ketahui teknologi luar dan dalam.
  2. Berhenti! Berpikir! Pergilah!
  3. Arsitek untuk apa pun yang mungkin muncul, tetapi hanya menerapkan apa yang benar-benar diminta.
  4. KISS - Keep It Simple Stupid
  5. Jika terlalu rumit, mungkin, itu tidak dipikirkan dengan baik. (Kembali ke 2 dan 4)
  6. Jangan terjebak di 5. Biasanya membayar untuk memulai dari awal (Kembali ke 2 dan 4)
  7. Kembali ke 1.
7
Rui Craveiro

Saya pikir mereka kata kunci di sini adalah "ketepatan waktu". Mereka tidak mengatakan Anda terlalu lambat, melainkan karena Anda tidak tepat waktu.

Dalam manajemen proyek, penting bagi manajer untuk dapat memperkirakan kapan item pekerjaan Anda akan lengkap dengan akurasi. Saya menduga bahwa alasan utama mengapa upaya Anda tidak dianggap tepat waktu adalah bahwa Anda sering memiliki barang yang tidak terkirim sesuai jadwal, dan dikirim jauh lebih lambat dari yang dijadwalkan.

Untuk meningkatkan ketepatan waktu Anda, Anda mungkin ingin meluangkan lebih banyak waktu untuk memahami berapa lama waktu yang dibutuhkan untuk menyelesaikan item pekerjaan tertentu yang diberikan keterampilan, pengalaman, dan domain Anda. Ini akan memungkinkan Anda untuk memberikan perkiraan yang lebih baik kepada manajer proyek Anda. Kuncinya di sini adalah "lebih baik" ... Anda dapat mengirimkan tepat waktu lebih sering dengan mengisi semuanya dengan faktor fudge, tetapi yang benar-benar ingin Anda perjuangkan adalah perkiraan yang lebih akurat.

Saya akan membahas ini dengan manajer Anda untuk melihat apakah ini benar-benar masalah. Jika tidak, Anda mungkin berakhir pemrograman dua kali lebih cepat, hal-hal yang menjanjikan dalam setengah waktu yang Anda gunakan, dan masih mendapatkan kritik karena ketepatan waktu Anda karena perkiraan Anda masih akan memiliki faktor kesalahan yang sama.

7
Larry Watanabe

Dapatkan stabil, tetap stabil.

Bangun sesuatu yang mengimplementasikan sedikit fungsi, dan pastikan itu berfungsi, ujung ke ujung. Kemudian, tetap berfungsi saat Anda menambahkan bit fungsionalitas baru. Ya, ini sebagian merupakan praktik TDD, tetapi masuk akal bahkan jika Anda tidak melakukan TDD.

Alasannya adalah bahwa setiap kali saya melihat seseorang dengan kode 2 minggu yang tidak pernah stabil, selalu membutuhkan 2 minggu untuk get stabil.

Jika Anda tetap stabil, Anda menghapus ketidakpastian itu, dan juga memberikan diri Anda cara untuk lingkup di dekat tenggat waktu jika perlu.

Argumen kontra yang jelas adalah bahwa melakukan hal ini akan membutuhkan lebih banyak waktu daripada hanya menulisnya sekali saja, karena Anda akan melakukan pekerjaan ekstra menstabilkan kode non-final. Saya tidak membeli ini sebentar. Ketika Anda memiliki kode yang berfungsi, Anda mengubah 5 baris, dan sesuatu rusak, Anda tahu persis di mana kerusakan itu pasti terjadi.

Jika Anda memiliki 10.000 baris kode yang tidak pernah berfungsi, dan Anda harus menemukan jeda, Anda memiliki banyak kode untuk dicari.

Perubahan kecil dan bertahap pada sistem FTW yang stabil secara konsisten. Lambat untuk cepat.

7
kyoryu

Bagi saya, mendapatkan produktivitas yang baik adalah memiliki gagasan yang jelas tentang apa yang ingin Anda capai, dan bagaimana Anda akan mencapainya.

7
mdma

Hampir semua jawaban telah dikatakan mati di banyak tempat di sini dan di tempat lain. Atau, setidaknya saya sudah mendengarnya sampai mati. Pelajari IDE Anda, belajar mengetik lebih cepat, menggunakan kerangka kerja, menggunakan pembuatan kode, dll., Dll. Ya tentu saja hal ini akan membantu dan saya ragu ada banyak programmer yang menguasai semuanya. Tetapi menjadi tipe programmer yang menanyakan pertanyaan dan sering mengunjungi situs-situs seperti Stack Overflow Anda sudah mengetahui hal-hal ini. Apakah Anda hanya ingin mengulanginya di sini atau Anda hanya ingin sedikit curhat?

Tetapi bagaimana jika kita bisa mencapai kondisi itu? Maksud saya menguasai semua saran ini? Lalu apa yang akan terjadi? Baik. Saya kira garis waktu akan berkurang lebih jauh. Dan lagi, kami akan kembali ke persepsi kualitas. Maksud saya, kerajinan kami pasti telah berkembang dan menjadi lebih dan lebih produktif selama beberapa dekade. Tetapi apakah kualitas meningkat selama waktu ini (tidak termasuk tahun-tahun awal tentu saja)?

Jawaban saya sederhana: perangkat lunak berkualitas membutuhkan wakt! Anda hanya dapat berdagang satu untuk yang lain (kualitas/kecepatan). Tapi ya kita semua tahu bahwa bagaimanapun juga kita tidak jujur ​​tentang sejauh mana pertukaran itu sering berakhir dengan kecepatan akhir dari skala. Dan kita adalah pembohong yang lebih besar di awal proyek!

Saya katakan bahwa Anda tidak bersalah di sini. Masalahnya adalah persepsi orang-orang tentang berapa lama kualitas perangkat lunak harus diambil. Kami membohongi diri sendiri karena meyakini bahwa kami mampu menciptakan perangkat lunak yang berkualitas dengan tipe garis waktu yang digunakan manajer kami atau bahkan kami memperkirakannya. Kami tidak membuat perangkat lunak berkualitas. Kami menulis perangkat lunak yang berfungsi tetapi terkadang dengan kilatan kualitas di sudut-sudut tertentu suatu aplikasi.

Jadi apa yang bisa kita lakukan tentang ini? Kami tidak bisa begitu saja meyakinkan bos kami bahwa kami perlu menggandakan atau melipatgandakan investasi dalam setiap proyek kami. Saya katakan memimpin dengan memberi contoh. Buat perangkat lunak yang benar-benar hebat sebagai proyek sampingan. Masukkan waktu Anda sendiri ke dalamnya dan jangan berkompromi. Sementara memperhatikan bagaimana Anda maju. Catat tugas yang tampaknya tidak terkait Anda harus memasukkan waktu yang tidak terduga dan lihat apakah Anda dapat membenarkannya. Bandingkan ini dengan semua proyek lain yang pernah Anda kerjakan. Jadilah sangat jujur dengan diri Anda sendiri dan semua aspek analisis ini. Dapatkah hal-hal ekstra yang Anda lakukan dengan perangkat lunak berkualitas Anda diabaikan dalam proyek "nyata" di tempat kerja? Tapi mungkin usahamu gagal. Apa alasannya? Apakah Anda bosan dan hanya bergegas untuk menyelesaikan fitur inti? Saya sendiri belum melakukan sesuatu seperti ini, itulah sebabnya saya mengakhiri pemikiran ini dengan sedikit keraguan - tetapi saya bermaksud untuk mencobanya. Saya akan membuat Anda diposting :).

Akhirnya, saya pikir sebagian besar (jika tidak semua) evaluasi kinerja bengkok dan sangat manipulatif. Anda tidak dapat membatasi kualitas dan kecepatan pada 100%. Atasan Anda harus membuat skor Anda terhadap standar yang ditetapkan oleh organisasi. Standar organisasi tentang pertukaran antara kualitas dan kecepatan. Mari kita bayangkan bahwa OrangeSoft Inc. mengharapkan kualitas 33% dan kecepatan 66%. Jadi, jika Anda menulis kode yang mungkin memiliki sepertiga dari tes unit itu harus tetapi membuatnya dengan kecepatan dan mengurangi waktu pengiriman Anda harus mencetak hampir 100% pada ulasan Anda! (Ini adalah analogi yang cukup kasar tetapi Anda mengerti maksudnya). Tetapi sebaliknya, yang terjadi adalah bahwa Bob menulis kode dengan sangat cepat tetapi yang terkenal buggy. Jadi pada ulasan kinerjanya dia akan skor 3/5 untuk kualitas dan 5/5 untuk kecepatan. Sebaliknya, Carol menulis kode jauh lebih lambat tetapi menghasilkan lebih sedikit bug. Dia skor 5/5 untuk kualitas tetapi 3/5 untuk kecepatan. Either way Bob dan Carol bisa merapat pada kenaikan gaji mereka. Apakah mungkin bagi karyawan mana pun untuk mendapatkan skor sempurna? Apakah ini adil?

6
Thiru

Teknik yang saya gunakan adalah prototyping evolusioner

Anda dapat google untuk info lebih lanjut - tetapi jika kebutuhan adalah untuk menghasilkan sesuatu dengan cepat, ini tentang satu-satunya cara untuk pergi. Plus, itu memiliki manfaat bahwa ketika pengguna mengatakan bahwa dia menyukainya, Anda sudah selesai (... dan dapat mulai melakukan dokumentasi).

5
slashmais

Apa hambatan waktu Anda? Saya menemukan bahwa berpikir adalah hambatan yang biasa saya alami, jadi meningkatkan kecepatan mengetik saya (sudah bagus) tidak akan menghasilkan apa-apa. Di sisi lain, jika mengetik tidak cepat dan alami untuk Anda, mungkin akan memperlambat Anda.

Apakah Anda mencoba melakukan lebih dari yang seharusnya? Biasanya, sebuah bisnis akan menginginkan banyak pekerjaan baik dari Anda daripada lebih sedikit tetapi lebih banyak pekerjaan yang dipoles, dan menambahkan fitur yang tidak akan digunakan menghabiskan waktu dan uang tanpa pengembalian bisnis.

Apakah Anda terlalu terburu-buru? Di bawah tekanan waktu, orang sering berhemat pada desain dan perencanaan di muka, berharap itu akan berhasil. Seringkali tidak.

Apakah Anda menangani waktu dengan benar? Pengembangan membutuhkan potongan waktu berpikir tanpa gangguan, atau Anda tidak akan efisien, dan karenanya lambat.

5
David Thornley

Baca buku bagus Neal Ford Programmer Produktif .

Ini penuh dengan banyak tips berguna.


Edit:

Dan, sebagaimana disebutkan di tempat lain, baca dokumen untuk alat Anda. Saya selalu belajar hal-hal baru untuk Vim dengan membaca Vim wiki. Demikian pula, hanya membaca halaman manual untuk bash atau zsh selalu memberikan trik baru untuk digunakan.

4
Rob Wells

Saya membaca sesuatu yang sudah lama tentang optimasi yang benar-benar macet dengan saya. Saya tidak ingat sumber atau kata-kata yang tepat, tetapi intinya adalah, "Satu-satunya cara untuk membuat program berjalan lebih cepat adalah dengan membuatnya lebih sedikit. Rencana lain hanyalah itu." Hal yang sama berlaku untuk manusia. Tentara juga memiliki pepatah, "Tergesa-gesa membuat sampah." Melakukan hal yang sama dengan yang kita lakukan sekarang, tetapi lebih cepat, hanya akan menciptakan masalah. Ada banyak rencana berbeda untuk menjadi lebih produktif di luar sana, dan saya tidak mengatakan mereka tidak efektif, tetapi mereka tidak akan disesuaikan dengan kebutuhan Anda. Lebih baik Anda melihat apa yang Anda lakukan dan menemukan hal-hal yang Anda lakukan yang tidak produktif, dan hilangkan itu. Rencana lain hanyalah versi sederhana dari itu.

4
Imagist

Inilah yang bekerja untuk saya:

  1. Hancurkan pekerjaan Anda menjadi tugas-tugas kecil yang (1) didefinisikan dalam ruang lingkup (2) singkat - mis. 2 jam.
  2. Mulailah hari dengan menuliskannya di atas kertas, secara berurutan. Gambarlah beberapa hal - hal-hal yang Anda harapkan untuk diselesaikan sebelum makan siang, hal-hal yang akan Anda lakukan pada akhir hari, dll.
  3. Kerjakan daftar Anda, silangkan item saat Anda pergi.
  4. Hal-hal kotak waktu - jika sesuatu mulai menyeret, beri batas waktu pada diri Anda sendiri untuk penelitian sebelum Anda meminta bantuan, atau selesaikan dengan cara yang lebih sederhana.
  5. Jika memungkinkan, susun pekerjaan Anda sehingga Anda berkomitmen di depan umum untuk jangka waktu ini - memasukkan perkiraan dalam pelacakan bug, dll.
  6. Jika Anda mendapati diri Anda menghabiskan waktu meneliti, membaca, dll., Lalu membalikkan urutan - misalnya, beri diri Anda hadiah 10 menit jika Anda berhasil menyelesaikan tugas 1 jam sesuai jadwal.

Saya telah melihat beberapa komentar bahwa Anda harus menghabiskan lebih sedikit waktu di Stack Overflow. Jika Anda menggunakannya dengan benar, Stack Overflow seharusnya membuat Anda lebih efisien, bukan kurang. Hindari diskusi dan fokus menggunakannya untuk menyelesaikan pekerjaan.

3
Jon Galloway

Jangan Ulangi Diri Sendiri

Gunakan kembali aset proyek lama.

Luangkan satu hari untuk mempelajari IDE Anda. Jika tidak menyediakan alat seperti snipets, kode pelengkapan otomatis ... pertimbangkan untuk mendapatkan yang baru.

Letakkan pintasan ke segala sesuatu di tempat-tempat utama sehingga Anda dapat mengakses sesuatu dengan lebih cepat.

Dapatkan layar kedua jika itu belum terjadi.

Jangan terlalu sering memeriksa email Anda.

Coba fokus hanya pada satu tugas pada satu waktu. Jika ini tidak memungkinkan, catat terus apa yang Anda lakukan dan jangan tersesat di antara 15 tugas yang tidak terkait.

Gunakan kertas. Ketika saya bekerja, saya selalu memiliki versi cetak dari tugas-tugas saya di mana saya dapat membuat catatan, mencoret dan sebagainya. Ini jauh lebih cepat daripada pergi ke layar yang berbeda untuk membaca sesuatu atau menulis sesuatu. Pada akhirnya saya butuh 10 menit untuk menyalin semuanya ke dalam sistem. Saya menyadari itu menyelamatkan saya beberapa waktu setiap hari.

3
marcgg
  1. Kembangkan diri Anda semakin banyak sebagai programmer, setiap hari ... Pelajari pola desain!
  2. Gunakan TDD, tetapi dengan cara yang tepat, bug yang dapat Anda miliki dalam kode Anda adalah hal yang paling memakan waktu.
  3. Gunakan ReSharper :)
3
Denis Biondic

Karena banyak dari jawaban lain berbicara tentang melakukan desain, saya hanya akan tetap pada aspek mekanis murni dari pengkodean lebih cepat. Sebagian besar ini mungkin jelas, tetapi saya tetap akan mengatakannya karena saya perhatikan bahwa banyak rekan kerja saya tidak melakukan beberapa hal ini.

Remap IDE pintasan keyboard Anda sehingga Anda bisa melakukan sebagian besar dengan tangan kiri. Ini membebaskan tangan-mouse Anda untuk menguraikan/refactoring kode yang cepat dan marah.

Pelajari cara menavigasi kursor Anda dan memilih teks menggunakan kombinasi CtrlShift, tombol panah, Home dan End.

Di bawah ini adalah pengaturan C++ saya (Visual Studio dengan Visual Assist X). Saya memiliki keyboard Norwegia, jadi harap tahan dengan saya:

Alt-Z: Ubah antara .h dan .cpp

Ctrl-Shift- <: Konteks sensitif melompat melalui referensi. (<Bagi saya adalah kunci kiri Z, kalian orang Inggris tidak memiliki salah satu dari itu. Peta ke Ctrl-Shift-Z kalau begitu.)

Alt- | : Menerapkan metode. Dengan menulis header terlebih dahulu dan hanya menekan Alt- | sepanjang waktu Anda dapat membuat garis besar seluruh kelas dalam beberapa detik. (bagi saya adalah kunci di bawah jalan keluar.) Ini terutama benar jika Anda menempatkan file cpp dan header di samping satu sama lain dalam editor teks sehingga header tidak dapat dikaburkan setiap kali Anda melakukan tindakan.

Alt-R: Mengganti nama simbol di bawah caret saya.

Alt-D: Menambahkan templat dokumentasi untuk fungsi yang dipilih.

Ini, selain penyempurnaan kode cepat kilat, memungkinkan pembuatan ulang tangan kiri.

3
Nailer

Cuplikan kode, pengalaman, dan antusiasme yang tak pernah berhenti. Selalu membaca hal-hal: blog programmer, buku, literatur, kode buruk orang lain. Anda akan mendapatkan lebih cepat jika Anda mendapatkan pandangan yang lebih luas tentang barang-barang. Jika Anda bisa membayangkan semua jenis proses latar belakang yang rumit yang terlibat, dan Anda benar-benar tahu seluruh kompleksitas sistem target.

The Buku Pegangan Programmer Pragmatis agak mengagumkan: ini tentang praktik terbaik dan perangkap utama dari berbagai aspek pengembangan perangkat lunak. Karet merunduk dan hal-hal terdengar terang-terangan kutu buku dan bodoh. Namun sifat dari sebagian besar masalah pemrograman adalah kita cenderung berpikir terlalu rumit. Saya penggemar solusi sederhana dan mudah: tidak ada trik hebat, tidak ada retasan super elegan: hanya menggunakan solusi paling sederhana.

Jika tim Anda bagus, Anda dapat mencoba bekerja secara kolaboratif: Bespin dan beberapa kerangka kerja lainnya saat ini memungkinkan pengeditan satu file bersama. Itu luar biasa jika Anda benar-benar menyukainya dan melihat rekan kerja Anda melakukan keajaiban;).

3
wishi

Coba periksa email Anda dengan interval yang lebih lama dan berhenti menggunakan alat sosial online seperti Twitter, facebook, dll.

Gunakan ini wallpaper .

Cobalah bekerja dengan tampilan depan terbuka. Saya biasanya menggunakan ruang konferensi ketika gratis, itu membantu saya fokus!

Cobalah bekerja dengan programmer lain di sekitar Anda.

3
Adnan Memon

Caranya bukan menulis kode lebih cepat, tetapi menulis kode kerja lebih cepat.

Semakin cepat bug Anda ditemukan, semakin sedikit upaya untuk memperbaikinya - ini adalah hal utama yang memengaruhi kinerja programmer.

Ini bukan tentang seberapa cepat Anda mengetik, atau seberapa cepat kompiler Anda, ini tentang kecepatan di mana Anda dapat mengidentifikasi bug dan memperbaikinya saat Anda pergi.

Oleh karena itu, saya menyarankan pemrograman pasangan sebagai cara untuk menjadi lebih cepat - itu benar-benar menghindari bug. Itu dan pengembangan berbasis tes. Memiliki dua pasang mata membuatnya lebih dari dua kali lebih sulit bagi bug untuk lolos (saya pikir pula).

Kiat lainnya adalah

  • Cobalah untuk mengurangi waktu perputaran kode-tes Anda ke minimum - ini jelas tergantung pada platform Anda dan alat. Jika Anda bekerja pada sistem tertanam konyol dengan alat lumpuh, waktu penyelesaian bisa sangat signifikan (misalnya jika Anda perlu membangun kembali gambar sistem dan net-boot perangkat), VM atau simulator dapat membantu di sini.
  • Jika tidak memasangkan pemrograman, sesekali tanyakan ulasan kode informal kepada orang lain, tetapi hanya pada saat logis dalam alur Anda (dan mudah-mudahan mereka). Lakukan ini sebagai tambahan untuk proses peninjauan kode formal yang pasti Anda miliki.
  • Tetap sederhana - jangan over engineer. Anda tidak akan membutuhkannya.
3
MarkR

Tulis alat produktivitas Anda sendiri. Pada awalnya mereka mungkin membutuhkan waktu untuk menulis, tetapi imbalannya bisa besar dari waktu ke waktu.

Beberapa alat yang saya tulis yang saya gunakan sepanjang waktu:

  • Pemformat SQL.
  • Generator SQL otomatis: cukup pilih tabel.
  • Prioritiser tugas sederhana, jadi saya bisa melihat semua tugas saya sekaligus.
  • Pengingat tugas yang mengganggu saya secara berkala.
  • Aplikasi yang mengambil teks terbatas dan memungkinkan Anda untuk memperlakukannya seperti spreadsheet dan teks suka.
  • Pemformat halaman PHP/Javascript/HTML. Berkah dari Tuhan ketika bekerja dengan kode orang lain.

Saya telah menulis banyak alat kecil lain di waktu saya yang telah jatuh di pinggir jalan, tetapi masih sepadan dengan usaha.

3
Jonathan Swift
  1. Saya benar-benar menikmati mendengarkan musik ketika saya memprogram karena saya merasa seperti itu menenangkan saya dan saya bisa fokus.

  2. Kursi yang nyaman. Saya tidak pernah menggunakan lab komputer sekolah saya untuk memprogram karena kursi kantor sangat tidak nyaman.

  3. Makan sesuatu sebelumnya karena tidak ada yang membunuh motivasi saya seperti mengomel karena lapar.

3
Matt Phillips

Praktek. Itu, dan dapatkan alat produktivitas yang memungkinkan Anda lebih cepat.

Misalnya (Anda tidak menyebut platform tempat Anda bekerja), di lingkungan .NET, ada Resharper.

2
Randolph West

Negosiasi ulang estimasi dan rentang waktu. Pastikan Anda adalah orang yang mengatakan berapa lama sesuatu akan terjadi, dan jangan menyerah pada saran "well, kita perlu dilakukan lebih cepat" atau "bagaimana dengan target".

Baca artikel Joel Spolsky tentang taksiran, yang pada dasarnya menganjurkan pemecahan pekerjaan menjadi potongan-potongan kecil, dan perkirakan masing-masing. Jika salah satu dari mereka dihitung dalam beberapa hari, pilah lebih lanjut hingga Anda memperkirakan semuanya dalam hitungan jam.

2
harriyott

Anda dan bos/evaluator Anda perlu menentukan berapa banyak waktu yang Anda miliki untuk memprogram. Keluarkan rapat, email, dokumentasi, pengujian, interupsi lainnya dari saat Anda diharapkan untuk bekerja dan lihat apa yang tersisa.

Cobalah untuk memonitor waktu Anda untuk mendapatkan patokan berapa lama tugas-tugas tertentu. Akan ada waktu yang produktif (bagi saya di awal hari atau rentang waktu yang saya dapatkan di tempat kerja tanpa interupsi) dan waktu yang tidak produktif. Temukan rata-rata.

Anda dapat menentukan bahwa tugas yang diberikan membutuhkan waktu 8 jam untuk diprogram, tetapi saya ragu Anda akan menyelesaikannya dalam satu hari.

Saya juga akan mencoba membandingkan diri Anda dengan orang lain. Budaya perusahaan mungkin menghabiskan banyak waktu.

2
JeffO

Yah, saya pikir saya tidak lambat, tetapi pekerjaan yang saya berikan cenderung untuk mengisi waktu yang tersedia.

Terlepas dari itu, saya seringkali mendengar "Wah, Anda melakukan itu dengan cepat", tetapi ini bukan dari menjadi seorang pembuat kode yang cepat, melainkan dari pengkodean yang lebih sedikit.

Saya pikir cara utama untuk mengurangi kode adalah berpikir seperti DSL. Jika Anda tidak bisa mendapatkan kode yang dihasilkan oleh preprocessor, maka tulis pembuat kode. Tidak harus mewah. Tujuannya adalah, jika Anda diberi persyaratan tunggal yang berdiri sendiri, untuk meminimalkan jumlah sumber perbedaan kode yang diperlukan untuk mengimplementasikan persyaratan itu. Idealnya, angka itu adalah 1. Jika Anda bisa menurunkannya sekitar 3-6 rata-rata, itu cukup bagus. (Bukan hanya karena Anda menulis lebih sedikit. Semakin kecil angka ini, semakin kecil pula jumlah bug yang Anda masukkan, dan itu sungguh-sungguh menghemat waktu.)

Untuk melakukan ini, saya sarankan melakukan penyetelan kinerja , karena dengan begitu Anda akan mengetahui praktik pengkodean apa yang mengarah pada perlambatan terbesar, dan mereka juga menyebabkan kode membengkak. Secara khusus, struktur data yang berlebihan dan pemrograman gaya acara/notifikasi. Hal-hal itu sendiri berkontribusi besar-besaran terhadap volume kode.

Banyak kode volume hari ini adalah karena antarmuka pengguna, terutama jika secara dinamis fleksibel. Saya menemukan cara untuk melakukan bagian itu, yang disebut Dialog Dinamis , yang memiliki kurva belajar yang sulit tetapi menyusut kode UI dengan kira-kira urutan besarnya.

Anda harus menemukan cara Anda sendiri dalam hal ini, saya rasa, tapi semoga beruntung.

2
Mike Dunlavey

Jaga kehidupan pribadi Anda teratur. Tidur nyenyak, makan sehat, dan minum vitamin - terutama jika Anda kekurangan zat besi. Tinggal jauh dari "minuman" - jika Anda tahu apa yang saya maksud. Dan ingat, "Anggur dan Wanita bisa menyesatkan pria bijak."

Selain itu, buat templat kode Anda dan "pembuat kode" yang berfungsi menggunakan pola ekspresi reguler. JIKA Anda menemukan diri Anda menyalin dan menempel, lalu mencari dan mengganti kelas yang serupa, otomatiskan proses ini. Saya melakukan ini untuk proyek PHP, di mana saya dapat membuat aplikasi CRUD, lengkap dengan semua komponen MVC dasar, berdasarkan dari tabel data saya - model data semua terlihat sama kecuali untuk tabel data yang mereka wakili, jadi ini adalah setup dalam template dan digunakan untuk menghasilkan kode awal saya. Menghemat berjam-jam mengetik.

Terakhir, beri tahu semua orang yang terlibat dengan proyek bahwa kode akan memakan waktu 1/4 hingga 1/2 kali lebih lama dari yang Anda pikirkan. Negosiasikan lebih banyak ruang bernapas untuk diri sendiri, sejak dini. "Terlambat" adalah istilah yang relatif. Ketika perubahan terjadi dalam proyek, aliran tengah, beri tahu semua orang di muka bahwa 8 jam kerja telah ditambahkan. Sistem pelacakan, seperti yang ditawarkan di "FogBugz" mungkin bisa membantu Anda dan manajer untuk mengantisipasi berapa lama waktu yang dibutuhkan untuk menyelesaikan sesuatu, berdasarkan pengalaman sebelumnya. Saya mencoba mengambil kebijaksanaan, "Ini belum terlambat - saya menggunakan jumlah waktu yang tepat untuk menyelesaikan fungsi ini - hanya butuh waktu lebih lama dari yang kami harapkan."

Pemrogram lain mungkin berkata, "Yah, saya bisa melakukannya lebih cepat ..." Mungkin, mungkin tidak, itu bukan poin yang layak diperdebatkan atau dipukuli sendiri - selalu akan ada orang "pintar" yang mencoba menekan tombol itu. Dia akan memperlambat Anda jika Anda memikirkannya! Itu selalu situasi yang buruk ketika itu bos Anda. Pada saat itu, saya mempertimbangkan untuk mencari pekerjaan lain, karena bos semacam itu adalah JERK yang sombong, dalam buku saya.

2
JasonMichael

T: Apa yang Anda lakukan untuk menyelesaikan lebih banyak dalam periode waktu yang lebih singkat?

A: Setiap hari datang ke kantor dan menulis apa yang ingin Anda selesaikan di catatan tempel (catatan tempel) Outlook. Mulailah mengerjakan urutan item-item itu. Percayalah pada akhir hari Anda akan merasa telah melakukan apa yang Anda rencanakan dan itu adalah perasaan yang hebat.

2
Cshah

Program pemasangan - ini memiliki segala macam manfaat:

  • memaksa Anda untuk mengartikulasikan/mengklarifikasi pemikiran Anda
  • memberi Anda wawasan tentang bagaimana orang lain bekerja, banyak ide yang dapat Anda adopsi/coba
  • pelajari teknologi baru secara langsung dari orang lain yang mengenalnya
  • ambil sedikit tips produktivitas dari orang lain. Anda selalu melihat seseorang menggunakan perintah menu yang tidak Anda mengerti sebelumnya, atau perintah Unix yang berguna.
2
ndp

Tulis kode lebih sedikit.

Usir Tidak Diciptakan-Di Sini dan manfaatkan perpustakaan/kerangka kerja/toolkit yang ada untuk menyediakan fungsionalitas umum (dan umumnya tidak terdefinisi) sehingga Anda hanya perlu menulis apa yang baru. Untuk bagian-bagian yang perlu Anda tulis sendiri, bangunlah dengan mengingatnya kembali sehingga Anda tidak perlu menulisnya lagi untuk proyek berikutnya.

Bahkan jika Anda tidak menambah jumlah baris kode kerja yang Anda hasilkan per hari, Anda masih bisa menyelesaikan lebih banyak dalam waktu lebih sedikit dengan membuat setiap baris berbuat lebih banyak.

2
Dave Sherohman

Satu-satunya hal jelas yang saya temukan bahwa bekerja adalah bebas dari gangguan. Yang, di beberapa lingkungan, tidak mungkin. Tetapi bisa fokus pada tugas tertentu dan HANYA pada tugas itu kemungkinan akan melebihi hal lain. Switch konteks itu adalah sink waktu yang sangat besar.

2
Joe

Juggling saat istirahat

Juggling

2
Cornelius

Minum Yerba Mate bukannya Kopi

Yerba Mate

2
Cornelius

Itu selalu merupakan satu-satunya keputusan yang sama, pengembangan cepat vs kualitas, keterbacaan, ekstensibilitas. Seret dan lepas kontrol dan file di belakang kode tak terbatas (cepat dan kotor) atau modularitas, pola, dan praktik (investasi jangka panjang)?

Menurut pendapat jujur ​​saya, semua orang harus berinvestasi dalam cara pengkodean jangka panjang. Seiring berjalannya waktu, perkembangan yang cepat akan menjadi kualitas yang hebat juga.

Namun jika saya tidak memahami pertanyaan Anda, dan Anda mencari jawaban dalam hal aspek praktis dari pengembangan cepat, seperti perkakas, pembuat kode dan hal-hal lain, pendapat saya adalah mulai menggunakan Resharper dan belajar sebanyak mungkin tentang = Anda IDE :)

1
Aggelos Biboudis

KERANGKA KERJA !! Jangan ganggu diri Anda dengan hardcoding!

1
Koosha

Pertama-tama, Anda tidak boleh merancang sistem berdasarkan beberapa pertemuan dengan pengguna akhir. Bahkan Anda tidak boleh terlibat dengan fase persyaratan proyek, itu untuk analis bisnis dan pengguna akhir untuk berolahraga.

Fase kedua adalah persyaratan teknis Anda, di sinilah Anda akan mulai bekerja dengan analis bisnis untuk menghasilkan solusi untuk spesifikasi yang diminta.

Sekarang adalah bagian yang penting. Pastikan Anda memahami persyaratan pengguna akhir dan persyaratan fungsional, tidak ada gunanya Anda memulai sesuatu hanya untuk menemukan itu tidak memenuhi harapan pengguna. Bicaralah jika Anda tidak mengerti sesuatu.

Sekarang, saatnya untuk menekan editor. Tetapi pendekatan saya adalah untuk tidak pernah menulis kode nyata, selalu menulis setumpuk komentar mutlak terlebih dahulu, lakukan dalam kode semu jika itu mudah bagi Anda, apa pun itu tidak masalah, asalkan jelas dan mudah dibaca/dimengerti.

Setelah Anda selesai memberikan komentar, Anda dapat mulai a) menulis kasus pengujian Anda b) menulis implementasinya.

Bergantung pada lingkungan Anda, Anda sebaiknya memulai dengan (a) tetapi sayangnya sebagian besar dimulai dengan (b) dan kemudian mencoba memaksakan tes untuk memenuhi implementasi. Terus terang berbicara, jika Anda adalah bagian dari sebuah perusahaan besar akan ada departemen yang menulis kasus uji untuk Anda bahkan sebelum Anda mulai melakukan apa pun.

1
Brett Ryan

Semua orang mengatakan 'memeriksa email' tetapi pertimbangkan waktu yang Anda habiskan untuk menulis email yang sangat teknis. Saya dapat dengan mudah menghabiskan satu jam menulis satu email. Untuk memperbaikinya, saya bisa 1) tidak menulis banyak, atau 2) menunda hal-hal teknis (dan hal-hal yang mengharuskan saya membaca kode untuk menjawab) sampai benar-benar diperlukan.

1
Shin

Ketika benar-benar menulis kode, CodeRush membantu sedikit terutama ketika Anda sudah menguasai pintasannya. Plus gratis: D

1
GaiusSensei

Saya menghabiskan sedikit waktu setiap minggu hanya mencari cara-cara kreatif baru untuk melakukan hal-hal yang mungkin atau mungkin tidak terkait langsung dengan apa yang sedang saya kerjakan. Seringkali saya akan menemukan trik atau alat baru yang tidak pernah saya sadari yang mempercepat alur kerja saya.

1
fscmj

Menjadi akrab dengan IDE Anda.

Jika IDE adalah Visual Studio, maka saya sangat merekomendasikan buku Sara Ford .

1
Jim G.
  • pelajari pola desain. Mereka membantu Anda memahami masalah, menjadikan Anda seorang programmer yang lebih baik -> akan membuat Anda lebih cepat memprogram karena Anda sudah memiliki solusi untuk beberapa masalah yang disiapkan dalam pikiran
  • ekstrak bagian yang berulang dalam program Anda. Jika ada beberapa logika yang berulang di seluruh beberapa program yang Anda tulis, pertimbangkan untuk menggeneralisasi mereka dan mengekstraknya ke beberapa perpustakaan kelas yang kemudian dapat Anda gunakan kembali pada aplikasi baru yang Anda tulis. Standarisasi hal: menginvestasikan waktu untuk mencari tahu bagaimana tugas berulang tertentu dilakukan dengan sangat baik. Dokumentasikan langkah-langkah untuk mencapai. Lain kali Anda akan tahu persis bagaimana menyelesaikan/menerapkannya.
  • Prinsip CIUMAN
  • Pembuatan kode akan bermanfaat (setelah alat yang berguna tersedia). Generator mulai mendapatkan popularitas, baru-baru ini.

Catatan: Hanya membuat semuanya bekerja lebih buruk !! Seperti disebutkan beberapa orang hanya untuk meretas sesuatu sampai mereka bekerja akan membuat Anda lebih cepat hanya untuk saat ini. Namun bug akan datang yang entah bagaimana menghitung juga dalam hal seberapa cepat Anda memprogram. Jika saya harus menulis beberapa fungsionalitas dan saya berinvestasi dalam menulisnya dengan baik, memiliki desain yang bagus, mungkin telah teruji dengan baik (dengan unit test) dan mengatakan saya akan membutuhkan setengah hari. Tapi anggap itu saja dan fitur Anda berfungsi dan Anda tidak perlu menyentuhnya lagi. Programmer lain, yang hanya fokus pada pencapaian cepat dari tujuannya, akan membuat (mungkin) desain yang buruk, karena pengujian yang hilang ia tidak akan mempertimbangkan (mengetahui) batas, kasus luar biasa. Dia akan membutuhkan 2 jam (katakanlah). Bug akan masuk, ia harus menyentuh kode lagi, memperbaikinya, mungkin memperpanjangnya (jam akan diinvestasikan lagi). Kode akan sulit untuk dipertahankan dll ... resume: pada akhirnya dia akan menghabiskan banyak waktu dan frustrasi akan lebih tinggi.

1
Juri

Gunakan tata letak keyboard yang dioptimalkan secara ergonomis . Beberapa bahkan ditujukan untuk programmer, melalui karakter khusus yang sangat mudah diakses.

1
knittl

Bekerja dari rumah. Ketika saya memiliki tenggat waktu yang sulit dan saya harus fokus sepenuhnya pada suatu masalah, saya memberi tahu atasan saya bahwa saya bekerja dari rumah. Ini memungkinkan saya mengatur lingkungan saya secara optimal, mengurangi gangguan, dan membuat saya fokus seperti sinar laser pada masalah.

1
Pedro Estrada

Anda akan lebih cepat dengan pengalaman dan lebih banyak menghafal API.

Hari-hari saya mencari fragmen kode di web jauh lebih singkat sekarang karena saya sudah belajar membuat kode dengan lebih baik.

Oh, Anda mungkin juga ingin mencoba menggunakan konsep pemrograman fungsional dan lamda untuk mengurangi kode Anda :)

1
Vince

Bersemangat dengan apa yang Anda lakukan adalah cara terbaik untuk meningkatkan efisiensi. Pastikan itu menyenangkan!

1
Jakob

Saya pikir membuat sketsa ide Anda di atas kertas, ingat hal-hal itu, adalah cara yang bagus untuk menyempurnakan beberapa ide. Sebagai programmer, baik profesional atau penggemar, kami menghabiskan banyak waktu menatap layar, yang memiliki outlet lain untuk meletakkan ide-ide Anda adalah baik. Saya menemukan bahwa mencoret-coret, menggambar garis tergesa-gesa yang menghubungkan ide-ide, melingkari hal-hal, menggarisbawahi, dll. Semua menambah penekanan pada ide dan benar-benar dapat membantu Anda memilah ide jauh lebih cepat daripada mencoba menyusunnya langsung dari kelelawar atau di beberapa bentuk bantuan komputer.

Hal lain yang membantu adalah membuat prototipe bagian-bagian kecil. Mendengarkan podcast audio TED tadi malam di mana pembicara sedang membahas membangun struktur kecil dari tongkat spaghetti dan Marshmallow, tampaknya ini adalah studi yang cukup banyak digunakan untuk menguji kemampuan konstruksi sosial kelompok kecil ... Lagi pula, kelompok yang selalu melakukan lebih baik, selain arsitek yang memahami penguatan dan konstruksi bangunan adalah anak-anak karena mereka menggunakan aliran umpan balik yang konstan untuk mendapatkan hasil. Saya pikir Anda juga dapat membuang ini ke dalam ide pemrograman di mana Anda melihat bahwa melakukan hal-hal kecil dan mendapatkan hasil tidak hanya lebih produktif tetapi jauh lebih menyenangkan dan bermanfaat daripada membangun beberapa konstruksi raksasa dan kemudian menghabiskan waktu berhari-hari men-debug-nya .... itu sudah terbunuh beberapa ide "kesenangan" saya di masa lalu pasti.

1
dscher

Ketika saya di kantor dan saya perlu mempertahankan fokus saya, saya menutup klien email saya. Tidak ada yang menghancurkan efisiensi bagi saya lebih cepat daripada godaan konstan untuk "melihat sekilas" pada pesan apa pun yang baru saja tiba. Saya juga telah bermain-main dengan Teknik Pomodoro untuk mengelola gangguan dan mempertahankan fokus.

1
Tim Trout

Gunakan pembuat kode kapan pun memungkinkan. Kadang-kadang bahkan Microsoft Excel (atau OpenOffice Calc) ternyata menjadi alat pembuat kode yang kuat.

0
Canavar

Sederhananya, papan tulis -> memecah menjadi persyaratan yang dapat diuji menjadi tugas (saya telah menggunakan Yayasan Tim untuk melacak setiap tugas dan berapa lama harus dilakukan.)

Gunakan pengujian untuk memastikan bahwa Anda mendapatkan apa yang harus dilakukan, tidak lebih dan tidak kurang. (Jangan khawatir tentang kinerja.)

Beralih dari persyaratan ke persyaratan dan uji setelah masing-masing dilakukan. Setelah setiap tugas selesai, Anda harus memiliki perkiraan yang akurat tentang waktu yang tersisa.

Ketika semua persyaratan sudah selesai kembali dan "poles" itu.

Melakukan pekerjaan kaki pertama-tama memaksa seseorang untuk menyelesaikan semua persyaratan yang menghemat waktu dengan melakukan hal-hal yang benar saat pertama.

Jika dilakukan dengan benar, ini akan memungkinkan lebih banyak waktu untuk dihabiskan di Stack Overflow :)

Semoga berhasil

0
Brad8118

Ada banyak ide bagus di sini. Untuk membantu saya masuk ke 'zona' saya menggunakan timer yang diatur pada interval 27 menit. Saya menemukan begitu saya dalam mode kerja mudah untuk bekerja dengan baik di luar bel dan bekerja dengan aliran tidak menyakitkan. Sulit untuk sampai ke sana.

0
Daver

Satu hal yang saya perhatikan paling memengaruhi kecepatan saya adalah motivasi dan bersenang-senang. Ini mungkin terlihat Fuzzy, tetapi ketika saya termotivasi dan melakukan sesuatu yang menurut saya menyenangkan, saya bisa menjadi sangat efektif. Di sisi lain ketika saya tidak melakukannya, rasanya saya harus mendorong setiap baris kode keluar dari saya.

Temukan titik-titik manis Anda, apa yang benar-benar memotivasi Anda dan tugas seperti apa yang benar-benar Anda sukai? Dan dapatkah Anda memengaruhi perencanaan sehingga Anda bisa melakukan ini? Bagi saya saat itulah saya bisa menyelesaikan masalah dan masalah desain, dan ketika saya merasa bahwa saya memiliki bagian dari proyek.

Beberapa bulan yang lalu kami memiliki proyek kecil yang ditugaskan untuk dilakukan oleh tim kecil kami dan itu adalah tenggat waktu yang sangat penting dan sangat tidak realistis untuk itu. Namun kami semua sangat termotivasi dan sangat senang melakukannya dan menyelesaikannya tepat waktu, dengan pelanggan yang bahagia. Alasan untuk motivasi saya adalah bahwa kami sangat terlibat dalam proyek dan harus datang dengan ide-ide kreatif untuk itu. Saya juga harus mengerjakan bagian yang sangat saya sukai.

Namun baru-baru ini saya telah terlibat dalam sebuah proyek di mana saya pada dasarnya menjadi monyet kode, hanya melakukan tugas-tugas yang mematikan dan membuat frustrasi, atau hanya memiliki hal-hal memperbaiki cepat cara tercepat yang saya tahu akan kembali dan menggigit saya dengan keras kapan-kapan di masa depan yang dekat, dan itu sangat lambat.

Jadi apa sweet spot Anda?

0
Runeborg
  1. Ketahuilah apa yang ingin Anda lakukan dan minati itu
  2. Luangkan beberapa jam untuk meneliti kode tentang cara melakukannya
  3. Salin dan tempel kode untuk mencapai hasil akhir
  4. Bekerja dengan gui dasar untuk menyelesaikan pekerjaan, JANGAN MENGHABISKAN WAKTU UNTUK MEMBUATNYA CUKUP
  5. Tes dan debug
  6. Kerjakan gui yang cantik
0
Matt S.

"Ketepatan waktu" tidak sama dengan "cepat". Jika itu masalahnya, evaluasi Anda seharusnya mengatakan "lambat". Jadi sebelum Anda mengambil jalan yang Anda lamar, pastikan Anda tahu apa yang diharapkan dari Anda.

Itu bisa berarti apa saja; bahkan mungkin berarti Anda tidak masuk kantor sampai 20 menit setelah kolega Anda, atau Anda memiliki manajemen waktu yang buruk. Itu mungkin tidak ada hubungannya dengan 'kecepatan pemrograman' Anda.

Saya mungkin menghabiskan sebagian besar waktu merancang dan merencanakan; lebih mudah untuk merencanakan tugas dari analisis dan desain yang baik, dan Anda kemudian akan memberikan perkiraan yang lebih baik yang akan dipercaya. Selain itu dari desain yang baik, pengkodean menjadi jauh lebih sederhana dan proses yang lebih terarah. Itu juga memungkinkan untuk membagi tugas dan mendistribusikannya di antara pengembang lain.

0
Clifford

Saya sudah hampir tiga kali lipat kecepatan coding C saya dengan VIM .

0
Liran Orevi

CodeRush! Mendapatkan! Suka!

0
Bobby Ortiz

Pilih editor cepat, kompiler cepat, dan tulis perangkat lunak dengan waktu eksekusi cepat. Dengan cara ini Anda dapat membuat kesalahan sepuluh kali lebih banyak dari programmer normal dan masih menjadi lebih baik daripada yang lain. Itu mungkin salah satu alasan aplikasi google sangat populer. Pengembangan web dipenuhi dengan bug jahat, dan menulis lebih banyak perangkat lunak pada platform buggy sangat menyebalkan. Tetapi waktu respon antara mengedit kode dan melihat hasil sangat cepat sehingga masih lebih mudah untuk membuat tumpukan sampah itu bekerja daripada memperluas program c ++. :)

0
AareP

Habiskan lebih banyak waktu untuk menyatukan berbagai hal di pikiran Anda daripada di depan IDE. Ketika Anda memiliki rencana, Anda sudah menyelesaikan sebagian besar pekerjaan. Implementasi hanyalah 20% lainnya. Jika Anda buntu saat menulis kode karena masalah khusus platform, tetap pada rencana, dan terus menerapkan dan menguji sisanya. Pada akhirnya, atasi semua tempat yang Anda tinggalkan, selesaikan satu per satu - mungkin ada beberapa yang terkait, dan memecahkan beberapa mungkin cukup untuk mencari tahu sisanya. Saya biasanya menggunakan solusi untuk masalah seperti itu, menambahkan komentar "// UNTUK MENGUBAH" di tempat-tempat tertentu dalam kode, dan menulis ulang yang paling berdampak pada kualitas dan kinerja pada akhirnya, jika saya tidak punya waktu untuk menyelesaikan semua dari mereka dengan batas waktu.

0
luvieere

Bangun pustaka kode Anda sendiri

Setiap kali Anda membuat kode suatu fitur baru, cobalah untuk tetap generik, tetapi jangan terlalu generik. Dalam jangka pendek ini akan sedikit lebih lambat, tetapi dalam jangka panjang karena kode perpustakaan Anda semakin besar, setiap proyek baru akan selesai lebih cepat karena banyak aplikasi bisnis memiliki kebutuhan yang sama (tidak selalu) tetapi cukup dekat sehingga banyak kode dapat digunakan kembali.

0
Darknight

Lebih cepat bukan berarti lebih baik. Jika Anda berhasil menjadi pemrogram yang lebih cepat dan lebih baik. Itu semua bermuara pada keseimbangan. Berapa lama Anda bisa melakukan itu? Berpikir, kesabaran, dan perencanaan selalu membuahkan hasil. Terkadang "cepat" di dunia berkembang dapat membawa hasil terburuk.

0
Ryuken

Dekonstruksi. Pecahkan apa pun yang Anda bangun menjadi fitur yang lebih kecil yang dapat Anda implementasikan secara bertahap. Kemudian, setiap kali Anda memiliki bagian-bagian yang lebih kecil selesai dan Anda telah diuji untuk memastikan itu tidak merusak apa pun, sebarkan dan tunjukkan ke Powers That Be.

Menggunakan iterasi kecil akan sering membantu Anda menyelesaikan proyek yang lebih besar lebih cepat dan lebih baik, karena Anda mendapatkan umpan balik saat Anda pergi dan Anda tidak perlu mundur dan mengulang sebanyak mungkin. Tetapi bahkan jika tidak, Anda menunjukkan kemajuan yang konstan, yang memiliki manfaat psikologis yang kuat dan mengembalikan kepercayaan manajer atau klien Anda.

Pengembangan yang digerakkan oleh tes juga banyak membantu dengan pendekatan ini. Pada awalnya mungkin tampak seperti menulis tes pertama yang memperlambat segalanya - tetapi mendapatkan waktu itu kembali dalam bug Anda akan menghindari, dan tergantung pada bagaimana Anda menulisnya, tes itu sendiri bisa menjadi hasil yang dapat Anda tunjukkan kepada Powers That Be dan konfirmasi perilaku aplikasi bahkan sebelum Anda menulis semuanya.

0
SFEley

Jika Anda memprogram dalam bahasa C maka belajar bit hacks adalah suatu keharusan untuk menjadi programmer yang lebih cepat. Baca juga praktik pengkodean oleh peringkat teratas di Topcoder.com. Kode mereka sangat kecil dan efisien.

0
avd

Menjadi lebih cepat programmer dengan memperlambat ketika Anda mendesain dan coding.

  • Pikirkan tentang apa yang Anda lakukan.
  • Pertimbangkan implikasi desain Anda.
  • Lakukan dengan benar pertama kali (uji kode Anda sendiri dengan penuh semangat).

Mungkin merasa lebih lambat, tetapi throughput Anda akan lebih cepat daripada kode joki yang mengubah iterasi dalam 4 jam, dan kemudian membutuhkan 6 putaran QA sebelum mereka kode lewat.

0
mmc

Re: Cara memperkirakan dan berpegang teguh pada itu:

Saat memperkirakan, ingatlah hukum Hofstadter dan juga sindiran ini: "Semuanya membutuhkan waktu lebih lama daripada yang dilakukannya". Ambil tebakan yang masuk akal untuk berapa lama sesuatu harus dilakukan, kemudian gandakan atau lipat tiga kali sebelum keluar dari mulut Anda. Akan ada komplikasi, kemunduran, pengalih perhatian, hal-hal yang Anda lupakan, dll. Lebih baik berjanji dan memberikan lebih banyak daripada sebaliknya.

Tetap berpegang pada estimasi, lakukan yang terbaik untuk menyelesaikan pekerjaan Anda secara efisien. Ketika masalah muncul, komunikasikan keterlambatan lebih awal. Ini memberi setiap orang waktu untuk menyesuaikan harapan mereka. Jika penjelasan Anda masuk akal, Anda mungkin diberi lebih banyak waktu atau bantuan atau gangguan (seperti tetangga yang berisik) dikeluarkan dari jalur Anda.

0
steamer25

Praktek-praktek berikut ini terkenal tetapi sering diabaikan karena berbagai alasan, seringkali karena tenggat waktu yang ketat, sehingga mereka pantas disebutkan di sini (pada dasarnya, ini adalah mekanisme untuk menghabiskan waktu di muka untuk menghindari pengeluaran lebih banyak waktu kemudian):

  • Do development-driven development; itu akan membantu Anda menulis hanya jumlah kode yang benar-benar diperlukan dan, akan membantu Anda menghindari pengenalan bug saat menambahkan fitur atau refactoring

  • Tulis komentar, tetapi hanya jika kodenya cukup kompleks untuk menjaminnya

  • Refactor dan simplify kode Anda sering

  • Gunakan perangkat lunak kontrol sumber yang layak (seperti Git atau Mercurial) -jika majikan Anda menggunakan sesuatu yang lain, gunakan milik Anda sendiri-

  • Komit kode sering berubah: untuk setiap fitur atau refactoring, lakukan komit, karena mengembalikan akan lebih murah untuk Anda jika terjadi kesalahan

  • Jangan takut untuk cabang; Git terutama memiliki mekanisme percabangan yang sangat cepat dan "aman" (misalnya, dibandingkan dengan Subversion)

0
Nick Toumpelis

Saya pribadi berpikir semua tentang kegunaan ulang kode. Kecuali jika Anda melakukan hal-hal yang sepenuhnya kustom setiap kali, Anda harus memiliki perpustakaan fungsi penggunaan umum yang dapat Anda lihat. Saya memiliki utils.php di mana saya memiliki seluruh "tempat barang rongsokan" dari fungsi yang saya gunakan pada proyek sebelumnya. Menghemat BANYAK waktu ketika saya harus melakukan sesuatu yang serupa.

Semoga beruntung dan jangan berkecil hati. Saya pikir kita semua kadang merasa lambat atau "bodoh". Saya tahu saya punya!

0
Code Monkey

Gunakan alat analisis statis.

Mereka membantu Anda menemukan lebih banyak bug pada waktu kompilasi yang seharusnya Anda lacak saat runtime.

Terutama ketika membangun aplikasi multithreaded mereka adalah bantuan NYATA.

0
Oliver Weiler

Ini semua adalah saran yang bagus. Saya akan menambahkan teknik produktivitas saya sendiri yaitu untuk mengetahui bagaimana menyelesaikan sesuatu tidak hanya dengan kode minimal tetapi dengan kode redundansi minimal.

Secara umum ini berarti semakin sedikit struktur data semakin baik.

Untuk membuat kode dengan redundansi minimal diperlukan kreativitas dan kemauan untuk melakukan sesuatu dengan cara yang mungkin memaksakan kurva belajar. Itulah harga produktivitas. Berikut satu contoh.

0
Mike Dunlavey