Saya tahu bagaimana memprogram, dan bagaimana belajar memprogram, tetapi bagaimana / di mana Anda belajar membuat sistem dengan benar? [Tutup]

11

Ada banyak hal yang perlu dipertimbangkan ketika membuat sistem, mari kita ambil contoh sistem berbasis web di mana pengguna masuk dan berinteraksi satu sama lain, membuat dan mengedit konten. Sekarang saya harus berpikir tentang keamanan, validasi (saya bahkan tidak berpikir saya 100% yakin apa yang diperlukan), "memastikan pengguna tidak saling menginjak kaki" (istilah untuk ini?), Mencegah kesalahan dalam banyak kasus, memastikan data database tidak menjadi masalah melalui ... situasi yang tidak terduga? Semua hal ini saya tidak tahu bagaimana atau di mana harus belajar, apakah ada buku tentang hal-hal semacam ini? Seperti saya katakan sepertinya ada perbedaan besar antara menulis kode dan benar-benar menulis kode yang benar, tahu apa yang saya maksud? Saya merasa pekerjaan pemrograman saya saat ini kurang dari apa yang saya jelaskan dan saya bisa melihat masalah yang ditimbulkannya nanti, dan kemudian masalahnya jauh lebih sulit untuk dipecahkan karena data ada dan orang-orang menggunakannya. Jadi, adakah yang bisa mengarahkan saya ke buku atau sumber daya atau subset pemrograman yang tepat (?) Untuk jenis pembelajaran ini?

PS: merasa bebas untuk memperbaiki tag saya, saya tidak tahu apa yang saya bicarakan.

Sunting: Saya berasumsi beberapa contoh yang saya tulis berlaku untuk jenis sistem lain juga, saya hanya tidak tahu contoh bagus lainnya karena saya sebagian besar terlibat dalam pekerjaan web.

MetaGuru
sumber

Jawaban:

10

Sejauh yang saya tahu, programmer profesional mempelajari hal-hal ini tiga cara utama:

  1. Belajar dari pengalaman buruk - Anda menemukan sesuatu yang salah. Anda memperbaikinya. Anda berkata, "Hei, aku seharusnya tidak melakukan itu lagi. Lain kali aku akan melakukan X." Anda jelas berada di tengah-tengah itu.
  2. Belajar sebelum pengalaman buruk - Akhirnya, Anda belajar untuk melihat beberapa jenis masalah datang. Ketika Anda melakukannya, Anda akan mencoba menghindarinya. Mungkin Anda membaca buku, mungkin Anda mencari di web, mungkin Anda mencoba beberapa eksperimen.
  3. Belajar dari kolega yang berpengalaman - Sejauh ini yang paling mudah, meskipun masih tidak mudah. Kuncinya adalah mencari tahu apakah kolega tersebut menanggapi pengalaman buruk yang masih relevan. Teknologi terus bergerak, setelah semua.

Saya mendorong Anda untuk menembak untuk ketiganya. Temukan tempat dengan kolega yang cerdas dan berpengalaman yang akan menjawab pertanyaan Anda. Pastikan itu adalah tempat yang memungkinkan Anda mengirim lebih awal dan sering, sehingga Anda dapat mencoba banyak hal. Dan luangkan waktu untuk penelitian dan refleksi.

William Pietri
sumber
Untuk # 1), ingatlah bahwa pengalaman buruk dan kesalahan yang Anda pelajari tidak harus menjadi pengalaman Anda sendiri. Habiskan waktu di web, bergaul dengan para programmer, pelajari beberapa cerita horor mereka tentang kesalahan gila yang mereka buat atau temui, pertahankan di belakang kepala Anda saat Anda memprogram.
Shadur
1
Saya setuju, Shadur, tetapi saya pikir beberapa pengalaman buruk benar-benar perlu menjadi milik Anda. Beberapa orang mencoba duduk di sela-sela, menunggu sampai mereka dapat membuat hal yang sempurna. Tetapi mereka benar-benar perlu masuk ke sana dan mulai membuat jika mereka ingin meningkatkan keterampilan mereka.
William Pietri
4

Ketika datang ke aplikasi web, ada lebih banyak info bagus yang dikompilasi dalam jawaban ini daripada tempat tunggal mana pun yang pernah saya lihat.

Tetapi kenyataannya adalah, ada banyak yang perlu diketahui untuk menyusun sistem yang lengkap dengan baik. Ada studi untuk mendukung 10.000 jam sebagai jumlah praktik yang diperlukan untuk mencapai tingkat penguasaan, dan mengembangkan sistem informasi tidak terkecuali untuk itu.

