Proyek hampir selesai, tetapi kode spaghetti prosedural. Apakah saya menulis ulang atau terus mencoba mengirimkannya? [Tutup]

Saya seorang pengembang web pemula (satu tahun pengalaman).

Beberapa minggu setelah lulus, saya ditawari pekerjaan untuk membangun aplikasi web untuk perusahaan yang pemiliknya tidak terlalu ahli dalam bidang teknologi. Dia merekrut saya untuk menghindari pencurian idenya, tingginya biaya pengembangan yang dibebankan oleh sebuah perusahaan jasa, dan untuk memiliki seseorang yang masih muda dia bisa percayai untuk mempertahankan proyek untuk jangka panjang (saya sampai pada kesimpulan ini sendiri jauh setelah dipekerjakan ).

Sombong ketika saya dulu, dengan ijazah ilmu komputer, saya menerima tawaran itu dengan berpikir saya bisa membangun apa saja.

Saya memanggil tembakan. Setelah beberapa penelitian saya menetap di PHP, dan mulai dengan PHP biasa, tidak ada objek, hanya kode prosedural yang jelek. Dua bulan kemudian, semuanya menjadi berantakan, dan sulit untuk membuat kemajuan. Aplikasi web sangat besar. Jadi saya memutuskan untuk memeriksa kerangka kerja MVC yang akan membuat hidup saya lebih mudah. Di situlah saya menemukan anak keren di komunitas PHP: Laravel. Saya menyukainya, mudah dipelajari, dan saya mulai mengkodekan segera. Kode saya terlihat lebih bersih, lebih teratur. Itu terlihat sangat bagus.

Tetapi sekali lagi aplikasi web itu sangat besar. Perusahaan menekan saya untuk memberikan versi pertama, yang ingin mereka gunakan, dan mulai mencari pelanggan.

Karena Laravel menyenangkan untuk dikerjakan, itu membuat saya ingat mengapa saya memilih industri ini sejak awal - sesuatu yang saya lupa ketika terjebak dalam sistem pendidikan yang buruk.

Jadi saya mulai mengerjakan proyek-proyek kecil di malam hari, membaca tentang metodologi dan praktik terbaik. Saya mengunjungi kembali OOP, beralih ke desain dan analisis berorientasi objek, dan membaca buku Paman Bob, Clean Code .

Ini membantu saya menyadari bahwa saya benar-benar tidak tahu apa-apa. Saya tidak tahu bagaimana membangun perangkat lunak CARA YANG BENAR. Tetapi pada titik ini sudah terlambat, dan sekarang saya hampir selesai. Kode saya tidak bersih sama sekali, hanya kode spaghetti, sangat menyebalkan untuk memperbaiki bug, semua logika ada di controller, dan ada sedikit desain berorientasi objek.

Saya terus-menerus berpikir bahwa saya harus menulis ulang seluruh proyek. Namun, saya tidak bisa melakukannya ... Mereka terus bertanya kapan semuanya akan selesai.

Saya tidak bisa membayangkan kode ini digunakan di server. Ditambah lagi, saya masih belum tahu apa-apa tentang efisiensi kode dan kinerja aplikasi web.

Di satu sisi, perusahaan sedang menunggu produk dan tidak bisa menunggu lagi. Di sisi lain saya tidak dapat melihat diri saya melangkah lebih jauh dengan kode yang sebenarnya. Saya bisa menyelesaikan, membungkusnya dan menyebarkan, tetapi hanya Tuhan yang tahu apa yang mungkin terjadi ketika orang mulai menggunakannya.

Apakah saya menulis ulang, atau terus mencoba mengirim, atau apakah ada opsi lain yang saya lewatkan?

Anda telah tersandung pada tumit achilles sebagian besar pendidikan CS: mereka mengajarkan Anda alat dan teknik, tetapi bukan perdagangan. Membangun perangkat lunak adalah keahlian, yang hanya dapat Anda peroleh selama bertahun-tahun latihan dan pengalaman menggunakan perangkat lunak Anda (pengguna jauh lebih keras daripada guru). Membangun perangkat lunak juga cukup sering bisnis, di mana tujuan bisnis dapat mengesampingkan ambisi teknis.

