Mengatasi penyelesaian masalah yang lambat karena peningkatan pengetahuan tentang apa yang mungkin salah [ditutup]

Ini telah mengganggu saya selama beberapa waktu, dan saya sangat menghargai masukan dari para profesional lain.

Latar belakang pendek: Saya mulai pemrograman ketika orang tua saya membelikan saya komputer pertama saya pada tahun 1988 (pada usia 14, saya 39 sekarang). Saya mengikuti beberapa jalur karier lain sebelum akhirnya menjadi programmer profesional pada tahun 1997. Terlambat berkembang, mungkin, tapi memang begitu. Saya masih senang dengan pilihan saya, saya suka pemrograman, dan saya menganggap diri saya baik pada apa yang saya lakukan.

Akhir-akhir ini, saya telah memperhatikan bahwa semakin banyak pengalaman yang saya dapatkan, semakin lama saya menyelesaikan proyek, atau tugas-tugas tertentu dalam suatu proyek. Aku belum pikun. Hanya saja saya telah melihat begitu banyak cara yang berbeda di mana hal-hal bisa salah. Dan potensi jebakan dan gotcha yang saya tahu dan ingat semakin lama semakin banyak.

Contoh sepele: dulu hanya "oke, tulis file di sini". Sekarang saya khawatir tentang izin, penguncian, konkurensi, operasi atom, tipuan / kerangka kerja, sistem file yang berbeda, jumlah file dalam direktori, nama file temp yang dapat diprediksi, kualitas keacakan dalam PRNG saya, kekurangan daya di tengah segala operasi, API yang dapat dimengerti untuk apa yang saya lakukan, dokumentasi yang tepat, dll, dll.

Singkatnya, masalahnya sudah lama berpindah dari "bagaimana saya melakukan ini" ke "apa cara terbaik / teraman untuk melakukannya".

Hasilnya adalah bahwa saya membutuhkan waktu lebih lama untuk menyelesaikan suatu proyek daripada seorang pemula. Versi saya mungkin sangat solid, dan tidak bisa ditembus seperti yang saya tahu bagaimana membuatnya, tetapi itu membutuhkan waktu lebih lama.

Contoh "buat file" di atas adalah contohnya saja. Tugas nyata jelas lebih kompleks, tetapi kurang cocok untuk pertanyaan umum seperti ini. Saya harap Anda mengerti ke mana saya akan pergi dengan ini. Saya tidak punya masalah dengan algoritma yang efisien, saya suka matematika, saya menikmati mata pelajaran yang kompleks, saya tidak memiliki kesulitan dengan konsentrasi. Saya pikir saya punya masalah dengan pengalaman, dan akibatnya dengan rasa takut akan kesalahan (intrinsik atau ekstrinsik).

Saya menghabiskan hampir dua jam sehari membaca perkembangan baru, teknik baru, bahasa, platform, kerentanan keamanan, dan sebagainya. Masalahnya adalah semakin banyak pengetahuan yang saya peroleh, semakin lambat saya menyelesaikan proyek.

Bagaimana Anda menangani ini?

Anda tidak lambat dalam menyelesaikan proyek. Sebelumnya, Anda mengira proyek pemula Anda telah selesai padahal sebenarnya tidak. Anda harus menjual kualitas ini kepada klien.

"Perusahaan ini mungkin menyelesaikannya lebih cepat dan lebih murah, tetapi apakah ini benar-benar dilakukan? Atau apakah kamu akan berburu serangga selama bertahun-tahun?"

Di luar itu, Anda perlu tahu dan menerima ungkapan lama: "Sempurna adalah musuh kebaikan."

Sepertinya sudah waktunya bagi Anda untuk bergabung dengan sisi gelap: manajemen.

Saya tidak menyarankan Anda berhenti pemrograman dan menjadi manajer. Tapi sepertinya semua pengalaman yang Anda kutip sampai sekarang bersifat teknis. Dalam operasi sederhana penulisan file, Anda dapat memikirkan 10 aspek berbeda yang tidak akan pernah dipertimbangkan oleh pengembang yang kurang matang. Belum tentu hal yang buruk, tapi ...

Sisi gelap adalah tentang nilai sekarang. Ini tentang membuat investasi minimal untuk keuntungan maksimum (analisis biaya-manfaat). Dalam bisnis semuanya bermuara pada seberapa besar biayanya, probabilitas kesuksesan, probabilitas kegagalan, probabilitas kegagalan spektakuler, dan potensi keuntungan. Lakukan perhitungan; bertindak sesuai itu.

