Secara amnya, apabila syarikat membangunkan perisian, mereka akan melaksanakan kerja pembangunan projek dalam dua cara selari: garis dasar dan penyesuaian. Tidak kira syarikat apa pun, ia perlu mengikut sistem proses pembangunan produk yang matang untuk menghasilkan produk yang lebih berkualiti. Oleh itu, jika terdapat banyak projek, garis dasar dan peristiwa penting sebelum penyesuaian harus diatur dengan munasabah supaya produk garis dasar boleh mengumpulkan seberapa banyak keperluan pengguna umum yang mungkin, memberikan sokongan teknikal untuk kemajuan projek penyesuaian, dan mengurangkan bilangan besar perubahan kod dalam projek penyesuaian, keperluan untuk menambah modul baharu berlaku. Selain itu, sistem proses pembangunan produk juga perlu diubah mengikut keperluan masa sebenar perniagaan Jangan berpegang kepada kaedah waterfall atau kaedah tangkas Semuanya perlu diuruskan mengikut kesesuaian anda. Hanya kaki anda sahaja yang tahu sama ada kasut itu sesuai dengan kaki anda atau tidak.
Kami di sini menggunakan proses pembangunan produk asas sebagai asas untuk penjelasan proses Perlu diingat bahawa untuk setiap peringkat yang diterangkan di bawah, Sebelum pelaksanaan projek, matlamat setiap peringkat mesti ditakrifkan dengan jelas, rancangan. komunikasi yang ditentukan dan tepat pada masanya, serta memastikan semua ahli mempunyai pemahaman yang konsisten tentang projek pada setiap tempoh.
Matlamat mesyuarat permulaan projek adalah untuk menjelaskan matlamat projek pembangunan produk. Matlamat tidak wujud secara berasingan Matlamat dan rancangan saling melengkapi matlamat, dan keberkesanan rancangan mempengaruhi pencapaian matlamat. Oleh itu, apabila melaksanakan matlamat, fikirkan dengan jelas tentang pelan tindakan anda sendiri dan cara mencapai matlamat dengan lebih berkesan Ini adalah soalan yang semua orang mesti jelas secara terperinci Jika tidak, matlamat yang tidak jelas atau terlalu tinggi akan menjejaskan prestasi sebenar hasil projek.
Mesyuarat permulaan projek perlu menjelaskan perkara utama seperti matlamat projek, pembahagian peringkat, struktur organisasi, proses pengurusan, dll. , dan menulis kandungan ini ke dalam PPT (sebaik-baiknya dengan format tetap dan teks sampel, supaya Piawaian mesti dipatuhi dalam pasukan atau dalam syarikat) dan semua orang perlu mencapai kata sepakat. Untuk pelantikan peranan utama, adalah perlu juga untuk mendengar pendapat pemimpin yang berkaitan dan pemegang kepentingan projek utama terlebih dahulu.
Sebelum mula membangunkan perisian, adalah perlu untuk menentukan perbandingan antara kos dan nilai yang diperolehi, iaitu ROI (Return On investment) Setelah ditentukan itu ia perlu dicipta, satu siri sumber perlu diatur untuk Menyokong kelangsungan perisian ini. Ini adalah perihalan keperluan yang paling primitif.
Mengapa kita memerlukan kedua-dua keperluan pengguna dan keperluan produk?
Oleh kerana terdapat perbezaan antara kedua-duanya, keperluan pengguna dikemukakan oleh pengguna, dan teknologi secara amnya tidak diterangkan, hanya matlamat produk yang diterangkan. Keperluan produk ialah keperluan pelaksanaan teknikal yang diubah daripada keperluan pengguna Ia adalah perlu untuk membahagikan matlamat produk yang dicadangkan oleh pengguna, meringkaskan setiap titik fungsi tertentu, dan kemudian membahagikan setiap titik fungsi ke dalam pelbagai proses operasi.
Keperluan pengguna dan keperluan produk terdedah kepada perbezaan Ini kerana walaupun semua orang bercakap tentang keperluan, titik permulaan mungkin berbeza, menyebabkan kebimbangan dan cara berfikir yang berbeza antara kedua-dua pihak. Keperluan pengguna memfokuskan pada cara sistem menyokong proses perniagaan, dan keperluan asas adalah untuk "mencapai matlamat perniagaan." Kakitangan teknikal memberi tumpuan kepada penyelesaian teknikal yang munasabah, dan keperluan di belakangnya ialah "beban kerja", "kesukaran pelaksanaan" dan "prestasi sistem".
Kita perlu memikirkan mengapa pengurus produk atau pencadang keperluan projek mahu melakukan projek ini? Ini adalah keperluan perniagaan yang paling penting. Keperluan perniagaan yang ditentukan oleh analisis permintaan semuanya diperoleh daripada keperluan perniagaan dan mesti memenuhi keperluan perniagaan.
Keperluan produk secara amnya termasuk spesifikasi keperluan produk dan matriks keperluan produk. Matriks keperluan produk secara amnya menyenaraikan semua keperluan fungsian mengikut struktur subsistem, set fungsi, dan unit pelaksanaan Setiap lajur sepadan dengan langkah kerja setiap fungsi dan beban kerja setiap langkah.
Selepas keperluan produk ditulis, ia perlu disemak. Pada mesyuarat semakan keperluan, adakah keperluan semakan produk dan teknologi terperinci apakah senario biasa untuk fungsi produk? Adakah ia membentuk gelung tertutup? Apakah senario yang luar biasa? Adakah ia bertimbang rasa?
Selepas semakan keperluan, pemimpin pembangunan dan ujian masing-masing akan menulis penyelesaian teknikal dan kes ujian.
Untuk menyemak pelan teknikal, pemimpin pembangunan mengumpulkan orang yang bertanggungjawab ke atas sistem lain untuk membincangkannya Pelan teknikal mesti mempunyai carta aliran perniagaan dan rajah jujukan Carta aliran perniagaan adalah untuk mengisih kesan pembangunan terhadap perniagaan dan sama ada ia selaras dengan keperluan. Rajah jujukan adalah untuk menyusun interaksi sistem yang terlibat dalam keperluan ini. Selepas pelan teknikal disemak dan diluluskan, beban kerja dan masa penghantaran akan disahkan dan dihantar semula kepada produk.
Matlamat fasa reka bentuk adalah terutamanya untuk menganalisis dan mereka bentuk seni bina sistem yang akan dibangunkan, dan untuk mewujudkan garis asas seni bina sistem untuk menyediakan asas yang stabil untuk kerja pelaksanaan seterusnya.
Fasa reka bentuk termasuk output seni bina sistem Reka bentuk seni bina sistem yang baik boleh membantu manusia menyusun logik perniagaan dan memahami keperluan teras, mereka bentuk sistem perniagaan yang stabil dan berskala serta menilai kitaran pembangunan perniagaan dan. Kos pembangunan, elakkan risiko dengan berkesan. Sebagai contoh, apabila membina rumah, anda mesti mempunyai lukisan seni bina Hanya dengan lukisan anda boleh mengira tempoh pembinaan.
Reka bentuk keseluruhan ialah reka bentuk rangka kerja keseluruhan sistem Ia sangat penting dan tidak boleh ditinggalkan dalam keadaan biasa (reka bentuk keseluruhan boleh ditinggalkan hanya untuk projek penyelenggaraan kerana projek garis dasar telah direka bentuk Diperlukan untuk semua projek pembangunan produk Pertama, melaksanakan reka bentuk keseluruhan Ia adalah langkah pertama reka bentuk Ia tidak dibenarkan meletakkan troli di hadapan kuda dan kemudian mereka bentuk ini adalah titik kesakitan kedua terbesar dalam pembangunan perisian pertama ialah keperluan yang tidak jelas dan perubahan sewenang-wenangnya dalam keperluan!) .
Reka bentuk keseluruhan dibahagikan kepada tiga fasa :
Fasa pertama : reka bentuk awal. Berdasarkan semakan dan penghalusan rajah aliran data yang diberikan, ia ditukar kepada rajah struktur modul awal.
Peringkat kedua : Reka bentuk yang diperhalusi. Mengikut prinsip "kesepaduan tinggi dan gandingan rendah" modul, gambar rajah struktur modul awal diperhalusi, dan struktur data global dan antara muka setiap modul direka bentuk.
Peringkat ketiga : Peringkat semakan reka bentuk, semak struktur perisian peringkat tinggi yang diperoleh dalam dua peringkat pertama, dan mungkin juga perlu membuat beberapa penyempurnaan pada struktur perisian jika perlu.
Tujuan reka bentuk garis besar adalah untuk menerangkan reka bentuk dalaman setiap modul sistem dan berfungsi sebagai penghubung antara reka bentuk keseluruhan dan reka bentuk terperinci .
Reka bentuk garis besar direka mengikut kaedah reka bentuk berstruktur. Idea asas kaedah reka bentuk berstruktur ialah: mengikut domain masalah, perisian diperhalusi langkah demi langkah dan diuraikan menjadi modul yang tidak perlu diuraikan Setiap modul melengkapkan fungsi tertentu dan berfungsi satu atau lebih modul induk (iaitu, menerima panggilan) , juga menerima perkhidmatan daripada satu atau lebih submodul (iaitu submodul panggilan). Konsep modul sepadan dengan subrutin atau fungsi dalam bahasa pengaturcaraan.
Dalam peringkat reka bentuk garis besar, perisian diuraikan kepada tahap modul mengikut prinsip tertentu, setiap modul diberi tugas tertentu, dan hubungan panggilan dan antara muka antara modul ditentukan.
Pada peringkat ini, pereka bentuk secara amnya akan mempertimbangkan dan menjaga pelaksanaan dalaman modul, tetapi tidak terlalu terlibat di dalamnya. Fokus terutamanya pada membahagikan modul, menyerahkan tugas dan menentukan perhubungan panggilan. Antara muka dan pemindahan parameter antara modul mesti dibuat dengan sangat terperinci dan jelas pada peringkat ini, dan kamus data yang ketat perlu ditulis untuk mengelakkan kekeliruan atau salah faham dalam reka bentuk seterusnya. Reka bentuk garis besar biasanya tidak dilakukan sekali gus, tetapi memerlukan pelarasan struktur berulang. Pelarasan biasa adalah untuk menggabungkan modul dengan fungsi pendua atau menguraikannya lagi menjadi modul yang boleh digunakan semula. Dalam peringkat reka bentuk garis besar, modul boleh guna semula harus diekstrak ke tahap maksimum, sistem struktur yang munasabah harus diwujudkan, dan beban kerja pautan berikutnya harus disimpan.
Bahagian paling penting dalam dokumen reka bentuk garis besar ialah rajah aliran data hierarki, rajah struktur, kamus data dan perihalan teks yang sepadan. Berdasarkan dokumen reka bentuk garis besar, reka bentuk terperinci setiap modul boleh dijalankan secara selari.
Peringkat reka bentuk terperinci adalah untuk mereka bentuk algoritma dan proses dalam setiap modul berdasarkan penguraian peringkat reka bentuk garis besar, dan memberikan penerangan terperinci tentang fungsi yang telah diselesaikan oleh setiap modul Ubah huraian berfungsi kepada huraian proses berstruktur yang tepat.
Dalam peringkat reka bentuk terperinci ini, setiap modul boleh diberikan kepada orang yang berbeza untuk reka bentuk selari. Objek kerja pereka bentuk ialah modul Berdasarkan tugas tempatan dan antara muka luaran yang diberikan oleh reka bentuk garis besar, pereka bentuk mereka bentuk dan menyatakan algoritma, proses, peralihan keadaan, dsb. Perlu diingatkan di sini bahawa jika didapati terdapat keperluan untuk pelarasan struktur (seperti sub-modul pengurai, dll.), anda mesti kembali ke peringkat reka bentuk garis besar dan mencerminkan pelarasan ke dalam dokumen reka bentuk garis besar , dan tidak boleh menyelesaikannya di tempat tanpa bertanya khabar . Bahagian paling penting dalam dokumen reka bentuk terperinci ialah carta alir modul , carta keadaan , pembolehubah setempat dan keterangan teks yang sepadan, dll. Satu modul sepadan dengan dokumen reka bentuk terperinci.
Rajah struktur perisian biasanya diperoleh dalam fasa reka bentuk garis besar Kaedah penerangan yang biasa digunakan dalam fasa reka bentuk terperinci termasuk: carta alir, rajah N-S, rajah PAD, pseudokod, dsb. Tujuan reka bentuk terperinci adalah untuk menerangkan aliran pemprosesan dalaman, kaedah pembangunan dan kemahiran pengekodan modul tertentu. Secara umumnya, reka bentuk terperinci terdiri daripada Pengenalan Projek, Penerangan Modul (menghuraikan secara khusus proses dalaman, fungsi, logik, penggunaan dan isu yang tidak dapat diselesaikan setiap modul), Reka Bentuk Antaramuka Ia terdiri daripada beberapa bahagian termasuk (termasuk antara muka dalaman dan antara muka luaran), reka bentuk struktur data (termasuk struktur fizikal dan struktur logik), pemprosesan khas dan sebagainya. Reka bentuk terperinci perisian pada akhirnya merupakan penerangan bertulis tentang kaedah reka bentuk, logik, dan fungsi khusus bagi setiap bahagian sistem perisian. Dengan cara ini, semasa proses pelaksanaan, pengkod boleh melaksanakan kod dengan ketat mengikut prinsip ini.
Kod penulisan boleh mengikut prinsip berikut:
Mula-mula lakukan ujian tekanan modul teras: Ramai pengaturcara sudah biasa menyelesaikan sesuatu dan kemudian tunggu sehingga mereka akan pergi ke dalam talian sebelum melakukan ujian prestasi reka bentuk sebelumnya Ini adalah masalah besar. Sudah tentu, ujian prestasi juga akan dilakukan apabila ia akan pergi ke dalam talian nanti, tetapi saya fikir ia masih sangat penting pada peringkat awal. Sudah tentu, untuk melakukan ini dengan baik, anda perlu memahami beberapa perniagaan Anda perlu tahu di mana tekanan perniagaan dan di mana tumpuan permintaan perniagaan Banyak kali, jika pengurus produk tidak menerangkannya, anda perlu bertanya dengan jelas .
Pastikan proses boleh dikawal: Output perantaraan mesti dikekalkan apabila kod dilaksanakan Contohnya, untuk setiap 100,000 log diproses, tulis log status rekod pemprosesan Bilangan catatan log dan masa pelaksanaan semasa.
Log lagi: Banyak kali, saya tidak begitu berpuas hati dengan kod yang saya tulis Contohnya, kecekapan pemprosesan tertentu tidak cukup dioptimumkan, dan tertentu kaedah pemprosesan tidak cukup ringkas Atau skalabilitinya agak lemah, dan kod ditulis sangat terencat, tetapi mungkin tidak dapat mencari penyelesaian yang paling munasabah dalam masa yang singkat peringkat pelancaran, kami tidak akan mengoptimumkannya secara sengaja, tetapi dalam kes ini saya sering meninggalkan nota dan menerangkan idea yang mungkin untuk pengoptimuman seterusnya, atau penyelesaian yang boleh dilaksanakan yang saya fikirkan.
Logik yang mudah dan mudah difahami: Jangan libatkan diri anda dari masa ke masa, tiada siapa yang akan dapat memahami logik anda. Jika logik benar-benar sukar untuk diselesaikan dalam fungsi, cuba belah.
Jangan taksub dengan rangka kerja : Apakah masalah terbesar dengan rangka kerja? Ia terlalu menyusahkan bersarang. Mengapa saya sentiasa marah dengan rangka kerja? Oleh kerana kami sering menghadapi senario pemprosesan yang memerlukan beribu-ribu permintaan sesaat, apabila menala, kami perlu mencari logik pemprosesan data dan titik terperangkap prestasi daripada rangka kerja yang tidak terkira Kami mungkin menukar hanya dua baris kod, tetapi mencari Masalahnya mengambil masa dua hari. Pengaturcara ingat bahawa keupayaan teknikal anda tidak boleh dihadkan oleh rangka kerja.
Gunakan teknologi yang biasa dan matang: Ramai orang langsung tidak memahami halangan dan masalah mereka sendiri, dan tidak mengetahui kelebihan dan kekurangan produk teknologi yang berkaitan. Di mana sahaja anda melihat sekumpulan penilaian data pihak ketiga, anda akan teruja dan mempelajari teknologi baharu, dan kemudian anda akan jatuh ke dalam lubang dan tidak dapat keluar Jika anda adalah syarikat permulaan, projek itu mungkin mati di dalamnya . Sebelum menggunakan teknologi baharu, adalah disyorkan untuk memahami sepenuhnya ciri, skop yang boleh digunakan dan skop teknologi yang tidak boleh digunakan.
Seperti yang kita sedia maklum, menjalankan semakan kod dalam satu pasukan boleh meningkatkan kualiti kod, berkongsi pengetahuan projek, menjelaskan tanggungjawab dan akhirnya membina Perisian yang lebih baik, lebih baik pasukan.
Semakan kod adalah sangat penting Secara umumnya, semakan kod perlu dilakukan setiap minggu. Pertama sekali, semakan kod membantu anda menjejaki kemajuan projek Kami benar-benar dapat melihat bagaimana orang di bawah kami berkembang dan mengetahui lebih awal jika mereka sesat. Kadang-kadang, orang akan berkata "Ia hampir selesai!", dan anda melihat kod dan mendapati bahawa tiada apa-apa atau hanya sekumpulan sampah, dsb., tetapi ia masih jauh dari lengkap. Dalam pengurusan, situasi ini adalah yang paling menjengkelkan, jadi saya fikir semakan kod adalah cara terbaik untuk mengelakkan masalah ini.
Untuk memahami ujian unit, anda mesti terlebih dahulu memahami apa itu "unit". Apa yang dipanggil "unit" merujuk kepada unit terkecil panggilan kod, yang sebenarnya merujuk kepada blok fungsi (Fungsi) atau kaedah (Kaedah). Jadi ujian unit merujuk kepada ujian unit yang memanggil kod ini.
Ujian unit ialah sejenis ujian kotak putih, iaitu ujian yang mesti sangat jelas tentang butiran kod unit. Oleh itu, penulisan dan pelaksanaan ujian meta tunggal dilakukan oleh jurutera perisian . Berbanding dengan ujian unit, terdapat juga ujian integrasi. Ujian integrasi pada asasnya ialah ujian kotak hitam, yang kebanyakannya dijalankan oleh penguji mengikut manual fungsi perisian, yang memerlukan kerjasama persekitaran ujian khusus. Ujian integrasi dibahagikan kepada ujian fungsian, ujian regresi, dsb.
Kod yang memerlukan ujian unit sebenarnya adalah logik yang ditulis oleh pembangun sendiri Menguji sama ada persekitaran yang bergantung kepada logik bukanlah tujuan ujian unit. Memperkenalkan logik ke dalam kod akses persekitaran hanya akan menjadikan logik lebih sukar untuk diuji, menjadikan kod logik mustahil untuk diuji unit. Oleh itu, kod yang boleh diuji unit boleh diuji unit. Cara lain untuk menentukan kod yang boleh diuji ialah melihat sama ada kaedah itu boleh dijalankan terus menggunakan fungsi utama Jika ya, ia adalah kod yang boleh diuji unit. Satu lagi ciri kod yang boleh diuji ialah parameter unit kaedah boleh disimulasikan secara bebas oleh pembangun tanpa bergantung pada persekitaran luaran.
Ujian integrasi, juga dipanggil ujian pemasangan atau ujian bersama. Berdasarkan ujian unit, semua modul dipasang ke dalam subsistem atau sistem mengikut keperluan reka bentuk untuk ujian integrasi. Amalan menunjukkan bahawa walaupun sesetengah modul boleh berfungsi secara bebas, tiada jaminan bahawa modul tersebut akan berfungsi dengan betul apabila disambungkan. Sesetengah masalah yang tidak dapat dicerminkan secara tempatan berkemungkinan besar akan didedahkan secara global.
Ujian integrasi ialah ujian yang dilakukan semasa proses penyepaduan sistem perisian Tujuan utamanya adalah untuk menyemak sama ada antara muka antara unit perisian adalah betul . Mengikut pelan ujian penyepaduan, ia menggabungkan modul atau modul lain ke dalam sistem yang lebih besar dan lebih besar sambil menjalankan sistem untuk menganalisis sama ada sistem yang dikarang adalah betul dan sama ada pelbagai komponen sesuai bersama. Terdapat dua strategi utama untuk ujian integrasi: atas ke bawah dan bawah ke atas. Ia juga boleh difahami sebagai ujian bersama pelbagai komponen sistem aplikasi (unit perisian, antara muka modul berfungsi, pautan, dll.) apabila unit reka bentuk perisian dan modul berfungsi dipasang dan disepadukan ke dalam sistem untuk menentukan sama ada mereka boleh bersama-sama, komponen boleh menjadi blok kod, aplikasi kendiri, program klien atau pelayan melalui rangkaian .
Fasa ujian sistem termasuk Pelan ujian sistem dan penulisan kes penggunaan, Ujian fungsional, Ujian prestasi , Ujian kestabilan.
Untuk mengesahkan sama ada fungsi yang ditentukan oleh analisis keperluan adalah lengkap dan dilaksanakan dengan betul, keperluan tidak berfungsi seperti pemasangan, penggunaan, kebolehsuaian, keselamatan dan antara muka juga mesti diuji. Ujian sistem juga adalah tanggungjawab penguji Ia harus direka bentuk selepas analisis keperluan selesai dan dilaksanakan selepas ujian integrasi selesai.
Ujian fungsian
biasanya diuji oleh pasukan ujian bebas menggunakan pendekatan kotak hitam, terutamanya menguji sama ada sistem mematuhi "spesifikasi keperluan". Selepas peringkat ujian dan pengesahan di atas, sistem disimulasikan sepenuhnya untuk menguji persekitaran pelanggan. Pengujian sistem adalah untuk menggabungkan perisian yang disahkan, perkakasan komputer, persisian, rangkaian dan elemen lain untuk menjalankan pelbagai ujian pemasangan dan ujian pengesahan sistem maklumat Tujuannya adalah untuk mengetahui dengan membandingkan dengan keperluan sistem Jika sistem yang dibangunkan tidak sepadan atau bercanggah dengan keperluan pengguna, penyelesaian yang lebih lengkap akan dicadangkan .
Ujian prestasi
Sahkan kestabilan dan kecekapan sistem dan semak sama ada sistem memenuhi keperluan prestasi yang ditentukan. Ujian prestasi biasanya memilih beberapa fungsi biasa untuk menyemak sama ada sistem stabil apabila sebilangan besar pengguna menggunakan sistem pada masa yang sama. Ujian prestasi adalah tanggungjawab penguji Ia boleh dilakukan selepas ujian sistem selesai, atau ujian prestasi modul penting boleh dilakukan terlebih dahulu. Ia boleh dijalankan sepanjang kitaran ujian mungkin dan selesaikan awal.
Ujian kestabilan dan ujian prestasi mesti menunggu sehingga sistem pada asasnya baik dan stabil untuk menjadi berkesan Jika tidak, ia akan menjadi sukar untuk diuji dengan lancar, dan mustahil untuk menentukan sama ada keabnormalan adalah masalah dengan seni bina sistem atau sama ada ia adalah kecacatan Fungsian.
Ujian kestabilan (juga dipanggil ujian kebolehpercayaan)
Dengan memuatkan tekanan perniagaan tertentu pada sistem dan membiarkan sistem berjalan secara berterusan untuk satu tempoh masa (biasanya 7x24 jam), ia menguji sama ada sistem boleh berjalan secara stabil.
Keluaran produk adalah langkah terakhir selepas ujian sistem Biasanya, dalam proses pembangunan produk perisian, tidak perlu pengeluaran percubaan produk dan ia boleh masuk secara dalam talian sahaja penguji diperlukan untuk mengeluarkan ujian sistem. Hanya melaporkan dan meluluskan produk untuk dikeluarkan (siarkan secara langsung).
Sebelum keluaran produk, sesi taklimat keluaran produk diperlukan untuk menyemak keseluruhan proses pembangunan produk dari penubuhan projek untuk menunjukkan kelemahan dalam keseluruhan proses, meringkaskan pengalaman dan menyediakan kes pengalaman untuk projek seterusnya. Mesyuarat ini boleh diadakan dalam bentuk mesyuarat rasmi Pengurus produk, pembangun utama, penguji, pemimpin atasan, dll. Mereka mesti bersedia sepenuhnya dan cuba sedaya upaya untuk menerangkan kesan dan faedah produk selepas ia dikeluarkan, untuk menilai nilai selepas ia dilancarkan. Pautan ini amat diperlukan Walaupun dalam syarikat Internet dengan kelajuan lelaran yang pantas, pautan ini masih perlu dipenuhi.
Sebenarnya proses ini tidak wujud dalam sistem proses pembangunan, tetapi saya secara peribadi berpendapat ia sangat penting.
Semua ringkasan hanya boleh diperolehi dengan berfikir dengan soalan. Ini adalah ulasan. Tidak kira berapa banyak yang saya katakan, jika saya tidak mengalami pengalaman yang sama, sukar untuk mempunyai resonans yang kuat. Saya fikir cara terbaik untuk melihat masalah dengan jelas ialah anda telah berada dalam dua peranan berbeza dalam masalah yang sama.
Tujuan meringkaskan pengalaman dan pengajaran projek adalah untuk meringkaskan masalah, menganalisis punca dan mengelak daripada melakukan kesilapan yang sama pada masa hadapan, dan bukannya meminta sesiapa bertanggungjawab.
Andaikan terdapat kecacatan dalam pemahaman keperluan Jika ia ditemui semasa peringkat keperluan, ia mungkin hanya mengambil masa sejam untuk mengubah suainya. ia dianggarkan mengambil masa sehari kerana pertambahan orang dan masa dokumen yang terlibat, dan jika kecacatan ini ditemui hanya selepas kod ditulis, ia mungkin mengambil masa sepuluh atau lapan hari. Bagaimana jika kecacatan itu tidak ditemui dan terus ke sistem pengeluaran? Ini bukan lagi soal beban kerja, dan anggaran kerugian sukar untuk dianggarkan. Dalam teori pengurusan kualiti, setiap kali kecacatan ditemui lewat, kos pembaikan akan digandakan sepuluh kali ganda.
Pembangunan tangkas, pembangunan melampau dan model lain adalah untuk menyelesaikan masalah lelaran pantas apabila keperluan tidak jelas dan masa yang ketat, bukannya menafikan proses R&D secara asasnya masih perlu direka bentuk, hanya bahagikan kitaran hayat dan bahagikan proses secara mendatar kepada beberapa kitaran. Pembangunan perisian ialah satu disiplin dengan keperluan kejuruteraan yang ketat Marilah kita mematuhi sikap yang ketat dan kaedah kerja yang cekap untuk mencipta produk perisian yang sangat tersedia dan berkualiti tinggi.
Artikel ini dicetak semula, pengarang asal: Zhou Mingyao, alamat asal: https://mp.weixin.qq.com/s/-XDomowMhz9rX-zeCIJuaA
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