Pertama-tama, kirim. Jika Anda menunjukkan kepada pemilik bisnis perangkat lunak, dan mereka merasa siap untuk dikirim, maka kirimkan. Jika tidak ke titik itu, tapi tutup, selesaikan. Satu-satunya perangkat lunak yang penting adalah apa yang sebenarnya digunakan. Satu-satunya bisnis perangkat lunak yang menghasilkan uang adalah bisnis yang memiliki produk.

Kedua, Anda telah belajar banyak hal yang berharga, jadi Anda harus menghargai pengalaman atas apa yang telah diajarkannya kepada Anda :

1. Kode selempang tanpa rencana atau arsitektur adalah resep untuk bencana
2. Ada lebih banyak pemrograman daripada menulis kode
3. Pemilik bisnis non-teknis sering tidak memahami dampak dari keputusan teknis (seperti siapa yang akan dipekerjakan), dan tergantung pada pengembang untuk menjelaskan berbagai hal kepada mereka.
4. Sebagian besar masalah sudah diselesaikan jauh lebih baik daripada yang Anda akan menyelesaikannya, dalam kerangka kerja yang ada. Membayar untuk mengetahui kerangka kerja yang ada dan kapan menggunakannya.
5. Orang-orang yang baru keluar dari sekolah yang ditugaskan untuk proyek besar dengan sedikit bimbingan cenderung menghasilkan semangkuk kode spageti. Ini normal.

Berikut ini beberapa saran untuk Anda tentang cara melanjutkan:

1. Berkomunikasi, berkomunikasi, berkomunikasi. Anda harus sangat terbuka dan jujur ​​tentang keadaan proyek dan ide-ide Anda tentang cara melanjutkan, bahkan jika Anda tidak yakin dan melihat banyak jalur. Ini membuat pemilik bisnis memiliki pilihan tentang apa yang harus dilakukan. Jika Anda menyimpan pengetahuan untuk diri sendiri, Anda menghilangkan pilihan.
2. Tahan godaan penulisan ulang penuh. Saat Anda menulis ulang, bisnis tidak memiliki produk. Juga, penulisan ulang jarang menghasilkan sebagus yang Anda bayangkan. Alih-alih pilih arsitektur dan migrasikan basis kode itu secara bertahap. Bahkan basis kode yang mengerikan dapat diselamatkan dengan cara ini. Baca buku tentang refactoring untuk membantu Anda.
3. Pelajari tentang pengujian otomatis / pengujian unit . Anda harus membangun kepercayaan pada kode, dan cara untuk melakukannya adalah menutupinya dengan tes otomatis. Ini sejalan dengan refactoring. Selama Anda tidak memiliki tes, uji secara manual dan komprehensif (cobalah untuk memecahkan kode Anda, karena pengguna Anda akan melakukannya). Catat semua bug yang Anda temukan sehingga Anda dapat memprioritaskan dan memperbaikinya (Anda tidak akan punya waktu untuk memperbaiki semua bug, tidak ada perangkat lunak yang mengirimkan bug-bebas di dunia nyata).
4. Pelajari tentang cara menggunakan aplikasi web dan menjalankannya. Buku Operasi Web: Menjaga Data Tepat Waktu adalah awal yang baik.

Ini terdengar seperti setiap sistem lain yang telah saya gunakan untuk memperbaikinya.

Tenang, ini terjadi pada banyak orang. Seorang yunior dilemparkan ke ujung dalam tanpa pengalaman, yang tidak memiliki bantuan, tidak ada dukungan, dan tidak ada panduan bukanlah resep untuk sukses. Mempekerjakan dan mengharapkan seorang programmer junior untuk membangun sistem baru dari awal yang bekerja dengan baik, berkinerja baik dan dapat dipelihara tidak realistis sama sekali. Sialan Anda beruntung jika semua itu terjadi dengan programmer senior.