Ini berfungsi dengan baik ketika Anda seorang pengembang: membuat file sementara, mengabaikan izin dan tabrakan nama - 5 menit. Keuntungan bersih, anggota tim lainnya dapat mulai mengerjakan kode apa pun tergantung pada keberadaan file itu. Apakah ini solusi yang sempurna? Benar-benar tidak. Apakah Anda mendapatkan 99%, 95%, mungkin 90%? Ya, mungkin akan begitu.

Pertanyaan lain untuk ditanyakan: Bagaimana perasaan Anda tentang utang teknis? Beberapa orang berpikir itu harus dihilangkan. Saya pikir orang-orang itu salah. Sama seperti dalam bisnis, hutang teknis memungkinkan Anda untuk meminjam "uang" atau "waktu" untuk memberikan sesuatu lebih cepat. Apa yang lebih baik: Solusi sempurna dalam 2 tahun atau peretasan lengkap yang dapat digunakan dan dibeli oleh pelanggan dalam 4 bulan? Setiap situasi berbeda, tetapi dalam beberapa situasi jika Anda menunggu 2 tahun, pelanggan Anda sudah akan mendaftar dengan pesaing Anda.

Kuncinya adalah mengelola utang teknis dengan cara yang sama dengan bisnis yang dikelola dengan baik mengelola utang keuangan. Jika Anda tidak mengambil cukup, Anda tidak mendapatkan pengembalian investasi optimal. Jika Anda mengambil terlalu banyak, bunga itu akan membunuh Anda.

Jadi saran saya: Mulailah mengevaluasi pekerjaan Anda berdasarkan apakah Anda memaksimalkan nilai Anda alih-alih memaksimalkan ketelitian Anda. Dan jika Anda berlatih ini, Anda akan mengembangkan intuisi yang sama yang sudah Anda kembangkan di bidang teknis Anda.

Sebagai catatan, saya baru-baru ini mulai melakukan teknik pomodoro dan itu telah banyak membantu. Alih-alih pergi bersinggungan dengan garis singgung, fokuslah dalam interval waktu kecil dan kemudian alokasikan pomodoros untuk pekerjaan / penelitian di masa depan. Sungguh menakjubkan berapa kali saya membuat catatan untuk meneliti suatu topik tetapi satu jam kemudian ketika saatnya tiba, saya berpikir dalam hati, "setidaknya ada 3 hal lain yang bisa saya lakukan dengan waktu saya hari ini yang semuanya lebih berharga."

Saya memiliki (kemungkinan) masalah yang sama bertahun-tahun yang lalu, itu berlangsung selama beberapa tahun dan saya mengatasinya. Jadi mungkin menarik bagi Anda untuk mengetahui bagaimana saya mencapainya, bahkan jika saya tidak yakin cara saya juga berlaku untuk Anda.

Anda juga harus melihat di sini: Tujuh Tahapan Keahlian dalam Rekayasa Perangkat Lunak. Ini menunjukkan bahwa produktivitas sebagian besar merupakan efek samping dari tingkat keterampilan. Mungkin Anda masih berada di beberapa titik antara tahap 3 dan tahap 4 pada teknologi yang saat ini Anda gunakan (kecakapan keterampilan tergantung pada teknologi, Anda dapat menguasai beberapa teknologi sambil masih mempelajari yang lain).

Sekarang saya mulai dengan kesaksian biografi.

Sedikit konteks. Saya 47. Saya mulai pemrograman pada 12 di 80-an. Sementara di sekolah menengah saya juga bekerja sebagai programmer game profesional paruh waktu. Pada dasarnya itu tidak membuat saya banyak uang, hanya cukup untuk membeli perangkat keras, tetapi saya menikmatinya dan belajar banyak. Pada usia 18 tahun saya memulai pembelajaran formal Ilmu Komputer.

Akibatnya ketika saya berusia 20 tahun, setiap kali memulai tugas pemrograman saya tahu banyak cara untuk menyelesaikan masalah yang diberikan dan sangat sadar akan banyak parameter dan perangkap di tangan, dan kelemahan dan batasan metode apa pun.

