Konsepsi dan desain sebelum pengkodean: berapa banyak ini benar? [Tutup]

Saya belajar di sekolah dan juga membaca di mana-mana bahwa metodologi pengembangan yang baik membutuhkan konsepsi dan desain sebelum mengkode dengan benar.

Itu bukan informasi baru bahkan untuk programmer pemula. Namun, saya bertanya-tanya apakah ini saran yang baik karena sejak saya mulai mengembangkan dalam beberapa bahasa pemrograman saya tidak pernah berhasil merancang dan memahami semuanya sejak awal.

Maksud saya, saya selalu melebur desain, konsepsi dan pemrograman. Apakah saya pengembang terburuk di dunia, atau apakah gagasan yang kita pelajari di sekolah hanyalah dogma agama lama yang tidak berarti ?

Bagaimana kita bisa membayangkan dan merancang sesuatu yang tidak pernah kita alami dan programkan sebelumnya? Bukankah itu konyol? Bukankah pemrograman memimpin konsep dan desain saja?

Saya pikir jawabannya adalah: Rencanakan sebanyak mungkin, tetapi tidak lebih dari itu.

Hanya sedikit orang yang berbicara menentang keutamaan perencanaan, tetapi sebagian besar perdebatan mengabaikan aspek penting. Perencanaan hanya berfungsi sejauh Anda memiliki keterampilan untuk membuat rencana yang baik, keterampilan itu cenderung disertai dengan pengalaman. Jika Anda tidak memiliki banyak pengalaman, rencana apa pun yang Anda buat kemungkinan akan memiliki masalah jumlah yang wajar, ini berarti bahwa untuk membuat suatu produk yang bukan total bencana, rencana tersebut harus direvisi secara besar-besaran selama pengembangan, jika paket terperinci maka ini kemungkinan akan membatalkan banyak detail, atau lebih buruk, Anda akan mencoba untuk menjaga penyesuaian minimum agar dapat mengikuti rencana.

Beberapa hal pasti memerlukan perencanaan, dan jika Anda tidak memiliki keterampilan untuk membuat tingkat rencana yang diperlukan, maka satu-satunya jalan ke depan yang dapat saya bayangkan adalah membuat prototipe, menulis kode hanya untuk mendapatkan pengalaman dengan tugas yang diperlukan untuk membuat rencana yang memadai .

Apakah Anda siap untuk menulis kode produksi, setelah Anda mencapai tingkat perencanaan maksimum, tidak ada lagi yang bisa dilakukan selain coding. Mungkin itu akan menjadi bencana, tetapi itu adalah pengalaman belajar yang baik, dan Anda akan jauh lebih siap untuk membuat rencana revisi.

Itu benar sekali. Semakin besar dan kompleks persyaratannya, semakin benar hal ini.

Untuk aplikasi konsol kecil untuk menghitung urutan Fibonacci, Anda mungkin tidak perlu lebih dari beberapa menit untuk berpikir tentang bagaimana menyusun algoritma dan UI (yang, ya, bisa berupa stdin dan stdout).

Tetapi bagaimana dengan platform perdagangan real-time yang diharapkan dapat melakukan jutaan transaksi per detik, didistribusikan secara global dan itu membutuhkan 99,9999 waktu kerja dan 100% kebenaran? Apakah Anda hanya melompat ke pengkodean itu?

Ada banyak opsi lain di antara kedua ekstrem ini.

Lihatlah proyek Euler . Selesaikan beberapa masalah, dalam urutan yang disajikan. Anda akan menemukan bahwa untuk menyelesaikan beberapa masalah dalam waktu yang wajar, Anda harus benar-benar berpikir sebelum beralih ke kode.

Jika Anda tidak perlu meluangkan waktu untuk berpikir dan merancang program Anda sebelum mulai membuat kode, Anda sedang mengerjakan hal-hal sepele atau melewatkan sesuatu yang lebih besar.

Saya tidak pernah berhasil mendesain dan memahami segalanya sejak awal

