Saya telah bekerja sebagai pengembang aplikasi selama satu setengah tahun sekarang (tidak lama saya tahu), dan saya baru saja diberi proyek besar pertama saya.

Tidak perlu dikatakan itu tidak berjalan sangat lancar, jadi saya mencari saran dari seorang programmer senior yang terlibat dalam proyek tentang bagaimana cara mendekatinya.

Dia mengatakan bahwa saya secara drastis telah memikirkan tugas yang sedang dihadapi, dan itu karena saya belum pernah menangani proyek skala ini sebelum saya menghabiskan terlalu banyak waktu untuk memikirkan pola desain. Dalam kata-katanya yang bijak, dia mengatakan kepada saya "F * ck masa depan, bangun untuk sekarang".

Apakah ini tren yang biasanya diikuti oleh pemrogram saat melakukan proyek seperti ini? Sebagai contoh, jika Anda diminta untuk melakukan pembuktian model konsep, apakah ini merupakan tren yang khas hanya untuk menumbuhkan contoh yang bisa diterapkan secepat mungkin?

Sunting: Sehubungan dengan perdebatan yang dipicu ini, saya ingin menyebutkan bahwa situasi ini cukup ekstrem: kami memiliki tenggat waktu yang sangat ketat karena faktor-faktor di luar kendali kami (yaitu pasar yang kami tuju akan kehilangan minat jika kami tidak dapat menunjukkan kepada mereka sesuatu) dan sarannya terbukti sangat efektif untuk tugas khusus ini.

Kapten Obvious to the Rescue!

Saya akan menjadi Kapten Obvious di sini dan mengatakan bahwa ada jalan tengah yang dapat ditemukan.

Anda memang ingin membangun untuk masa depan dan menghindari mengunci diri Anda ke dalam pilihan teknologi atau desain yang buruk. Tetapi Anda tidak ingin menghabiskan 3 bulan merancang sesuatu yang seharusnya sederhana, atau menambahkan titik ekstensi untuk aplikasi cepat dan kotor yang akan memiliki masa pakai 2 tahun dan tidak mungkin memiliki proyek tindak lanjut.

Sulit untuk menemukan perbedaannya, karena Anda tidak selalu dapat memprediksi kesuksesan produk Anda dan jika Anda perlu memperpanjangnya nanti.

Bangun untuk Sekarang jika ...

• proyek ini akan dibatalkan
• proyek ini memiliki masa hidup yang singkat
• proyek tidak boleh memiliki ekstensi
• proyek tidak memiliki nilai dampak risiko (sebagian besar dalam hal gambar)

Secara umum, proyek in-house atau sesuatu yang dibangun untuk pelanggan harus dikembangkan untuk saat ini. Pastikan untuk memiliki persyaratan langsung, dan hubungkan dengan mereka sesuai kebutuhan untuk mengetahui apa yang dibutuhkan dan apa yang tidak. Tidak ingin menghabiskan terlalu banyak waktu untuk hal-hal yang "menyenangkan untuk dimiliki." Tapi jangan kode seperti babi juga.

Tinggalkan Masalah Umum untuk nanti, jika mungkin perlu dan sepadan dengan usaha:

Bangun untuk Masa Depan jika ...

• proyek akan menjadi publik
• proyek adalah komponen yang akan digunakan kembali
• proyek ini adalah batu loncatan untuk proyek lain
• proyek akan memiliki proyek tindak lanjut atau rilis layanan dengan perangkat tambahan

Jika Anda membangun sesuatu untuk umum, atau itu akan digunakan kembali dalam proyek lain, maka Anda memiliki probabilitas yang jauh lebih tinggi bahwa desain yang buruk akan kembali menghantui Anda, jadi Anda harus lebih memperhatikan hal itu. Tapi itu tidak selalu dijamin.

Pedoman

Saya akan mengatakan mematuhi prinsip-prinsip berikut ini sebaik mungkin, dan Anda harus menempatkan diri Anda dalam posisi merancang produk yang efisien dan mudah beradaptasi:

• tahu bahwa YAGNI ,
• KISS ,
• setiap kali Anda ingin menggaruk gatal dan memikirkan tambahan, tulislah. Lihatlah kembali persyaratan proyek Anda dan tanyakan pada diri Anda apakah penambahan itu prioritas atau tidak. Tanyakan apakah mereka menambah nilai bisnis utama atau tidak.

