Berhati-hati untuk mengelakkan tujuh salah faham pengaturcaraan ini!

Kami jarang melihat orang bercakap secara terbuka tentang kesilapan mereka.

Tiada orang suci, bagaimana mungkin seseorang tidak mempunyai kesalahan? Sukar untuk dikatakan, tetapi merenung kesilapan lalu boleh menghalang anda daripada melakukan kesilapan yang sama pada masa hadapan—sekurang-kurangnya dalam jangka pendek.

Mohamed Barouma ialah seorang pengaturcara profesional selama 5 tahun, tetapi seperti orang lain, dia melakukan kesilapan.

Beliau berkata begini: "Biasanya, saya tidak sedar apa yang salah saya serta-merta; Saya hanya tahu kesilapan yang saya lakukan selepas didedahkan dengan cara yang betul dalam melakukan sesuatu."

Digabungkan dengan teks asalnya, artikel ini meringkaskan tujuh salah faham utama yang dibuatnya.

1. Tidak menggunakan ORM yang sesuai

Kod lapisan akses data sentiasa berantakan, membosankan dan membosankan. Malangnya, ini sering tidak ditemui sehingga akhir.

Mohamed dan ORM mempunyai hubungan yang tidak baik. ORM, Pemetaan Hubungan Objek, ialah singkatan Model Hubungan Objek. Fungsinya adalah untuk membuat pemetaan antara pangkalan data hubungan dan objek, supaya program boleh memanipulasi pangkalan data dengan memanipulasi objek penerangan.

Apabila Mohamed mula-mula membuat aplikasi perakaunan dalaman yang mudah, dia mendapati bahawa hanya untuk melengkapkan program asas, dia perlu menulis banyak kod. Oleh itu, dia mula melibatkan diri dalam ADO.NET dan secara manual menulis ORM buatan sendiri dengan skema jadual yang sangat istimewa dan disesuaikan untuk memenuhi tujuan itu.

Untuk satu tempoh masa, ORM ini berfungsi dengan baik Sehingga beberapa bulan kemudian, keperluan perniagaan syarikat berubah, yang membawa kepada perubahan dalam keseluruhan skema jadual, dan kemudian pengubahsuaian berulang pada ORM. Proses ini sangat menyakitkan sehingga Mohamed akhirnya memilih penyesuai set data yang ditaip kuat.

Walaupun perkara ini telah diselesaikan, jika ORM yang lebih sesuai (seperti NHibernate) boleh didapati untuk menyiapkan kerja, Mohamed tetap diwajibkan untuk berbuat demikian Sekurang-kurangnya apabila bilangan penggunanya meningkat, dia tidak perlu risau untuk menukar bekalan pangkalan data.

2. Tidak belajar menggunakan generik

Kerjaya Mohamed Barouma sebagai pengaturcara profesional bermula dengan Net 1.1. Pada masa itu, masalah utama dengan Net 1.1 ialah ia tidak mempunyai sokongan generik, yang bermaksud ia tidak boleh mempunyai senarai yang ditaip dengan kuat dan terpaksa menyelesaikan ArrayList yang membosankan. Walau bagaimanapun, menggunakan Arraylist untuk melakukan penukaran jenis dan tinju dalam kod Java akan membuat membaca dan menulis sangat menyakitkan.

Oleh itu, pengaturcara Net 1.1 menggunakan CodeSmith untuk menjana senarai koleksi yang ditaip kuat.

Tetapi apabila pangkalan kod berkembang, senarai yang dijana tersuai itu sendiri menjadi raksasa yang tidak terurus. Selagi anda sering membuat objek atau kaedah panggilan untuk mencapai matlamat anda, anda kemudiannya akan mengubah suai kod untuk menyebabkan kekeliruan dan ralat.

Jika anda beralih kepada Net 2.0 dan mula menggunakan generik sebaik sahaja ia tersedia, daripada mencipta lebih banyak senarai koleksi tersuai yang sukar diselenggara, semuanya akan hilang.

3. Jangan sekali-kali berputus asa "mencipta semula roda"

Ini adalah topik biasa, "mencipta semula roda" (Reinvent The Wheel). Pengaturcara baru sentiasa suka "mencipta semula roda" berulang kali, memikirkan bahawa pelaksanaan semasa tidak cukup baik, jadi mereka perlu menulis semula semuanya dari awal.

Mengapa ia dipanggil "membuat roda"? Sama seperti roda sebenar yang ditentukan untuk bulat beribu-ribu tahun yang lalu, banyak pangkalan data telah lama matang dan mudah digunakan, tetapi masih terdapat banyak pengaturcara yang gigih dalam "membuat roda", dan beberapa rama-rama terbang ke dalam api, a cacing terbang ke pokok, tetapi sesetengah orang adalah unik dan inovatif Ini adalah tarikan ajaib "membuat roda".

Antaranya ialah Mohamed, yang ingin menulis semula kawalan UInya sendiri kerana kawalan UI Windows Forms terlalu mudah. Akhirnya, alat GUI yang diciptanya mudah dikalahkan oleh sistem kawalan .Net UI yang dikomersialkan, dan satu lagi "roda" yang dicipta oleh pengaturcara baharu telah tenggelam ke dalam lautan kod.