Menurut pendapat saya, Anda harus berterus terang. Ini tidak akan menyenangkan. Katakan kepada mereka bahwa Anda telah melakukan yang terbaik, itu berhasil (kebanyakan), tetapi Anda khawatir itu mungkin tidak berkinerja baik dan akan ada banyak bug ( selalu ada bug). Ini perlu ditinjau oleh programmer senior, dan mereka harus dapat memperbaiki masalah kinerja / keamanan yang mencolok dengan cukup cepat. Atau mereka dapat menyebarkannya dan menyilangkan jari mereka. Itu akan baik-baik saja, atau naik dalam asap. Mungkin Anda dapat memperbaiki masalah saat masalah itu muncul. Jika Anda memiliki basis pengguna yang besar, mungkin tidak.

Atau Anda bisa melakukan apa yang dilakukan kebanyakan orang dalam situasi ini: ambil uangnya, hilang dan biarkan mereka mengatasinya. Saya akan menyerahkan kepada Anda untuk mencari tahu apa pilihan etisnya.

Sunting (karena pertanyaan ini memiliki banyak suara, saya mungkin juga menambahkan beberapa konten lagi)

Bagian dari kegembiraan menjadi seorang programmer adalah bahwa orang-orang non-teknis (mungkin manajer Anda, pasti sisa bisnis) tidak tahu apa yang Anda lakukan. Ini baik dan buruk. Bagian yang buruk adalah Anda harus terus-menerus menjelaskan cara kerja proyek pengembangan perangkat lunak. Perencanaan, persyaratan, tinjauan kode, pengujian, penggunaan, dan perbaikan bug. Adalah tugas Anda untuk menjelaskan pentingnya pengujian, dan menyisihkan waktu untuk menguji. Anda harus bertahan di sini. Orang tidak akan mengerti pentingnya ( "tidak bisakah kita mulai menggunakannya?") tetapi begitu mereka mulai menguji (bukan di lingkungan langsung!) mereka akan segera memahami manfaatnya. Salah satu alasan mengapa mereka mempekerjakan Anda adalah karena mereka tidak tahu apa-apa tentang pengembangan perangkat lunak, jadi terserah kepada Anda untuk mendidik mereka. Anda perlu menekankan pentingnya pengujian dan perbaikan bug di sini - ingat, mereka bukan programmer, mereka tidak tahu perbedaan antara pembagian dengan nol dan tag html yang rusak.

Seringkali banyak masalah yang muncul sebenarnya bukan bug. Mereka akan menjadi masalah kegunaan, persyaratan yang terlewatkan, persyaratan yang telah berubah, harapan pengguna (mengapa saya tidak dapat menggunakan ini di ponsel saya?) Dan kemudian bug nyata yang sebenarnya. Anda harus menyelesaikannya sebelum ditayangkan - sering kali banyak bug dapat diperbaiki atau diperbaiki beberapa hari kemudian. Jika orang mengharapkan sistem yang sempurna mereka akan mengalami banyak rasa sakit. Jika mereka mengharapkan bug, hidup Anda akan jauh lebih mudah selama beberapa minggu ke depan.

Oh dan jangan bingung pengujian pengguna dengan pengujian unit atau dengan pengujian sistem.

• Unit Testing - apakah fungsi kode saya mengembalikan nilai yang benar
• Pengujian Sistem - apakah ada kesalahan saat saya mengklik X
• User Acceptance Testing (UAT) - apakah program sesuai dengan persyaratan? Apakah itu melakukan apa yang mereka minta agar Anda lakukan? Bisakah ini ditayangkan?

Jika Anda belum menuliskan persyaratan dari apa yang mereka minta Anda lakukan, UAT akan jauh, jauh lebih sulit. Di sinilah banyak orang jatuh. Memiliki apa yang mereka inginkan agar sistem dituliskan di atas kertas akan membuat hidup Anda jauh lebih mudah. Mereka akan berkata, "Mengapa tidak dilakukan X?" dan Anda bisa mengatakan "Anda mengatakan kepada saya untuk membuatnya Y". Jika program salah, perbaiki. Jika persyaratannya salah, perbaiki dokumen, minta satu atau dua hari ekstra (tidak, bersikeras), buat perubahan, perbarui dokumentasi dan uji ulang.