Saya tahu bahwa saya pribadi cenderung terlalu banyak berpikir dan overengineer. Sangat membantu untuk menuliskan ide dan sangat sering berpikir ulang jika saya membutuhkan fitur tambahan. Seringkali, jawabannya adalah tidak, atau, "nanti akan keren." Gagasan terakhir itu berbahaya, karena mereka tetap berada di belakang kepalaku, dan aku harus memaksakan diriku untuk tidak merencanakannya.

Cara terbaik untuk kode tanpa rekayasa ulang dan tanpa memblokir diri sendiri untuk nanti adalah fokus pada desain minimal yang baik. Memecahkan berbagai hal baik sebagai komponen yang nanti dapat memperpanjang, tetapi tanpa berpikir sudah tentang bagaimana mereka dapat diperpanjang kemudian. Anda tidak dapat memprediksi masa depan.

Buat saja hal-hal sederhana.

Dilemmata

Overengineering

Apakah ini tren yang biasanya diikuti oleh pemrogram saat melakukan proyek seperti ini?

Sial ya. Ini adalah dilema yang diketahui, dan itu hanya menunjukkan bahwa Anda peduli dengan produk tersebut. Jika tidak, itu lebih mengkhawatirkan. Ada ketidaksepakatan tentang apakah kurang selalu benar-benar lebih dan jika lebih buruk selalu benar-benar lebih baik . Anda mungkin tipe pria MIT atau New Jersey . Tidak ada jawaban yang mudah di sini.

Prototyping / Quick-n-Dirty / Less is More

Apakah ini merupakan tren yang khas hanya untuk memberikan contoh yang bisa diterapkan sesegera mungkin?

Ini adalah praktik yang lazim, tetapi bukan bagaimana sebagian besar proyek didekati. Meski demikian, prototyping adalah tren yang bagus menurut saya, tetapi satu dengan downside berarti. Dapat tergoda untuk mempromosikan prototipe cepat dan kotor ke produk aktual, atau menggunakannya sebagai dasar untuk produk aktual di bawah tekanan manajemen atau kendala waktu. Saat itulah prototipe dapat kembali menghantui Anda.

Ada keuntungan yang jelas untuk membuat prototipe , tetapi juga banyak potensi untuk penyalahgunaan dan penyalahgunaan (banyak kebalikan dari keuntungan yang sebelumnya tercantum sebagai hasil).

Kapan Menggunakan Prototyping?

Ada petunjuk tentang jenis proyek terbaik untuk menggunakan prototyping :

[...] prototyping paling bermanfaat dalam sistem yang akan memiliki banyak interaksi dengan pengguna.

[...] prototyping sangat efektif dalam analisis dan desain sistem on-line, terutama untuk pemrosesan transaksi, di mana penggunaan dialog layar jauh lebih banyak bukti. Semakin besar interaksi antara komputer dan pengguna, semakin besar manfaatnya [...]

"Salah satu penggunaan prototyping cepat yang paling produktif hingga saat ini adalah sebagai alat untuk rekayasa kebutuhan pengguna yang berulang dan desain antarmuka manusia-komputer."

Di samping itu:

Sistem dengan sedikit interaksi pengguna, seperti pemrosesan batch atau sistem yang sebagian besar melakukan perhitungan, hanya mendapat sedikit manfaat dari pembuatan prototipe. Terkadang, pengkodean yang diperlukan untuk menjalankan fungsi sistem mungkin terlalu intensif dan potensi keuntungan yang dapat diberikan prototipe terlalu kecil.

Dan jika Anda memiliki monster hijau, pastikan untuk menyimpan prototipe sesuai anggaran ...

Ketika Anda memulai pemrograman, semuanya adalah bukti konsep meskipun hanya untuk Anda sendiri. Ada kasus ketika sebuah ide membutuhkan sesuatu yang cepat dan kotor atau prototipe karena waktu adalah faktor kunci. Ketakutan besar di antara pengembang adalah para pemangku kepentingan berpikir aplikasi kecil ini siap untuk diproduksi atau Anda harus dapat menambahkan fitur pada tingkat yang sama selamanya. Anda mengerjakan proyek besar dan menemukan ini bukan masalahnya.

