Saya masih tidak tahu cara memprogram?


122

Saya sudah membaca banyak buku untuk berbagai bahasa pemrograman, Java, Python, C, dll. Saya mengerti dan tahu semua dasar-dasar bahasa dan saya mengerti algoritma dan struktur data. (Setara dengan mengatakan dua tahun kelas ilmu komputer)

TETAPI, saya masih tidak dapat menemukan cara untuk menulis program yang dapat melakukan sesuatu yang bermanfaat.

Semua buku pemrograman menunjukkan kepada Anda bagaimana menulis bahasa, tetapi BUKAN cara menggunakannya! Contoh pemrograman semuanya sangat mendasar, seperti membuat katalog kartu untuk perpustakaan atau permainan sederhana atau menggunakan algoritma, dll. Mereka tidak menunjukkan kepada Anda bagaimana mengembangkan program yang rumit yang benar-benar melakukan sesuatu yang berguna!

Saya telah melihat program open-source di SourceForge , tetapi mereka tidak masuk akal bagi saya. Ada ratusan file di setiap program dan ribuan baris kode. Tetapi bagaimana saya belajar bagaimana melakukan ini? Tidak ada dalam buku apa pun yang dapat saya beli di Amazon yang akan memberi saya alat untuk menulis semua program ini.

Bagaimana Anda beralih dari membaca Pengantar Java atau Pemrograman Python, atau Bahasa Pemrograman C, dll. Untuk benar-benar bisa mengatakan, saya punya ide untuk program X? Apakah ini bagaimana saya mengembangkannya?

Sepertinya ada jauh lebih banyak yang terlibat dalam menulis program daripada yang dapat Anda pelajari dalam buku atau dari kelas. Saya merasa ada sesuatu.

Bagaimana saya bisa ditempatkan di jalur yang benar?


52
Beberapa orang tidak dimaksudkan untuk memprogram. Hanya Anda yang dapat menjawab apakah jalur alternatif akan menyortir Anda atau apakah sudah waktunya untuk mencoba yang lain. Anda tidak mungkin mendapatkan jawaban yang akan berguna di sini.
duffymo

3
Apa yang Anda anggap "berguna"?

7
@Michael - Saya, misalnya, memilih sebagai Off-Topic, pindah ke P.SE. Saya pikir itu akan menjadi tempat yang lebih tepat untuk diskusi tentang pemrograman sebagai karier dan keahlian.

12
@duffymo: Dan beberapa orang tidak seharusnya mengomentari pertanyaan.
davidk01

4
Saya pikir Anda hanya mengambil lompatan terlalu lama. Beralih dari contoh buku ke proyek Sourceforge yang lengkap sangat luas dan menakutkan. Sebagai gantinya, coba rentangkan apa yang sudah Anda buat. Tambahkan fitur, tambahkan GUI, tambahkan kemampuan jaringan; dan segera, saya membayangkan Anda akan memiliki proyek Anda sendiri di Sourceforge.
gablin

Jawaban:


93

Membangun program yang lebih kompleks hadir dengan pengalaman. Ketika saya pertama kali memprogram saya pikir saya baik-baik saja jika panjangnya lebih dari 25 baris (dan saya harus menggunakan scroll bar) Sekarang saya menulis ratusan baris sehari selama bertahun-tahun pada aplikasi proyek yang sama.

Anda mungkin menemukan halaman ini menarik "Teach Yourself Programming in Ten Years" http://norvig.com/21-days.html

BTW: Sangat sulit untuk memulai program. Seorang penulis dapat menyebutnya "blok penulis". Sebaliknya saya sarankan Anda mulai menulis kode dan memperbaikinya. Jangan takut untuk menghapus bagian besar yang tidak melakukan apa yang Anda butuhkan. Mulai lagi, kali ini Anda akan menulis dengan ide yang lebih baik tentang apa yang Anda lakukan. Mulai lagi dan Anda akan menemukan Anda tidak perlu setengah dari barang yang Anda tulis terakhir kali. Ketika seorang penulis menulis sebuah cerita, dibutuhkan waktu yang lama, banyak penulisan dan penulisan ulang, dll. Banyak ulasan dan umpan balik dan hanya selesai ketika harus diterbitkan (dirilis)


13
+1 Untuk apa yang dikatakan Bill dan untuk mendiskusikan "blok penulis."
David Weiser

Ya ampun, saya sudah melakukan ini selama beberapa tahun (10 + -2) dan saya masih menulis banyak kode sesekali dan akhirnya menghapusnya. Saya sudah punya beberapa "refactor" yang saya kerjakan selama beberapa hari dan undid (melalui kontrol sumber) karena saya adalah seorang retard (harus tumpul).
Ken Henderson

5
+1 untuk analogi menulis cerita. Program saya masih dalam tahap "Sekali waktu ...".
Andy

4
Salah satu hal paling menakutkan tentang pemrograman adalah dokumen kosong. Setelah Anda melewati rintangan itu, Anda telah membuat kemajuan yang baik.
gablin

1
blok penulis. Anda dipaku di sana!
abel

70

Saya selalu kewalahan oleh proyek yang sangat besar juga, seperti yang Anda temukan di SourceForge atau GitHub. Saya bertanya-tanya bagaimana orang, atau bahkan sebuah tim, dapat memahami apa yang terjadi pada 10 atau 100 file, dengan ribuan dan ribuan baris kode.

Tidak ada yang tahu. Setidaknya pada awalnya.

Proyek adalah hal-hal organik. Apa yang dimulai sebagai ide yang sangat sederhana, dapat dengan cepat berkembang menjadi karya besar. Ini, saya pikir, alasan utama untuk pengembangan berulang bukan pendekatan air terjun klasik.

Pikirkan membangun mobil. Meskipun terlihat cukup sederhana dari luar, mempelajari sedikit saja dalam diri Anda menemukan bahwa ada sejumlah besar pertimbangan, pertukaran, dan kasus-kasus tak berdosa yang perlu ditangani.

Contoh:

Dalam kasus proyek semi-besar, seringkali dimulai dari yang kecil. "Saya ingin membangun server cache". Jadi, Anda menghabiskan beberapa hari meretas, dan sampai pada sesuatu yang berhasil, tetapi dapat ditingkatkan secara dramatis. Jadi, Anda menambahkan konsep threading.

Kemudian Anda mengalami masalah konkurensi karena threading itu. Jadi Anda memperbaikinya dengan mengubah struktur data bersamaan.

Sekarang prosesnya melambat. Jadi, Anda mengubah struktur data bersamaan menjadi yang biasa, tetapi menyediakan mekanisme penguncian untuk sinkronisasi.

Semuanya tampak berjalan dengan baik, kecuali pengguna mulai mengeluh bahwa operasi tidak atom, dan data sedang rusak.

Jadi Anda menambahkan beberapa operasi atom klasik, seperti kenaikan dan simpan. Ini berfungsi, dan pengguna Anda senang. Tetapi seseorang membuka tiket menanyakan apakah mungkin untuk melakukan operasi daftar.

Jadi, Anda menghabiskan satu atau dua minggu membangun fitur itu. Pada sekitar waktu ini, seorang teman memutuskan untuk membantu Anda. Anda mengerjakannya bersama, menyelesaikan, dan melepaskannya.

Dua tiket terbuka. Ada bug dalam pemrosesan daftar, dan ada beberapa kasus langka yang menemui jalan buntu.

Teman Anda bekerja pada bug pemrosesan daftar, saat Anda mengatasi jalan buntu. Anda menyadari bahwa penulisan ulang yang cukup signifikan untuk operasi atom perlu terjadi.

