Bagaimana saya beralih dari bisa menulis kode menjadi pengembang yang baik?

Saya frustrasi dengan kurangnya penjelasan konkret tentang cara beralih dari kemampuan untuk skrip (bash, awk) dan menulis aplikasi sederhana (c, php, python) untuk merancang dan mengembangkan perangkat lunak yang lebih besar, lebih rumit. Tampaknya di satu sisi ada buku-buku bahasa pemrograman dan di sisi lain ada buku rekayasa perangkat lunak / proyek manajemen yang dirancang untuk tim-tim programmer.

Saya sudah membaca banyak dari keduanya. Saya telah membaca XP / Agile klasik dan memiliki pemahaman teoritis yang layak tentang proses pengembangan perangkat lunak. Saya suka membaca kode orang lain dan bisa mengikutinya dengan cukup baik. Tetapi ketika saya memiliki ide untuk sebuah proyek atau ingin beralih dari "ini masalahnya / perlu" ke "inilah solusinya", pikiran saya kosong dan saya tidak tahu harus mulai dari mana.

Apakah saya hanya meretasnya? Apakah ada alur kerja terstruktur untuk pengembang individual yang tidak bekerja dalam tim atau untuk rumah perangkat lunak besar? Saya benar-benar tidak memiliki keinginan untuk mendapatkan PMP atau bekerja untuk perusahaan perangkat lunak. Saya hanya mencari alur kerja yang efektif, efisien, dan praktis.

Menurut pendapat saya, Anda menjadi pengembang yang baik dengan memiliki pengalaman dan bekerja dengan berbagai cara dalam melakukan sesuatu. Anda telah menyatakan bahwa Anda memiliki masalah mulai dari "inilah ide saya" hingga "inilah solusi saya". Itu sesuatu yang lebih ke arah metodologi pengembangan perangkat lunak serta menjadi pengembang yang berpengalaman.

Menggunakan metodologi pengembangan perangkat lunak lebih dari "hanya meretas kode", dan metodologi ini menyediakan alur kerja terstruktur. Di sana Agile family menyediakan struktur yang baik untuk tim pengembangan yang lebih kecil (atau individu) yang dapat Anda ikuti untuk membantu Anda beralih dari fase "ide" ke fase "produk jadi".

Ada beberapa hal yang saya pelajari selama bertahun-tahun dari orang lain dan melalui mengerjakan berbagai proyek, seperti:

• Buat semuanya dapat diuji, ini akan membuat hidup Anda jauh lebih mudah;
• Anda tidak dapat berharap untuk memiliki desain yang sempurna dan dapat merancang aplikasi perusahaan / judul game terbesar berikutnya / menyisipkan lebih banyak di sini, tanpa memiliki pengalaman dalam melakukannya;
• Sulit untuk merancang perangkat lunak yang baik jika Anda belum memiliki pengalaman melakukannya dan belajar dari orang lain;
• Anda tidak akan pernah memiliki desain yang sempurna pertama kali, bahkan sebagai pengembang yang berpengalaman - semuanya berubah dan karenanya; desain Anda mungkin juga;
• Tuliskan semuanya: Menulis / menggambar / papan tulis / melukis / apa pun yang membuat Anda merasa nyaman, itu membuat hidup lebih mudah jika Anda menuliskannya. Seperti desain GUI, diagram kelas, dll. Dalam pengalaman saya, hanya akan "meretas sesuatu bersama" memiliki potensi gagal serempak;
• Jangan menemukan kembali roda, Anda tidak harus melakukannya. Jika Anda mencoba menerapkan HashMap Anda sendiri, maka Anda mungkin melakukan sesuatu yang salah. Cari tahu berbagai hal, dan pikirkan sebelum Anda menulis kode.

Semoga ada yang bisa membantu.

Menurut saya, seperti dalam profesi apa pun, untuk menjadi profesional yang baik, semua yang diperlukan - selain pembentukan teoretis - adalah pengalaman .

Sebagai seorang dokter tidak bisa menjadi baik dengan hanya kelas-kelas yang diambil di sekolah kedokteran, atau seorang pengacara tidak dapat mengetahui semua sisi politik menjadi perjalanan dengan hanya gelar, menjadi pengembang yang baik membutuhkan pengalaman dan waktu.