Setelah Anda melewati proses ini beberapa kali Anda dapat mulai melihat Agile .. tapi itu dunia lain :)

TL; DR Testing bagus

Setiap kali Anda memulai dari awal, Anda hampir pasti akan membuat kesalahan dengan jumlah yang sama atau lebih karena Sindrom Sistem Kedua . Kesalahan baru Anda akan berbeda, tetapi jumlah waktu yang dibutuhkan untuk debugging akan sama dan juga akan putus asa tentang bagaimana itu tidak cocok. Ini juga akan menunda penyebaran ke dalam produksi atau penyebaran fitur baru jika versi pertama digunakan, yang akan menjadi masalah serius bagi perusahaan. Joel Spolsky menyebutnya "kesalahan strategi tunggal terburuk" yang dapat dilakukan oleh perusahaan atau pengembang mana pun.

Pendekatan yang disarankan adalah untuk membersihkan kekacauan awal sedikit demi sedikit selama pemeliharaan. Dan bahkan tidak mencoba untuk memperbaiki itu hanya demi itu. Selain itu, manajer biasanya melihat itu sebagai pemborosan uang (yang sering terjadi) dan itu membawa risiko yang tidak perlu untuk memperkenalkan bug baru. Setelah Anda dengan susah payah men-debug kode, itu mungkin tidak cantik, tetapi itu akan berhasil. Jadi biarkan sampai Anda perlu menyentuhnya karena alasan lain (baik itu perbaikan bug, fitur baru atau hanya perubahan yang diminta oleh pemasaran). Kemudian bersihkan bagian yang paling sulit untuk disesuaikan. Ini sering disebut Aturan Kepanduan .

Dan pada saat itu Anda tidak perlu berdebat dengan manajer. Cukup sertakan refactoring minimal yang diinginkan dalam perkiraan permintaan. Anda akan belajar melalui pengalaman ketika Anda mampu menghasilkan sedikit karena perusahaan benar-benar dalam perbaikan dan ketika Anda tidak ingin membuat masalah di masa depan dan hanya tidak mengakui kemungkinan dengan cepat meretasnya.

Terakhir, satu lagi bacaan yang direkomendasikan: Big Ball of Mud .

Saya lupa di mana saya pertama kali membacanya, tetapi saya hanya ingin menggemakan, sedikit lebih kuat, apa yang dikatakan orang lain:

Pengiriman adalah fitur.

Tidak ada yang lebih buruk daripada seorang pria yang terus "membersihkan" kode yang ada (mungkin hacky, jelek, kotor) yang bekerja dengan sangat baik , memperkenalkan bug baru, dll. Yang penting di dunia nyata adalah menyelesaikan pekerjaan Anda. Anda sudah melakukannya. Kapal. Jangan tersesat dalam mendesain ulang proyek yang bekerja dengan sangat baik, bahkan jika itu buruk. Saat Anda memperbaikinya, lakukan secara bertahap, dan buat diri Anda sebagai test suite yang baik sehingga Anda memiliki regresi sesedikit mungkin.

Setiap proyek membuat Anda lebih pintar dari sebelumnya. Setelah setiap proyek Anda akan mengumpulkan lebih banyak pengalaman yang akan sangat berguna ketika Anda memilikinya dari awal. Saya tahu sulit untuk tidak meninjau kembali semuanya dan menerapkan apa yang telah Anda pelajari. Tapi ingat:

Sempurna adalah musuh kebaikan.

Untuk klien selalu lebih baik untuk memiliki perangkat lunak yang baik sekarang daripada perangkat lunak yang sempurna yang tidak akan pernah dirilis.

Ini hanya proyek pertamamu. Akan ada lebih banyak proyek di masa depan di mana Anda dapat menerapkan semua yang telah Anda pelajari dari awal.