quentin-starin
sumber
Jadi saya kira itu berbeda untuk hal yang berbeda, kan?
MetaGuru
Banyak masalah akan, katakanlah, spesifik untuk aplikasi web dan banyak akan lebih umum. Tidak yakin saya sepenuhnya mengerti apa yang Anda tanyakan.
quentin-starin
3

Saya suka jawaban William Pietri (+1), tapi saya yakin perlu ditambahkan. Bahkan menganggap bahwa apa yang Anda maksudkan dengan sistem hanya terdiri dari perangkat lunak.

Tapi sebelum saya membahasnya, saya tidak tahu buku apa yang bisa saya bantu. Semua yang mengikuti, saya belajar dari pengalaman (artinya tiga poin yang dibuat William).

Apa yang Anda bicarakan tentang bentang minimal empat peran luas. Terkadang satu orang mungkin mengisi semua peran itu, untuk proyek-proyek berukuran kecil hingga menengah, tetapi ketika Anda memulai proyek-proyek besar, Anda perlu setidaknya memisahkan peran-peran tersebut. Sulit bagi siapa pun untuk menjadi ahli dalam hal itu semua dengan cara yang berarti.

  1. Analis bisnis

    Itulah orang yang berbicara kepada pelanggan dan menerjemahkan persyaratan mereka menjadi sesuatu yang dapat dipahami oleh seorang arsitek. Pada dasarnya daftar persyaratan yang dirumuskan dengan benar. Ini termasuk persyaratan fungsional yang jelas (apa yang harus diberikan sistem ini?), Tetapi juga persyaratan non-fungsional (apa karakteristik umum yang harus dipenuhi sistem? Ini mungkin termasuk keamanan, keandalan, ketersediaan, ketahanan, kapasitas, kinerja, ketahanan dan persyaratan lain semacam itu dari sudut pandang pengguna).

    Ini adalah langkah pertama yang harus dilakukan sistem, awal dari pemikiran serius.

  2. Arsitek sistem

    Orang ini menghasilkan kerangka teknis tingkat tinggi untuk bekerja. Mereka memberikan rencana pencocokan garis besar. Alat umum, teknik, konstruksi. Mereka memecah seluruh sistem menjadi komponen yang lebih kecil, bagaimana mereka cocok satu sama lain, bagaimana mereka cocok dengan dunia luar ...

    Ini membantu dalam banyak hal memperbaiki apa yang perlu dipikirkan. Sangat sering masalah akan ditemukan pada tahap itu tentang persyaratan seperti yang ditulis oleh analis bisnis. Kembali kepada mereka untuk beberapa iterasi untuk meningkatkan pemahaman mereka tentang apa yang mereka inginkan dan ekspresi mereka tentang itu.

  3. Perancang sistem

    Peran ini adalah tentang bagaimana membuat semuanya berfungsi. Ini mungkin lebih banyak kerja tim daripada pertunjukan satu orang. Tetapi ada kemungkinan desainer utama untuk mengawasi seluruh desain sistem. Orang ini harus menggali detail dan memastikan pandangan arsitek adalah sesuatu yang benar-benar dapat dibangun.

    Harapkan penyempurnaan lebih lanjut dari arsitektur sistem, dan karena itu berpotensi analisis bisnis.

  4. Manajer tes

    Peran ini sangat sering dilupakan. Tetapi pada akhirnya jika Anda tidak dapat mengujinya, bagaimana Anda dapat membuktikan bahwa Anda dapat membuatnya? Harus ada tinjauan ulang hasil dari semua tahap: analisis bisnis, arsitektur dan desain oleh seseorang yang kompeten dalam pengujian yang akan dapat menyoroti kekurangan dan karenanya memungkinkan koreksi awal, jauh sebelum kode apa pun ditulis.

Itu ringkasan singkat.

Cowok / cewek itu hanya orang-orang biasa dalam rantai untuk memikirkan apa yang harus dipikirkan.

Untuk proyek-proyek kompleks seperti perbankan besar atau aplikasi luar angkasa hanya untuk mengambil dua contoh (pikirkan ratusan hingga ribuan hari kerja), ada banyak ahli materi pelajaran yang kami panggil untuk meninjau dan mendukung proyek di setiap tahap. Peran-peran ini mencakup analisis keamanan, penentuan ukuran sistem, kapasitas, kinerja, basis data, pengelompokan, dan banyak bidang keahlian sempit lainnya, termasuk bidang bisnis yang tepat. Variasi peran tergantung pada ukuran dan kompleksitas sistem.