Pengalaman tidak datang dengan membaca kode pihak ketiga. Jika Anda mendapatkan mahasiswa kedokteran, ia akan dapat menunjukkan banyak prosedur, penyakit, obat-obatan dll., Tetapi aplikasi sebenarnya dari hal-hal ini (kapan menerapkan satu prosedur, penyakit apa yang didiagnosis, dll.) Hanya datang dengan pengawasan dan pengalaman.

Karena Anda tidak ingin bekerja untuk perusahaan besar (atau perusahaan mana pun dalam hal ini), saya sarankan Anda mulai dengan mengembangkan aplikasi kecil, selangkah demi selangkah. Mengembangkan perangkat lunak sendiri membutuhkan banyak waktu, percayalah.

Hal lain yang saya sarankan kepada Anda untuk menjadi pengembang / insinyur perangkat lunak yang baik, adalah berkontribusi pada perangkat lunak sumber terbuka. Banyak orang telah menghasilkan banyak uang (dan pengalaman, btw) dengan membantu mengembangkan perangkat lunak open source dan memberikan konsultasi sesudahnya. Mereka telah membuat nama untuk diri mereka sendiri dengan kontribusi mereka ke open source.

Bagaimanapun, saya pikir tidak ada jalan pintas untuk mendapatkan pengalaman, dan itu harus dilakukan dengan disiplin dan kesabaran .

Anda dapat mulai dengan meningkatkan kode orang lain. Ambil beberapa proyek yang Anda punya dan tambahkan fitur padanya. Anda harus memutuskan fitur apa yang akan dilakukan, dan bagaimana seharusnya melakukannya. Bekerja dalam kerangka kode yang ada, rancang solusi Anda.

Dan jangan takut untuk meretas barang. Banyak pengembangan baru dilakukan dengan memperbaiki (atau lebih disukai menulis ulang) prototipe cepat dan kotor. Silakan dan gunakan setiap praktik terburuk dan antipattern dalam buku ini, hanya melakukan sesuatu yang melakukan apa yang Anda inginkan. Lalu, kembali dan desain dengan benar. Biasanya, saya mendapati diri saya berpikir "Anda tahu, cara yang lebih baik untuk melakukan ini adalah ..." sementara saya meng-coding beberapa parameter konfigurasi di 800-baris tiga prosedur monstrositas saya.

Saya tahu itu saat ini tidak populer, tetapi teknik analisis terstruktur sangat membantu saya menangani desain perangkat lunak. Bermain-mainlah dengan membuat beberapa bagan gelembung dan DFD untuk merasakan pembusukan masalah dan merancang berbagai bagian sistem untuk bekerja bersama.

Seperti yang dikatakan orang lain, pengalaman berasal dari menulis kode. Tetapi Anda juga harus meminta orang lain meninjau kode Anda jika memungkinkan. Seorang programmer yang lebih berpengalaman dapat menunjukkan masalah dalam kode Anda dan menunjukkan cara yang lebih baik dalam melakukan sesuatu. Berkontribusi pada proyek sumber terbuka akan memberi Anda kesempatan untuk melakukan keduanya.

Bagi saya, ini membantu untuk memecah sebagian besar perangkat lunak menjadi potongan-potongan kecil. Dan kemudian memecah potongan-potongan itu menjadi bagian yang lebih kecil dan seterusnya. Setiap program perangkat lunak adalah sekumpulan logika kecil.

Pertimbangkan sebuah blog, misalnya. Anda ingin dapat membuat dan mengedit posting yang dapat dibaca orang lain. Segera Anda dapat membagi proyek menjadi admin dan bagian publik. Minimal, admin akan meminta pengguna admin, halaman login, dan bagian untuk mengelola blog. Bagian untuk mengelola blog dapat dipecah menjadi antarmuka CRUD (Buat, Baca, Perbarui, Hapus). Membuat posting blog baru akan memerlukan pemeriksaan untuk memastikan pengguna admin memiliki hak yang tepat, formulir, validasi formulir, dan kemampuan untuk menyimpan ke database. Dan seterusnya.

Semakin Anda memecahkan masalah atau fitur turun, semakin mudah dikelola. Itu memecah belah dan menaklukkan. Setelah Anda dapat memetakan perangkat lunak Anda seperti ini, Anda dapat melihat bagaimana bagian-bagian yang berbeda berinteraksi satu sama lain. Di mana Anda dapat mengulangi kode? Apa yang bisa diabstraksikan? Ini harus menjadi proses berulang saat Anda merencanakan dan saat Anda menulis kode itu sendiri.

