Terjebak karena “tahu terlalu banyak” [ditutup]

Perhatikan diskusi lebih lanjut di http://news.ycombinator.com/item?id=4037794

Saya memiliki tugas pengembangan yang relatif sederhana, tetapi setiap kali saya mencoba untuk menyerang, saya akhirnya berputar dalam pemikiran yang mendalam - bagaimana hal itu dapat memperpanjang masa depan, apa yang dibutuhkan klien generasi ke-2, bagaimana pengaruhnya terhadap "tidak fungsional" aspek (mis. Kinerja, otorisasi ...), bagaimana cara terbaik bagi arsitek untuk mengizinkan perubahan ...

Saya ingat beberapa waktu yang lalu, lebih muda dan, mungkin, lebih bersemangat. "Aku" yang pada waktu itu tidak akan kupikirkan tentang semua itu - dia akan pergi dan menulis sesuatu, kemudian menulis ulang, kemudian menulis ulang lagi (dan lagi ...). "Aku" hari ini lebih ragu-ragu, lebih berhati-hati.

Saya merasa jauh lebih mudah hari ini untuk duduk dan merencanakan dan mengajar orang lain tentang cara melakukan sesuatu daripada benar-benar maju dan melakukannya sendiri - bukan karena saya tidak suka kode - sebaliknya, saya suka! - tetapi karena setiap kali saya duduk di keyboard, saya berakhir di tempat yang sama.

Apakah ini salah? Apakah ini evolusi alami, atau apakah saya mendorong diri sendiri ke dalam kebiasaan?

Pengungkapan yang adil - di masa lalu saya adalah seorang pengembang, hari ini jabatan saya adalah "arsitek sistem". Semoga beruntung, apa artinya - tapi itulah judulnya.

Wow. Sejujurnya saya tidak berharap pertanyaan ini menghasilkan banyak tanggapan. Saya akan mencoba merangkumnya.

Alasan:

1. Analisis kelumpuhan / Rekayasa berlebihan / penyepuhan emas / (yang lain "terlalu banyak berpikir di muka dapat melukai Anda").
2. Terlalu banyak pengalaman untuk tugas yang diberikan.
3. Tidak fokus pada apa yang penting.
4. Tidak cukup pengalaman (dan menyadarinya).

Solusi (tidak sesuai dengan alasan):

1. Pengujian dulu.
2. Mulai koding (+ untuk bersenang-senang)
3. Satu untuk dibuang (+ satu API untuk dibuang).
4. Tetapkan batasan waktu.
5. Lepaskan bulu, tetap dengan barang-barang.
6. Buat kode fleksibel (agak berlawanan dengan "satu untuk dibuang", bukan?).

Terima kasih kepada semua orang - saya pikir manfaat utama di sini adalah menyadari bahwa saya tidak sendirian dalam pengalaman ini. Sebenarnya, saya sudah mulai mengkode dan beberapa hal yang terlalu besar telah jatuh, secara alami.

Karena pertanyaan ini ditutup, saya akan menerima jawabannya dengan suara terbanyak pada hari ini. Kapan / jika itu berubah - Saya akan mencoba mengikuti.

Memikirkan hal-hal ini benar-benar baik, tetapi jangan biarkan itu menghentikan kemajuan Anda.

Salah satu pendekatan yang bekerja sangat baik (terutama dengan pengembangan berulang) adalah menerapkan solusi sederhana dan kemudian refactor sesuai kebutuhan nanti. Ini membuat kode sesederhana mungkin, dan menghindari rekayasa berlebihan. Sebagian besar perubahan kinerja atau arsitektur yang Anda renungkan mungkin tidak akan diperlukan, jadi jangan repot-repot menulisnya sampai secara resmi menjadi perlu. Misalnya, jangan khawatir tentang kinerja sampai seorang profiler memberi tahu Anda bahwa inilah saatnya untuk meningkatkan kinerja.