Semua itu untuk mengatakan bahwa Anda tidak harus mencoba dan mengetahui semuanya, Anda tidak akan. Namun Anda bisa mendapatkan gambaran keseluruhan dan pada proyek-proyek kecil Anda dapat mempelajari lebih banyak daripada pada proyek-proyek besar, hanya karena tingkat kerumitan memungkinkan Anda untuk lebih bulat.

Jika Anda ingin tahu cara mendesain sistem, maka Anda harus mulai mengajukan pertanyaan dengan berpikir di luar kotak. Tempatkan diri Anda pada posisi pelanggan dan coba dan pikirkan apa yang bisa salah, apa yang perlu diuji. Kemudian berkumpul dengan pelanggan nyata dan mendorong mereka untuk menjelaskan luasan dan batasan sistem yang mereka bayangkan mereka butuhkan. Plus setiap kali saya mengatakan 'pelanggan', Anda harus memahami bahwa ini mencakup beberapa orang yang sangat berbeda. Ada orang yang menggunakan sistem hari demi hari untuk apa yang dirancang untuk dilakukan. Ada operator, dukungan teknis, manajer yang membutuhkan laporan atau lainnya, auditor, tim infrastruktur, pemangku kepentingan yang membayarnya, manajer kualitas yang membutuhkan sarana untuk menguji sistem Anda ... Tanyakan semuanya (dan jika mereka adalah satu orang, minta mereka untuk meletakkan semua topi ini satu per satu), jadi tanyakan semua yang mereka butuhkan dan Anda akan memiliki awal yang baik untuk mengetahui apa persyaratan sistem Anda. Dari sana Anda dapat memperoleh arsitektur, dan dari sana desain.

Untuk sistem yang kompleks (apakah hanya perangkat lunak atau untuk diintegrasikan dengan perangkat keras dalam arti paling umum) tidak hanya satu orang tidak cukup untuk masing-masing dari empat peran yang saya sebutkan di atas, tetapi Anda perlu memproyeksikan mengelola bahkan definisi apa yang harus sistem lakukan, apalagi fase lainnya.

HPH, asm.

pindahkan
sumber
2

di sini untuk belajar, apakah ada buku tentang hal-hal semacam ini?

Bukan "buku". Banyak buku.

Tidak ada jalan kerajaan

Seperti yang saya katakan, tampaknya ada perbedaan besar antara menulis kode dan benar-benar menulis kode yang benar

Baik.

Anda sedang berbicara tentang "arsitektur", pemrograman dalam skala besar.

Langkah 1. Baca banyak kode. Banyak sekali. Pikirkan hal-hal yang ingin Anda lakukan. Temukan proyek sumber terbuka terkait. Baca kodenya. Semua itu.

Langkah 2. Baca lebih banyak kode. Lebih banyak lagi.

Langkah 3. Baca buku tentang arsitektur.

S.Lott
sumber
2
Baca, baca, baca. Tetapi saya harus menyarankan itu tidak sama dengan apa yang Anda pelajari ketika Anda benar-benar menerapkan sistem nyata.
quentin-starin
@ qes: Pertanyaannya adalah "di mana Anda belajar cara membuat sistem dengan benar?" Anda tidak mempelajarinya dengan membangun sistem nyata dengan buruk. Memang, menerapkan sistem nyata dengan buruk adalah kebalikan dari pembelajaran.
S.Lott
3
Dari Code Complete, salah satu hal yang paling saya sukai: "Bidang rekayasa perangkat lunak membuat penggunaan contoh keberhasilan dan kegagalan masa lalu yang sangat terbatas. Jika Anda tertarik pada arsitektur, Anda akan mempelajari gambar [arsitek terkenal] ... kunjungi beberapa bangunan ... ".
Yakub
@ S.Lott: siapa yang mengatakan sesuatu tentang melakukannya dengan buruk?
quentin-starin
@ qes: tanpa membaca prior art, apa peluang melakukan program skala besar dengan baik? Untuk seorang jenius seperti Anda, mungkin saja seseorang bisa menulis program bagus setiap saat dan semua skala. Tetapi bagi semua orang yang belum melihat pemrograman skala besar, memulai dengan mencoba menerapkan sistem besar tanpa membaca apa pun adalah jalan menuju penulisan sesuatu yang mengandung begitu banyak kesalahan sehingga tidak ada yang berguna yang dapat dipelajari darinya. Pengalaman Anda mungkin berbeda, tetapi saya tahu bahwa saya tidak cukup pintar untuk bekerja tanpa membaca terlebih dahulu.
S.Lott
1