... dan begitulah.

Ini tampaknya cukup khas tentang bagaimana sebuah proyek tumbuh. 10 atau lebih file baru saja bertambah menjadi 20 dalam beberapa minggu. Fitur baru ditambahkan yang tidak terlepas dari paket aslinya. Perbaikan bug yang berbelit-belit ditambahkan yang menumbuhkan kode besar secara tidak wajar.

Saranku:

Jangan sampai kewalahan. Jika Anda punya ide, terapkan potongan fungsionalitas. Jika perlu mengejar setelah itu, tambahkan sedikit demi sedikit. Biarkan proyek Anda tumbuh secara alami.


Ya, hampir seperti itu berasal dari pengalaman pribadi ...
NickAldwin

@Nick, bukankah kita semua memiliki pengalaman yang sama dengan proyek "X" dengan fitur "Y" dan "Z"? Saya memiliki dua proyek serupa dalam setahun terakhir. Tak satu pun dari mereka Redis = P
Josh Smeaton

Ini menggambarkan hampir setiap program yang saya tulis.
Tim Post

Begitu seterusnya. Kurt Vonnegut memenuhi pemrograman komputer
Zoot

1
Contoh yang sangat baik, tetapi jika itu bisa mulai sedikit lebih kecil itu akan lebih baik. Misalnya, mulai dengan membangun beberapa struktur data, lalu beberapa kode yang menyediakan API untuk struktur data ini, kemudian beberapa kode yang menggunakan API ini untuk mengimplementasikan fungsi cache, dan akhirnya GUI di atasnya. Voilá, Anda telah menulis server cache!
gablin

28

Bahkan program terbesar dimulai dengan sebuah ide dan ditulis satu baris setiap kali.

Cara terbaik (mungkin satu-satunya) untuk belajar cara menulis program dunia nyata adalah mulai melakukannya. Ketika Anda mengalami masalah, Anda mencari di web atau bertanya di sini untuk solusi masalah tersebut. Akhirnya, Anda akan mendapatkan pengalaman dan harus bertanya lebih jarang.

Namun, ada beberapa hal yang harus Anda sadari sejak awal:

  • Hampir tidak ada aplikasi besar yang ditulis sepenuhnya dari awal hari ini. Anda bisa menyelesaikan lebih banyak hal dalam waktu yang jauh lebih singkat jika Anda menggunakan pustaka dan kerangka kerja berkualitas tinggi yang ada. Memulai dengan ini sering terasa sangat frustasi dan lebih banyak pekerjaan daripada melakukannya sendiri, tetapi itu hampir tidak pernah benar.
  • Memikirkan dengan cermat tentang bagaimana Anda menyusun program Anda (bagaimana mendesainnya) sangat penting sekali program Anda menjadi lebih besar. Luangkan waktu untuk itu, dan baca beberapa buku tentang desain (saya terutama akan merekomendasikan "Kode Bersih") dan rekayasa perangkat lunak serta tentang dasar-dasar teknis.

6
"Cara terbaik (mungkin satu-satunya) untuk belajar cara menulis program dunia nyata adalah mulai melakukannya." Kurang lebih apa yang akan saya katakan. Anda hanya dapat membaca dan "memahami dasar-dasar" begitu banyak ... karet harus mengenai jalan di suatu tempat.
WernerCD

1
+1 untuk baris "Mulai lakukan itu." Anda tidak dapat mempelajari pengalaman dari buku.
riwalk

+1 untuk menyebutkan buku "Kode Bersih". Anda harus selalu membuat kode Anda dapat dibaca. Mudah dibaca == mudah dimengerti == mudah dimodifikasi
Igor Popov

15

Yang Anda bicarakan adalah lebih banyak rekayasa perangkat lunak daripada pemrograman. Ini sedikit arsitektur, sedikit "praktik terbaik" dan "pola desain," sedikit bekerja dengan orang lain. Meskipun ada buku yang dapat membantu, sebagian besar berasal dari pengalaman. Tidak ada yang mulai menulis, katakanlah, Microsoft Word.

Pikirkan tentang program besar, "nyata" yang ingin Anda tulis. Sekarang pikirkan tentang berbagai bagian yang Anda butuhkan untuk membuatnya berfungsi seperti yang Anda inginkan. Misalnya, dalam gim orang pertama modern Anda akan membutuhkan mesin grafis 3D, AI non-pemain-karakter, modul musik / suara, mesin fisika, dan modul tingkat atas yang menegakkan aturan main (tahu "peta", bagaimana berbagai karakter berinteraksi, dll.). Dan kemudian ada karya seni dan desain karakter dan musik, tidak ada yang kode tetapi yang diperlukan untuk permainan harus lengkap.

Sekarang: Manakah dari ini yang akan Anda bangun sendiri dan mana yang akan Anda dapatkan di tempat lain? Sebagian besar proyek perangkat lunak besar tidak diprogram dari awal. Mungkin Anda akan menggunakan mesin 3D dan modul musik / suara dan hanya memprogram hal-hal yang membuat permainan Anda unik. OK, jadi Anda harus mencari tahu modul pihak ketiga apa yang akan Anda gunakan, yang akan melibatkan faktor-faktor seperti biaya, bahasa apa yang mereka gunakan, fitur apa yang mereka miliki, bagaimana API mereka dirancang (yaitu, seberapa lengkapnya) adalah, seberapa cocok dengan gaya pemrograman pribadi Anda, dll.). Mungkin Anda akan menulis "proof of concept" atau program pengujian menggunakan satu atau dua kandidat untuk berbagai modul pihak ketiga untuk memastikan mereka akan melakukan semua hal yang Anda butuhkan dan mudah untuk Anda gunakan.

Juga, bahkan kode yang ingin Anda tulis sendiri mungkin merupakan pekerjaan yang terlalu besar untuk Anda selesaikan dalam kerangka waktu yang Anda pikirkan. Berapa banyak programmer lain yang perlu Anda kerjakan dalam proyek ini? Bagaimana Anda akan membagi pekerjaan? Bagaimana berbagai modul dirancang sehingga semuanya bisa saling cocok meskipun ditulis oleh orang yang berbeda? Bagaimana Anda semua bekerja pada kode sumber yang sama tanpa menghapus perubahan satu sama lain (jawaban: kontrol versi, yang sangat berguna ketika Anda bekerja solo tetapi sangat diperlukan ketika bekerja dengan orang lain).

Setelah Anda mengetahui modul apa yang ingin Anda tulis sendiri, Anda melakukan proses yang sama. Cari tahu bagian-bagian dari setiap modul, bagaimana mereka harus cocok bersama, dan mana yang akan Anda tulis sendiri dan yang akan Anda dapatkan di tempat lain. Lanjutkan memecah-mecah sampai setiap bagian cukup kecil untuk Anda pegang dalam pikiran Anda, untuk Anda katakan, "ya, saya bisa menulis itu!" Dan kemudian melakukannya. Ketika Anda melakukannya, Anda akan menemukan hambatan yang tidak terduga dalam bagaimana berbagai bagian dari program Anda cocok bersama. Ini akan membuat frustrasi, tetapi itu adalah kesempatan bagi Anda untuk mempelajari lebih lanjut tentang kerajinan Anda, dan harus dilihat seperti itu.