Satu hal yang dapat Anda lakukan untuk membantu Anda menyesuaikan diri adalah menetapkan batas waktu yang sulit tentang berapa lama Anda memikirkan sesuatu sebelum menulis kode. Sebagian besar waktu, kode akan menjadi lebih baik jika Anda berpikir sebentar, menulisnya, menyadari kesalahan Anda, dan kemudian memperbaikinya dengan refactoring.

Ada keseimbangan yang harus dicapai di sini. Anda tidak boleh langsung berpikir dan tidak memikirkan konsekuensinya, tetapi Anda juga tidak boleh mencoba merekayasa ulang kode Anda juga.

Wikipedia menamainya "Analisis kelumpuhan" dalam perangkat lunak. Resepnya adalah tetap pada metodologi yang gesit. Berarti bahwa setiap kegiatan atau tindakan individu memiliki nilai lebih daripada upaya untuk menetapkan praktik atau kebijakan. Setiap kontributor dalam tim bernilai, tidak peduli seberapa baik atau buruk kemampuan seseorang sesuai dengan cita-cita arsitektur. Dalam kelincahan, individu, ego adalah yang pertama, kebijakan adalah yang terakhir.

Jawaban favorit saya adalah "Arsitektur adalah kata kerja". Berhentilah berpikir, mulailah bertindak, tidak peduli seberapa tidak sempurna dan tidak efisiennya Anda dan tim akan merasa. Mungkin tindakan pertama bisa membongkar kebijakan yang tidak pantas.

40 tahun yang lalu Fred Brooks menulis tentang ini, "Tulis saja untuk dibuang, Anda akan bagaimanapun." Tidak ada yang berubah........

Apakah ini salah? Apakah ini evolusi alami, atau apakah saya mendorong diri sendiri ke dalam kebiasaan?

Tergantung. Ini cenderung menjadi langkah umum di sepanjang jalan pengembang.

1. Mulai melempar omong kosong bersama, digigit pantatnya
2. Mulai rekayasa ulang neraka yang hidup dari segalanya, sadari bahwa YAGNI
3. Selesaikan di jalan tengah pragmatis di mana hal-hal mudah ditampar bersama-sama dan hal-hal yang sulit / kemungkinan perubahan diberikan cukup teknik untuk membuatnya cukup mudah untuk bekerja dengan / berubah.

Ini hanya kebiasaan jika Anda tetap di nomor 2.

Salah satu hal yang selalu ingin saya ingat adalah ungkapan "masa depan tidak seperti dulu."

Dengan sejumlah pengalaman tertentu, tergoda untuk meyakini bahwa Anda dapat memprediksi masa depan, tetapi Anda tidak bisa. Sangat mudah untuk membayangkan fitur-fitur yang diinginkan klien / pengguna / apa pun yang mereka inginkan, tetapi itu tidak berarti mereka akan menginginkannya segera. Itu juga tidak berarti mereka akan menginginkan mereka daripada beberapa fitur yang saling bertentangan. Jadi Anda benar-benar perlu membatasi berapa banyak waktu yang Anda habiskan hari ini merencanakan masa depan. Anda terutama perlu membatasi berapa banyak waktu yang Anda habiskan untuk membangun sesuatu hari ini yang hanya akan berguna di masa depan.

Pertanyaan yang saya ajukan yang membuat saya tetap di jalur yang lurus dan sempit adalah "seberapa sulitkah membangun fitur ini lebih lambat daripada membangun dukungan untuk fitur itu sekarang?" Biasanya, jawabannya adalah bahwa upaya di masa depan hampir sama atau mungkin dua kali lipat dari yang harus dilakukan sekarang. Dalam hal ini, karena saya tidak dapat memprediksi masa depan, saya tidak punya masalah untuk tidak membangunnya sekarang. Jika jawabannya mencapai 10x atau lebih, maka saya akan mulai bertanya tentang seberapa besar kemungkinan orang berpikir bahwa kita akan membutuhkan ini dalam satu atau dua tahun ke depan. Bahkan kemudian, kecuali ada kesepakatan luas, saya hanya akan membatasi diri untuk memastikan tidak perlu membatalkan hal-hal yang kita lakukan hari ini untuk mencapai tujuan itu di masa depan.