Saya [...] membaca kode bersih Paman Bob.

Saya terus-menerus berpikir bahwa saya harus menulis ulang seluruh proyek.

Buku ini memiliki bagian bernama, sangat tepat, "The Grand Redesign in the Sky".

Jangan mencoba menulis ulang semuanya karena, jika Anda memiliki waktu untuk membuatnya, Anda tetap akan menghadapi masalah yang sama. Ketika Anda telah selesai mendesain ulang, Anda akan mempelajari hal-hal baru dan akan menyadari bahwa bagian pertama sangat tidak profesional, sehingga Anda ingin menulis ulang lagi.

Mendesain ulang dan menulis ulang itu bagus, tetapi hanya jika dilakukan secara bertahap pada sistem kerja. Seperti yang ditunjukkan pengguna lain, ikuti Aturan Kepanduan, lakukan refactoring kode Anda sedikit demi sedikit saat Anda mengerjakannya.

Kamu baik-baik saja.

Anda mengatakan bahwa kode Anda berfungsi, dan hampir siap untuk dikirimkan, bukan? Dan Anda merasa bahwa kode Anda mungkin jauh lebih baik. Baik.

Dilema Anda banyak mengingatkan saya pada pengalaman pertama saya dengan lepas (dipekerjakan pada tahun ke-2 saya di uni untuk membuat sistem POS multibahasa). Saya melalui pertanyaan tanpa akhir karena saya tidak pernah puas dengan kode, ingin skalabilitas, ingin menemukan kembali roda yang lebih baik ... Tapi saya hanya menunda proyek (seperti, sekitar 12 bulan sekitar) dan ... apa? Setelah Anda menyebarkan hal itu masih perlu banyak pemeriksaan, pengujian, penambalan dll ...

Apakah Anda memiliki pengalaman bekerja dengan basis kode profesional? Banyak basis kode yang penuh dengan kode unik, sulit dipertahankan. Sebuah alternatif untuk menemukan kompleksitas perangkat lunak dengan mencoba membangun sebuah program besar sendiri akan mempertahankan / memperluas kode yang sama berantakannya ditulis oleh orang lain.

Satu-satunya kasus di mana saya telah melihat penulisan ulang lengkap melakukan banyak hal baik adalah ketika tim secara bersamaan mengadopsi toolchain / kerangka kerja baru.

Jika logika yang mendasari (apa yang dilakukan program, bukan bagaimana ia ditata sebagai fungsi, kelas dan sebagainya ...) adalah suara, itu akan bekerja sama baiknya, jadi, Anda berpikir bahwa itu kode spaghetti tidak berarti seharusnya tidak dikerahkan.

Anda harus membiarkan pelanggan Anda memiliki sesuatu yang dapat mereka gunakan. Kemudian ketika mereka meminta Anda untuk memperbaikinya / menambah fungsionalitas Anda memutuskan apakah refactor diperlukan, dan tidak apa-apa untuk memberi tahu pelanggan Anda bahwa "beberapa pekerjaan teknis diperlukan untuk mengintegrasikan fitur baru tersebut". Dengan mana mereka akan mengerti bahwa itu akan menghabiskan lebih banyak uang, dan mereka harus menunggu lebih lama. Dan mereka akan mengerti (atau Anda bisa menarik diri).

Waktu yang lebih baik untuk menulis ulang semuanya adalah ketika pelanggan lain meminta Anda untuk membuat sesuatu yang serupa.

Singkatnya, kecuali Anda dapat menunjukkan bahwa semuanya akan meledak di wajah semua orang jika dikerahkan, menunda penyebaran akan menjadi tidak profesional, dan tidak akan menguntungkan Anda atau pelanggan Anda. Belajar melakukan refaktor kecil sambil memperbaiki bug atau menambahkan fitur baru, itu akan menjadi pengalaman berharga bagi Anda.