Di beberapa titik (katakanlah sekitar 26 tahun) menjadi sangat sulit bagi saya untuk menulis program apa pun. Ada begitu banyak kemungkinan terbuka sehingga saya tidak dapat lagi memilih di antara mereka. Selama beberapa tahun (membuatnya 6) saya bahkan berhenti pemrograman dan menjadi penulis berita teknis.

Namun saya tidak pernah berhenti mencoba memprogram. Dan pada suatu saat itu kembali. Kuncinya bagi saya adalah Pemrograman ekstrem, lebih khusus prinsip Kesederhanaan: "Tulis Hal Sederhana yang Mungkin Bisa Berfungsi".

Pada dasarnya saya memaksakan diri saya untuk tidak peduli dengan efisiensi kode (yang merupakan hambatan utama saya, hindari desain yang tidak efisien), tetapi lakukan cara termudah. Saya juga memaksa saya untuk tidak terlalu memperhatikan kesalahan, dan menunda penanganan kesalahan di lain waktu, setelah menulis tes yang meningkatkan kesalahan (benar-benar TDD).

Itu adalah sesuatu yang saya pelajari ketika saya sedang menulis. Ketika saya tidak tahu apa yang harus ditulis, atau saya tahu apa yang saya tulis itu buruk . Lanjutkan saja. Sebenarnya menulis hal-hal buruk. Saya akhirnya akan memperbaikinya nanti. Atau jika benar-benar seburuk itu menghapus dan menulis ulang, tetapi lebih cepat untuk menulis hal-hal dua kali yang menulis sesuatu yang sempurna pertama kali.

Benar-benar sangat mungkin bahwa kode yang Anda yakini baik pada penulisan pertama akan membutuhkan perbaikan sebanyak yang benar-benar buruk.

Jika Anda mengikuti jalur Kesederhanaan Anda juga mendapatkan bonus tambahan. Anda dengan mudah menerima untuk menghapus / mengubah desain / pengkodean awal. Anda mendapatkan pikiran yang lebih fleksibel.

Saya juga punya kebiasaan untuk memberikan komentar sementara dalam kode, menjelaskan apa yang tidak saya lakukan sekarang dan dimaksudkan untuk dilakukan nanti ketika kode akan berfungsi dalam kasus penggunaan normal.

Saya juga menghadiri XP Dojo sebuah kode praktek kode dengan programmer lain untuk menginternalisasi praktik XP. Itu membantu. Itu membuat metode formal di atas naluriah. Pemrograman pasangan juga membantu. Bekerja dengan programmer muda memberikan momentum, tetapi dengan pengalaman Anda juga melihat apa yang tidak mereka lakukan. Sebagai contoh dalam kasus saya, saya sering melihat mereka terlibat dalam desain yang terlalu rumit dan saya tahu mimpi buruk desain yang dapat menyebabkan. Pergi ke sana. Lakukan itu. Punya masalah.

Poin terpenting bagi saya adalah menjaga alur. Menjadi cepat benar-benar berhasil menjaga arus.

Sekarang saya kembali sebagai programmer profesional dan saya percaya saya lebih baik dan lebih cepat dengan pemahaman yang lebih dalam tentang apa yang saya lakukan. Berlatih TDD Saya mungkin masih sedikit lebih lambat daripada ketika saya masih muda (dan tidak menguji apa-apa), tapi saya juga tidak takut refactoring dan tentu saja menghabiskan lebih sedikit waktu debugging (hampir tidak ada waktu sama sekali, membuatnya kurang dari 10% dari waktu ).

Singkatnya: Saya mengatasi kode kunci saya menggunakan metode agile (XP), pergi untuk kesederhanaan kemudian refactoring, dan berlatih untuk membuat naluriah itu. Itu berhasil untuk saya. Tidak yakin itu bisa digeneralisasi ke orang lain.

Dalam hal tingkat perolehan keterampilan, saya kebanyakan belajar untuk menerima bahwa setiap kali saya mengubah teknologi (belajar bahasa baru, kerangka kerja baru, dll.) Saya akan melewati tahap ketika saya melambat. Ini normal dan pada akhirnya akan mengatasinya. Saya juga bisa mengimbanginya dengan metodologi yang baik dan keterampilan pemrograman tujuan umum dan itu tidak akan menjadi masalah.

Bagian penting dari pemrograman adalah mengelola dan mengendalikan kompleksitas dan bagi saya pribadi, itu adalah salah satu masalah utama. Jika diabaikan maka frekuensi kekurangan melonjak atau, seperti dalam kasus Anda, ETA perangkat lunak selesai meningkat secara dramatis.