Proyek besar biasanya memiliki persyaratan yang lebih kompleks, sehingga ada godaan untuk mencoba dan mengimplementasikan desain yang rumit. Anda akan menghabiskan banyak waktu membaca, meneliti, dan mencoba menerapkannya. Ini bisa menjadi pemborosan waktu yang besar, tetapi itu semua adalah bagian dari pembelajaran dan mendapatkan pengalaman. Mengetahui kapan harus menggunakan desain tertentu itu sulit dan biasanya disertai dengan pengalaman. Saya mencoba "itu" pada proyek "ini" dan itu tidak berhasil tetapi sekarang saya melihat itu harus berhasil "di sini".

Anda harus merencanakan dan merencanakan banyak hal, tetapi jangan lakukan semuanya sekaligus. Itu pasti tidak harus dilakukan di awal. Saya lebih suka melihat seseorang membuat proyek besar pertama mereka seperti ini:

1. Rancang dan diskusikan sedikit.
2. Tulis banyak kode yang melakukan sesuatu.
3. Kenali masalah dan STOP coding.
4. Serius dengan desain dan jangan khawatir tentang kehilangan momentum atau kode-mojo Anda dan abaikan manajer proyek (Anda membantunya.).
5. Dapatkan proyek di bawah kendali. Perbaiki kekacauan Anda. Pastikan semua orang mengerti rencananya. Jaga agar proyek tetap terkendali.

Terkadang Anda menekan salah satu fitur yang benar-benar membuat Anda khawatir tentang bagaimana mengimplementasikannya dalam basis kode yang ada. Ini bukan saatnya untuk "hanya membuatnya bekerja". Saya memiliki seorang bos yang berkata, "Kadang-kadang Anda harus mengambil kursi daripada palu." Dia mengatakan hal ini kepada saya setelah dia menangkap saya "berpikir" di meja saya. Tidak seperti banyak bos, dia tidak menganggap saya bermain-main dan memastikan saya mengerti dia ingin saya melakukan lebih banyak. Jenius.

Pada akhirnya, kode Anda adalah desain. Ini didukung oleh dokumen, diagram, pertemuan, email, diskusi papan tulis, pertanyaan SO, argumen, cussing, kemarahan dan obrolan tenang sambil minum kopi. Ada titik di mana Anda tidak dapat mendesain lagi dan berisiko harus membuang lebih banyak waktu desain karena kekurangan yang hanya akan Anda temukan ketika mencoba menulis kode. Selain itu, semakin banyak kode yang Anda tulis, semakin besar peluang Anda untuk memperkenalkan cacat desain yang tidak dapat Anda kode jalan keluarnya. Saatnya buang air besar lagi.

Apakah programmer biasanya membangun sesuatu yang berfungsi sekarang tanpa memikirkan masa depan?

Iya.

Haruskah mereka melakukannya?

Tidak.

Pada pandangan pertama akan terlihat bahwa "memikirkan masa depan" melanggar prinsip-prinsip desain yang sudah ada seperti KISS dan YAGNI , yang mengklaim bahwa tidak boleh ada implementasi apa pun yang tidak diperlukan saat ini.

Tapi sebenarnya tidak. Berpikir tentang masa depan berarti merancang perangkat lunak yang sederhana, dapat dikembangkan, dan dikelola. Ini sangat penting untuk proyek jangka panjang. Fitur-fitur baru akan dibutuhkan seiring waktu, dan memiliki desain yang solid akan membuatnya lebih mudah untuk menambahkan potongan-potongan baru.

Bahkan jika Anda tidak akan mengerjakan proyek setelah Anda menyelesaikannya, Anda harus tetap mengembangkannya dengan cerdas. Ini pekerjaan Anda, dan Anda harus melakukannya dengan baik, setidaknya agar tidak lupa bagaimana pekerjaan yang baik dilakukan.

Pengembang yang gesit memiliki pepatah, "Anda Tidak Akan Membutuhkannya (YAGNI)" yang mendorong Anda mendesain apa yang Anda butuhkan sekarang daripada apa yang menurut Anda mungkin Anda butuhkan di masa depan. Untuk memperluas desain agar berfungsi di masa mendatang, rute yang disarankan adalah ke refactor.