Sebagai contoh, saya bekerja pada beberapa proyek di mana kami menghabiskan banyak waktu mengabstraksi fakta bahwa kami menggunakan Hibernate sebagai akses data nanti. (Belum pernah saya melihat proyek yang dibangun di atas Hibernate berhenti menggunakannya, jadi itu membuang-buang waktu untuk memulai, tapi mari kita kesampingkan itu.) Bahkan jika itu adalah kemungkinan yang masuk akal bahwa kita mungkin ingin mengubahnya nanti, karena kami juga menggunakan pola objek akses data, tidak akan sulit untuk membangun fleksibilitas untuk mengganti Hibernate dan mengubahnya pada saat yang sama ketika kami membutuhkannya daripada membangun fleksibilitas sejak awal. Menghadapi situasi seperti itu sekarang, saya hanya akan menunda memiliki fleksibilitas itu sampai kita benar-benar membutuhkannya.

Kecuali jika Anda melakukan perencanaan strategis untuk sebuah perusahaan besar, hampir tidak ada gunanya untuk memikirkan masalah arsitektur lebih dari dua atau tiga tahun ke depan, karena teknologi berubah begitu cepat. Fitur yang Anda mungkin pikirkan tentang membangun hari ini mungkin tersedia secara bebas di sumber terbuka dalam dua atau tiga tahun. Hampir pasti analisis biaya-manfaat akan berubah.

Batasi diri Anda untuk membangun sistem yang melakukan apa yang Anda butuhkan hari ini, yang Anda banggakan, dan bahwa Anda akan senang bekerja dalam beberapa bulan apa pun yang membawa perubahan selanjutnya. Sungguh itu yang terbaik yang bisa Anda lakukan.

Inilah proses eliminasi pribadi saya untuk desain-desain luar biasa gila yang (dalam versi pertama mereka) dapat menjadi tidak praktis dan merusak proyek dari perspektif bisnis.

1. Identifikasi pusat gempa : Pikirkan proyek Anda sebagai kios hot-dog, pusat gempa akan menjadi hot dog. Anda dapat mengeluarkan rempah-rempah / saus / sayuran lainnya dari stand Anda dan masih bisa menjual hot dog. Apa tujuan utama dari perangkat lunak Anda? Isolasikan setiap tambahan lainnya dan / atau nilai tambah darinya dan fokuskan dulu pada pusat gempa.
2. Terus ulangi pada diri sendiri "melakukannya nanti berarti melakukannya dengan lebih baik" : lihat di mana itu masuk akal dan tuliskan sedikit "untuk nanti". Jika Anda melakukannya dengan baik dan memikirkan penggunaannya di dunia nyata, Anda akan berakhir dengan desain yang sama tetapi diprioritaskan dalam peta jalan.
3. Diminish-Decouple-Discard : Apa pun desain modul yang Anda buat, sesederhana / esensial / murni / universal sebanyak yang Anda bisa (kadang-kadang ini dapat dilakukan tanpa menghilangkan fitur). Ketika Anda tidak dapat menyederhanakannya lebih jauh, mulailah memisahkan elemen yang dapat hidup sendiri dan memiliki tujuan. Pada akhirnya jika Anda masih memiliki sedikit lemak di sana, Anda akan bisa memotongnya.
4. Pisahkan "kode perpustakaan" dari "kode produksi" : Akan selalu ada kode yang tidak dapat digunakan kembali, tetapi selalu menambah noise pada desain. Kode ini adalah yang mengandung aturan bisnis. Anda akan menemukan bahwa kadang-kadang beberapa aturan bisnis lebih mudah dan lebih cepat untuk diubah ( sangat penting ) daripada dengan desain yang kuat. Anda akan menemukan kode yang dapat Anda andalkan, dan kode yang perlu diubah atau diterapkan ulang oleh pelanggan di masa mendatang. Anda ingin mereka disimpan terpisah mungkin.

Dan BTW, langkah 0 adalah: "menjadi gila dengan desain". Ini membantu saya mengeluarkannya dari sistem saya dan sering menemukan implikasi baru, persyaratan tersembunyi dan bahkan fitur yang muncul.