Pada awalnya, Anda hanya akan dapat memegang bagian yang sangat kecil dari program Anda - katakanlah, fungsi individu - di dalam pikiran Anda, dan karenanya Anda harus sering memecah banyak hal sebelum mulai coding. Ketika Anda mendapatkan pengalaman, Anda akan berpikir dalam fungsi daripada perlu berpikir tentang fungsi dan mulai berpikir tentang objek. Dan Anda akan berpikir dalam objek dan berpikir tentang modul yang lebih besar. Akhirnya, Anda akan berpikir dalam modul dan berpikir tentang keseluruhan, besar, program nyata.

Dan kemudian Anda akan menemukan bahwa Anda masih harus banyak belajar ... tetapi begitulah seterusnya. Jika, sebagai seorang programmer, Anda pernah berhenti belajar, Anda sudah usang dan akan diganti dengan model yang lebih baru.

Pokoknya, jangan takut, dan jangan khawatir jika ini terdengar ... mengerikan atau tidak mungkin dan Anda tidak benar-benar ingin menjadi seorang programmer. Ini bukan untuk semua orang. Saya suka musik dan makanan penutup, dan saya bisa memainkan kunci sedikit dan memasak beberapa hidangan, tetapi saya tidak mau menghabiskan waktu yang dibutuhkan untuk menjadi musisi yang hebat atau master chef.

Jika ternyata Anda tidak ingin menjadi programmer yang menulis aplikasi desktop yang besar dan nyata, ada beberapa jenis pekerjaan pemrograman lainnya. Anda bisa menjadi programmer yang tertanam, misalnya. Ada tantangan yang pasti dan menarik yang terlibat dalam penulisan program yang disematkan, dan Anda melakukan pekerjaan yang bermanfaat, tetapi biasanya programnya lebih kecil daripada aplikasi desktop. Atau Anda bisa menulis aplikasi web. Di Web, mudah untuk merekatkan sedikit fungsionalitas bersama-sama, sehingga Anda dapat menulis (misalnya) sistem komentar Web dan itu akan berguna bahkan jika itu bukan aplikasi Web secara keseluruhan. Sangat mudah untuk secara bertahap meningkatkan hal-hal di Web, sehingga Anda dapat mulai dengan (katakanlah) klien email Web dasar dan, seiring waktu, mengubahnya menjadi sesuatu seperti Gmail. (Tapi jangan lakukan itu, karena dengan begitu Anda akan bersaing dengan Gmail.)

Jika Anda tidak ingin menjadi programmer sama sekali, tetapi masih ingin bekerja dengan komputer, mungkin Anda bisa masuk ke IT atau bidang teknis lainnya. Dalam kasus ini, mengetahui pemrograman sebanyak yang sudah Anda lakukan sangat berguna, karena teman-teman Anda mungkin tidak memiliki sebanyak itu. Atau, Anda tahu, menjadi musisi jika itu menarik, karena (seperti kebanyakan bidang) itu melibatkan komputer saat ini. Menulis program kecil yang memanipulasi file audio atau MIDI dengan berbagai cara pintar, sehingga menjadikan Anda musisi yang lebih baik. Anda akan menemukan bahwa keterampilan pemrograman apa pun yang Anda miliki dapat diterapkan di banyak bidang untuk membuat Anda lebih baik dalam pekerjaan Anda.


Saya tidak setuju bahwa program tertanam biasanya lebih kecil dari aplikasi desktop. Mungkin memang begitu di masa lalu, tetapi saya telah mengerjakan beberapa produk tertanam yang membutuhkan 100+ tahun pengembangan dan ini tidak dianggap sangat besar.
Bart van Ingen Schenau

1
Saya kira itu akan tergantung pada apa yang Anda maksud dengan "tertanam." Jika Anda memaksudkan sesuatu seperti smartphone atau sistem otomotif terintegrasi, saya dapat mempercayai 100 tahun man Anda. Masih ada banyak sistem yang lebih kecil untuk dikerjakan di ruang itu.
hati

1 untuk memulai dengan berpikir tentang hal-hal yang lebih kecil, dan kemudian pindah ke berpikir dalam hal yang sama dan tentang hal-hal yang lebih besar.
gablin

1
Apa salahnya bersaing dengan GMail? Jika sesuatu yang Anda tulis sendiri dapat bersaing dengan sesuatu yang dirilis Google, Anda dapat menganggap diri Anda seorang programmer yang sangat bagus.
gablin

Alasan utamanya adalah saya menganggap GMail telah memecahkan surat Web. Sebagian besar programmer tidak merasa sangat menarik untuk mengerjakan masalah yang telah dipecahkan (dan dipecahkan dengan baik) oleh orang lain. Anda mungkin dapat menemukan masalah yang belum diselesaikan dan bersenang-senang lebih banyak - dan berpotensi membawanya ke pasar tanpa harus bersaing dengan gorila 800 pon.
hati

9

Anda tidak akan menemukan cara memprogram kecuali Anda akan menghadapi tugas nyata. Tidak ada teori yang akan menggantikan tugas dunia nyata yang sederhana. Sebelum mulai mengerjakan skenario baru, saya secara naif membaca banyak buku, dengan semua contoh, tetapi ketika saya menghadapi masalah nyata, saya tidak bisa mengumpulkan semua pengetahuan teoretis saya untuk menyelesaikan tugas. Jika Anda pemula, saya sarankan Anda untuk mendapatkan tugas dari mana saja Anda bisa. Jangan berpikir itu tidak berguna kecuali Anda sudah menyelesaikannya. Sebagai langkah pertama, cobalah memecahkan masalah struktur data, seperti menyortir daftar tertaut, melakukan DFS, BFS pada pohon, grafik, dll. Tidak hanya akan meningkatkan keterampilan pengkodean Anda, tetapi yang lebih penting, itu akan meningkatkan keterampilan analitik dan algo Anda , yang mempercayai saya adalah pengetahuan yang berharga. Kemudian, ketika Anda akan tahu bahwa Anda dapat bermain rock dengan pointer, rekursi,

Intinya. Ini semua tentang latihan. Teruslah menggali dan kode, kode, kode.


7

Mulailah dengan permainan komputer, seperti yang dilakukan orang lain. Gim yang bagus adalah tantangan pemrograman dan desain, perlu pemikiran cermat tentang struktur internal, dan gim ini menggunakan pustaka sistem dengan cara yang mengajarkan banyak hal, tetapi tidak cenderung merusak barang dan tidak memerlukan "alasan yang bagus dengan hasil yang baik" seperti perangkat lunak "berguna" yang sebenarnya.

Aturan umum adalah bahwa setelah menulis hal-hal yang cukup, semacam pencerahan pasti akan terjadi.

Poin yang bagus untuk memulai (jika Anda merasa seperti C) adalah http://gamedev.net/ , khususnya http://nehe.gamedev.net/ . Ada juga banyak poin bagus untuk memulai: D


4
(Oh dan saya baru menyadari mengapa semua orang mulai dengan permainan. Hal-hal yang mengkilap dan cantik memotivasi.)

10
semuanya ? Klaim berani.

4
Saya tidak memulai dengan permainan. Saya akan menemukan bahwa di luar kompleks = P
Josh Smeaton

4
Sebagian besar orang saat ini mulai dengan aplikasi web, penghalang masuk yang jauh lebih rendah (hanya teks).
slebetman

4
Komentar pertama Anda mungkin lebih baik daripada jawaban Anda - hal yang mengkilap dan cantik memotivasi . Itu yang penting.
Scorchio

6

Anda sedang melihat seluruh program besar dan sepertinya tidak mungkin. Tetapi semuanya terdiri dari program-program kecil yang bodoh seperti yang Anda katakan "jangan lakukan sesuatu yang berguna."

