Bagaimana jika saya tidak punya ide bagus untuk mengimplementasikan fitur? [Tutup]

32

Saya sedang mengerjakan aplikasi saya sendiri dan saya mandek. Saya harus mengimplementasikan fitur tetapi saya tidak dapat menemukan pendekatan yang baik untuk mengimplementasikan fitur ini. Saya memikirkannya selama beberapa hari, dan tidak ada pikiran yang baik datang. Mencari di internet tidak memberi saya inspirasi.

Saya perlu pindah, tetapi saya ingin tahu, apa yang terbaik:

Pikirkan lebih banyak, tunggu lebih banyak, dan terus mencari pendekatan terbaik
Berhentilah membuang-buang waktu dan mulailah dengan desain yang buruk, mencakup semuanya dengan tes

Apa yang kamu pikirkan? Seperti yang saya katakan sebelumnya, saya sedang mengerjakan aplikasi saya sendiri. Saya tidak punya tenggat waktu, tetapi saya juga ingin menyelesaikan pengkodean aplikasi secepatnya.

design

— pengguna21974
sumber

2

kemungkinan duplikat Prototyping vs. Clean Code pada tahap awal . Lihat juga: Mengembangkan dengan cepat dan bermasalah, kemudian memperbaiki kesalahan atau lambat, hati-hati untuk setiap baris kode?

— nyamuk

12

@gnat: Pertanyaan-pertanyaan lain ini berhubungan dengan situasi di mana para penanya sudah tahu cara mengimplementasikan beberapa fitur secara bersih, tetapi mungkin ingin mengorbankan desain yang baik untuk menjadi "cepat dan kotor". Pertanyaan ini, bagaimanapun, menggambarkan situasi yang berbeda, ini adalah tentang pemecahan masalah secara umum ketika Anda tidak menemukan titik yang baik untuk memulai sama sekali, jadi itu adalah IMHO tidak ada duplikat.

— Doc Brown

Catatan: jika aplikasi ini sukses, Anda tidak akan pernah "menyelesaikan pengkodean" dan fitur akan tetap didesain ulang. Jadi saya akan menerapkannya dengan cara terbaik yang saya bisa sekarang.

— ren

41

Selain berbicara kepada orang-orang tentang hal itu (pertanyaan menunjukkan Anda tidak memiliki rekan kerja di proyek), saya sering menemukan pendekatan yang baik untuk fokus pada hal-hal yang dapat saya lakukan.

Biasanya ada beberapa bagian dari kode yang saya tahu harus saya tulis. Hal-hal yang saya belum tahu cara menulis, kemudian digantikan oleh bertopik yang baik mengembalikan hasil dummy, atau menggunakan perkiraan yang cukup baik untuk menguji sisanya.

Ini membuat Anda tetap produktif. Dan pada saat Anda perlu mengimplementasikan bagian yang hilang, Anda memiliki antarmuka. Dan Anda telah menulis banyak kode di sekitar masalah, di domain masalah yang sama, yang biasanya membantu saya menghasilkan ide: Anda tahu persis apa yang harus Anda hasilkan, dan input apa yang tersedia jika membantu menyelesaikan masalah . Juga, seringkali kesimpulannya adalah bahwa bagian yang hilang tidak perlu mencakup semua seperti yang dipikirkan sebelumnya.

— jdv-Jan de Vaan
sumber

6

Kelemahan dari penulisan kode yang paling berisiko dan paling tidak dipahami adalah bahwa Anda mungkin menemukan bahwa tidak mungkin untuk menyelesaikan masalah, atau hanya mungkin untuk menyelesaikannya dengan perubahan besar pada arsitektur program, yang menyebabkan banyak usaha yang sia-sia.

— Rich Smith

1

Kelemahan lain dari pendekatan ini adalah kadang-kadang membawa Anda ke, "Saya bisa menyelesaikan masalah X. Yang tersisa adalah melakukan Y." padahal kenyataannya, Y tidak layak dan solusi sebenarnya adalah Z.

— Brian

@RichSmith, Brian: Itu terjadi, meskipun jarang jika Anda bertanya kepada saya. Ini kemudian dapat memberi Anda pemahaman yang lebih baik tentang mengapa bagian yang hilang begitu sulit, yang meningkatkan perkiraan Anda. Dan saya tidak akan menyarankan untuk memasukkan pekerjaan berminggu-minggu berdasarkan pada pembagian tanggung jawab yang spekulatif dan sewenang-wenang.

— jdv-Jan de Vaan

itu bisa diperdebatkan apakah itu kerugian atau tidak. apakah waktu Anda akan lebih baik dihabiskan untuk tidak menjelajahi masalah sama sekali? atau dengan Anda duduk-duduk menebak apa yang akan berhasil? Saya pikir ini praktik yang baik untuk menulis prototipe cepat, mencoba berbagai hal dan gagal dengan cepat. itu satu-satunya cara untuk mengetahui dengan pasti dan mendapatkan pengalaman untuk situasi serupa di masa depan

— sara

14

Jika pencarian gagal, Anda selalu bisa menerapkan menggunakan ide pertama (belum tentu yang terbaik) yang Anda dapatkan, dan kemudian refactor nanti ketika Anda menemukan pendekatan yang tepat.

Ini adalah pendekatan yang tepat, karena bahkan jika Anda menemukan sesuatu yang tampak seperti ide yang bagus, itu bisa berubah menjadi buruk nantinya. Atau mungkin bagus saat itu, tetapi nanti Anda menemukan sesuatu yang jauh lebih baik. Maka Anda masih harus refactor.

Saat melakukan ini, pastikan untuk merancang dan mengimplementasikan sedemikian rupa sehingga mudah untuk di refactor. Jika Anda melakukannya dengan benar, Anda harus mengubah hanya bagian yang bermasalah, dan tidak memulai dari awal.