Saya mengambil 1 & 2 dari Rework .

Tulis tesnya. Anda selesai ketika semua tes lulus: tidak sebelumnya, dan tentu saja tidak lama setelah selama fase epik rekayasa berlebihan. Memiliki serangkaian tes untuk kode yang Anda tulis akan memberi Anda pengamat independen yang memberi tahu Anda kapan Anda bisa berhenti.

Ketika Anda muda, Anda tidak melihat risiko (mungkin alasan politisi junior menakutkan), tetapi seiring bertambahnya usia, pengalaman buruk Anda melumpuhkan Anda di setiap kesempatan (mungkin alasan politisi senior mandek). Mengadopsi pisau cukur Occam dipandu pendekatan - pergi untuk solusi yang memiliki kebutuhan paling sedikit dan kemudian berkembang dari sana.

Hanya ada dua hal yang benar-benar perlu Anda ingat ketika menulis dan merancang perangkat lunak: rawatan dan kebenaran.

Kebenaran adalah jangka pendek yang paling penting dan dapat dengan mudah dibuktikan dengan tes.

Pemeliharaan akan membantu nanti dalam pengembangan tetapi lebih sulit untuk dijabarkan.

Strategi saya saat ini adalah untuk pertama-tama mendapatkan bukti konsep monolitik dan kemudian memisahkan UI dari model (memastikan model tidak tahu apa-apa tentang UI) setelah saya puas bahwa itu layak. Jika saya akan menunggu terlalu lama untuk langkah ini, saya akan mendapatkan sesuatu yang tidak dapat dipelihara. Jika saya mulai dengan layer yang terpisah, sepertinya saya tidak bisa memulai karena saya terjebak pada apa yang perlu diketahui UI tentang model tersebut.

Ketika saya terjebak dalam situasi seperti ini, saya menemukan bahwa itu membantu untuk secara keras kepala membayangkan bahwa saya adalah pengguna akhir yang menggunakan program hipotetis untuk menyelesaikan sesuatu yang sepele. Kemudian saya mencoba untuk fokus pada apa yang diperlukan oleh titik masuk program untuk mendukung tindakan-tindakan itu, berusaha sebisa mungkin untuk mengabaikan aspek-aspek lain dari sistem. Dari sini sering mungkin untuk membuat 'daftar whish' (kecil!) Fitur dari sistem yang sudah selesai, dan menulis beberapa kode tidak realistis yang mulai mengimplementasikannya. Setelah latihan itu, saya biasanya mulai, dan sisa sistem mulai menjadi lebih jelas. Ini semua tentang titik masuk - dan titik masuk sebagian besar dari semua perangkat lunak adalah tindakan awal pengguna akhir dengan suatu program.

Saya pikir ini adalah sindrom bahwa tugas yang Anda lakukan terlalu mudah untuk Anda.

Beberapa tahun yang lalu, balasan bagi Anda adalah menulis kode yang akan menyelesaikan tugas yang diberikan. Inilah yang sepenuhnya melibatkan pikiran Anda. Sekarang, pikiran Anda (pengalaman Anda, dll.) Bekerja lebih efektif dan melakukan tugas yang sama hanya membutuhkan sebagian energi yang sebelumnya dibutuhkan. Inilah sebabnya mengapa Anda berakhir dengan semangat pemikiran yang mendalam itu. Pikiran Anda mempertahankan diri dari rutinitas dan berjuang untuk tantangan.

Saya pikir Anda harus mempertimbangkan untuk mengubah pekerjaan Anda. Mungkin Anda harus belajar bahasa pemrograman baru.

Saya memiliki masalah yang sama 15 tahun yang lalu. Saya ingin menulis kode yang sempurna, dapat digunakan kembali, universal, .... yang membuat solusi jauh lebih rumit daripada yang diperlukan. Hari ini saya melihat ini sebagai penyepuhan emas . Apa yang banyak membantu saya adalah saran dari seorang kolega:

• jika Anda memiliki ide apa yang dapat meningkatkan fungsionalitas, membuatnya lebih univeral, ... tulis ide ini ke dalam file teks terpisah "ideas.txt" tetapi jangan mengimplementasikannya sekarang .
• terus menerapkan tugas-tugas mendesak.
• setelah enam bulan, tinjau "ideas.txt" Anda dan analisis perubahan mana yang benar-benar akan menguntungkan proyek.

Ini hanya kelumpuhan dengan analisis. Itu terjadi pada banyak orang di berbagai bidang. Anda bisa menerobosnya.

Jawabannya adalah - HANYA DENGAN ITU ;-)

Saya memposting di forum kebugaran dan berkali-kali orang memposting tentang rutinitas yang berbeda, mencoba untuk menemukan yang tepat untuk mereka. Jadi kami memberi tahu mereka bahwa baru mulai pelatihan dan kerjakan saat Anda melanjutkan. Anda ingin menjadi lebih kuat, melakukan beberapa latihan kekuatan dan kemudian men-tweak hal-hal yang Anda lakukan.

Ketika Anda memiliki program besar dan otak Anda bekerja lembur - cukup kode untuk kasus-kasus sederhana terlebih dahulu. Awalnya program harus dijalankan, kemudian harus mengambil input, dll
. Tantangan Anda adalah membiarkan hal-hal mudah diperbarui dan direvisi nanti tetapi kode HARUS tidak lebih rumit daripada yang diperlukan untuk melakukan tugas yang ada.

Ingat di masa depan, boleh saja kode refactor untuk memenuhi prioritas baru. Anda tidak dapat memprediksi semuanya di muka jadi jangan coba-coba.

Kode untuk tugas selanjutnya - HANYA. Kode sederhana dan baik sehingga mudah untuk refactor jika perlu. Pastikan program bekerja. Ulangi.

Karena Anda "terjebak" terlalu memikirkan kemungkinan skenario kasus penggunaan pengguna akhir, ada sesuatu untuk dipertimbangkan di sini jika Anda akan menerbitkan API dan berharap bahwa orang-orang yang tidak dikenal oleh Anda akan menggunakan API itu. Setelah API diterbitkan, Anda juga harus terus mendukungnya, meskipun Anda kemudian menyadari betapa buruknya rilis pertama Anda, atau Anda harus melanggar kode semua orang, mungkin tidak diketahui oleh Anda, yang telah menulis menentangnya sehingga berisiko mengasingkan mereka untuk semua waktu mendatang.

Solusi standar adalah mempublikasikan dengan ketentuan bahwa API dapat berubah dengan cara apa pun kapan saja sampai Anda memahami apa yang dibutuhkan pengguna Anda dan yang dilakukan konsumen API.

Dalam solusi itu saya pikir adalah solusi Anda sendiri. Tuliskan hanya beberapa hal kecil yang melakukan satu atau dua hal, mungkin lakukan dengan baik, pertahankan pemahaman pada diri sendiri bahwa apa pun yang Anda lakukan dapat berubah di masa depan.

Tidak mungkin untuk memperbaikinya, atau dalam beberapa kasus bahkan APAPUN dengan benar, ketika Anda memulai karena desain benar-benar sebuah perjalanan penemuan; ini adalah yang terakhir muncul, bukan hal pertama yang harus dilakukan.

Anda tidak dapat langsung mendesain API dan tidak perlu membaginya ke konsumen. Anda mengerti mengapa demikian. Dengan cara yang sama Anda tidak dapat menulis perangkat lunak dan tidak harus membuang semuanya dan memulai kembali dengan pendekatan baru.

Saya tidak berpikir Anda memiliki masalah dalam arti Anda secara tidak sengaja berevolusi menjadi sesuatu yang kurang kreatif, produktif atau diinginkan. Saya pikir Anda memiliki standar tinggi yang secara tidak sengaja Anda salah gunakan untuk situasi Anda - kesalahan umum dalam berpikir setiap orang membuat.