Yang Anda butuhkan adalah pengalaman memecah tugas-tugas besar yang rumit menjadi tugas-tugas kecil yang sederhana. Itu adalah akar dari semua pemrograman. Sisanya hanya semantik.


6

Sama seperti mengemudi atau memasak, pemrograman adalah sesuatu yang Anda pelajari dengan melakukan. Latihan tidak tergantikan.

Jika contoh buku teks sudah terlalu mendasar untuk Anda, itu hebat! Saatnya bergerak untuk sesuatu yang lebih kompleks - dan Anda sudah bisa memikirkan beberapa latihan yang menantang untuk diri sendiri.

Atau, jika Anda memiliki ide spesifik dalam benak Anda, pisahkan menjadi beberapa bagian. Selesaikan sebagian kecil masalah terlebih dahulu. Lalu berkembang. Ketika mengintegrasikan kode baru ke kode yang ada menjadi sulit, maka Anda mendesain ulang semuanya.


5

Tulis skrip 200 baris. Kemudian mulailah memperbaikinya.

Anda akan mendapatkan 100 file sumber dan beberapa ratus KLOC dalam waktu singkat :)


5

"Mereka tidak menunjukkan kepada Anda bagaimana mengembangkan program kompleks yang benar-benar melakukan sesuatu yang bermanfaat!"

Tanpa definisi "berguna" benar-benar tidak banyak yang bisa kami lakukan untuk membuat Anda berada di jalur yang benar.

Kami tidak tahu bagaimana Anda gagal, atau apa yang salah. Kami tidak dapat mengetahui trek apa yang sedang Anda jalani.

Entah bagaimana, Anda memiliki gagasan di kepala Anda bahwa Anda tidak berkomunikasi.

Perangkat lunak - pemrograman - adalah semua tentang mendapatkan gagasan dari kepala Anda ke dalam beberapa bahasa (Python, Java, Inggris, apa pun).

Salah satu langkah penting dalam pemrograman (dan mengajukan pertanyaan) adalah mendefinisikan istilah Anda. Apa yang Anda maksud dengan "melakukan sesuatu yang bermanfaat"? Sangat jelas, sangat lengkap dan sangat tepat.


Terpilih, saya benar-benar tertarik dengan jawaban OP dalam topik ini.
Scorchio

5

Saya selalu ditanya pertanyaan ini, misalnya bagaimana memulai. Sederhana kok. Ini langkah demi langkah.

  1. Munculkan ide. Sepertinya kamu sudah memilikinya.
  2. Sederhanakan ide Anda menjadi inti dasarnya - sesuatu yang Anda pikir dapat Anda tangani
  3. Letakkan UI di selembar kertas atau serbet, apa pun.
  4. Coba dan tata letak UI di lingkungan pengembangan Anda.
  5. Jika Anda menemui kesulitan, google, google, google, ajukan pertanyaan di stackoverflow, gunakan omong kosong hidup dari sumber daya internet untuk mendapatkan bantuan. Mintalah teman dan rekan kerja yang merupakan programmer untuk membantu Anda dengan situasi tertentu. Kembali ke langkah 4.
  6. Mulailah menulis logika aplikasi Anda. Jika Anda mengalami kesulitan, lanjutkan ke langkah sebelumnya dan coba lagi.
  7. Segera, Anda akan memiliki sesuatu yang bekerja segera.

+1 untuk alur kerja - seharusnya bisa berfungsi, entah bagaimana. Saya tidak tahu seberapa penting langkah kedua. Mungkin itulah langkah yang akan memutuskan apakah Anda dapat menangani tugas atau tidak.
Scorchio

"Sepertinya kamu sudah memilikinya." Saya akan membantahnya. Jika ada ide, itu akan menjadi bagian dari pertanyaan.
S.Lott

Sebenarnya, imho, Anda harus mulai dengan menulis logika untuk aplikasi, lalu menambahkan UI ke dalamnya. Lebih sederhana.
CaffGeek

Jika Anda bisa memikirkan alat / aplikasi yang akan Anda gunakan itu akan lebih baik. Membuang proyek-proyek dapat memotivasi. Apa pun itu, mulailah dari yang kecil dan bangun dari sana. Saya akan menyarankan alat baris perintah.
Carlosfocker

1
@Chad, saya tidak setuju dengan Anda. Untuk noobs, logikanya abstrak, tetapi UI mudah dipahami. Kebalikannya datang dengan pengalaman.
AngryHacker

4

Buat sesuatu yang kecil. Tidak masalah, program Anda akan menjadi yang ke 1000 yang melakukan itu.

Beberapa ide:

  • sebuah jam (digital pertama, kemudian analog-look),
  • pencipta labirynth otomatis,
  • penampil struktur direktori,
  • daftar album mp3,
  • dll.

Memilih platform, alat adalah bagian dari tugas.


Saya sebenarnya setuju dengan Anda secara prinsip. OP bertanya tentang perangkat lunak yang bermanfaat. Daftar album mp3 akan menjadi pilihan yang bagus. Pemutar mp3 dasar akan lebih baik, karena ia akan mengalami kesulitan yang dihadapi proyek. Termasuk LOC.
Josh Smeaton

@Josh, decoding mp3 adalah non-sepele untuk mendapatkan yang benar untuk seorang programmer pemula.

@ Tor, benar-benar tidak sepele. Tapi itu akan berguna, dan akan mengajar dengan sangat cepat bagaimana program bisa menjadi begitu besar. Semua nuansa, perbaikan bug, kasus tepi. Ini mungkin tidak sesuai dalam kasus khusus ini, tetapi itu bisa sesuai secara umum. Mampu menggunakan sendiri perangkat lunak yang Anda tulis adalah hal yang hebat.
Josh Smeaton

@ Ya ampun, saya masih tidak berpikir decoder MP3 adalah hal kecil dan cocok untuk tujuan ini.

3

Baiklah, mari kita mulai dengan ide Anda untuk program X yang melakukan sesuatu yang bermanfaat dan mari kita uraikan:

  • Gunakan kertas, pemetaan pikiran, atau pembuatan diagram perangkat lunak untuk mengatur tata letak alur logis program.

  • Karena Anda baru memulai memilih salah satu dari barang-barang itu (lebih disukai dekat awal) dan memecahnya lebih jauh.

  • Tulis kode Anda untuk itu terlebih dahulu dan gunakan untuk membangunnya

Apakah Program X perlu membuka file, memanipulasinya, dan membuat file output? Lihat apakah Anda dapat membuka dan menggema file sebagai langkah pertama Anda. Apakah Anda ingin antarmuka pengguna yang bagus? Buat satu yang dapat menjalankan program file gema Anda, dll. Anda tidak hanya akan membangun kode yang dapat Anda gunakan dalam program kompleks Anda selangkah demi selangkah, tetapi Anda juga akan membangun pengetahuan bahasa Anda karena Anda harus mencari dan mencari informasi.

Seperti kata pepatah - Gnome tidak dibangun dalam sehari :-)


3

(sudah dijawab di komentar. Disarankan untuk mengirimkan ini sebagai jawaban setelah pertanyaan dibuka kembali.)

Anda mulai dengan masalah - sesuatu yang ingin Anda selesaikan - tidak peduli seberapa kompleksnya Anda pikirkan. Kemudian Anda mengambil masalah ini dan menuliskannya dan mulai memecahnya menjadi masalah yang lebih kecil. Anda kemudian memecah masalah-masalah yang lebih kecil, dll. Sampai Anda memiliki sesuatu yang primitif yang Anda sudah tahu bagaimana menyelesaikannya atau dapat melakukannya dengan beberapa usaha. Anda mulai mengkodekan masing-masing bagian ini dan mengaturnya ke dalam fungsi yang berbeda atau kelas yang berbeda, dll.