Saya akan merekomendasikan mencari tahu apa set fitur minimum Anda untuk memulai dan mengimplementasikannya sebelum menambahkan bagian lain ke dalamnya. Anda ingin membuat kode secara defensif sehingga perubahan di masa depan tidak akan terlalu sulit, tetapi pada saat yang sama, Anda tidak ingin menerapkan setengah fitur yang mungkin tidak pernah selesai. Ini adalah garis yang sulit untuk berjalan antara tetap fleksibel dan rela membunuh dengan kejam kesayangan Anda, untuk meminjam referensi sastra. Menjadi ahli dalam tindakan penyeimbangan tertentu hanya berasal dari pengalaman.

Dan itulah sebabnya, seperti jawaban yang lain katakan: pengalaman. Satu-satunya cara untuk mendapatkannya adalah mulai saja. Jangan terlalu khawatir tentang membuatnya sempurna sejak awal. Pertama buat kode berfungsi, lalu buat indah, lalu buat cepat.

Juga, tidak seperti paragraf ini, jangan tempel keamanan pada akhirnya sebagai renungan. Anda harus memiliki gagasan tentang cara perangkat lunak Anda dapat dikompromikan, tetapi sebagai permulaan, jangan pernah mempercayai input pengguna apa pun.

Saya tahu Anda mengatakan Anda tidak ingin bekerja untuk perusahaan perangkat lunak, tetapi itu adalah tempat yang baik untuk mendapatkan pengalaman yang banyak dibicarakan oleh jawaban lain. Dan apakah Anda ingin bekerja pada proyek-proyek besar, paparan pekerjaan dan gaya kerja orang lain adalah hal yang baik untuk dimiliki.

Anda tidak dapat mencoba Pair Programming sendiri, misalnya. Dan jika Anda dipasangkan dengan seseorang yang lebih pintar dari Anda, Anda mendapatkan manfaat tambahan dari mendapatkan praktik yang lebih baik dari mereka sambil mendapatkan pengalaman dalam metodologi itu.

BTW, saya sudah mempraktikkannya untuk mencoba bekerja dengan kelompok-kelompok di mana saya merasa berada di bawah rata-rata dalam pengalaman, keterampilan, dan sejenisnya. Ini sangat meningkatkan permainan saya. Jauh lebih sulit untuk melakukannya sendiri atau di mana Anda adalah pria yang "berpengalaman".

Apa yang Anda cari adalah keterampilan memecahkan masalah . Saya perhatikan bahwa diasumsikan bahwa pengembang sudah bisa melakukan ini, yang konyol. Untungnya, pemecahan masalah adalah keterampilan umum, yang digunakan dalam matematika, penelitian, kehidupan sehari-hari dan sebagainya.

Terutama, Anda harus mengikuti metode ilmiah, dengan embel-embel.

1. Anda memiliki masalah (gunakan alat dan teknik untuk membantu mendefinisikan ini)
2. Anda membuat hipotesis solusi (pola dan pengalaman membantu)
3. Uji hipotesis (Anda mungkin tidak memiliki kode di sini)
4. Ulangi langkah 2 dan 3 sampai hipotesis bertahan. Anda sekarang memiliki teori (program kerja untuk memecahkan masalah)
5. Kembangkan eksperimen untuk menekankan teori, mencari lubang (test case!)
6. Jika test case bertahan, Anda punya solusinya! Kalau tidak, bilas dan ulangi

Perhatikan bahwa ini adalah level yang agak tinggi. Setiap langkah biasanya melibatkan beberapa langkah, seperti menentukan apa masalah sebenarnya. Sebagai contoh, lihat memecahkan masalah kata dalam matematika. Anda mengumpulkan fakta (alat), dan menentukan apa yang sebenarnya diinginkan. Kemudian, Anda memeriksa fakta-fakta Anda, mencoba memetakannya ke solusinya.

Ini akhirnya menjadi sub masalah dari masalah utama. Jadi, ikuti langkah-langkahnya lagi. Kami membutuhkan barang setengah jadi untuk mendapatkan hasil akhir, jadi itu menjadi masalah baru kami. Ini menguraikan masalah menjadi beberapa bagian kecil, mudah dipahami. Ketika setiap bagian dipecahkan, solusinya disatukan.