Pengalaman tidak pernah diperhitungkan melawan Anda kecuali jika Anda menjadi orang yang sinis mengetahui segalanya, melakukan segalanya, dan itu benar-benar terdengar seperti kebalikan dari situasi Anda.

Saya memiliki beberapa gambar yang saya ingat ketika saya menjadi besar. Salah satunya bermain dengan Lego. Saya menyatukannya dan memisahkannya sesuka hati. Apa yang saya mulai membuat mungkin bukan apa yang akhirnya saya buat. Saya berselancar dan mengambil keuntungan dari kemungkinan yang muncul di benak saya saat saya mengikuti, sering menciptakan tujuan saya sepenuhnya di tempat dalam sekejap inspirasi ... itulah kreativitas IS.

Gambar lainnya adalah analogi yang saya dengar yang menggambarkan melakukan sains nyata. Anda meraba-raba di ruangan gelap untuk kucing hitam yang mungkin tidak ada di sana. Mengerikan hanya jika Anda menganggap diri Anda gagal karena tidak menemukan kucing itu. Tidak ada cara lain untuk menemukan kucing hitam. Itulah satu-satunya kegiatan yang menemukan mereka. Yang lainnya adalah beberapa bentuk sudah memiliki apa yang Anda cari.

Anda tidak tahu terlalu banyak; kamu tidak cukup tahu! Dan Anda baru menyadari itu.

Jangan berpikir tentang pilihan desain Anda sebagai sesuatu yang harus Anda dapatkan "benar", karena tidak ada "benar" - ada banyak "kesalahan", tetapi ada juga pengorbanan (dalam kecepatan eksekusi, waktu untuk menyelesaikan pengkodean tugas, ekstensibilitas, dll.). Kode yang Anda tulis jika dipahami dengan baik masih akan memiliki berbagai kekuatan dan kelemahan.

Tujuannya adalah untuk mencapai titik di mana memahami kekuatan dan kelemahan ini dalam konteks penggunaan dan pemeliharaan saat ini dan di masa depan tidak secara dramatis lebih sulit daripada menulis kode.

Jadi jangan menghindari pemikiran yang mendalam, tetapi ingat bahwa Anda membutuhkan pengalaman, bukan hanya pemikiran, untuk menjadi ahli dalam desain semacam ini. Pikirkan sampai Anda mencapai titik di mana Anda tidak percaya diri terhadap pilihan tertentu, kemudian terapkan apa yang Anda harapkan adalah yang terbaik, cobalah, dan belajar dari bagaimana hasilnya.

Berlatih coding. Buat latihan atau temukan secara online, dan cobalah untuk menyelesaikannya dengan benar secepat mungkin. Ketika Anda meningkatkan kecepatan, tambahkan pertimbangan seperti rawatan dan kinerja. Anda akan menyadari bahwa itu menyegarkan untuk hal-hal kode yang tidak akan masuk ke produksi dan mungkin membantu Anda keluar dari rasa takut Anda coding.

Lakukan pengkodean di waktu luang Anda, seperti yang Anda lakukan 10 tahun yang lalu, dengan sedikit kekhawatiran dan kesenangan.

Menjadi manajer tim dan mengarahkan pengembang yang lebih muda - yang sekarang berada dalam kondisi mental yang sama dengan Anda 10 tahun yang lalu.

Tidak, Anda belum cukup tahu.

Perkaya pengetahuan Anda, mis. Dengan aturan sederhana ini:

• CIUMAN: Tetap kecil dan sederhana.
• YAGNI: Anda tidak akan membutuhkannya.
• Lebih buruk lebih baik: Beberapa solusi buruk sebenarnya lebih baik dalam hal pemeliharaan.

Jangan overengineer. Bersiaplah untuk perubahan dengan memiliki keterampilan refactoring, tetapi jangan menyandikan setiap kemungkinan perubahan kode. Jika Anda melihat bahwa seiring waktu, kelas atau fungsi tumbuh terlalu besar, ubahlah. Memecah dan menaklukkan. Gunakan antarmuka, gunakan lebih banyak fungsi. Jika Anda merasa bahwa Anda telah membagi terlalu banyak (artinya menjadi lebih bagus, tetapi kurang dapat dibaca), batalkan perubahan terakhir Anda.

