Tulisan ini akan menjelaskan pendekatan ilmiah untuk memecahkan masalah. Meskipun ditulis untuk mengatasi masalah yang berhubungan dengan Teknologi Informasi, konsep mungkin juga dapat diterapkan dalam disiplin lain. Metode, konsep, dan teknik yang telah dijelaskan di sini adalah sesuatu yang baru, tapi mengejutkan berapa banyak "pemecah masalah" gagal untuk menggunakannya. Di antara Aku akan menyertakan beberapa contoh nyata.
Mengapa pemecah masalah menebak manfaat mengikuti pendekatan ilmiah untuk memecahkan masalah? Mungkin karena terasa lebih cepat? Mungkin kurangnya pengalaman dalam pemecahan masalah yang efisien? Atau mungkin karena rasanya kerja keras untuk melakukannya secara ilmiah? Mungkin sementara Anda terus menebak-nebak dan tidak benar-benar memecahkan, Anda menghasilkan lebih banyak pendapatan dan menambahkan beberapa keamanan pekerjaan? Atau mungkin karena Anda melanggar prinsip pertama dari pemecahan masalah: mengerti masalahnya.
Prinsip # 1. Memahami * nyata * masalah.
Bukankah jelas bahwa sebelum Anda dapat menyelesaikan, anda perlu memahami masalah? Mungkin. Namun, sebagian besar waktu para solver akan mulai memecahkan tanpa mengetahui masalah yang sebenarnya. Apa yang klien atau pengguna gambarkan sebagai "Masalah" biasanya hanya gejala! "komputer saya tidak mau mengaktifkan" adalah gejala. Masalah sebenarnya mungkin bahwa seluruh bangunan itu tanpa kekuasaan. "Setiap kali saya mencoba untuk menambahkan produk baru, saya mendapat pesan kesalahan" adalah gejala. Di sini masalah yang sebenarnya bisa "Hanya 2 produk terakhir saya mencoba untuk menambahkan memberikan 'Produk sudah ada' kesalahan". Contoh klasik lain: "Tidak ada yang bekerja". . .
Anda memulai penyelidikan dengan mendefinisikan "masalah". Ini akan memerlukan mengajukan pertanyaan (dan kadang-kadang memverifikasi mereka), dan melakukan beberapa pengujian dasar. Ajukan pertanyaan-pertanyaan pengguna seperti "kapan terakhir kali itu berhasil berhasil? "," Berapa lama Anda telah menggunakan sistem? "," Apakah itu bekerja di PC lain maupun pengguna lain? "," Apa tepatnya pesan kesalahan? "dll Mintalah layar-jejak kesalahan jika mungkin. Dasar Anda akan pengujian untuk memastikan end-to-end peralatan dan berjalan. Periksa pengguna PC, jaringan, Web Server, Firewall, File Server, Database back-end, dll Best-kasus Anda akan pint-point masalah sudah. Terburuk Anda bisa menghilangkan banyak daerah untuk penyebab masalahnya.
Sebuah contoh kehidupan nyata. Gejala sesuai dengan user: "Sistem menutup telepon secara acak kali ketika saya memesan". Lingkungan: Para pengguna memasukkan perintah detail di formulir dalam aplikasi mainframe. Ketika semua rincian selesai, pengguna akan tab dari formulir. Mainframe kemudian mengirimkan detail ini melalui perangkat lunak komunikasi untuk Oracle Client / Server sistem di pabrik. Sistem Oracle akan melakukan perencanaan kapasitas dan juga mengembalikan sebuah kesalahan atau suatu tanggal untuk diharapkan kembali ke sistem mainframe. Masalah ini sangat serius, karena Anda bisa kehilangan klien jika mereka mencoba untuk menempatkan sistem perintah dan tidak menerima mereka! Untuk mencoba mengatasi masalah ini, orang-orang mulai dengan menyelidiki: 1) Beban dan kapasitas dari hardware mainframe 2) Memantau beban jaringan antara mainframe dan sistem Oracle 3) Mempekerjakan konsultan untuk men-debug software komunikasi 4) Debugging Oracle kapasitas sistem perencanaan Setelah menghabiskan beberapa bulan mereka tidak bisa memecahkan masalah.
The "Scientific Problem Solver" dipanggil masuk Hanya butuh waktu kurang dari satu hari dan masalah itu terpecahkan! Bagaimana? Para pemecah menghabiskan hari pada pengguna untuk melihat apa yang "masalah" itu. Ditemukan bahwa masalah hanya terjadi dengan pesanan ekspor. Dengan menyelidiki layar menangkap dan tindakan pengguna, ditemukan bahwa dengan pesanan ekspor bidang terakhir pada form selalu dibiarkan kosong dan pengguna tidak tab dari bidang ini. Sistem ini tidak menggantung, itu menunggu pengguna untuk tekan "tab" lain waktu. Problem solved. Dapat dicatat bahwa "Masalah ilmiah Solver" sudah sangat terbatas pengetahuan tentang mainframe, dari ordo menangkap sistem, perangkat lunak komunikasi, dan dari sistem perencanaan kapasitas Oracle. Dan ini membawa kita pada Prinsip # 2.
Prinsip # 2. Jangan takut untuk memulai proses penyelesaian, bahkan jika Anda tidak mengerti sistem.
Berapa kali Anda mendengar "Aku tidak bisa menyentuh kode, karena dikembangkan oleh orang lain! ", atau" Saya tidak bisa membantu karena saya seorang HR Consultant dan itu adalah masalah Keuangan "? Mesin cuci jika Anda tidak ingin mengaktifkan, Anda tidak perlu menjadi seorang Electrical Engineer, Spesialis Perbaikan Mesin Cuci, Teknisi, atau apa pun yang spesialis untuk melakukan beberapa kesalahan dasar temuan tersebut. Pastikan steker bekerja. Cek perjalanan-switch, dll "Aku belum pernah melihat kesalahan ini sebelum" tidak boleh berhenti Anda dari mencoba memecahkan. Dengan pesan kesalahan dan mesin pencari internet, Anda bisa mendapatkan banyak titik awal.
Dalam setiap sistem kompleks ada beberapa dasar prinsip-prinsip kerja. Sistem A yang membaca data dari Sistem B dapat mengerikan kompleks (mungkin Laboratorium Spektrometer yang membaca data dari Programmable Logic Komputer melalui RS-232 port). Namun, beberapa dasar untuk menguji: Apakah kedua sistem tersebut memiliki kekuasaan? Apakah ada pesan error di event log pada salah satu sistem ini? Dapatkah Anda "ping" atau jejak paket jaringan dari satu sistem yang lain? Coba kabel komunikasi yang berbeda. Cari internet untuk pesan kesalahan.
Sekali Anda telah menetapkan apa masalahnya, Anda perlu mulai memecahkannya. Kadang-kadang penyelidikan awal akan mengarahkan Anda langsung ke solusi (saklar daya, ganti kabel rusak, dll). Tapi, kadang-kadang masalah yang sebenarnya rumit dalam dirinya sendiri, maka prinsip berikutnya adalah menyelesaikan sederhana.
Prinsip # 3. Menaklukkannya sederhana.
Mari kita mulai bagian ini dengan contoh kehidupan nyata. Dalam kondisi tertentu, sebuah prosedur yang tersimpan akan menggantung. Prosedur yang disimpan biasanya membutuhkan waktu sekitar satu jam untuk menjalankan (jika tidak menggantung). Jadi, pengembang berusaha untuk debug. Membuat beberapa perubahan dan kemudian menunggu satu jam lagi untuk melihat apakah masalah ini dipecahkan. Setelah beberapa hari pengembang menyerah dan "Problem Solver" mengambil alih. The "Problem Solver" harus nya pembuangan pengetahuan di bawah kondisi penyihir prosedur yang tersimpan akan menggantung. Jadi, itu adalah latihan sederhana untuk membuat salinan dari prosedur, dan kemudian dengan salinan ini untuk melucuti semua kode yang tidak perlu. Semua parameter yang berubah dengan nilai-nilai dikodekan keras. Potongan kode dieksekusi pada satu waktu dan hasil-set sekali lagi keras-kode ke dalam salinan prosedur. Dalam waktu 3 jam masalah terpecahkan. Loop tak terbatas ditemukan.
Apa yang "Problem Solver" itu, adalah untuk meniru masalah dan pada saat yang sama mencoba untuk mengisolasi kode yang menyebabkan masalah. Dalam melakukannya, kompleks (dan memakan waktu) disimpan prosedur menjadi sesuatu yang cepat dan sederhana.
Jika masalah ada di dalam aplikasi, membuat aplikasi baru dan mencoba untuk mensimulasikan masalah dalam aplikasi baru sesederhana mungkin. Jika masalah terjadi ketika sebuah metode tertentu untuk kontrol tertentu dipanggil, kemudian cobalah untuk hanya menyertakan kontrol dalam aplikasi yang kosong dan memanggil metode yang dikodekan dengan keras nilai-nilai. Jika masalah adalah dengan SQL tertanam di dalam C # aplikasi, lalu mencoba untuk mensimulasikan SQL dalam sebuah alat Query Database (seperti SQL * Plus untuk Oracle, Query Analyzer untuk SQL Server, atau menggunakan kode dalam MS Excel melalui ODBC ke database ).
Saat Anda dapat mereplikasi masalah dengan cara yang sederhana, Anda lebih dari 80% di jalan untuk menyelesaikannya.
Jika Anda tidak tahu di mana dalam program ini masalahnya, kemudian gunakan DEBUG.
Prinsip # 4. Debug.
Sebagian besar alat-alat pengembangan aplikasi standar datang dengan debugger. Cuaca itu adalah Macromedia Flash, Microsoft Dot Net, Delphi, atau apa pun lingkungan pengembangan akan ada semacam debugger. Jika alat tidak datang standar dengan debugger, maka Anda dapat mensimulasikan satu.
Hal pertama yang Anda ingin lakukan dengan debugger adalah untuk menentukan di mana masalahnya. Anda melakukan ini dengan menambahkan breakpoints di bidang kunci. Kemudian anda menjalankan program dalam mode debug dan Anda akan tahu antara breakpoints masalah yang terjadi. Menelusuri dan Anda akan menemukan tempat. Sekarang Anda tahu di mana masalahnya, Anda bisa "menaklukkannya sederhana"
Fitur bagus lain dari kebanyakan debugger mencakup fasilitas untuk menonton variabel, nilai, parameter, dll sebagai langkah Anda melalui program ini. Dengan nilai-nilai ini diketahui pada langkah-langkah tertentu, Anda bisa keras-kode mereka ke "versi sederhana" program
Jika alat pembangunan tidak mendukung debugging, maka Anda dapat mensimulasikan itu. Dimasukkan ke dalam langkah-langkah dalam program yang output nilai variabel dan "halo Aku di sini" pesan baik ke layar, untuk file log, atau ke tabel database. Ingatlah untuk membawa mereka keluar setelah masalah ini teratasi. . . Anda tidak ingin sistem file Anda akan berantakan atau penuh dengan file-file log!
Prinsip # 5. Ada banyak informasi pada database back-end yang akan membantu untuk memecahkan masalah.
The "Problem Solver" dipanggil untuk membantu menyelesaikan masalah yang sangat rumit. Sebuah proyek adalah sistem migrasi dari mainframe ke client-server teknologi. Semua berjalan dengan baik selama pengujian, tetapi ketika sistem itu hidup, tiba-tiba ada cukup banyak, dan cukup acak "Jenderal Perlindungan Kesalahan". (The GPF-kesalahan adalah perangkap kesalahan umum pada Windows 95 dan 98). Itu mencoba untuk menyederhanakan kode, debug adalah berusaha, tapi itu mustahil untuk ditiru. Dalam lingkungan LAB, masalah tidak akan terjadi! Debugging melacak pesan ke file-file log menunjukkan bahwa masalah terjadi sangat acak. Beberapa pengguna yang berpengalaman lebih dari yang lain, tapi akhirnya semua pengguna akan mendapatkan mereka! Masalah menarik.
The "Problem Solver" dipecahkan ini setelah ia mulai menganalisis database back-end. Tidak yakin apakah itu kebetulan atau karena ia sistematis bergerak dalam arah yang tepat karena pendekatan ilmiah. Melalui menelusuri apa yang terjadi di tingkat back-end, ditemukan bahwa semua aplikasi ini adalah menciptakan lebih banyak-dan-lebih banyak koneksi ke database. Setiap kali user menjalankan transaksi baru lain didirikan untuk koneksi database. Jumlah total dari koneksi hanya dilepaskan ketika aplikasi ditutup. Sebagai user navigasikan jendela baru dalam aplikasi yang sama, lebih dan lebih banyak koneksi dibuka, dan setelah sejumlah tertentu koneksi, aplikasi akan memiliki cukup dan kemudian crash. Ini adalah kesalahan pemrograman dalam sebuah template yang digunakan oleh semua pengembang. Solusinya adalah untuk pertama-tama menguji jika kursor ke database sudah terbuka, sebelum membuka lagi.
Bagaimana Anda melacak di database back-end apa yang terjadi? Database utama memiliki GUI penyedia alat-alat yang membantu Anda untuk melacak atau menganalisis apa yang dipecat query terhadap database. Juga akan menunjukkan kepada Anda ketika orang terhubung, lepaskan, atau tidak dapat menghubungkan karena pelanggaran keamanan. Kebanyakan database juga mencakup beberapa kamus tabel sistem yang dapat bertanya untuk mendapatkan informasi ini. Jejak ini kadang-kadang bisa kirim 'n seluruh kisah tentang mengapa sesuatu itu gagal. Kode query mengambil dari jejak dapat membantu untuk "menyederhanakan pencarian". Anda dapat melihat dari jejak jika program berhasil membuat kontak dengan database. Anda dapat melihat berapa lama waktu yang dibutuhkan untuk query untuk mengeksekusi.
Untuk menambah Prinsip # 2 (jangan takut untuk memulai...); Anda dapat menganalisis informasi jejak ini, walaupun anda mungkin tidak tahu apa-apa tentang detail dari aplikasi.
Ingat meskipun back-end ini jejak dapat menempatkan sebuah ketegangan pada sumber daya back-end. Jangan biarkan mereka berlari untuk tidak perlu lama.
Prinsip # 6. Gunakan mata segar.
Ini adalah prinsip terakhir. Jangan terlalu banyak menghabiskan waktu pada masalah sebelum Anda meminta bantuan. Bantuan tidak harus dari orang yang lebih senior daripada Anda. Prinsipnya adalah bahwa Anda perlu sepasang mata segar untuk perspektif yang segar dan kadang-kadang sedikit udara segar dengan mengambil istirahat. Orang lain akan melihat dan kemudian mengajukan pertanyaan atau dua. Kadang-kadang itu adalah sesuatu yang sangat jelas yang tidak terjawab. Kadang-kadang hanya dengan menjawab pertanyaan itu membuat Anda berpikir dalam arah baru. Juga, jika Anda menghabiskan berjam-jam melihat potongan kode yang sama, sangat mudah untuk mulai mencari lebih dari kesalahan yang konyol. Banyak masalah perimbangan keuangan bisa diselesaikan atas bir. Bisa perubahan pemandangan, dan / atau suasana santai yang akan meletup dari solusi. Mungkin itu adalah oksigen segar yang pergi ke otak sambil berjalan ke pub. Mungkin itu karena masalah sampai dibicarakan dengan orang lain.
Mengapa pemecah masalah menebak manfaat mengikuti pendekatan ilmiah untuk memecahkan masalah? Mungkin karena terasa lebih cepat? Mungkin kurangnya pengalaman dalam pemecahan masalah yang efisien? Atau mungkin karena rasanya kerja keras untuk melakukannya secara ilmiah? Mungkin sementara Anda terus menebak-nebak dan tidak benar-benar memecahkan, Anda menghasilkan lebih banyak pendapatan dan menambahkan beberapa keamanan pekerjaan? Atau mungkin karena Anda melanggar prinsip pertama dari pemecahan masalah: mengerti masalahnya.
Prinsip # 1. Memahami * nyata * masalah.
Bukankah jelas bahwa sebelum Anda dapat menyelesaikan, anda perlu memahami masalah? Mungkin. Namun, sebagian besar waktu para solver akan mulai memecahkan tanpa mengetahui masalah yang sebenarnya. Apa yang klien atau pengguna gambarkan sebagai "Masalah" biasanya hanya gejala! "komputer saya tidak mau mengaktifkan" adalah gejala. Masalah sebenarnya mungkin bahwa seluruh bangunan itu tanpa kekuasaan. "Setiap kali saya mencoba untuk menambahkan produk baru, saya mendapat pesan kesalahan" adalah gejala. Di sini masalah yang sebenarnya bisa "Hanya 2 produk terakhir saya mencoba untuk menambahkan memberikan 'Produk sudah ada' kesalahan". Contoh klasik lain: "Tidak ada yang bekerja". . .
Anda memulai penyelidikan dengan mendefinisikan "masalah". Ini akan memerlukan mengajukan pertanyaan (dan kadang-kadang memverifikasi mereka), dan melakukan beberapa pengujian dasar. Ajukan pertanyaan-pertanyaan pengguna seperti "kapan terakhir kali itu berhasil berhasil? "," Berapa lama Anda telah menggunakan sistem? "," Apakah itu bekerja di PC lain maupun pengguna lain? "," Apa tepatnya pesan kesalahan? "dll Mintalah layar-jejak kesalahan jika mungkin. Dasar Anda akan pengujian untuk memastikan end-to-end peralatan dan berjalan. Periksa pengguna PC, jaringan, Web Server, Firewall, File Server, Database back-end, dll Best-kasus Anda akan pint-point masalah sudah. Terburuk Anda bisa menghilangkan banyak daerah untuk penyebab masalahnya.
Sebuah contoh kehidupan nyata. Gejala sesuai dengan user: "Sistem menutup telepon secara acak kali ketika saya memesan". Lingkungan: Para pengguna memasukkan perintah detail di formulir dalam aplikasi mainframe. Ketika semua rincian selesai, pengguna akan tab dari formulir. Mainframe kemudian mengirimkan detail ini melalui perangkat lunak komunikasi untuk Oracle Client / Server sistem di pabrik. Sistem Oracle akan melakukan perencanaan kapasitas dan juga mengembalikan sebuah kesalahan atau suatu tanggal untuk diharapkan kembali ke sistem mainframe. Masalah ini sangat serius, karena Anda bisa kehilangan klien jika mereka mencoba untuk menempatkan sistem perintah dan tidak menerima mereka! Untuk mencoba mengatasi masalah ini, orang-orang mulai dengan menyelidiki: 1) Beban dan kapasitas dari hardware mainframe 2) Memantau beban jaringan antara mainframe dan sistem Oracle 3) Mempekerjakan konsultan untuk men-debug software komunikasi 4) Debugging Oracle kapasitas sistem perencanaan Setelah menghabiskan beberapa bulan mereka tidak bisa memecahkan masalah.
The "Scientific Problem Solver" dipanggil masuk Hanya butuh waktu kurang dari satu hari dan masalah itu terpecahkan! Bagaimana? Para pemecah menghabiskan hari pada pengguna untuk melihat apa yang "masalah" itu. Ditemukan bahwa masalah hanya terjadi dengan pesanan ekspor. Dengan menyelidiki layar menangkap dan tindakan pengguna, ditemukan bahwa dengan pesanan ekspor bidang terakhir pada form selalu dibiarkan kosong dan pengguna tidak tab dari bidang ini. Sistem ini tidak menggantung, itu menunggu pengguna untuk tekan "tab" lain waktu. Problem solved. Dapat dicatat bahwa "Masalah ilmiah Solver" sudah sangat terbatas pengetahuan tentang mainframe, dari ordo menangkap sistem, perangkat lunak komunikasi, dan dari sistem perencanaan kapasitas Oracle. Dan ini membawa kita pada Prinsip # 2.
Prinsip # 2. Jangan takut untuk memulai proses penyelesaian, bahkan jika Anda tidak mengerti sistem.
Berapa kali Anda mendengar "Aku tidak bisa menyentuh kode, karena dikembangkan oleh orang lain! ", atau" Saya tidak bisa membantu karena saya seorang HR Consultant dan itu adalah masalah Keuangan "? Mesin cuci jika Anda tidak ingin mengaktifkan, Anda tidak perlu menjadi seorang Electrical Engineer, Spesialis Perbaikan Mesin Cuci, Teknisi, atau apa pun yang spesialis untuk melakukan beberapa kesalahan dasar temuan tersebut. Pastikan steker bekerja. Cek perjalanan-switch, dll "Aku belum pernah melihat kesalahan ini sebelum" tidak boleh berhenti Anda dari mencoba memecahkan. Dengan pesan kesalahan dan mesin pencari internet, Anda bisa mendapatkan banyak titik awal.
Dalam setiap sistem kompleks ada beberapa dasar prinsip-prinsip kerja. Sistem A yang membaca data dari Sistem B dapat mengerikan kompleks (mungkin Laboratorium Spektrometer yang membaca data dari Programmable Logic Komputer melalui RS-232 port). Namun, beberapa dasar untuk menguji: Apakah kedua sistem tersebut memiliki kekuasaan? Apakah ada pesan error di event log pada salah satu sistem ini? Dapatkah Anda "ping" atau jejak paket jaringan dari satu sistem yang lain? Coba kabel komunikasi yang berbeda. Cari internet untuk pesan kesalahan.
Sekali Anda telah menetapkan apa masalahnya, Anda perlu mulai memecahkannya. Kadang-kadang penyelidikan awal akan mengarahkan Anda langsung ke solusi (saklar daya, ganti kabel rusak, dll). Tapi, kadang-kadang masalah yang sebenarnya rumit dalam dirinya sendiri, maka prinsip berikutnya adalah menyelesaikan sederhana.
Prinsip # 3. Menaklukkannya sederhana.
Mari kita mulai bagian ini dengan contoh kehidupan nyata. Dalam kondisi tertentu, sebuah prosedur yang tersimpan akan menggantung. Prosedur yang disimpan biasanya membutuhkan waktu sekitar satu jam untuk menjalankan (jika tidak menggantung). Jadi, pengembang berusaha untuk debug. Membuat beberapa perubahan dan kemudian menunggu satu jam lagi untuk melihat apakah masalah ini dipecahkan. Setelah beberapa hari pengembang menyerah dan "Problem Solver" mengambil alih. The "Problem Solver" harus nya pembuangan pengetahuan di bawah kondisi penyihir prosedur yang tersimpan akan menggantung. Jadi, itu adalah latihan sederhana untuk membuat salinan dari prosedur, dan kemudian dengan salinan ini untuk melucuti semua kode yang tidak perlu. Semua parameter yang berubah dengan nilai-nilai dikodekan keras. Potongan kode dieksekusi pada satu waktu dan hasil-set sekali lagi keras-kode ke dalam salinan prosedur. Dalam waktu 3 jam masalah terpecahkan. Loop tak terbatas ditemukan.
Apa yang "Problem Solver" itu, adalah untuk meniru masalah dan pada saat yang sama mencoba untuk mengisolasi kode yang menyebabkan masalah. Dalam melakukannya, kompleks (dan memakan waktu) disimpan prosedur menjadi sesuatu yang cepat dan sederhana.
Jika masalah ada di dalam aplikasi, membuat aplikasi baru dan mencoba untuk mensimulasikan masalah dalam aplikasi baru sesederhana mungkin. Jika masalah terjadi ketika sebuah metode tertentu untuk kontrol tertentu dipanggil, kemudian cobalah untuk hanya menyertakan kontrol dalam aplikasi yang kosong dan memanggil metode yang dikodekan dengan keras nilai-nilai. Jika masalah adalah dengan SQL tertanam di dalam C # aplikasi, lalu mencoba untuk mensimulasikan SQL dalam sebuah alat Query Database (seperti SQL * Plus untuk Oracle, Query Analyzer untuk SQL Server, atau menggunakan kode dalam MS Excel melalui ODBC ke database ).
Saat Anda dapat mereplikasi masalah dengan cara yang sederhana, Anda lebih dari 80% di jalan untuk menyelesaikannya.
Jika Anda tidak tahu di mana dalam program ini masalahnya, kemudian gunakan DEBUG.
Prinsip # 4. Debug.
Sebagian besar alat-alat pengembangan aplikasi standar datang dengan debugger. Cuaca itu adalah Macromedia Flash, Microsoft Dot Net, Delphi, atau apa pun lingkungan pengembangan akan ada semacam debugger. Jika alat tidak datang standar dengan debugger, maka Anda dapat mensimulasikan satu.
Hal pertama yang Anda ingin lakukan dengan debugger adalah untuk menentukan di mana masalahnya. Anda melakukan ini dengan menambahkan breakpoints di bidang kunci. Kemudian anda menjalankan program dalam mode debug dan Anda akan tahu antara breakpoints masalah yang terjadi. Menelusuri dan Anda akan menemukan tempat. Sekarang Anda tahu di mana masalahnya, Anda bisa "menaklukkannya sederhana"
Fitur bagus lain dari kebanyakan debugger mencakup fasilitas untuk menonton variabel, nilai, parameter, dll sebagai langkah Anda melalui program ini. Dengan nilai-nilai ini diketahui pada langkah-langkah tertentu, Anda bisa keras-kode mereka ke "versi sederhana" program
Jika alat pembangunan tidak mendukung debugging, maka Anda dapat mensimulasikan itu. Dimasukkan ke dalam langkah-langkah dalam program yang output nilai variabel dan "halo Aku di sini" pesan baik ke layar, untuk file log, atau ke tabel database. Ingatlah untuk membawa mereka keluar setelah masalah ini teratasi. . . Anda tidak ingin sistem file Anda akan berantakan atau penuh dengan file-file log!
Prinsip # 5. Ada banyak informasi pada database back-end yang akan membantu untuk memecahkan masalah.
The "Problem Solver" dipanggil untuk membantu menyelesaikan masalah yang sangat rumit. Sebuah proyek adalah sistem migrasi dari mainframe ke client-server teknologi. Semua berjalan dengan baik selama pengujian, tetapi ketika sistem itu hidup, tiba-tiba ada cukup banyak, dan cukup acak "Jenderal Perlindungan Kesalahan". (The GPF-kesalahan adalah perangkap kesalahan umum pada Windows 95 dan 98). Itu mencoba untuk menyederhanakan kode, debug adalah berusaha, tapi itu mustahil untuk ditiru. Dalam lingkungan LAB, masalah tidak akan terjadi! Debugging melacak pesan ke file-file log menunjukkan bahwa masalah terjadi sangat acak. Beberapa pengguna yang berpengalaman lebih dari yang lain, tapi akhirnya semua pengguna akan mendapatkan mereka! Masalah menarik.
The "Problem Solver" dipecahkan ini setelah ia mulai menganalisis database back-end. Tidak yakin apakah itu kebetulan atau karena ia sistematis bergerak dalam arah yang tepat karena pendekatan ilmiah. Melalui menelusuri apa yang terjadi di tingkat back-end, ditemukan bahwa semua aplikasi ini adalah menciptakan lebih banyak-dan-lebih banyak koneksi ke database. Setiap kali user menjalankan transaksi baru lain didirikan untuk koneksi database. Jumlah total dari koneksi hanya dilepaskan ketika aplikasi ditutup. Sebagai user navigasikan jendela baru dalam aplikasi yang sama, lebih dan lebih banyak koneksi dibuka, dan setelah sejumlah tertentu koneksi, aplikasi akan memiliki cukup dan kemudian crash. Ini adalah kesalahan pemrograman dalam sebuah template yang digunakan oleh semua pengembang. Solusinya adalah untuk pertama-tama menguji jika kursor ke database sudah terbuka, sebelum membuka lagi.
Bagaimana Anda melacak di database back-end apa yang terjadi? Database utama memiliki GUI penyedia alat-alat yang membantu Anda untuk melacak atau menganalisis apa yang dipecat query terhadap database. Juga akan menunjukkan kepada Anda ketika orang terhubung, lepaskan, atau tidak dapat menghubungkan karena pelanggaran keamanan. Kebanyakan database juga mencakup beberapa kamus tabel sistem yang dapat bertanya untuk mendapatkan informasi ini. Jejak ini kadang-kadang bisa kirim 'n seluruh kisah tentang mengapa sesuatu itu gagal. Kode query mengambil dari jejak dapat membantu untuk "menyederhanakan pencarian". Anda dapat melihat dari jejak jika program berhasil membuat kontak dengan database. Anda dapat melihat berapa lama waktu yang dibutuhkan untuk query untuk mengeksekusi.
Untuk menambah Prinsip # 2 (jangan takut untuk memulai...); Anda dapat menganalisis informasi jejak ini, walaupun anda mungkin tidak tahu apa-apa tentang detail dari aplikasi.
Ingat meskipun back-end ini jejak dapat menempatkan sebuah ketegangan pada sumber daya back-end. Jangan biarkan mereka berlari untuk tidak perlu lama.
Prinsip # 6. Gunakan mata segar.
Ini adalah prinsip terakhir. Jangan terlalu banyak menghabiskan waktu pada masalah sebelum Anda meminta bantuan. Bantuan tidak harus dari orang yang lebih senior daripada Anda. Prinsipnya adalah bahwa Anda perlu sepasang mata segar untuk perspektif yang segar dan kadang-kadang sedikit udara segar dengan mengambil istirahat. Orang lain akan melihat dan kemudian mengajukan pertanyaan atau dua. Kadang-kadang itu adalah sesuatu yang sangat jelas yang tidak terjawab. Kadang-kadang hanya dengan menjawab pertanyaan itu membuat Anda berpikir dalam arah baru. Juga, jika Anda menghabiskan berjam-jam melihat potongan kode yang sama, sangat mudah untuk mulai mencari lebih dari kesalahan yang konyol. Banyak masalah perimbangan keuangan bisa diselesaikan atas bir. Bisa perubahan pemandangan, dan / atau suasana santai yang akan meletup dari solusi. Mungkin itu adalah oksigen segar yang pergi ke otak sambil berjalan ke pub. Mungkin itu karena masalah sampai dibicarakan dengan orang lain.
Kesimpulan
Setelah membaca makalah ini, penulis berharap bahwa anda akan mencoba hal ini di lain waktu Anda menghadapi masalah seperti ini. Mudah-mudahan dengan menerapkan prinsip-prinsip keenam Anda akan menyadari keuntungan yang mereka bawa, bukan untuk "menebak" jalan ke solusi.
sumber : www.johns-company.com
Postingan