4. Dokumentasi yang tidak terlalu ringkas

Ramai pengaturcara yang baru memasuki industri akan mendapati dokumentasi kod itu bagus pada mulanya kerana ia diulas dalam bahasa Inggeris yang ringkas What the code sedang melakukan. Tetapi sebenarnya, dokumen ini biasanya menjadi sekeping kertas buangan selepas beberapa perubahan kod, menjadi lapuk, ketinggalan zaman atau hanya salah.

Selalunya orang menghabiskan banyak masa menulis dokumentasi kod - seperti dokumen XML, hanya untuk mendapati bahawa mereka perlu mengemas kini dokumentasi apabila kod itu ditukar. Kerana fungsinya mungkin telah berubah. Mengemas kini kod adalah perlu, tetapi mengemas kini dokumen XML tidak: ia membebankan, ia memakan masa, dan ia tidak berguna.

Akhirnya, menukar dokumen XML berulang kali membuatkan seseorang hilang sabar dan beralih kepada perkara lain.

5. Tidak menggunakan binaan automatik

Penyebaran dan pembungkusan aplikasi agak lebih mudah daripada pengaturcaraan, jadi ia sering diletakkan pada keutamaan yang sangat rendah. Tetapi tidak lama lagi, binaan yang buruk akan dikenakan pelbagai aduan kerana ia gagal berfungsi:

"Prasyarat tiada, bagaimana untuk memperbaikinya?" boleh? Bolehkah anda memberi saya tampalan?”

“Mengapa ikon saya hilang?”

Kemudian panggilan telefon datang ke meja seperti runtuhan salji. Ini adalah pengalaman sebenar bagi Mohamed, dan ia menyebabkan dia keletihan pada hari itu—bukan daripada pengaturcaraan, tetapi daripada proses penempatan semula dan pembungkusan semula yang membosankan fikiran.

Dalam semua ini, beberapa masa boleh disimpan dengan menulis skrip automatik, jika tidak, masa yang terbuang untuk penyahpepijatan selepas itu pasti akan menjadi beberapa kali lebih banyak daripada masa yang boleh disimpan. Perisian harus dibina dengan satu klik, jika tidak, ia adalah satu pembaziran.

6 Tidak berhenti bergantung pada pemeriksaan visual dan penyahpepijatan

Visual Studio memudahkan orang untuk menyahpepijat kod dan melakukan pemeriksaan dinamik, yang juga memungkinkan untuk membuat borang Dan memaparkan output adalah sangat mudah. Tetapi jika anda terlalu ketagih dengan penyahpepijat, faedah ini akan bertukar menjadi keburukan.

Kenapa? Bayangkan jika kaedah hanya dipanggil 45 minit selepas aplikasi dihidupkan dan dijalankan Adakah anda bercadang untuk menunggu 45 minit sebelum memulakan penyahpepijatan

Jadi, pecahkan aplikasi kepada komponen yang boleh dipanggil secara bebas submodul? anda boleh menyediakan nilai input yang menghasilkan output ralat dan mula mengujinya dari sana.

7. Tiada ujian unit

Ramai pengaturcara mungkin berfikir seperti ini: "Aplikasi saya adalah remeh, ia boleh dilindungi dengan mudah oleh ujian manual ; Ujian unit adalah untuk perkara yang besar dan kompleks, bukan untuk program saya "

Seperti yang anda boleh bayangkan, ini secara langsung akan mencipta kod yang tidak mempunyai pemisahan kebimbangan, sukar untuk difaktorkan semula dan tidak dapat diselenggara sepenuhnya. perpustakaan.

"Creepy-footing" hampir menjadi masalah biasa di kalangan ramai pengaturcara pemula, yang takut untuk membuat walaupun sedikit pengubahsuaian pada kod, kerana sebarang perubahan mungkin atau mungkin tidak membawa kepada perubahan yang merosakkan. Akibatnya, ia tidak terkawal akhirnya dan masalah yang timbul tidak dapat diselesaikan. Bekerja dengan kod warisan ini bukan sahaja membosankan dan memberi tekanan, tetapi juga tekanan mental.

Tetapi menggunakan ujian unit boleh meningkatkan hayat kod dengan banyak. Mohamed berharap beliau dapat mempelajari "seni" ujian unit dan mengamalkan ujian unit sejak hari pertama persekolahan, tetapi malangnya pihak sekolah tidak mengajar perkara ini.

Banyak inovasi menarik di dunia diperolehi daripada banyak percubaan dan kesilapan, tetapi walaupun begitu, ia masih perlu untuk mengelakkan kesilapan asas. Dalam kehidupan pengaturcaraan anda, apakah "salah faham" yang tidak masuk akal lain yang pernah anda temui? Atau adakah ia telah mencipta beberapa "salah faham maut" yang membingungkan? Dialu-alukan untuk meninggalkan mesej di bawah untuk berkongsi pengalaman anda dalam pembelajaran pengaturcaraan.

Rujukan:

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software- engineer -f14ef540be10

Atas ialah kandungan terperinci Berhati-hati untuk mengelakkan tujuh salah faham pengaturcaraan ini!. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!