Singkatnya: Buat kode Anda cukup fleksibel, tetapi tidak lebih. Sebaliknya, buat diri Anda fleksibel, beli buku tentang refactoring.

Dua hal:

1. Tidak cukup tahu banyak. Anda harus memiliki pendapat tentang apa yang layak diterapkan. Saya pribadi melihat TDD sebagai penopang yang memungkinkan arsitektur yang buruk. Mengingat banyaknya opini populer yang menentang saya dalam hal ini, saya mungkin salah, tetapi apakah menerapkan TDD dalam JavaScript bukanlah masalah yang saya pikirkan, karena debug tidak pernah menjadi masalah besar bagi saya dan hei, itu bukan pertama kalinya opini populer di komunitas pembangunan kemudian dilihat sebagai cacat tahun kemudian. Jadi belajarlah untuk menjadi orang yang sombong. Setidaknya di bagian dalam. Anda mungkin salah, tetapi setidaknya Anda berkomitmen untuk hal-hal yang bekerja untuk Anda daripada memikirkan hal-hal yang mungkin tidak.

2. Sepertinya Anda mulai dengan mikro. Mulai dengan makro. Pertama, alat yang Anda butuhkan untuk melakukan hal-hal yang perlu dilakukan aplikasi Anda. Bagian itu harusnya cukup mudah. Kemudian mulai dengan masalah arsitektur / antarmuka. Bagaimana pipa ledeng menghubungkan dan apa yang terhubung harus benar-benar hanya bit tipis di atas segala sesuatu yang Anda hanya bisa menggesek samping dan ganti sambil iseng. Begitu juga dengan detail bagaimana hal-hal dilakukan. Dibungkus dengan benar, ini dapat diganti / diedit dengan mudah.

tetapi setiap kali saya mencoba untuk menyerang, saya akhirnya berputar dalam pikiran yang mendalam

Tidak ada yang salah. Anda hanya memperhatikan bahwa inilah saatnya untuk meningkatkan proses Anda: dalam hal ini, proses berpikir Anda.

Banyak orang tersesat dalam analisis atau dialihkan dengan cara lain dan bahkan tidak pernah menyadarinya. Anda telah memperhatikan sehingga Anda dapat mengubah proses berpikir Anda untuk tetap di jalur.

Ada banyak solusi untuk ini, dan yang terbaik yang saya lihat di atas adalah menetapkan batasan waktu. Sebelum Anda mulai, putuskan berapa lama (1 jam?) Yang akan Anda curahkan untuk menganalisis dan memikirkannya. Atur timer.

Kemudian, ketika timer mati, mulailah pengkodean. Jika Anda mendapati diri Anda memikirkan hal terlalu lama lagi, buat saja keputusan instan. Apa pun yang Anda putuskan pada saat itu adalah keputusan yang tepat. Anda selalu dapat melakukan perubahan dan peningkatan di lain waktu.

Selain itu, lingkungan kita selalu berubah. Kita sering perlu memperbarui kode kita untuk menangani persyaratan baru, teknologi baru, perangkat keras baru, bahasa dan pembaruan sistem, dll.

Ya, kengerian pengkodean ini terjadi bahkan untuk saya. Terkena Stack Overflow. Pengkodean secara detail untuk aplikasi kecil. Tetapi ketika itu adalah proyek outsourcing, itu tidak memakan banyak waktu karena kendala waktu. Dan saya merasa bekerja sama dengan sekelompok orang baru dapat mengatasi hal ini.

Kamu Tidak Cukup Kejam

http://playswithfire.com/blog/2012/02/19/you-are-not-ruthless-enough/

Sunting: Inti dari artikel ini adalah memperhatikan detail kecil ketika mengembangkan, tapi saya merasa membantu untuk mendekati tugas sederhana atau kompleks dengan sikap kejam untuk menemukan solusi tunggal yang paling efisien yang mungkin dan hanya menyelesaikan pekerjaan.