Pertama, saya ingin mengatakan bahwa saya terbiasa melakukan Pemrograman Prosedural sebagai hobi saya - saya mencoba belajar OOP dalam beberapa bahasa, dan memahami teorinya , hanya saja bukan praktiknya.
Saya punya proyek peliharaan yang ingin saya buat, khususnya dalam PHP dengan backend basis data (tidak peduli apa). Alasan utama saya adalah agar aplikasi digunakan pada perangkat apa pun, jadi WebApp sepertinya pilihan yang logis.
Saya mengerti bahwa untuk membangun PHP WebApps yang dapat dikelola, itu harus menggunakan OOP, Kelas, Kerangka Kerja, Perpustakaan, dll. Ini terdengar logis, jadi saya memutuskan untuk mencoba beberapa yang populer. Namun, setelah seluruh akhir pekan hanya mencoba mereka dan mencoba untuk melewati tutorial, saya bingung dan frustrasi mencoba untuk menyesuaikan tutorial untuk proyek kecil saya.
Saya memutuskan, terutama untuk pembuktian konsep, untuk membangun aplikasi di program lain (Microsoft Access), dan mencapai tujuan utama saya hanya dalam beberapa jam - kecuali bagian Web.
Pertanyaan saya adalah, haruskah saya mengikuti jalur yang saya tahu, kemudian mencoba menerapkan praktik pengkodean yang benar, atau haruskah saya mulai dengan praktik pengkodean yang baik, dan mencoba memalsukan jalan saya? Untuk proyek ini, saya ingin Open Sourced di GitHub, jadi saya akan terbuka untuk orang lain menggunakan dan mengubah kode saya, tetapi saya juga tahu bahwa jika kode ditulis dengan buruk, akan sulit untuk mengumpulkan coder untuk membantu.
sumber
Jawaban:
Praktik terbaik sebagian besar adalah saran dan proposal yang dikumpulkan dari pengalaman untuk membantu membuat proyek lebih mudah untuk * dapat dilakukan.
Aspek kunci dari IMHO ini adalah bagian pengalaman. Meskipun praktik terbaik ini adalah cara yang baik bagi orang-orang dengan pengalaman lebih banyak untuk membaginya dengan pemula, saya pikir orang masih membutuhkan tingkat pengalaman minimum untuk benar-benar memahami apa yang membuat ini merupakan praktik terbaik. Melakukan sebaliknya berarti mengikuti mereka secara membabi buta sebagai aturan hukum yang pada akhirnya saya pikir akan memperlambat pembelajaran Anda ketika Anda perlahan-lahan membiarkan orang lain berpikir untuk Anda.
Bagaimanapun, hal terpenting terpenting yang harus dilakukan dalam proyek perangkat lunak bagi saya adalah ... yah ... selesaikan, kirimkan ... singkatnya membuatnya berfungsi!
Apa pun sebelum titik itu adalah vaporware, isapan jempol dari imajinasi Anda. Hanya sekali Anda memiliki sesuatu yang berfungsi, Anda dapat benar-benar mengevaluasi jika lambat, sulit untuk dipelihara, sulit untuk diuji dll. Proses membuatnya bekerja akan mengekspos hal-hal yang, mungkin, ada praktik terbaik yang akan membantu Anda memikirkan kembali dengan cara yang membuatnya lebih mudah untuk mencapai tujuan itu.
Jadi ya, mulailah dengan apa yang Anda ketahui terlebih dahulu, perhatikan hal-hal yang Anda lakukan yang sulit. Ketika Anda menabrak dinding, selangkah mundur dan lihatlah dinding itu, pelajari terbuat dari apa. Dalam banyak kasus Anda akan menyadari bahwa ANDA adalah akar masalahnya. Kurangnya pemahaman Anda tentang beberapa bagian dari masalah yang Anda coba selesaikan, kurangnya pengetahuan Anda tentang bagaimana Anda dapat memanfaatkan alat yang Anda miliki dengan lebih baik atau ketidaktahuan Anda akan alat lain yang ada di bawah hidung Anda sepanjang waktu tetapi tidak siap untuk mulai penguasaan mereka.
Pada saat yang sama, terus membaca tentang cara-cara baru untuk melakukan sesuatu. Baca praktik terbaik ini dan cobalah untuk melihat apakah itu berlaku untuk apa pun yang Anda temukan sulit dalam proyek Anda. Jika tidak, ingat keberadaan mereka dan kunjungilah mereka dari waktu ke waktu. Tetap penasaran. Pada saatnya nanti Anda akan melihat bahwa pengamatan yang dilakukan di atas cukup klik secara alami dengan pengetahuan yang Anda peroleh di sini.
Terakhir, bereksperimenlah dengan apa yang telah Anda pelajari dan lihat apakah itu membuat segalanya lebih sederhana. teruskan ini dan pada akhirnya Anda akan membaca praktik terbaik apa adanya. Hanya saran sederhana dari orang yang telah menderita dan belajar cara untuk membuatnya lebih mudah. Heck Anda bahkan mungkin tidak setuju dengan beberapa dari mereka dan melihat bahwa cara Anda benar-benar bekerja lebih baik untuk Anda. Tapi tanpa sepengetahuan Anda hanya berjalan buta.
semoga berhasil
sumber
TL; DR
Anda tidak akan pernah tahu semuanya. Ada cukup banyak hal yang lebih dalam dan luas di sekitar setiap "hal" individu yang dapat Anda ketahui. Belajar sambil jalan. Terapkan "praktik terbaik" yang menurut Anda relevan sekarang. Membuat kesalahan. Cobalah untuk menghindari membuat kesalahan yang sangat mahal . Cari mentor jika proyek Anda dapat menyebabkan kesalahan yang mahal.
Dan sekarang jawaban panjangnya ...
1. "Perangkat lunak yang berfungsi adalah ukuran utama dari kemajuan." ( Agile Manifesto )
Jika Anda dapat melihat ujung-ujung pengetahuan Anda, itu luar biasa! Kejar pinggirannya! Terus belajar! Namun perlu diingat, Anda bisa belajar dan menganalisis selamanya .
Bangun sesuatu.
2. Belajar dan membuat kesalahan; tetapi jangan membuat yang "buruk". *
Terus mendorong batas-batas pengetahuan / keterampilan Anda. Anda akan membuat kesalahan. Anda bisa belajar dari mereka. Tapi, Anda tidak perlu gegabah .
Waktu yang Anda habiskan untuk menemukan dan bekerja dengan pengembang dan mentor yang lebih berpengalaman harus meningkat secara proporsional dengan nilai bisnis dan profil risiko proyek.
Jika Anda membuat CLI kecil untuk diri sendiri : Buatlah itu bekerja sesuai keinginan Anda.
Jika Anda menulis portal web bank: Kelilingi diri Anda dengan pengembang yang sangat berpengalaman.
3. "Praktik terbaik" harus ditulis dalam tanda kutip dan diucapkan dengan mengedipkan mata.
"Praktik" dipromosikan menjadi "praktik terbaik" ketika mereka diamati berhasil mencapai X dalam setidaknya beberapa kasus. Seseorang mengakui manfaat dari Praktek A untuk mencapai Manfaat X dan menyatakannya sebagai "praktik terbaik" di internet. Yang lain setuju - sering karena alasan yang baik. Tapi, sejak saat itu, kita umumnya lupa mengapa beberapa praktik adalah "praktik terbaik" dan yang lain adalah "antipatterns" atau "stinky."
Masalahnya adalah, "praktik terbaik" tidak pernah mementingkan diri sendiri. "Antipatterns" sebenarnya tidak jahat dalam dan dari diri mereka sendiri. Dan, bahkan "bau busuk" hanya kadang-kadang berasal dari busuk. Kadang-kadang, bau itu hanya keju mewah, lezat ...
Anda tidak mempraktikkan hal-hal seperti "injeksi ketergantungan" (DI) karena "injeksi ketergantungan" secara inheren berharga bagi bisnis. Ini bahkan tidak terlalu penting untuk membangun produk yang berfungsi. Ini menyelesaikan sesuatu yang mungkin Anda inginkan dalam produk akhir Anda. Tapi, itu mungkin juga hanya membuat pekerjaan Anda lebih lama tanpa manfaat ...
Hmm ...
Jadi, haruskah Anda mengikuti "praktik terbaik?" Bahkan jika Anda tidak memahaminya? ... Err ... ya. Maksud saya tidak. Tapi ya. Tapi, hanya yang benar-benar berlaku untuk Anda dan perangkat lunak Anda dan tujuannya.
Memohon POAP ! (Yup. Blog saya.)
Jadi, Anda mungkin tidak sepenuhnya memahami setiap nuansa DI, misalnya. Tetapi, jika Anda memahami maksudnya, Anda akan tahu jika Anda "harus" menggunakan DI, dan Anda secara implisit akan memahami DI dengan lebih baik.
Dan, setelah Anda merilis produk, Anda dapat merenungkan apakah DI (atau apa pun) benar-benar bermanfaat. Jika demikian, jelaskan mengapa secara tertulis. Jika tidak, jelaskan mengapa secara tertulis ...
Pembacaan bonus / Agak relevan:
Analisis kelumpuhan adalah suatu hal. Anda perlu menganalisis dan belajar; tetapi, Anda juga harus menyelesaikan pekerjaan. Keseimbangan.
Anda mungkin selalu merasa seperti pembuat kode koboi .
* Anda benar - benar akan membuat kesalahan buruk jika Anda melakukan sesuatu yang patut diperhatikan. Tapi, Anda manusia, saya kira. Jadi, kami memaafkan Anda sebelumnya ... Atau, setidaknya saya lakukan. Mungkin. ... Baiklah ... Kita lihat saja nanti.
sumber
Mungkin mencoba yang terbaik tetapi masih mengirimkan sesuatu? Ada dua kekuatan yang berbeda antara bagaimana pengguna mengevaluasi kualitas dan daya tarik suatu produk dan bagaimana pengembang di belakangnya mengevaluasi kualitas kode. Cobalah untuk membuat kedua kekuatan ini selaras mungkin. Berfokus pada satu terlalu banyak dengan mengorbankan yang lain biasanya adalah bagaimana Anda berakhir dengan rute yang paling tidak produktif.
sumber
Yah, pertama-tama, saya akan menyarankan bahwa mengadopsi praktik pengkodean yang baik tidak menipu ... Triknya adalah memahami tujuan dari setiap praktik dan cara menerapkannya dengan benar.
Lingkungan pengembangan aplikasi yang cepat menggoda, karena Anda bisa menyelesaikan banyak hal dalam waktu yang sangat singkat. Saya membangun seluruh sistem akuntansi di Access sekali. Tetapi Anda sendiri yang mengatakannya: Anda tidak dapat membawa aplikasi seperti itu ke web tanpa menulis ulang, dan alat yang Anda butuhkan benar-benar berbeda.
Ada alasan mengapa tidak ada lagi yang menggunakan alat desain visual seperti Access atau Visual Basic. Mereka cenderung melindungi Anda dari kode yang benar-benar menyelesaikan sesuatu. Akses adalah alat yang bagus, tetapi sangat membutuhkan aplikasi web yang khusus dirancang untuk menghindari: instalasi. Kustomisasi penampilannya bisa sulit; bahkan jika Anda tidak membutuhkannya di web, aplikasi Access akan selalu terlihat sangat mirip dengan aplikasi Access lainnya. Kebanyakan orang yang menulis aplikasi Access pertama mereka tidak cukup tahu untuk menulis aplikasi yang baik, dan Access membuatnya mudah untuk menulis aplikasi yang buruk.
Jadi sekarang Anda pasrah belajar teknologi baru untuk mendapatkan aplikasi Anda di web. Haruskah Anda membangunnya dengan cara yang benar sejak awal? Tentu saja. Tetapi belajar lingkungan pengembangan baru dan filosofi adalah seperti mempelajari hal lain; Anda harus menggunakannya untuk sementara waktu untuk memperbaiki keadaan.
Itu sebabnya saya pikir Anda telah mengajukan dikotomi palsu. Tidak ada yang mempelajari semua "praktik terbaik" terlebih dahulu. Mereka mempelajarinya saat mereka pergi. Tetapi untuk menjadi produktif dalam bahasa OOP apa pun, saya pikir Anda harus tahu beberapa OOP, atau setidaknya bagaimana kelas bekerja secara fundamental.
Untuk apa nilainya, saya tidak berpikir PHP adalah pilihan terbaik Anda. PHP menarik karena "dangkal," yang berarti Anda tidak perlu tahu banyak untuk menulis program kerja. Praktik terbaik sebagian besar diserahkan kepada pengembang, yang berarti bahwa PHP tidak akan membantu Anda menulis program "baik". Ini tidak perlu hal yang buruk, tetapi itu berarti bahwa, seperti Access, Anda mungkin juga akhirnya membuang PHP untuk platform yang lebih kuat.
sumber
Pertimbangkan OOP hanya sebagai pola lain yang dapat Anda terapkan pada waktu yang tepat. OOP bukan kerangka kerja yang secara sistematis dapat menyelesaikan setiap tugas. Hal semacam itu tidak ada dalam rekayasa perangkat lunak.
Juga perhatikan, bahwa apa yang orang nyatakan sebagai praktik yang baik terkadang dipertanyakan. Saya sering melihat pengembang yang tidak berpengalaman mengadopsi pola pemrograman yang sangat rumit yang tidak perlu untuk masalah yang diberikan. Kompleksitas kode harus sesuai untuk kompleksitas masalah. Kesederhanaan adalah nilai penting.
Artikel di web, pernyataan dari pakar industri dan saran dari kolega senior bisa saja salah. Saya sudah sering melihat ini.
Karena itu saya sarankan Anda menerapkan solusi paling sederhana yang memecahkan masalah Anda. Kemungkinan, ini akan mencakup penggunaan salah satu kerangka kerja populer di ruang Anda. Dalam batasan ini Anda dapat dengan bebas memilih kode seperti apa yang Anda suka. Jangan hanya berpikir bahwa cara mereka melakukannya sesuai untuk kasus Anda .
Juga, pahami mengapa teknik tertentu direkomendasikan. Misalnya, OOP adalah tentang enkapsulasi. Anda dapat merangkum dengan cara lain (prosedur juga tentang enkapsulasi).
Contoh negatif: Kadang-kadang orang menulis lapisan akses data untuk memisahkan database. Di sini, inti dari pola ini adalah untuk menjadi independen dari penyimpanan data yang konkret dan untuk mengekspos antarmuka yang lebih sederhana ke lapisan kode yang lebih tinggi. Tetapi jika Anda tidak membutuhkan manfaat ini maka Anda tidak perlu lapisan akses data dan dapat menyimpan pekerjaan. Namun, banyak ahli merekomendasikan untuk selalu melakukan DAL yang merupakan rekomendasi yang salah.
Saya menemukan bahwa kode yang baik sering menyenangkan untuk dikerjakan. Ini menyenangkan karena Anda mulai mengerjakan persyaratan aktual alih-alih mengurus masalah infrastruktur. Jika Anda mendapati bahwa apa yang Anda lakukan terlalu banyak pekerjaan kasar, kemungkinan besar Anda telah memilih pola yang salah.
sumber