— BЈовић
sumber

1

Tampaknya diasumsikan dalam posting ini, tetapi saya ingin menambahkan bahwa sangat penting bagi Anda untuk menulis kode dengan cara yang mudah untuk faktor ulang.

— c_maker

@ c_maker Ya, tentu saja. Kalau tidak, tidak masuk akal untuk menulis ulang semuanya nanti dari awal. Saya akan menambahkannya ke jawabannya. terima kasih

— BЈовић

10

Bagaimana dengan bertanya kepada orang lain? Misalnya, Anda bisa menggambarkan masalah Anda di sini, atau, jika ini lebih merupakan masalah implementasi, di stackoverflow.com, dan minta ide. Kadang-kadang itu akan membantu Anda jika Anda mulai menuliskan masalahnya, bahkan jika Anda tidak mendapatkan jawaban yang baik.

— Doc Brown
sumber

Jika itu adalah Antarmuka Pengguna yang merupakan masalah, ada juga ux.stackexchange.com

— Rob Church

jika Anda bertanya pada SO maka jawaban akan dilindungi hak cipta di bawah Creative Commons, dan tergantung pada proyeknya, kode itu bisa tidak dapat digunakan.

— smcg

2

Nasihat dapat memiliki hak cipta? Tentunya penulis akan menggunakannya sebagai tutorial, bukan copy / paste?

— grizwako

@smcg: topiknya dibahas di sini: meta.stackexchange.com/questions/12527/… - Tapi jujur, jika itu benar-benar menjadi masalah, saya pikir kita bisa mengelak dari ini dengan cara yang disarankan GrizzLy.

— Doc Brown

@DocBrown IANAL jadi saya tidak bisa mengatakan dengan pasti apakah itu akan bertahan, tetapi kadang-kadang ada baiknya untuk berhati-hati.

— smcg

2

Beberapa ide:

Brainstorm
Tulis setiap ide bodoh yang Anda miliki (di atas kertas atau papan tulis). Singkirkan yang Anda yakin tidak akan berhasil. Tetap menulis. Sertakan solusi untuk masalah dunia nyata yang berpotensi terkait. Misalnya, apakah mencampur cat, atau meletakkan paku di dinding, atau mengganti oli Anda bisa menyelesaikan perumpamaan dunia nyata?
Mintalah bantuan untuk
Google, tanyakan di sini, tanyakan teman-teman geek Anda, dll.
Memecahkan masalah terkait
Anda tidak bisa memecahkan yang masalah, tapi dapat Anda memecahkan satu lebih sederhana? Atau yang terkait, sama rumitnya? Lakukan itu. Kemudian buat perubahan kecil dan individual untuk membawa solusi Anda lebih dekat ke solusi yang diinginkan.
Mulailah menulis dari luar di
Terlepas dari apakah antarmuka Anda adalah layanan web, halaman web, bentuk asli, kamera, keyboard, monitor, atau apa pun , ada antarmuka. Tulis beberapa baris kode / pseudocode untuk membuat antarmuka berfungsi. Gunakan metode ajaib yang belum ada. Secara rekursif melakukan hal yang sama untuk setiap metode magis yang tidak ada. Optimalkan nanti.

— svidgen
sumber

2

Tidak ada yang salah dengan solusi yang buruk. Sering kali Anda hanya tidak cukup tahu tentang domain masalah pada saat itu. Pergi dengan solusi yang buruk membuat Anda melanjutkan dan mempelajari lebih lanjut tentang masalahnya. Maka Anda masih bisa kembali dan memperbaiki solusi pertama Anda.

— Oliver Weiler
sumber

1

Saya selalu mencoba dan melihatnya dari sudut pandang pengguna akhir. Sangat mudah untuk memikirkan ide "keren" sebagai pengembang yang dapat Anda habiskan bertahun-tahun untuk bekerja yang sebenarnya menambah sangat sedikit pada aplikasi Anda.

Idealnya Anda ingin memetakan semua fitur di aplikasi Anda dan memprioritaskannya sesuai dengan manfaatnya bagi pengguna akhir, secara pribadi saya menggunakan MOSCoW , meskipun selama Anda menjaga metode penentuan prioritas Anda, hal yang sama dapat dilakukan sesederhana 1 - 5.

Setelah itu jika Anda masih menemukan bahwa fitur ini merupakan bagian penting dari aplikasi Anda, maka seperti yang telah dikatakan orang, tanyakan! Saya tidak berpikir saya pernah mengalami masalah yang akhirnya belum diselesaikan oleh seorang kolega atau orang-orang baik di Stackoverflow.

— Tuan Fldig
sumber

Keren, karena saya dari Moskow :)

— user21974

Ini dia pertanda!

— Mrk Fldig

1

Pendapat saya adalah: jangan pernah menulis kode yang hanya berfungsi! Seharusnya sangat sulit untuk refactor di masa depan.

Ini adalah pendekatan yang sangat umum untuk pengembang (dan tentu saja PM atau bos). Saya mendengar banyak waktu "hanya membuatnya bekerja" atau "Saya akan memperbaikinya nanti" (nanti ketika ??? tidak pernah!) Tetapi, saya pikir kualitas bukanlah sesuatu yang tidak dapat Anda peroleh di tengah proyek.

Saran saya adalah, berhentilah memikirkan masalah Anda untuk sementara waktu .... lakukan sesuatu yang lain, dan, kadang-kadang, solusinya muncul begitu saja.

Btw, meminta seorang kolega benar-benar cara yang bagus untuk menyelesaikan masalah Anda.

— Andrea Girardi
sumber