Tidak ada yang melakukan apa pun kecuali masalah yang paling sepele. Sekali lagi, semakin besar dan kompleks proyek, semakin benar hal ini - desain akan memiliki kesalahan, hal-hal yang diabaikan dll ...

Seni dalam merancang di tingkat tinggi terlebih dahulu, melihat apakah potongan-potongan besar cocok. Kemudian dapatkan daftar prioritas - mulai bekerja pada yang paling penting / infrastruktur terlebih dahulu. Lalu kami pergi dan memecah potongan-potongan yang lebih besar menjadi yang lebih kecil, memastikan setiap bagian yang lebih besar terdiri dari potongan-potongan yang masuk akal.

Ini membutuhkan waktu dan usaha - dan mungkin tidak lengkap atau sepenuhnya benar di awal.

Tapi inilah mengapa ini disebut soft -ware dan bukan hard -ware. Ini lunak dan dapat diubah.

Saya belajar di sekolah dan juga membaca di mana-mana bahwa metodologi pengembangan yang baik membutuhkan konsepsi dan desain sebelum mengkode dengan benar.

Ini benar.

Namun, saya bertanya-tanya apakah ini saran yang baik karena sejak saya mulai mengembangkan dalam beberapa bahasa pemrograman saya tidak pernah berhasil merancang dan memahami semuanya sejak awal.

Dan ini masalahnya.

Untuk sebagian besar masalah non-sepele, Anda perlu melakukan beberapa pemikiran untuk mencari tahu bagaimana hal-hal akan bekerja - bagaimana hal-hal akan cocok bersama. Paradoksnya, untuk sebagian besar masalah non-sepele, tidak mungkin Anda bisa merencanakan semuanya . Terlalu banyak yang tidak diketahui untuk Anda pertanggungjawabkan, terlalu banyak perubahan yang akan terjadi selama pengembangan. Agile telah mendapatkan daya tarik yang dimilikinya karena ia menerima bagian kedua dari kesepakatan ini: orang tidak mahatahu dan perubahan adalah konstan.

Jadi memang benar bahwa Anda perlu melakukan desain sebelumnya, tetapi juga benar bahwa tidak mungkin hanya merancang sebelumnya.

Anda benar-benar harus memiliki beberapa desain sebelum pengkodean.

Alasannya cukup mudah - jika Anda tidak memiliki desain, Anda tidak tahu apa yang Anda buat .

Anda benar-benar harus memiliki beberapa kode sebelum desainnya final.

Alasannya cukup mudah - desain akan berubah, dan pengembangan bagian dari desain akan mengungkapkan pertanyaan, peluang, dan tantangan yang sulit diantisipasi tanpa mulai mengerjakan solusinya.

Pembangunan itu berulang.

Apakah dengan rencana atau tidak, apakah tim menyadarinya atau tidak, setiap proyek perangkat lunak dilakukan secara iteratif - bagian dari pekerjaan diselesaikan, dan kemudian dievaluasi, dan evaluasi mengarah pada perubahan dalam bagaimana sisa pekerjaan dilakukan.

Cobalah lebih dari satu pendekatan.

Dibutuhkan latihan dan pengalaman untuk mengetahui cara terbaik untuk menyeimbangkan desain di muka dengan membuat kode. Ini adalah keterampilan yang hampir tidak ada yang dikuasai dan setiap proyek akan memiliki cita-cita yang berbeda (pertimbangkan untuk merancang alat kecil untuk Anda gunakan sendiri versus tim yang menciptakan produk besar, rilis tunggal seperti video game utama).

Saya telah merancang dan mengamati orang lain mendesain banyak sistem di masa lalu dan saya telah melihat prosesnya berkembang dalam banyak cara berbeda, tetapi apa yang saya temukan umum adalah bahwa arsitektur awal setidaknya harus merencanakan keberadaan sebagian besar fitur utama.