Kompleksitas perangkat lunak dapat dikendalikan dan dikelola dari berbagai tingkatan dan cara tetapi aturan praktis yang baik untuk mendapatkan perspektif adalah ini: "Prioritas utama dari setiap proyek perangkat lunak adalah kepuasan pelanggan yang merupakan fungsi dari harapan mereka."

Dengan kata lain, kompleksitas perangkat lunak sangat tergantung pada seberapa terampil Anda mengendalikan harapan pelanggan Anda.

Ketika seseorang mengadopsi pandangan itu, maka dua poin penting menjadi jelas:

1. harapan pelanggan harus dibuat eksplisit (dalam bentuk apa pun);
2. harapan pelanggan selalu dapat dimodifikasi dan itu dilakukan melalui seni negosiasi.

Contoh Anda adalah contoh yang sangat bagus, "cukup tulis" dan "banyak pertimbangan lain". Pikirkan tentang hal itu - jika seseorang menuliskan persyaratan lengkap untuk kedua varian, dapatkah ada persamaan dalam fitur yang dijelaskan atau tidak?

Membangun F16 berbeda dari membangun Cessna walaupun keduanya bisa terbang.

Jawaban sederhananya adalah: menerimanya.

Di semua sistem ada trade-off yang harus dibuat antara keandalan, ketahanan, keamanan, kecepatan, biaya perangkat keras, biaya pengembangan, waktu ke pasar, apa saja. Anda tidak akan selalu setuju dengan bagaimana pelanggan membuat kompromi itu, tetapi bukan Anda yang membuat keputusan itu. Yang bisa Anda lakukan hanyalah memberikan opini yang dipertimbangkan. Pengembangan perangkat lunak mencakup keseluruhan, dari "halaman web pribadi saya" hingga "menjalankan reaktor nuklir", dan kode harus ditulis sesuai. Jika crash berarti "memuat ulang halaman web pribadi saya", lalu siapa yang benar-benar peduli jika itu terjadi? Tetapi jika sebuah crash berarti "Chernobyl" maka preferensi Anda untuk kode padat adalah jika ada sesuatu yang agak kasual sesuai dengan keinginan saya.

Ada beberapa klien yang akan dengan senang hati menerima kode level "Bukti Konsep" dan menjalankannya dalam sistem live mereka, dan seringkali mereka memiliki administrator sistem yang terbiasa dengan hal itu. IME sistem mereka biasanya tidak tersedia selama satu jam atau lebih di tengah malam sementara banyak restart dijadwalkan terjadi. Tetapi mereka telah membuat keputusan bisnis bahwa itulah yang ingin mereka lakukan. Idealnya karena bidangnya sangat cepat sehingga kode berkualitas tinggi tidak akan pernah siap, tetapi seringkali karena mereka tidak dapat melihat nilainya (jika suatu sistem "hanya bekerja" mereka tidak pernah menyadarinya, oleh karena itu sistem itu tidak mewakili nilai untuk uang). Jika itu terlalu mengganggu Anda, cobalah untuk menghindari klien-klien itu.

Tetap up to date adalah waktu yang kita semua harus habiskan, atau setidaknya harus menghabiskan. Terkadang itu akan membuat Anda bekerja, di lain waktu itu hanya membuat pikiran Anda dalam kondisi yang baik. Apa pun itu, cobalah untuk menikmatinya.

Kedengarannya keterampilan Anda akan sangat berguna untuk pengembangan sistem kritis misi berkualitas sangat tinggi, seperti aplikasi terkait keuangan / perdagangan, penyiaran, kedirgantaraan, pertahanan ...

Kesalahan dalam aplikasi semacam ini sangat mahal dan mereka mempekerjakan orang yang berpikir seperti Anda karena Anda dapat menutupi semua kasing.

Yang benar adalah bahwa sistem modern menjadi semakin kompleks. Komputer sekarang mirip dengan game "Jenga" di mana Anda memiliki semua bagian ini dengan mengandalkan banyak yang lain. Tarik bagian yang salah dan Anda memiliki kesalahan, tarik bagian yang benar / perlu dan Anda masih dapat menghasilkan kesalahan. Semakin kompleks sistem, semakin banyak waktu yang Anda habiskan untuk memikirkan cara membuat kode Anda lebih kuat, dan semoga lebih aman juga. Kecepatan akan menyenangkan, tetapi saya pikir kecepatan sangat sering terjadi belakangan ini ketika Anda mendengar berita bahwa perusahaan "XYZ" diretas dan 6 juta nomor kartu kredit pelanggan dicuri.