Kemudian Anda mengerjakan sub-masalah berikutnya. Saat Anda mengerjakan setiap masalah, Anda dapat menulis kasus uji kecil dan benar-benar melihat kemajuan Anda membuahkan hasil. Akan selalu ada tantangan di sepanjang jalan, tetapi tidak akan melihatnya sebagai sesuatu yang terlalu kolosal untuk didekati (apa yang tampaknya sedang dihadapi sekarang). Ini berlaku untuk pemrograman dan banyak tantangan hidup. Kunci mereka adalah untuk memecahnya.

Adapun apa yang harus dilakukan - ide. Anda dapat mencoba untuk menciptakan sesuatu yang baru, tetapi Anda juga dapat mengambil sesuatu yang Anda sukai dan sudah ada, tetapi hanya membuatnya lebih baik atau bahkan hanya berbeda. Saat ini saya sedang menulis aplikasi penyetem gitar untuk Android di waktu luang saya. Saya tahu sudah ada banyak aplikasi penyetem gitar lainnya, tetapi saya pikir ini akan menjadi proyek yang menyenangkan dan menantang jadi saya menerimanya. Pada awalnya sepertinya hampir mustahil, tetapi setelah saya memecahkan masalah menjadi langkah-langkah kecil itu sebenarnya datang bersama dengan baik. Pisahkan dan taklukkan dan gigihlah dengan tujuan Anda.


3

Salah satu hal yang paling sulit untuk dilakukan ketika Anda seorang pemula adalah menetapkan tujuan yang realistis untuk apa yang "bagaimana saya bisa tingkatkan" - latihan harus berisi pada tingkat Anda saat ini.

Oleh karena itu saya menyarankan Anda memilih untuk berlatih memecahkan latihan kecil yang diberikan, karena kemampuan untuk menyelesaikan program sesuai dengan spesifikasi yang diberikan adalah hal yang sangat berharga bagi semua orang yang memprogram untuk mencari nafkah.

Saya akan menyarankan Anda melihat lebih dekat di http://projecteuler.net/ yang memiliki banyak latihan dan sistem "jawaban jawaban" otomatis, yang memungkinkan Anda untuk bekerja dengan kecepatan Anda sendiri. Latihan-latihan ini dilakukan dengan baik, tetapi mungkin mengharuskan Anda untuk berpikir. Beberapa bahkan mungkin mengharuskan Anda untuk berpikir banyak, tetapi bahkan gagal untuk menyelesaikannya, akan mengajarkan Anda sesuatu yang bermanfaat.

Kata-kata lengkap dari masalah 1 adalah:

Jika kita mendaftar semua bilangan alami di bawah 10 yang merupakan kelipatan 3 atau 5, kita mendapatkan 3, 5, 6 dan 9. Jumlah kelipatan ini adalah 23.

Temukan jumlah semua kelipatan 3 atau 5 di bawah 1000.

Apakah Anda pikir Anda bisa menyelesaikan ini? Maka lakukanlah!


3

Anda membutuhkan pengalaman dunia nyata !! . Tidak ada buku yang bisa mengajarkan hal itu kepada Anda!

Anda harus belajar cara membaca kode orang lain, bagaimana memeliharanya, bagaimana membenci mereka (baik kode dan pembuat kode) bagaimana memperbaikinya, bagaimana berpikir Anda bisa melakukannya dengan lebih baik dan beberapa bulan kemudian berteriak keras saya ' akan membunuh siapa yang pernah menulis potongan kode ini !!! Hanya untuk mengetahui dalam kontrol versi sumber, itu adalah Anda!

Anda harus memahami buku yang sangat spesifik dan kadang-kadang untuk orang yang sudah tahu cara mengembangkan perangkat lunak.

Jadi saya sarankan Anda untuk mencari pekerjaan pemrograman. Jika perlu, terapkan untuk level entri paling dasar. Mungkin Anda tidak akan mendapatkan penghasilan sebanyak yang Anda pikir pantas, tetapi gunakan beberapa bulan untuk mempelajari bagaimana perangkat lunak dikembangkan di dunia nyata (dan itu tidak selalu sesempurna dan dengan semua praktik terbaik yang indah yang kami baca di web , sering kali, kualitas kode sangat rendah, tergantung di mana Anda bekerja, tapi itu bagian dari pengalaman)

Teruslah membaca buku-buku Anda, Anda akan menemukan, setiap tahun Anda memahami sedikit lebih banyak (atau berbeda) topik yang sama, karena Anda dapat melihatnya tahu dengan segelas pengalaman.

Jika Anda berhasil mendapatkan pekerjaan dengan pengembang berbakat, jauh lebih baik. Belajarlah dari mereka, jangan takut untuk melakukan kesalahan.

Sampai Anda harus memperbaiki bug mendesak produksi langsung pertama Anda, Anda tidak akan tahu apa itu bug perangkat lunak!

:)


2

Cobalah proyek sumber terbuka, lihat apakah Anda dapat menyesuaikan. Mulailah dengan mengunduh sumber, dan lihat apakah Anda dapat mengambil beberapa tiket


15
Pemrogram pemula tidak boleh mencoba untuk bergabung dengan proyek sumber terbuka; Anda hanya akan menghalangi. Proyek open source tidak ada di sana untuk mengajari pemula.

alternatif untuk terlibat langsung adalah dengan mengambil sumber proyek dan mencoba memperbaiki tiket di cabang Anda sendiri dan cukup membiarkannya begitu saja. Nilai-nilai kode bacaan ditulis dan ditinjau oleh banyak orang, struktur proyek yang terorganisasi dengan baik dan dapat berfungsi sebagai templat untuk kreasi Anda sendiri, dan memahami bagaimana proses kolaborasi bekerja sangat banyak. Cukup amati bagian-bagian publik, dan buang kotoran dengan kode secara pribadi.
Ubur

3
@ Jellyfishtree, jika Anda tidak dapat memprogram yang mungkin agak terlalu ambisius.

@ Thorbjorn pasti, tapi itu sesuatu yang saya berharap saya akan melakukan lebih banyak ketika saya mulai. Seperti apa pun, saya pikir Anda belajar banyak hanya dengan osmosis dan menyelam di kepala terlebih dahulu. Paling tidak Anda akan mendapatkan ukuran yang lebih baik dari apa yang tidak Anda ketahui / pahami - sesuatu yang jauh lebih berharga ketika Anda pertama kali memulai dan ingin tahu ke mana harus menetapkan tujuan Anda dan apa yang harus diusahakan.
Ubur

@ ubur-ubur, tentu, dan saya yakin ini adalah langkah yang baik untuk dilakukan, tetapi belum dalam kasus ini.

2

Ketika saya ingin belajar bahasa baru, saya biasanya mencoba menerapkan beberapa grafik fraktal. Dengan begitu Anda akan mendapat umpan balik langsung jika berhasil dan itu sangat bermanfaat. Dan ada banyak cara Anda dapat meningkatkan fraktal. Implementasi naif mandelbrot lambat sekali.

Ini tidak terlalu berguna, tetapi Anda belajar banyak dan indah untuk dilihat.


Saya suka ini - cara yang cukup puitis untuk belajar bahasa baru. Tapi saya tidak tahu apakah kami harus merekomendasikan ini untuk pemula: D
Scorchio