Untuk memperkuat baca banyak buku ....

Sekarang Anda tahu Anda memiliki masalah, ada beberapa poin dalam meminta Anda untuk membaca buku-buku ini. (Sebelum Anda melakukan pekerjaan nyata, ada gunanya mendiskusikan buku-buku ini)

Pola Desain oleh Gamma, Helm, Johnson dan Vlissides Pattern Bahasa Desain Program 1,2,3 dan 4.

Tetapi jangan mencoba menerapkan setiap derai di mana pun Anda melihatnya dapat digunakan

itu hal yang buruk juga.

Semoga ini membantu.

Tim Williscroft
sumber
1

Cara terbaik untuk belajar bagaimana melakukan sesuatu adalah dengan melakukannya. Jika Anda ingin belajar cara berbicara bahasa Prancis, Anda harus berbicara bahasa Prancis, dan membaca bahasa Prancis dan menulis bahasa Prancis dan membaca tentang bahasa Prancis dan pergi ke Prancis dan berbicara dengan orang-orang Prancis dalam bahasa Prancis. Jika Anda ingin tahu cara bermain piano, Anda harus benar-benar bermain piano. Anda harus memainkan lagu-lagu sederhana dan mempelajari struktur piano, dan struktur musik. Anda harus belajar cara membaca musik, dan cara mengekspresikan musik melalui piano menggunakan jari-jari Anda. Anda harus mempelajari seperti apa suara musik dan suara apa yang bisa dibuat piano dibandingkan dengan apa yang bisa dilakukan oleh gitar atau seruling atau saksofon.

Pemrogramannya persis sama. Jika Anda tahu cara mendesain database, Anda harus mendesain database. Jika Anda ingin memahami kriptografi, terapkan algoritma kriptografi dan protokol kriptografi. Jika Anda ingin menulis perangkat lunak yang dapat melayani banyak pengguna secara bersamaan, Anda harus memahami cara kerja IO disk, IO jaringan, dan utas. Untuk memahami cara kerjanya, Anda harus menulis kode yang membaca dan menulis dari file, mentransmisikan data melalui jaringan, dan menyinkronkan akses ke sumber daya. Semua itu membutuhkan latihan.

"Sistem" pada umumnya hanyalah kumpulan barang. Potongan yang berkoordinasi untuk membentuk keseluruhan. Untuk membangun sesuatu yang besar, Anda harus membangun banyak bagian kecil. Jadi, jika Anda ingin mempelajari cara membangun sistem, mulailah membangun sistem. Ambil masalah, pecahkan menjadi beberapa bagian, dan terapkan masing-masing bagian satu per satu. Akhirnya Anda akan memiliki "sistem" yang terintegrasi. Anda mungkin akan gagal beberapa kali, tapi tidak apa-apa. Jika Anda tidak gagal biasanya berarti Anda tidak berusaha cukup keras.

Juga, saya akan merekomendasikan pergi ke sekolah untuk belajar Ilmu Komputer. Itu tidak akan banyak membantu dengan bagian "latihan". Anda harus melakukannya sendiri, tetapi itu akan membantu bagian paparan. Anda akan belajar banyak, tentang hampir semua yang berhubungan dengan cara kerja komputer, dan sistem komputer, yang sulit dipelajari sendiri.

Scott Wisniewski
sumber
1
+1, Meskipun saya menyarankan hanya melakukan itu tidak cukup. Anda tidak akan tahu apakah Anda telah melakukannya dengan baik atau buruk sampai Anda mengunjungi kembali kode yang sama setelah beberapa waktu berlalu. Dan bahkan kemudian, Anda mungkin tahu ada sesuatu yang salah, tetapi tidak bagaimana hal itu dapat diperbaiki. Salah satu cara untuk memotong semua itu adalah untuk memastikan banyak umpan balik promtp dari orang-orang yang lebih berpengalaman tentang apa yang Anda coba pelajari. Jadi ya, "lakukan" sangat penting, tetapi umpan balik tentang apa yang Anda lakukan mungkin bahkan lebih mempercepat proses pembelajaran.
Marjan Venema