Klien Anda mungkin tidak ingin mendengar bahwa program mereka perlu aman, kuat, dll. Tetapi Anda dapat memberi tahu mereka bahwa mobil mereka tidak memerlukan sabuk pengaman dan kantung udara atau rumah mereka perlu kunci dan pintu ... karena siapa yang ingin mendengar semua bahwa?

Jika Anda terlalu memikirkan Anda akan melakukan hal-hal dengan cara yang benar, kecuali bahwa Anda perlu memilih strategi yang tampaknya "konkret" dan hanya pergi dengannya.

Sepertinya Anda menyadari kecenderungan Anda untuk memikirkan segala hal yang bisa salah.

Pengembang Cautious berpengalaman sering belajar untuk mengikuti mantra YAGNI, Anda tidak akan membutuhkannya, ketika mereka mencoba untuk kembali ke alur kerja yang ramping, lincah dan produktif setelah terlalu tersumbat di gulma kegagalan-mode-analisis-hilang-mengamuk.

Namun, jika Anda memang menulis sesuatu dalam domain di mana tingkat perawatan itu tidak kurang dari yang dituntut oleh Profesionalisme, maka Anda harus menyadari bahwa "kecepatan" Anda, "produktivitas" Anda, dalam istilah bersih, dapat diukur dengan seberapa baik ( atau kerusakan) yang Anda lakukan pada perusahaan Anda, pelanggan Anda, dan rangkaian perangkat lunak, atau kelompok produk yang Anda bangun atau pelihara.

Ingat untuk:

• Sertakan total biaya pemeliharaan, total biaya kepemilikan, dan total biaya penggunaan dan pemeliharaan solusi ketika Anda mempertimbangkan perubahan dalam pendekatan Anda. Melaju lebih cepat dan membuat lebih banyak kesalahan mungkin atau mungkin tidak membuat segalanya lebih baik.

• Jika Anda bekerja di perusahaan yang baik, Anda mungkin dapat mendiskusikan hal ini di tim Anda sendiri, dan dengan penyelia Anda sendiri, tanpa menjadi Karir Pembatas Karier. Jika Anda tidak bisa, sekarang adalah waktu yang tepat untuk mengetahuinya, dan cari pekerjaan baru.

Satu-satunya hal yang dapat saya lihat adalah: "Anda menjadi semakin berharga".

Ketika dan ketika Anda mendapatkan lebih banyak pengalaman, Anda belajar tentang hal-hal yang harus Anda hindari, dan inilah yang membuat Anda lebih baik daripada yang lain.

Satu hal yang Anda perhatikan bahwa kode Anda akan lebih aman dan lebih dapat dikelola sekarang.

• Satu-satunya hal yang perlu Anda lakukan adalah menjelaskan klien Anda mengapa perlu waktu dan bagaimana itu akan berguna bagi mereka.
• Anda perlu menunjukkan kedalaman pengetahuan Anda kepada mereka.
• Anda perlu memberi tahu mereka mengapa Anda melakukannya, apa yang Anda lakukan dan bagaimana itu akan berpengaruh pada mereka dan bisnis mereka.

Saran saya adalah berkonsentrasi pada bagian ini.

ketika ragu default untuk mengutip Knuth ...

"Optimalisasi prematur adalah akar dari semua kejahatan."

Inilah yang saya sarankan, karena sepertinya Anda memiliki masalah yang saya miliki dari waktu ke waktu ...

Apa yang benar-benar bekerja untuk saya ...

1. Tulis tes unit, seolah-olah semua kode sudah selesai.
   
2. mendokumentasikan antarmuka.
   
3. mengimplementasikan antarmuka.

apa yang telah Anda lakukan:

1. bekerja melalui persyaratan lapisan model
2. benar-benar mengatur pembagian kerja, objek mana yang bertanggung jawab untuk apa
3. mulai bekerja di lingkungan ketika Anda benar-benar dapat melangkah melalui kode kerja, yang membuat segalanya jauh lebih cepat menjadi lebih akurat ...