Sebagian besar dari apa yang akan saya katakan dalam menanggapi pertanyaan Anda telah diucapkan oleh orang lain. Baca "Hal-Hal yang Seharusnya Tidak Pernah Anda Lakukan, Bagian I" oleh Joel Spolsky (bersama dengan beberapa pos lainnya tentang "astronot arsitektur"). Ingatlah bahwa "yang sempurna adalah musuh dari yang baik". Belajar refactor secara bertahap. Pengiriman itu penting, dll.

Yang ingin saya tambahkan adalah ini: Anda telah ditugasi dengan sesuatu yang dianggap dapat dilakukan oleh seorang lulusan baru yang bekerja dengan anggaran / kerangka waktu startup kecil. Anda seharusnya tidak memerlukan sesuatu yang jauh lebih canggih daripada pemrograman prosedural yang baik, terstruktur, dan baik. (Dan, FYI, "pemrograman prosedural" bukanlah kata yang buruk. Ini adalah keharusan pada tingkat tertentu dalam kebanyakan kasus, dan itu sepenuhnya memadai untuk banyak keseluruhan proyek.)

Pastikan Anda benar - benar melakukan pemrograman prosedural dan terstruktur. Pengulangan dalam kode Anda belum tentu merupakan tanda bahwa Anda membutuhkan struktur polimorfik yang besar. Ini hanya bisa menjadi tanda bahwa Anda perlu mengambil kode yang diulang dan memasukkannya ke dalam subrutin. Aliran kontrol "Spaghetti" mungkin sekadar peluang untuk menyingkirkan global.

Jika ada aspek proyek yang secara sah menyerukan polimorfisme, warisan implementasi, dll., Saya akan menyarankan bahwa mungkin ukuran proyek itu diremehkan.

Jika Anda benar-benar tertarik dengan dilema yang Anda miliki, Anda juga harus membaca "Lean Startup". Banyak saran yang Anda berikan di sini akan lebih cocok dengan Anda jika Anda membaca buku itu. Pada dasarnya, tingkat pembakaran sumber daya adalah musuh terburuk Anda dan tidak ada yang lebih berharga bagi Anda dan organisasi Anda daripada umpan balik pengguna akhir / pelanggan. Jadi, bawa produk Anda ke keadaan layak (Produk Minimum yang Layak - atau MVP) lalu kirimkan keluar (terlepas dari apa kode itu sebenarnya terlihat). Biarkan pelanggan Anda menentukan perubahan dan versi masa depan Anda, bukan sebaliknya. Jika Anda fokus pada pendekatan itu, Anda dan bos Anda akan lebih bahagia dalam jangka panjang.

Untuk alasan yang orang lain telah jelaskan secara menyeluruh, sekarang saatnya untuk menyelesaikan proyek dan mengirimkannya, sesakit mungkin.

Saya hanya ingin menekankan bahwa pengujian aplikasi juga merupakan bagian dari "penyelesaiannya". Jika sebagian besar fungsi tidak dilakukan secara menyeluruh dan mengoreksi hasil dikonfirmasi, maka Anda dibenarkan dalam keprihatinan Anda bahwa orang akan mengalami masalah dengan aplikasi ini ketika itu digunakan.

Tes unit dan tes tingkat tinggi otomatis sangat bagus dan merupakan hal yang harus Anda miliki sebanyak yang Anda bisa sebelum Anda mencoba untuk memperbaiki (atau menulis ulang) aplikasi ini. Tetapi saat ini Anda terutama perlu mengujinya , bahkan jika Anda harus menjalankan setiap tes "dengan tangan" dan mengkonfirmasi fungsi yang benar "dengan mata". Jika Anda dapat mengetahui cara mengotomatiskan pengujian tersebut nanti, itu akan membantu ketika saatnya untuk mulai bekerja pada versi produk selanjutnya.