Aspek penting untuk ini adalah untuk menjaga persyaratan untuk produk Anda dalam pikiran Anda saat Anda mendesain, dan untuk memastikan bahwa Anda tidak merancang untuk sekelompok persyaratan yang mungkin terjadi di masa depan.

Ada sesuatu yang bisa dikatakan untuk pengembang yang dapat memikirkan dua atau tiga iterasi di masa depan - mereka tahu klien atau domain mereka dengan sangat baik sehingga mereka dapat mengantisipasi kebutuhan di masa depan dengan tingkat akurasi yang tinggi dan membangun untuk mereka, tetapi jika Anda tidak yakin, lebih baik tidak menghabiskan terlalu banyak waktu untuk hal-hal yang Anda atau klien tidak butuhkan.

Apakah ini tren yang biasanya diikuti oleh pemrogram saat melakukan proyek seperti ini?

Saya menduga apa yang mentor Anda maksudkan adalah bahwa Anda seharusnya tidak membangun kompleksitas tambahan apa pun yang mungkin tidak diperlukan oleh solusi akhir.

Terlalu mudah untuk berpikir bahwa aplikasi harus melakukan ini dan itu dan mendapatkan secara besar-besaran dialihkan.

Adapun pola desain, perlu diingat bahwa mereka adalah sarana untuk mencapai tujuan. Jika Anda menemukan dengan pengalaman bahwa pola desain tertentu tidak cocok meskipun firasat Anda sebelumnya, maka ini bisa menunjukkan bau kode.

Sebagai contoh, jika Anda diminta untuk melakukan pembuktian model konsep, apakah ini merupakan tren yang khas hanya untuk menumbuhkan contoh yang bisa diterapkan secepat mungkin?

Layak untuk dikemudikan sebelum proyek dimulai untuk mengetahui tonggak apa yang ada dan apakah mereka ingin melihat sedikit dari segalanya (potongan vertikal) atau hanya setiap bagian secara terperinci saat Anda mengembangkannya (potongan horizontal). Sebagai bagian dari desain awal, saya merasa layak menaiki seluruh aplikasi sehingga meskipun kode tidak ditulis, Anda dapat melakukan tampilan helikopter dari seluruh hal atau menyelam dalam-dalam pada area tertentu.

Dia mengatakan bahwa saya secara drastis telah memikirkan tugas yang sedang dihadapi, dan bahwa karena saya tidak pernah menangani proyek besar seperti ini, saya telah menghabiskan terlalu banyak waktu untuk memikirkan pola desain. Dalam kata-katanya yang bijak, dia mengatakan kepada saya "F * ck masa depan, bangun untuk sekarang".

Saya pikir itu sedikit mentalitas koboi dari pengembang lain. Versi modern dari kutu buku tangguh yang hanya "melakukannya sekarang". Ini menjadi tema populer di kalangan pemula dan tidak ada terima kasih kepada orang-orang di Facebook untuk memulai kalimat "menyelesaikannya lebih baik daripada melakukannya dengan benar".

Ini menarik. Ini menggembirakan dan menawarkan visi pengembang berdiri di sekitar konsol bertepuk tangan ketika mereka meluncurkan proyek besar mereka ke dunia tepat waktu, sesuai anggaran dan semua karena mereka tidak melakukan rekayasa apa pun.

Ini adalah fantasi idealis dan kehidupan tidak berjalan seperti ini.

Orang bodoh akan terburu-buru ke dalam sebuah proyek dengan berpikir dia hanya bisa "melakukannya" dan menyelesaikannya. Keberhasilan akan menguntungkan pengembang yang mempersiapkan diri menghadapi tantangan yang tak terlihat, dan memperlakukan profesinya seperti keahlian yang baik.

Setiap pengembang senior dapat mengkritik, mengutuk dan mengeluh - dan kebanyakan melakukannya!

Sementara dia memberi tahu Anda bahwa Anda "terlalu memikirkan" proyek tersebut. Saya mengucapkan selamat kepada Anda untuk benar-benar "berpikir" dulu. Anda telah mengambil langkah pertama untuk menjadi pengembang yang lebih baik daripada orang lain.