juga bergantung pada konfirmasi dalam pengembangan awal ... lalu cari solusi mana yang perlu diterapkan dan Anda tidak akan menulis kode yang tidak terjangkau, atau sulit untuk diuji.

Saya pikir Anda harus tetap berpegang pada standar pengkodean Anda, tetapi pastikan Anda di muka dengan klien Anda. Banyak klien tidak tahu apa yang diperlukan / biaya untuk membangun perangkat lunak yang baik. Itu bagian dari pekerjaan pengembang profesional untuk mendidik mereka.

Apakah Anda lincah atau jatuh, Anda mendapatkan semacam persetujuan dari klien tentang apa yang mereka harapkan dilakukan oleh aplikasi. Terlalu banyak pengembang (OK, mungkin lebih banyak tenaga penjualan) bersalah karena sandbagging . "Mereka tidak mengatakan bahwa mereka menginginkan situs web yang sangat aman." Dalam kebanyakan kasus, itu karena mereka tidak diminta. "Apakah kamu keberatan jika situs e-commerce Anda diretas?" Tentu saja mereka peduli dan mengapa Anda membangunnya untuk membiarkan siapa pun menembus keamanan? Anda harus mendidik mereka.

Pastikan Anda hanya melakukan apa yang dibayar klien untuk Anda lakukan. Bagian dari layanan Anda adalah pengalaman Anda. Klien mengharapkan Anda untuk mengetahui perangkap tanpa harus bertanya. Terserah mereka untuk memasukkan persyaratan. Anda mungkin ingin meneruskan klien yang menginginkan sesuatu yang murah.

Pikirkan tentang konsekuensi praktis bug dibandingkan dengan semua masalah lain yang perlu dipecahkan.

Pertimbangkan konsekuensi-konsekuensi berikut dari menciptakan sepotong kode yang ditulis dengan buruk:

1. Seluruh basis data akan dibuang setiap bulan. 48 jam downtime sementara cadangan dipulihkan.
2. Catatan pelanggan saling terkait. Pesanan senilai $ 200 dikirimkan ke pelanggan yang salah per bulan.
3. Pesanan macet dalam status yang salah seminggu sekali. Pesan kapal tetapi gudang harus menghubungi helpdesk setiap kali itu terjadi.
4. Sekali dua minggu atau lebih, aplikasi mogok dan pengguna harus memasukkan kembali data senilai 2 menit.
5. Sebulan sekali, aplikasi hang saat startup. Pengguna harus mematikan proses dan memulai kembali.

Yang pertama jelas tidak bisa diterima. # 2 - # 5 mungkin atau mungkin tidak, tergantung pada sifat bisnis. # 2 - # 5 perlu dievaluasi dalam konteks masalah lain yang dihadapi bisnis.

Idealnya, # 2 - # 5 tidak akan pernah terjadi. Dalam kehidupan nyata, dengan prioritas yang saling bertentangan, orang-orang yang menandatangani gaji Anda mungkin ingin Anda mengerjakan hal-hal lain daripada menulis kode sempurna yang tidak pernah, pernah mengalami masalah. Mereka tidak akan terkesan jika # 5 diperbaiki dengan mengorbankan tidak memperbaiki bug yang lebih serius di program lain.

Solusinya adalah membuat koleksi perpustakaan dengan fungsi yang umum digunakan yang dapat Anda gunakan kembali di seluruh proyek. Misalnya saya memiliki perpustakaan StringFunctions.dll .NET yang melakukan hal-hal seperti pengkodean, enkripsi, dekripsi, evaluasi ekspresi reguler, dll. Dengan cara ini, saya tidak perlu terus menulis ulang hal-hal yang tidak berubah.

Memiliki pembungkus untuk tugas pembuatan file juga masuk akal. Pustaka Anda dapat mengekspos metode yang disebut GetFile () yang melakukan semua pemeriksaan untuk Anda dan mengembalikan null atau file (atau apa pun yang Anda anggap berguna).

Saya pikir Anda perlu belajar untuk memutuskan berapa banyak yang harus dilakukan untuk proyek yang mana. Beberapa proyek mungkin sepele dan Anda benar-benar tidak perlu menghabiskan semua waktu itu untuk menyempurnakannya. Tidak semuanya akan membutuhkan enkripsi yang solid atau segalanya akan ditingkatkan ke jutaan pengguna.