Sebagai contoh, saya telah melihat sistem kontrol HVAC yang tidak memiliki konsep bangunan, lantai, kamar dll yang dilengkapi dengan itu dan hasilnya jelek seperti yang mereka datang. Atau perangkat musik seluler yang dibuat dari komponen yang lebih cocok untuk arloji saku Anda (non-pintar). Tidak perlu dikatakan bahwa produk akhir dalam kedua kasus itu bukan favorit pelanggan.

Ketika Anda mengatakan "konsepsi" itu hanya satu langkah dari "ide" dan sebuah konsep bisa sangat kabur. Bisnis biasanya peduli dengan konsep. Pelanggan biasanya peduli tentang UX - sebuah konsep yang diwujudkan dengan cara yang mudah dan menyenangkan untuk digunakan dan membawa nilai melalui penggunaannya.

Anda harus melakukan "konsep" sebelum pemrograman apa pun, saya tidak dapat membayangkan diri saya membuka studio visual (atau IDE pilihan Anda) dan secara acak menulis kode, untuk melihat ke mana ia pergi.

Anda mungkin tidak melakukan desain yang lengkap (dan Anda tidak seharusnya) sebelum pengkodean tetapi Anda harus memiliki sketsa kasar tentang apa yang akan menjadi alur kerja pengguna.

Desain dan pengkodean UX cukup sering saling menguntungkan satu sama lain, Anda mungkin akan dipaksa untuk menggunakan beberapa pendekatan Agile untuk apa pun kecuali proyek terkecil sebagai cara untuk memasukkan fakta ini ke dalam cara Anda mendekati pekerjaan. Jadi jangan berpikir Anda adalah programmer terburuk jika Anda tidak bisa melihat semuanya sekaligus - tidak ada yang bisa dan orang-orang yang berpikir mereka bisa menjadi orang-orang yang cukup mengabaikan masalah sehingga mereka dapat mengklaim bahwa mereka memiliki program yang lengkap gambar.

Salah satu contoh menempatkan ukuran pada sesuatu yang besar. Konsep: "Buat alat berbasis cloud visual yang memungkinkan perusahaan untuk mengintegrasikan platform perangkat lunak mereka". Ini kedengarannya hebat dan seseorang dapat mulai menulis materi pemasaran dan menjualnya bahkan sebelum itu ada. Anda harus memiliki ini sebelum pengkodean.

Pra-desain: "Memiliki bentuk dan panah seperti di Visio untuk menjelaskan logika; memiliki kemampuan plug-in untuk memungkinkan koneksi ke berbagai platform (SAP, SF, database ...); memiliki konsol pemantauan di mana orang dapat mencari data yang melewati sistem; memiliki cara untuk menggambarkan data secara visual dan mengubah satu format ke format lain ". Gumpalan pemasaran hebat lainnya. Ini juga memberi Anda beberapa ide tentang apa yang penting, harus memiliki sketsa kasar sebelum pengkodean juga.

Desain / Kode: "Memiliki browser yang meng-host perancang HTML dengan fitur ini dan itu; kode backend di Jawa sehingga dapat berjalan di server yang ada; tentukan struktur data dan UX untuk meminta atau memodifikasi mereka sesuai kebutuhan; rencana pemulihan bencana, kesalahan pelaporan, audit logging; kontrol versi rencana; kontrol akses rencana; .... "- semakin halus daftar, semakin tidak realistis untuk meramalkan semuanya.

... namun orang harus paling tidak menyadari hal-hal seperti apa yang akan terjadi secara kasar atau produk akhir Anda mungkin berakhir dengan beberapa implementasi yang benar-benar tidak berguna yang akhirnya membunuh konsep yang terdengar sangat bagus - katakanlah perancang visual Anda membutuhkan 40 " layar untuk menunjukkan alur kerja dunia nyata, atau tidak ada cara untuk mencari log selain dari kecocokan string yang tepat terbatas pada salah satu dari 20 bidang dalam log dll. Tidak ada cara yang baik untuk mencegah hal ini terjadi selain menjalankan implementasi Anda - beberapa akan berhasil, yang lain akan gagal.