Beberapa orang memiliki kemampuan untuk duduk di depan proyek perangkat lunak baru sebagai pengguna uji alpha dan membuat kesalahan. Artinya, mereka pandai memecahkan barang. Jika Anda cukup beruntung memiliki orang yang sangat berbakat bekerja dengan Anda, biarkan mereka mencoba aplikasi terlebih dahulu sehingga Anda memiliki kesempatan untuk memperbaiki bug yang jelas lebih awal. Jika Anda harus melakukan tugas ini sendiri, maka:

• Bersikaplah metodis.
• Coba setiap fitur.
• Berpura-puralah Anda seorang pengguna yang tidak berpengalaman dengan aplikasi Anda. Buat kesalahan bodoh dan lihat bagaimana perangkat lunak menanganinya.
• Tuliskan apa yang Anda lakukan sehingga Anda dapat mencobanya lagi setelah Anda berpikir Anda telah memperbaiki masalahnya.

Pertanyaan Anda mengatakan: "Mulai salah, haruskah saya mulai lagi" sementara teks tambahan sebenarnya mengatakan "Proyek selesai, tetapi apakah itu salah, haruskah saya memulai dari awal". Untuk headline pertanyaan saja: Jika jumlah pekerjaan pemrograman yang telah Anda lakukan kecil dibandingkan dengan total pekerjaan yang dibutuhkan, maka memulai dari awal akan masuk akal. Itu sering terjadi ketika masalahnya kompleks dan kurang dipahami, dan cukup banyak waktu dihabiskan untuk mencari tahu apa masalahnya sebenarnya. Tidak ada gunanya melanjutkan dengan awal yang buruk, jika membuangnya dan memulai dari awal, kali ini dengan pemahaman masalah yang baik, berarti Anda akan benar-benar selesai lebih cepat.

Inilah yang akan saya lakukan secara pribadi:

1. Berhenti, buat alasan dan menyerah (Anda bahkan dapat memberikan kembali sebagian dari gaji Anda sehingga Anda tidak terlihat buruk)
2. Bersihkan kode Anda sebanyak mungkin
3. Buat dokumentasi tentang semua bagian pekerjaan Anda yang bagus seperti desain bagus, ide bagus, dll ...

Mengapa saya menyarankan semua ini kepada Anda?

Karena pikirkan tentang masa depan. Akan ada waktu di masa depan ketika orang-orang tertentu akan mendapatkan kode ini. Mereka akan membuat segala macam asumsi dan penilaian tentang Anda dan kemampuan Anda. Mereka tidak peduli ketika Anda menulisnya, mereka tidak peduli dengan situasinya. Mereka hanya ingin melihat di dalamnya apa yang ingin mereka lihat untuk mengkonfirmasi apa pun yang ingin mereka konfirmasi.

Anda akan dicap sebagai nama buruk apa pun, istilah yang dapat mereka buat untuk memberi dampak negatif bagi Anda. Dan meskipun Anda di masa depan mungkin sangat berbeda dalam hal kemampuan teknis, keterampilan, pengetahuan, gaya dan situasinya akan sangat berbeda, kode ini akan digunakan untuk melawan Anda dengan segala cara yang mungkin. Ini seperti pengadilan di mana mereka dapat mengatakan semua hal buruk tentang Anda dan kode serta desain Anda dan Anda bahkan tidak menyadarinya sehingga Anda dapat menjelaskan dan mempertahankan diri Anda. (dan Anda mungkin belajar sangat sering bahwa mereka sangat salah, berulang kali) Jadi jangan lakukan itu. Menyerah.

Percayalah, ada orang yang membuat banyak asumsi tentang Anda karena Anda melakukan sesuatu untuk tujuan apa pun pada saat apa pun. Bagi mereka, jika Anda suka ini dalam situasi A, Anda akan melakukannya dalam situasi B. Mereka berpikir sangat sederhana.

Dua saran lagi, saya berani bertaruh setidaknya satu dari ini yang belum Anda lakukan.

1) Letakkan pelacak bug di tempatnya dan ajarkan bos Anda untuk menggunakannya. Ini bisa menjadi bagian dari percakapan tentang bagaimana Anda mengacau, telah belajar lebih baik dan akan memperbaikinya secara terencana