Apakah ini tren yang biasanya diikuti oleh pemrogram saat melakukan proyek seperti ini? Sebagai contoh, jika Anda diminta untuk melakukan pembuktian model konsep, apakah ini merupakan tren yang khas hanya untuk menumbuhkan contoh yang bisa diterapkan secepat mungkin?

Itulah bukti konsep. Ini adalah upaya untuk menumbuk sesuatu secepat mungkin sehingga orang dapat mengambil langkah mundur dan melihatnya. Ini dilakukan untuk mencegah kesalahan, penyesatan dan waktu / uang yang terbuang.

Ada banyak jenis pembuktian konsep. Anda dapat membangun sesuatu yang dibuang ke sampah saat selesai, atau Anda dapat membangun sesuatu yang mewakili titik awal untuk proyek. Itu semua tergantung pada apa yang Anda butuhkan, dan seberapa dekat konsepnya dengan produk akhir.

Ini juga merupakan kesempatan untuk menunjukkan ide Anda. Ada saat-saat ketika saya mempresentasikan prototipe yang membawa berbagai hal ke tingkat yang tidak mereka harapkan.

Desain biasanya bersifat terbuka sehingga terlalu mudah untuk menerapkan terlalu banyak atau terlalu sedikit. Dan Anda akan tahu jumlah yang benar hanya setelah proyek selesai atau dibuang. Atau bahkan belum.

Tidak ada resep umum untuk sukses, tetapi Anda bisa belajar mengenali yang ekstrem. Desain lengkap segala sesuatu di depan hampir tidak pernah berhasil di luar hal-hal sepele. Tidak apa-apa untuk meninggalkan komponen untuk disempurnakan dan hanya memiliki perasaan bahwa itu dapat dilakukan, atau ada cara untuk menemukan masalah lebih awal.

Anda dapat melihat bagaimana pengembangan bertahap bekerja jika Anda tidak terbiasa. Metode yang sukses biasanya berulang pada satu tingkat atau lebih, mencari umpan balik yang ketat dan tumbuh pada beberapa kerangka.

Ada beberapa alasan bagus untuk mendengarkan saran untuk berhenti merencanakan dan mulai menulis kode;

1. Setelah hanya 18 bulan sebagai pengembang, kecil kemungkinan Anda dapat mengantisipasi masa depan dengan cukup baik untuk merencanakannya, tidak peduli IPK kuliah Anda. Ini adalah sesuatu yang sangat sulit untuk dipahami oleh pengembang yang cerdas tetapi tidak berpengalaman, karena ini semua tentang tidak mengetahui apa yang tidak Anda ketahui. Tangan lama mungkin telah mengenali kelemahan ini dalam penglihatan Anda, dan dengan bijak mendorong Anda untuk masuk ke dalamnya dan melakukan yang terbaik.

2. Pengembang muda mungkin menjadi terobsesi dengan menyempurnakan desain sebelum mereka mulai membuat kode. Mereka mungkin menutupi rasa takut menulis kode (kecemasan kinerja), atau mungkin memiliki blok coder (seperti blok penulis). Mereka sibuk dalam desain karena tidak ada hasil kerja yang diperlukan. Dev muda mungkin akan menanggapi dengan marah saran bahwa mereka "takut" pada apa pun. Mungkin di akhir proyek mereka akan menyadari bahwa mereka ada. Saran untuk tidak khawatir dan mendapatkan kode merupakan satu-satunya obat yang dikenal untuk blok coder. Tangan tua mungkin dengan bijak menawarkan saran ini.

3. Di hadapan kendala jadwal yang keras, peluang Anda untuk menyelesaikan proyek sama sekali terbatas. Rencanakan terlalu lama, dan betapapun bagusnya rencananya, Anda tidak dapat melaksanakannya tepat waktu, dan Anda tidak pernah sampai ke pasar. Mulai meretas dari awal, dan mungkin Anda akan beruntung dan menjadi yang pertama kali. Anda mengirimkan produk secara ajaib. Atau, mungkin Anda tidak seberuntung itu, dan mengirimkan sepotong terak setengah matang tetapi masuk ke pasar tepat waktu dan Anda belajar sesuatu. Atau mungkin Anda gagal. Tetapi "mungkin Anda gagal" masih peluang yang lebih baik daripada "tidak pernah sampai ke pasar" karena Anda berencana terlalu lama. Pemahaman kuncinya adalah bahwa peluang Anda terbatas sejak awal, sehingga Anda tidak kehilangan apa-apa dengan meretas. Manajer Anda mungkin tahu ada sedikit peluang untuk berhasil, dan menetapkan sumber daya junior hanya sebagai latihan belajar. Kita belajar lebih baik dari kegagalan daripada dari kesuksesan. Pernahkah Anda bertanya, "Kapan saya bisa memiliki seluruh proyek?"