Menulis program yang dapat mengukur dengan baik untuk lebih dari satu juta pengguna akan membutuhkan waktu dan pengalaman yang Anda miliki sekarang, tetapi jika Anda tahu bahwa aplikasi Anda tidak akan digunakan oleh lebih dari 1000 pengguna, tidak ada gunanya menghabiskan semua waktu itu menyempurnakannya.

Saya pikir ini adalah tahap penting dalam karir pemrograman Anda dan sekarang Anda perlu melangkah ke tingkat berikutnya, yang berhubungan dengan kedewasaan dan bukan pemrograman. Anda harus dapat memutuskan dengan tepat berapa banyak waktu dan kode yang harus cukup untuk proyek tertentu.

Dan seperti yang lainnya, Anda bisa mencapai ini juga dengan latihan. Jadi cobalah untuk memutuskan ini sebelum Anda memulai sebuah proyek, kadang-kadang bahkan ketika Anda sedang mengerjakannya, dengan pengalaman Anda akan melewati itu juga. Mungkin ada beberapa hit dan miss di awal tetapi seiring waktu Anda akan menyempurnakannya (pengambilan keputusan, bukan kode).

@ Zilk, saya bukan programmer hebat dan saya sudah pemrograman sejak tahun 1998. Bahkan saya menghadapi masalah ini sekarang. Tetapi apa yang saya sadari pada akhirnya adalah masalah kualitas. Jika saya mati hari ini, seseorang harus dapat mengambil apa yang saya lakukan sekarang dari tempat saya pergi. Tersebut harus menjadi standar pemrograman (Universal).

Saya telah pindah dari pengembang ke arsitek sekarang. Pindah ke Manajemen mengubah garis. Jika Anda ingin melanjutkan dengan hasrat Anda, Anda dapat pindah untuk menjadi Arsitek.

Awalnya sebagai Arsitek Teknis -> Arsitek Solusi -> Arsitek Perusahaan -> Kepala Arsitek dan sebagainya.

Sebagai seorang Arsitek, Anda akan membimbing orang menuju kesuksesan. Orang-orang seperti Anda yang telah memprogram bertahun-tahun pengalaman yang dapat Anda manfaatkan untuk memandu orang lain.

Seperti burung yang lebih tinggi ia terbang lebih banyak tanah yang bisa dilihatnya begitu juga pengalaman Anda.

Biarkan saya juga memberi tahu Anda pemrograman implementasi yang benar adalah penting daripada pemrograman implementasi yang salah lebih cepat. Baru-baru ini salah satu junior saya memprogram sesuatu yang salah dan menghabiskan banyak uang di bank. Tentu saja kami telah mengirimkan tepat waktu sebelumnya tetapi itu tidak ada gunanya! Apakah saya diberi peran untuk membimbing meskipun junior yang sama akan berkode bahwa masalah tidak akan terjadi. Saya memberikan contoh ini untuk menekankan bahwa memberikan bimbingan yang baik juga penting. Beberapa menyebut pekerjaan ini sebagai Konsultasi.

Pilihan lain adalah: berhenti menulis kode, alih-alih menjual keahlian Anda dalam menemukan masalah sebelumnya.

Dengan kata lain, jadilah Konsultan .

Banyak organisasi dengan senang hati membayar dolar mahal (jika tidak mahal) bagi seseorang untuk menemukan masalah sebelum menghabiskan waktu berbulan-bulan untuk menciptakan kode yang membuat masalah. Diketahui bahwa memperbaiki bug dalam desain, adalah urutan besarnya lebih murah / lebih mudah daripada memperbaikinya setelah kode, diuji, dan digunakan.

Anda tidak akan menulis sebanyak kode, dan Anda mungkin mungkin kehilangan itu, tapi kemudian tampaknya bahwa garis-garis yang sebenarnya kode yang tidak kekuatan inti Anda, tetapi dalam mengetahui mana baris kode harus ditulis - dan yang tidak seharusnya.

Fokus pada kekuatan Anda.
(yah, jika itu yang Anda nikmati ...)

Rekomendasi terbaik saya untuk Anda adalah: blok bangunan.

Buat blok pembangun file yang bisa Anda percayai selalu, buat satu untuk API Anda, berhenti buang waktu Anda menulis hal yang sama berulang kali. Pikirkan setiap masalah sekali dan perbaiki sekali dan untuk semua.

Tidak ada yang akan mengejar ketinggalan, tentu saja bukan pemula yang menghabiskan 80% dari waktu mereka kode debugging yang gagal untuk kasus sudut mereka tidak mengerti.