2

Pemrograman adalah tentang pemecahan masalah dan komunikasi, bukan menulis banyak kode. Kode hanya suatu keharusan, Anda biasanya harus mencoba menulis lebih sedikit kode, bukan lebih.

Jika Anda tidak tahu harus mulai dari mana, mungkin Anda tidak punya masalah!

Lihatlah Linux dan sistem mirip Unix lainnya: semuanya terdiri dari banyak aplikasi kecil yang hanya melakukan satu hal, tetapi melakukannya dengan baik .

Ketika saya membutuhkan skrip untuk menemukan 10 file terbesar di folder di komputer saya, saya tidak membaca buku. Saya baru saja googled dan menggunakan salah satu solusi yang ada. Apakah saya menulis kode? - Tidak. Apakah masalah terpecahkan? - Iya. Apakah program satu baris ini bermanfaat? - Sial ya.

Program dengan ribuan baris kode biasanya ditulis oleh lebih dari satu programmer. Anda tidak akan dapat menulis seluruh sistem operasi sendirian dan Anda tidak perlu melakukannya. Mereka juga sering menggunakan kode curang seperti kontrol versi dan pengujian unit .


Tolong jangan menyebutkan kontrol versi dan pengujian unit sebagai "curang". Membuat cadangan pekerjaan Anda dan bekerja dengan itu adalah suatu keharusan. Kontrol versi hanya membantu menjaga kewajaran. Sama tentang pengujian unit: setiap orang yang menulis satu baris kode tahu bahwa beberapa pengujian harus dilakukan, mengapa tidak menjaganya tetap rapi?
Scorchio

@ Scorchio Saya hanya bermaksud menggunakan kontrol versi dan pengujian unit memberi Anda keunggulan dibandingkan orang yang tidak menggunakannya (cukup). Apalagi ketika berhadapan dengan proyek besar.
kolobos

2

Memecah dan menaklukkan.

Sesederhana atau sekeras itu.


2

Ketika saya mulai pemrograman, saya menyukai game komputer. Jadi saya mulai menulis game sendiri, segera setelah saya punya alat untuk melakukannya.

Cukup alami, game pertama saya adalah petualangan teks. Demikian pula, Anda bisa mulai dengan kuis atau sesuatu, atau semacam permainan menebak.

Juga, Anda bisa mulai dengan sesuatu, seperti mesin slot (Anda tidak benar-benar membutuhkan animasi, atau bahkan gambar. Cukup gunakan A = apel, L = lemon, S = mulai, P = Plum dll).

Ini akan mengajarkan Anda dasar-dasar penanganan beberapa input pengguna, mempertahankan status game dan menghasilkan output yang sesuai.

Saya menuju jalan ini cukup jauh. Saya semakin belajar, cara membaca keadaan keyboard, atau mouse, cara menggunakan kode grafis. Saya belajar lebih banyak tentang bahasa itu sendiri (saya mulai dengan PASCAL) dan menggunakan ini untuk meningkatkan permainan saya yang ada atau baru memulai sesuatu yang baru.

Saya pikir game sangat bagus untuk belajar pemrograman. Bahkan dengan sedikit pengalaman, Anda dapat menciptakan hal-hal kecil, yang memberi Anda momen kebanggaan kecil. Karena Anda membuat sesuatu, itu menyenangkan. Membangun aplikasi yang sebenarnya tidak ada gunanya, karena dibutuhkan banyak pekerjaan untuk membuat sesuatu, yang sebenarnya berguna, sedangkan sangat sederhana, untuk membuat game kecil, yang ternyata membuat ketagihan.

Anda mungkin ingin benar-benar menggunakan bahasa pendidikan (dalam kasus saya, ini PASCAL dan dalam retrospektif, saya pikir itu terbukti menjadi pilihan yang cukup baik). Banyak dari mereka secara khusus ditujukan untuk membuat game dan semacamnya.

Membuat aplikasi lebih dari sekedar membuat algoritma. Anda harus mendesain fitur, Anda perlu mengatur dan menyusun kode Anda di berbagai lapisan dan modul. Tidak seperti masalah "atomik" yang Anda berikan di universitas, aplikasi terkadang paling baik dikembangkan secara bertahap. Anda mulai dengan sesuatu dan Anda menambahkan hal-hal di atasnya. Jadi sudah memiliki sesuatu untuk memulai (seperti yang Anda lakukan dalam beberapa bahasa yang tercantum dalam artikel wikipedia), Anda menghemat banyak frustrasi dan mulai membuat sesuatu segera. (Seorang kolega saya memulai pemrograman dengan menulis gempa 2 mod). Pada titik tertentu, Anda akan menemukan keterbatasan alat yang mudah digunakan ini, tetapi sampai saat itu, Anda akan memiliki lebih banyak wawasan dan pemahaman. Mungkin cukup,


2

Di perguruan tinggi, ada kelas yang disebut praktikum pemrograman yang pada dasarnya mengajarkan jalan ini. Awal Anda diberi UI untuk aplikasi belanja dasar, dan harus membuat kode backend, bulan terakhir adalah Tetris dari awal. Saya pikir sekitar 50% siswa baru (tidak mengikuti kelas) gagal, karena ramping dari kecil ke besar sangat sulit.

Saya menyarankan satu atau lebih hal berikut:

  • Unduh proyek sumber terbuka, dan tambahkan sesuatu. Itu tidak harus berguna atau bagus, tetapi Anda harus melihat strukturnya, yang akan memberi Anda perasaan tentang bagaimana proyek besar dibangun.

  • Cukup rancang proyek akhir Anda di atas kertas, dengan panah untuk dependensi. Jika Anda membuat ular, Anda mungkin memiliki kepala ular, ekor ular, makanan, ruang kosong, dinding, papan, arah saat ini, dll. Mungkin dapat membantu Anda menyadari jika proyek Anda jauh lebih besar daripada yang Anda pikirkan.

  • Ambil proyek dasar, dan buat itu semakin besar. Anda mungkin akan melakukan banyak refactoring, dan mudah-mudahan Anda akan belajar cara membuat proyek yang lebih kecil yang dapat dengan mudah ditambahkan.

  • Jika Anda mengenal seseorang yang berpengalaman, beri tahu mereka ide Anda untuk sebuah proyek, dan minta mereka menulis kelas Anda + beberapa metode penting, mungkin akan memakan waktu satu jam atau lebih. Dengan begitu Anda bisa mengisi metode, dan selalu tahu apa yang perlu Anda lakukan selanjutnya.

Akhirnya, apa pun yang Anda lakukan, Anda mungkin harus menggunakan pola desain MVC (Model, View, Controller) dasar. Tanpa merinci lebih jauh, masukkan tampilan Anda (UI) ke dalam 1+ kelas, pengontrol Anda (Input, output, dll) ke dalam 1+ kelas, dan Model Anda (Logika, Data, pada dasarnya yang lainnya) ke beberapa kelas. Ini adalah cara mudah untuk mendapatkan organisasi dasar.

Ingat, langkah ini sulit. Memang benar bahwa beberapa orang tidak dapat memprogram, tetapi Anda mungkin hanya terjebak pada tahap ini. Semoga berhasil!


2