Dibutuhkan pengembang yang cukup introspektif dan bebas ego untuk melihat ketidaksempurnaan mereka sendiri, jadi bermeditasi sebentar sebelum membaca sisanya, jangan sampai Anda memberi diri Anda alasan untuk mengabaikan kelemahan Anda sendiri ...

Tidak setiap pengembang pandai menganalisis, merencanakan, dan tugas-tugas lain yang membutuhkan pemikiran. Pikiran itu sulit dan menjijikkan. Ini membutuhkan semacam keringat mental yang membuat Anda tidak nyaman dan lelah setelah seharian bekerja. Hanya saja tidak menyenangkan seperti masuk ke keadaan aliran dengan dua kaleng Rakasa dan batu Anda muncul dengan keras dan coding, coding, coding. Pengembang yang tidak suka berpikir akan menolak gagasan bahwa perencanaan adalah ide yang baik. Mereka merekomendasikan metodologi dev yang tidak memerlukan perencanaan di muka. Mereka menyukai perusahaan dan manajer yang tidak menekankan perencanaan. Mereka condong ke pekerjaan di mana biaya tidak perencanaan tidak terlalu tinggi. Mereka menghargai sesi pengkodean sepanjang malam dan memberikan perbaikan terbaru kepada pelanggan yang seluruh bisnisnya rusak karena bug.

Beberapa pengembang bahkan menyadari bahwa membuat sesuatu berfungsi cukup baik untuk didemonstrasikan berarti membuatnya berfungsi sepenuhnya dan dalam keadaan apa pun dapat ditangguhkan, dan mungkin bahkan didorong ke pengembang lain, sementara mereka menerima pujian untuk "menyelesaikan pekerjaan" pada awalnya.

Ada beberapa manajer yang tidak dapat melihat sendiri trennya sampai tren tersebut sudah pecah di Facebook. Alih-alih menemukan pekerjaan mengelola toko ban diskon, para manajer ini menjadikannya masalah Anda bahwa mereka membutuhkan kode tersebut berjalan pada hari Jumat. Mereka tidak ingin mendengar bahwa Anda perlu merancang API atau menguji apakah algoritme Anda dapat diskalakan. Ini hanya omong kosong teknologi bagi mereka. Mereka akan mendorong Anda untuk membuat kode karena hanya itu yang mereka pahami tentang perangkat lunak saat mereka menulis skrip perl untuk membantu pelanggan mentransfer file mereka. (Mereka memiliki gelar 'insinyur perangkat lunak' dalam pekerjaan penjualan pertama mereka. Siapa yang tahu perangkat lunak akan sangat membosankan dan sulit?)

Tunjukkan kode Anda dan saya akan memberi tahu Anda siapa Anda

Kode Anda adalah kartu kunjungan Anda. Jika Anda menulis kode yang berantakan, apa yang memberi tahu Anda tentang diri Anda kepada orang lain? Coba pikirkan itu. Setiap kali kita menemukan di kantor sebuah fragmen kode yang sangat buruk, kita bertanya pada diri kita sendiri, siapa yang telah menulisnya dan bagaimana dia melewati universitas?

Anda menjadi apa yang Anda kode

Kode Anda adalah program seumur hidup Anda.

Seorang programmer menulis kode buruk seperti menari penari balet di klub striptis

Beberapa orang tidak peduli menari di klub striptis. Tetapi jika mereka adalah penari tinggi, mereka menyia-nyiakan keterampilan mereka. Jika Anda penari yang buruk tetapi memiliki kaki yang bagus, Anda dapat menelanjangi banyak orang.

Akhirnya, Anda harus membaca novel Gogol 'The Portrait', dan Anda harus diingatkan oleh kisah tokoh utama. Teman Anda mirip dengan pria dari potret. Dia memikat Anda dengan uang, tetapi Anda akan membayar mahal untuk itu.