Saya selalu membagikan waktu sebagai berikut:

1. 1/3 Desain
2. 1/3 Pengembangan
3. 1/3 Pengujian

Desain: Tidak hanya visual, tetapi juga konseptual. Bagilah menjadi beberapa bagian, baik secara visual maupun logika. Cari kesamaan yang digunakan kembali dan merupakan pola desain sendiri.

Pengembangan: Setelah Anda mengetahui bagian-bagian Anda, beri kode. Kemudian Anda mengintegrasikannya.

Pengujian: Tidak hanya menguji bahwa kode terintegrasi dan ditulis dengan benar, selalu akan ada wawasan yang terlihat dan pelajaran yang dipetik dan itu akan menciptakan cara-cara baru untuk berinteraksi, kemampuan baru akan dipahami dan diinginkan. Waspadalah terhadap cakupan creep.

Selain aspek-aspek ini, ketahuilah bahwa sebuah proyek juga memiliki 3 fase di atas semua fase ini.

1. Upaya pertama yang kurang direkayasa
2. Upaya kedua yang direkayasa secara berlebihan, dari pelajaran yang dipetik dari upaya pertama.
3. Upaya ke-3 yang direkayasa dengan baik.

Saya telah menemukan bahwa semakin baik Anda melakukan fase desain, itu meminimalkan upaya tambahan. Alih-alih melakukan kembali semuanya, Anda mungkin hanya memiliki sub-sistem yang akan dikerjakan ulang.

Saya seorang pengembang perangkat lunak, dan manajer pengembangan perangkat lunak untuk proyek pengembangan in-house, outsourcing dan lepas pantai.

Ada asumsi mendasar yang salah di sini. Anda tidak akan pernah dapat membuat desain yang bagus tanpa menulis kode terlebih dahulu (sekolah tidak akan pernah mengajarkan hal ini kepada Anda). Namun, sekolah benar bahwa Anda tidak akan mendapatkan kode yang bagus tanpa desain.

Solusinya adalah:

1. Tulis beberapa kode yang menurut Anda dapat menyelesaikan masalah.
2. Munculkan desain berdasarkan apa yang Anda pelajari dari kode.
3. Buang semua kode dan tulis ulang dari awal sesuai dengan desain.
4. Ulangi seperlunya.

Membuang semua kode adalah tidak langkah opsional dalam proses ini, tapi untuk proyek-proyek kecil secara formal penulisan desain mungkin. Untuk proyek besar, Anda lebih cenderung mengulangi langkah " buang semua kode " - meskipun jika Anda memiliki modularitas yang cukup, ini mungkin hanya berlaku untuk bagian basis kode.

Terlalu banyak proyek memegang kode warisan karena mereka tidak mau mengubahnya - atau karena terlalu rumit, karena tidak pernah dirancang untuk dibuang. Mengakui kenyataan bahwa upaya pertama Anda akan gagal akan membuat hidup Anda jauh lebih baik.

konsepsi adalah desain kunci yang selalu dapat diubah pemrograman harus memenuhi persyaratan aplikasi yang dikandung sepenuhnya.

1 apa intinya, 2 bagaimana harus diakses, ke 3 siapa pengguna, ke-4 lay out lingkup pekerjaan penuh SOW mendefinisikan dalam istilah tertentu semua aplikasi ini harus dilakukan. dan bagaimana setiap fungsi yang Anda tambahkan akan berfungsi.

sebelum ada pilihan untuk arsitektur aplikasi web Anda, rencanakan dan pikirkan sepenuhnya.

lalu pilih tumpukan terbaik

Saya seorang pengembang LAMP

jadi saya cenderung mempersempit pertanyaan ke kerangka php apa yang akan saya gunakan. dan skrip front end saya harus membuatnya melakukan semua hal yang saya butuhkan untuk dilakukan dengan cara yang ideal

untuk menambahkan ini, belajar menggunakan kerangka kerja MVC, ZEND dan CAKEPHP adalah kerangka kerja pengembangan cepat (PHP) terbaik