Pertama, Anda sudah melakukan prasyarat dengan mengambil kelas, membaca bahan referensi, melihat proyek open source, dan tetap penasaran dengan pertanyaan. Saya menekankan hal ini karena saya secara pribadi menemukan pertanyaan serupa sebelum orang tersebut melakukan kerja keras di pihak mereka (khususnya, individu yang menghindari kelas dan berharap untuk mengambil jalan pintas). Sekarang, saya berpikir kembali ketika kami memiliki laboratorium tentang mesin Turing dan bagaimana saat itu saya merasa itu bukan pemrograman yang sebenarnya. Ini adalah pengalaman yang akan Anda ingat bahwa siapa pun yang mengambil jalan pintas akan melewatkannya.

  • Mendaftar untuk proyek siswa. Saya terlibat dengan (CSUA) sekelompok siswa yang berpikiran sama untuk membangun permainan untuk stan karnaval tahun senior saya. Jika Anda terus menikmatinya dan berpikir Anda ingin memperluas keterlibatan Anda, manfaatkan sumber daya. Cari tahu tentang proyek, bicaralah dengan teman sekelas Anda, profesor Anda, dan dapatkan magang.

  • Duduklah dengan programmer yang berpengalaman. Ada sekitar tiga kali dalam sejarah saya ketika saya menonton program orang lain yang benar-benar inspiratif. Bagi mereka, mereka hanya menulis kode dan berpikir keras. Tidak berlebihan, saya merasa lebih asyik mendengarkan mereka daripada bertahun-tahun sendiri. Jika Anda menemukan lebih banyak, Anda jauh lebih kaya. Kita beruntung berada di zaman di mana kita dapat menonton video, memeriksa repositori sumber lengkap, dan mencari toko online besar pengetahuan secara instan. Ini bukan pengganti pengalaman pribadi, tetapi dengan tidak adanya seorang mentor itu adalah peningkatan dramatis atas materi tradisional. Melihat kode mentah oleh orang lain dengan sendirinya mungkin tidak mengarah ke apa pun. Anda akan ingin memiliki sesuatu dalam pikiran dan debugger yang baik untuk masuk ke logika. Salah satu momen terindah saya adalah membuat mod gempa dan bukan mod itu sendiri yang memiliki sesuatu yang mengesankan. Itu melihat logika dalam game Carmack. Mod itu hanya alasan bagi saya untuk menyelam.

  • Berlatihlah menjelaskan dan menjawab pertanyaan yang diajukan oleh mitra lab Anda. Sukarelawan untuk membantu mengajar. Mungkin membentuk kelompok belajar dan meminta setiap anggota menjadi ahli dalam topik kelas. Kemudian bakar orang itu dan minta mereka memanggang Anda. Ketika Anda dipaksa untuk menjawab pertanyaan, Anda akan wajib mempelajari sendiri jawabannya. Ketika Anda dapat menjelaskan konsep dengan jelas kepada orang lain, Anda telah memperkaya pemahaman Anda sendiri sampai pada titik di mana Anda dapat menyampaikannya di luar buku dan pikiran Anda.

  • Terakhir, jangan takut belajar dengan cara yang sulit, buat tangan Anda kotor, buat kesalahan. Ini juga bisa disebut pengalaman. Sebagai contoh yang lebih praktis sehubungan dengan pertanyaan Anda tentang proyek-proyek dengan basis kode yang berat dan jumlah file yang besar, lakukan latihan ini: gunakan satu file untuk pekerjaan Anda. Sungguh aku tidak bercanda. Pertanyaan yang sama ini sebenarnya muncul di perusahaan saya saat ini dan sebelumnya. Di sini pengembang lain mengamati bahwa saya lebih suka menyimpan satu file untuk setiap kelas. Ini tampak asing baginya dan, dalam hal yang terkait, ia juga tidak suka kelas parsial. Jadi salah satu cara bagi Anda untuk mengetahui kapan atau di mana pantas untuk membagi logika menjadi file-file yang terpisah adalah dengan memulai hanya dengan satu file. Setelah Anda mempraktikkan aturan satu file pada banyak proyek semoga menambah kompleksitas, Anda dapat menjalankan proyek di mana Anda memiliki begitu banyak kelas dalam satu file yang Anda rasa sulit untuk dibaca atau karena kontrol versi menjadi sulit untuk dikolaborasikan. Pada titik ini, Anda ingin membuat file terpisah untuk mengelompokkan berbagai kelas. Dengan preferensi Anda, Anda dapat memutuskan sejak awal bahwa Anda menyukai semua kelas data dalam satu file. Kemudian lagi mungkin nanti, Anda dapat memutuskan bahwa Anda suka file terpisah bahkan antara kelas data sebagai grup.


+1 Jawaban yang bagus. Harus mengatakan duduk dengan programmer yang berpengalaman dapat mengintimidasi ketika memulai untuk orang baru juga. Mempercepat hal-hal yang akan menghabiskan banyak waktu bagi Anda. Tetapi, tergantung pada jenis orang Anda, hal-hal seperti itu bisa menjadi faktor pendorong dan menyalakan sebagian dari api itu di perut Anda. Mendorong Anda untuk ingin menendang pantat.
Terrance

1

Anda tidak perlu memiliki ide bagus untuk memulai pemrograman sesuatu. Saya akan mulai dari bagian yang mudah. Seperti, program yang sudah Anda gunakan. Cobalah untuk membuat sesuatu yang Anda sudah tahu cara kerjanya. Hadapi masalah Anda, jadi Anda akan mempelajarinya lebih cepat. Setelah Anda memiliki lebih banyak pengalaman, Anda akan mulai memiliki beberapa ide program yang bagus untuk membuat hidup Anda lebih mudah saat pemrograman, atau hanya program yang baik untuk melakukan sesuatu yang tidak pernah Anda pikirkan sebelumnya. Saya telah memprogram Java selama hampir satu tahun, dan bahasa lain selama beberapa tahun. Butuh waktu untuk mulai melakukan apa yang benar-benar ingin saya lakukan. Saya baru saja mulai mengerjakan barang-barang saya sendiri. Terima kasih kepada StackOverflow. Saya tidak tahu tentang itu sebelumnya.


1

Jadi ada satu ton jawaban, jadi maafkan saya jika saya mengulangi banyak dari apa yang telah dikatakan, tapi ini 2 sen saya.

Pertama-tama pilih ide. Gagasan apa pun akan baik-baik saja, sesuatu yang sederhana mungkin akan lebih baik daripada besar. Proyek memiliki kecenderungan untuk tumbuh dalam cakupannya dengan sangat cepat (beberapa menyebutnya fitur creep).

Selanjutnya buat kerangka untuk proyek tersebut. Ini akan membutuhkan sedikit pengetahuan arsitektur dan desain dan Anda mungkin akan salah sepuluh kali pertama Anda mencobanya - saya lakukan. Cukup susun struktur file yang layak dan mungkin kerangka kecil kode yang menunjukkan bagian-bagian penting dari sistem.

Simpan kerangka di VCS Anda (pilih racun Anda dengan yang ini dan tahan ketika itu mengarah ke perang suci). Setelah Anda mulai menggunakan VCS, terus-menerus menggunakannya untuk perubahan kecil menjadi kebiasaan, tetapi pastikan untuk memulai.

Sekarang pilih fitur kecil, tetapi penting untuk sistem dan buatlah. Jangan khawatir untuk memastikan Anda memiliki semua yang dienkapsulasi dengan sempurna dan memiliki desain "terbaik" (yang akan berkembang dengan sistem). Hanya dapatkan sesuatu yang akan berhasil. Juga mendapatkan beberapa unit test akan membantu memastikan Anda tahu apa yang terjadi ketika sesuatu rusak, jika Anda menjalankan tes secara teratur.