Yang terpenting, jangan memperbaiki masalah yang tidak dapat terjadi, seperti izin yang salah.

Jika izin salah, sesuatu sudah salah dan Anda harus memperbaikinya daripada membuat program Anda bukti peluru.

Pada titik tertentu Anda harus tidak menembak kaki Anda sendiri daripada selalu memeriksa apakah Anda melakukannya atau tidak.

Alih-alih menghabiskan waktu untuk dokumentasi, habiskan waktu membuat kode Anda mendokumentasikan diri sendiri dan sesingkat mungkin. Ganti semua fungsi duplikat tersebut. Kecilkan perpustakaan Anda, ganti nama benda dengan presisi.

Jangan terlalu keras pada diri sendiri. Anda bekerja dalam profesi dengan kompleksitas yang semakin meningkat, yang membutuhkan lebih banyak kecerdasan, pengetahuan, dan pengalaman manusia daripada sebelumnya.

Kekuatan pemrosesan komputer melambat - mungkin segera macet - mengarah pada kebutuhan untuk memperkenalkan chip multi-core, numerik bertenaga GPU, paralelisme, dll. Hanya ada begitu banyak transistor yang dapat ditempatkan pada sebuah chip.

Oleh karena itu kemajuan besar saat ini dan di masa depan akan datang dari programmer - algoritma canggih dan kode yang lebih efisien.

Jika Anda melihat GTA 4 dan GTA 5 perbedaannya sangat mengejutkan. Tetapi keduanya berjalan pada perangkat keras yang sama. Ini adalah hasil dari beberapa praktik pemrograman yang sangat cerdas dan canggih yang tidak diperlukan, atau tersedia, 10 tahun yang lalu.

Ini juga bisa berarti bahwa pemrogram berpengalaman dapat menjadi lebih berharga di masa depan - seperti profesi lain seperti teknik di mana pendapatan puncak biasanya terjadi di akhir karir.

Sama seperti Anda, saya mulai pemrograman pada usia 14, juga ketika saya mendapatkan komputer pertama saya (meskipun saya telah belajar selama beberapa bulan pada saat itu). Namun, saya "hanya" 33 sekarang. :-)

Saran saya adalah, ketika mengembangkan sesuatu, Anda mengambil setiap kekhawatiran itu (izin file, jumlah file dalam direktori, dll.) Dan kemudian menggunakan semua pengalaman Anda yang luas untuk menjawab beberapa pertanyaan tentangnya, dengan semangat ini:

• Berapa lama yang dibutuhkan untuk menangani masalah itu dengan benar dalam kode Anda?
• Jika Anda tidak menanganinya dengan benar, seberapa besar kemungkinan hal ini akan menggigit Anda nanti?
• Jika itu menggigit Anda, apa konsekuensinya?

Berbekal jawaban itu, pria yang berpengalaman tidak akan memiliki masalah untuk membuat keputusan yang bijak. ;-)

Adalah tanggung jawab "veteran" seperti Anda untuk menemukan jenis persyaratan ini, dan itu melibatkan pengidentifikasian apa yang salah dan memutuskan masalah potensial yang harus Anda perhatikan.

Mengetahui semua kriteria yang mungkin saat mengembangkan aplikasi adalah hal yang paling penting dalam mengembangkan produk yang berkualitas. Anda melakukan yang baik dalam hal ini. Satu hal yang dapat Anda lakukan adalah, Anda dapat mengkategorikan persyaratan ke dalam tingkat kualitas kemudian memetakan tingkat dengan tenggat waktu yang diberikan. Dengan cara ini Anda dapat memenuhi tenggat waktu proyek dengan mudah.

Dalam kata-kata Edsger Dijsktra: "Jika debugging adalah proses menghilangkan bug perangkat lunak, maka pemrograman harus menjadi proses memasukkannya." Anda hanya melakukan sedikit dari yang terakhir sehingga Anda harus mengurangi yang sebelumnya. Ini hanya masalah belajar menghabiskan waktu mengkodekannya dengan benar. Saya masih seorang programmer yang relatif muda (baca 20ish) dan saya bercita-cita untuk dapat kode sesuatu yang benar sekali. Satu jam perencanaan dan 10 menit pengkodean jauh lebih baik daripada 10 menit perencanaan, satu jam pengkodean, dan tiga debugging.