2) Mulailah menggunakan kontrol versi, meskipun mudah-mudahan Anda sudah melakukannya.

Ada banyak sistem yang dihosting di luar sana yang menyediakan keduanya di atas secara gratis pada akun kecil. Saya sangat menyukai FogBugz yang juga memiliki estimasi yang bagus dan sistem penyelesaian tugas yang akan memberi atasan Anda lebih banyak kepastian bahwa Anda menangani berbagai hal dengan cara yang terkelola dengan baik.

sunting

Wow, seseorang benar-benar tidak suka ini - downvote DAN flag hapus? Mengapa?

Saya telah mengembangkan perangkat lunak selama lebih dari tiga puluh tahun termasuk banyak pekerjaan konsultasi dan mewarisi kode orang lain. Sejumlah besar sistem masalah yang saya lihat adalah tempat orang menggali lubang dan tidak memiliki catatan terperinci tentang bagaimana mereka sampai di sana dan juga tidak memiliki kontrol versi.

Untuk menjawab pertanyaan Anda: seperti yang banyak orang lain katakan, tidak. Kirim, dan bersihkan sedikit demi sedikit dalam proses memperbaiki bug.

Selain itu, sementara buku / StackExchange / webforums adalah sumber belajar yang baik, Anda mungkin menemukan bahwa tidak ada yang dapat menandingi pembelajaran yang akan Anda terima dari bekerja (atau bahkan hanya mendiskusikan pekerjaan) dengan programmer lain. Menemukan dan menghadiri grup lokal untuk teknologi yang Anda gunakan atau ingin pelajari adalah investasi yang luar biasa untuk waktu Anda. Selain pengetahuan teknis yang akan diperoleh, ini adalah cara mudah untuk jaringan yang sangat berharga saat Anda menantikan pertunjukan di masa depan.

Atasan Anda mengetahui tingkat pengalaman Anda ketika dia mempekerjakan Anda. Hanya mengungkapkan kekhawatiran Anda, dan biarkan dia tahu Anda gugup. Juga beri tahu dia berapa banyak yang telah Anda pelajari dan seberapa baik Anda dapat melakukan proyek berikutnya.

Anda adalah pengembang web pemula, tanpa ada pengembang yang baik untuk memberi saran kepada Anda, bos Anda mempekerjakan Anda untuk mengetahui hal ini sepenuhnya. Saya pikir Anda baik-baik saja dan siapa pun dapat mengharapkan Anda melakukannya. Sebenarnya, fakta bahwa Anda memiliki wawasan bahwa pekerjaan itu bisa lebih baik, dan bahwa Anda benar-benar mempelajari hal-hal yang memungkinkan Anda melakukannya dengan lebih baik, berarti Anda melakukan lebih baik daripada kebanyakan. Ingatlah untuk kewarasan Anda sendiri bahwa versi Anda yang memulai pekerjaan tidak dapat melakukannya dengan lebih baik. Seseorang yang lebih berpengalaman (dan karenanya dibayar lebih baik), atau Anda dengan satu pengalaman proyek yang berharga, bisa melakukannya dengan lebih baik.

Apa yang harus dilakukan sekarang : Bersyukurlah bahwa Anda adalah pengembang yang lebih baik daripada setahun yang lalu. Proyek selanjutnya Anda akan melakukan lebih baik (dan pada akhirnya Anda akan lebih berpengalaman lagi dan tidak senang dengan apa yang telah Anda lakukan; itu normal). Mengubah atau menulis ulang proyek terakhir akan memberi bisnis sangat sedikit manfaat untuk biayanya. Yang dapat Anda lakukan adalah mengganti kode yang buruk dengan kode yang baik ketika Anda harus melakukan perubahan; itu masuk akal karena memodifikasi kode yang tidak dapat dirawat bisa lebih sulit daripada menggantinya dengan kode yang baik. Dan jika Anda mendapatkan pengembang berpengalaman baru untuk membantu, memberitahu mereka bahwa ini kode bukan contoh bahwa mereka harus menyalin.