Bangun sistem Anda. Ini juga akan menjadi saat yang tepat untuk mendapatkan sistem pembangunan otomatis dan integrasi berkelanjutan. Jika Anda tidak tahu apa itu, maka pelajarilah dan cobalah, atau lanjutkan dengan risiko Anda sendiri; bagaimanapun tetap bekerja.

Sekarang pilih fitur lain dan ulangi dan ulangi dan ulangi.

Setelah Anda berpikir itu bekerja dengan baik, perlihatkan kepada teman. Teman itu tidak harus tahu cara memprogram atau bahkan tahu apa yang dikerjakan program. Satu Anda akan merasa senang menunjukkan kepada seseorang dan dua itu akan membantu Anda tahu persis apa yang sistem lakukan.

Jika Anda sampai pada titik di mana Anda sangat percaya diri dengan apa yang Anda buat, lepaskan secara online dan coba dan dapatkan umpan balik. Hub repositori atau sub-redit programer mungkin memberi Anda kritik membangun. Coba dan temukan profesor CS / SE dan minta dia melihatnya. Mungkin bertanya kepada programmer profesional. Hanya dapatkan pendapat programmer lain.

Setelah Anda selesai (atau mungkin sebelumnya) Anda akan menyadari bahwa kode yang Anda tulis pada awalnya jauh lebih buruk daripada yang Anda buat baru-baru ini. Itu sangat alami dan terjadi pada kita semua. Anda sekarang perlu menemukan proyek baru dan mempelajari sesuatu yang baru - mungkin strategi pengujian baru atau cara menggunakan Arsitektur Berorientasi Layanan.


1

Sesuatu yang dapat membantu adalah memikirkan masalah sederhana yang Anda miliki sehari-hari di mana sesuatu yang mungkin Anda lakukan dengan pensil dan kertas dapat diganti dengan program.

Ini memberi Anda masalah yang relatif sederhana dengan solusi yang cukup dikenal yang hanya membutuhkan tingkat otomatisasi. Perlu diingat ini tidak perlu menjadi MS Word / WordPad / NotePad berikutnya; hanya sesuatu yang memecahkan masalah (sederhana) Anda.

Misalnya masalah yang saya terus implementasi ulang ketika bekerja dengan bahasa baru adalah aplikasi pencatat waktu sederhana. Aplikasi ini digunakan untuk melacak jam yang dapat ditagih ke berbagai proyek selama sehari. Sebuah program yang cukup sederhana dengan banyak gotcha kecil, seperti bagaimana Anda menangani reboot di tengah hari atau bagaimana Anda menambah / menghapus item dari daftar Anda.


1

Saya pikir bagian dari masalahnya adalah ketika Anda membaca buku pemrograman, mereka hanya mengajarkan Anda bahasa. Mereka gagal menyebutkan bahwa untuk memprogram hampir semua hal, Anda memerlukan akses ke pemrograman PERPUSTAKAAN dan SDKS, dll. Mengetahui bahasanya sayangnya tidak cukup.


1

Saya kira masalah Anda berasal dari: 1. Konflik ada antara teori dan praktek, dan juga bahwa ... 2. ... Anda harus menyadari bahwa kode Anda akan dijalankan oleh kode orang lain. 3. Anda tidak dapat membuat kode sesuatu jika Anda tidak tahu apa yang bisa Anda buat. 4. Anda tahu setengah dari kesulitannya

  1. Mengetahui bahasa secara teori tidak berarti Anda "berbicara": perbedaan antara membaca bahasa Inggris dan berbicara itu. Juga sejumlah besar alat berbeda yang tersedia untuk menyusun, menautkan, mengedit kode sumber akan membuat kepala Anda berputar.

  2. ketika mempelajari cara memprogram, sebagian besar jika waktu terminal digunakan untuk input / output teks, karena ini adalah cara paling sederhana untuk berurusan dengan pemrograman. Bahkan, programmer menggunakan perpustakaan (seperti Qt), frameworks (django kurasa) dan kode pintas lainnya agar menjadi produktif. Tentu saja jika Anda merasa dapat menulis roda sendiri, jangan menciptakannya kembali dan membaca buku tentang desain kompiler dan desain kernel: ada banyak hal yang perlu dipelajari: mungkin Anda merasa bodoh untuk menghapus aplikasi yang tidak memerlukan banyak teknis.

  3. Temukan sesuatu! Tentu saja Anda dapat melakukan editor teks, permainan, dll. Masalahnya adalah, Anda tidak akan melakukan itu jika Anda tidak melihat alasan untuk: program ini tidak akan berguna bagi Anda jika semua yang Anda pikirkan telah dibuat . Personnaly Saya masih bermimpi untuk dapat membuat kode protokol P2P yang terdesentralisasi seperti facebook dengan chat, pesan offline, dll semuanya dalam satu sehingga dapat digunakan dengan perangkat nirkabel yang tertanam. Internet memberi banyak kemungkinan, jangan lupa untuk memikirkannya.

  4. Sebenarnya teori itu perlu untuk dipraktekkan, tetapi bukan itu saja: algoritma dan teknik bukan bagian dari teori pemrograman, ada banyak paradigma dan cara "standar" lain untuk melakukan kode Anda: pola desain, daftar tertaut, dll.


1

Mungkin Anda bisa memilih bahasa scripting untuk memulai. Saya mulai pemrograman dengan bahasa C. Menurut pendapat saya bahasa C mudah untuk memulai, tetapi lebih banyak waktu diperlukan untuk mengetahui algoritma dan sesuatu tentang sistem operasi. Dan setiap kali saya berolahraga hanya dengan GUI DOS, itu membuat saya depresi.

Dan kemudian saya memilih bahasa scripting bernama ActionScript untuk memulai. Bahasa scripting adalah bahasa berorientasi objek, dan dapat mengontrol perilaku film Flash. Bahasa scripting mudah untuk melakukan beberapa pekerjaan yang dekat dengan domain masalah , seperti trace("HelloWorld")di ActionScript untuk menghasilkan string. Dan ia memiliki IDE yang kuat untuk memungkinkan Anda checkout jika program Anda berjalan dengan baik.

Singkatnya, jika Anda ingin memulai pemrograman dengan cara cepat , bahasa skrip mungkin merupakan pilihan yang baik :-)


1

Tulis spesifikasi. Apa yang Anda ingin program Anda lakukan? Layar (jika ini adalah program berbasis UI) logika, input / output, dll. Biarkan ruang lingkup terbatas pada apa yang dapat Anda lakukan dalam jumlah waktu yang wajar (satu minggu? Satu bulan?).

Kemudian bangunlah. Tetap pada spesifikasi, membuatnya bekerja sesuai dengan kebutuhan spesifikasi. Tentu Anda akan menemukan gangguan, tentu Anda harus melakukan riset karena Anda belum pernah menghadapi masalah tertentu sebelumnya, tetapi Anda akan membangun sesuatu yang ingin Anda bangun. Ini berbeda dengan membangun sesuatu yang baru saja Anda 'bangun'.

Setelah selesai, perbaiki kode Anda, cobalah membuatnya lebih efisien. Kemudian jika Anda merasa program Anda masih belum selesai, mulailah dari awal, perbaiki spesifikasi, perbaiki kode dan terus lakukan ini.

Ingat, sebagian besar perangkat lunak komersial menyelesaikan suatu kebutuhan .. Sangat penting untuk mendefinisikan kebutuhan, dan solusi untuk memenuhi kebutuhan itu sebelum benar-benar menyelesaikan masalah. Dan seiring meningkatnya kebutuhan, perangkat lunak Anda juga akan tumbuh seiring waktu!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.