"Itu berhasil kemarin, aku bersumpah!" Apa yang bisa kamu lakukan? [Tutup]


59

Ketika Anda tiba di pagi hari, Anda menemukan bahwa perangkat lunak Anda tidak berfungsi lagi, meskipun itu terjadi ketika Anda pergi kemarin malam.

Apa yang kamu kerjakan? Apa yang Anda periksa pertama kali? Apa yang Anda lakukan untuk berhenti marah dan mulai mengerjakan masalah Anda? Apakah Anda menyalahkan kolega Anda dan langsung mendatangi mereka? Apa yang dapat dilakukan untuk menghindari situasi seperti itu?


10
Menyalahkan bukanlah ide yang bagus. Karena Anda belum menguraikan pertanyaan atau masalah, tidak mungkin menebak bahwa program tidak menghasilkan kesalahan itu sendiri. Sebagai contoh: Jika sebuah situs web di server hosting mencapai batas bandwidth, itu turun sendiri. Karena itu Anda tidak dapat menyalahkan siapa pun sampai Anda yakin bahwa kode itu tidak berlaku semula.
Pankaj Upadhyay

1
baik itu bukan pada stack overflow sehingga lebih merupakan pertanyaan umum. Bagian menyalahkan adalah sedikit lelucon :)
Nikko

28
@ Nikko - tidak berhasil kemarin juga. ITULAH yang terjadi banyak dalam pengembangan perangkat lunak :)
Joris Timmermans

4
Untuk menghindari situasi, jangan buru-buru menguji sehingga Anda dapat menggunakan dalam beberapa menit terakhir sore. Dan lepaskan kacamata hitam pekat mawar / bahaya Anda saat menguji.
Steve314

18
Apakah ada hubungannya dengan DateTime.Now () ???
Sarawut Positwinyu

Jawaban:


96

Tersangka yang biasa adalah:

  • Anda mengira itu berhasil kemarin, tetapi setelah seharian bekerja Anda terlalu buta untuk menyadari bahwa itu tidak berhasil.

  • Pagi ini Anda tidak lagi dapat merujuk pada apa yang ada di memori cache IDE kemarin.

  • Workstation telah di-boot ulang tadi malam atau operasi pemeliharaan setiap malam membersihkan direktori / tmp.

  • Sesuatu telah berubah dalam basis kode: periksa apakah seseorang (mungkin diri Anda) telah melakukan perubahan antara kompilasi terakhir Anda kemarin dan kompilasi terakhir Anda hari ini.

  • Sesuatu telah berubah di perpustakaan dukungan: periksa apakah perpustakaan tersebut telah dikompilasi ulang atau ditingkatkan. Penyebabnya mungkin di dalam proyek untuk perpustakaan tertentu atau di luar jika versi baru dari paket yang tampaknya independen telah digunakan.

  • Sesuatu telah berubah di lingkungan pengujian: versi baru dari mesin virtual, rintisan yang telah dimodifikasi, perubahan di server basis data jauh ...

  • Sesuatu telah berubah dalam rantai kompilasi: perubahan pada Makefiles, versi baru IDE, kompiler, dari perpustakaan standar ...


82
Anda lupa "intervensi ilahi" dan "partikel energi tinggi melewati server dan secara acak menata ulang bit". Dan letusan matahari.
Kheldar

17
Anda lupa "Anda menggunakan <masukkan bahasa paling tidak favorit Anda di sini>, yang terkenal tidak bisa diandalkan.
konfigurator

4
@Kheldar - jangan lupa sprite berbahaya, gremlins et al.
5arx

5
@configurator: itu sebabnya Anda harus selalu menulis bahasa Anda sendiri. Tanya Spolsky tentang Wasabi! memeriksa apakah Atwood ada di sekitar dan melarikan diri
Kheldar

13
perangkap klasik lain adalah perubahan tanggal. Ini tentu saja terutama berlaku untuk tanggal "batas" (hari pertama atau terakhir bulan / minggu, 29 Februari, dll).
Brann

49

1) Jika tidak berfungsi hari ini, itu juga tidak berfungsi kemarin.

Anda pikir itu berhasil, tetapi ternyata tidak.

2) Ada masalah, dan itu harus dipecahkan .

Jangan berpikir tentang siapa yang bertanggung jawab untuk ini atau menyalahkan orang lain.

Jika tidak ada yang berubah antara kemarin dan hari ini (seperti saya kira membaca pertanyaan Anda), itu berarti Anda harus melakukan pekerjaan yang lebih baik dalam menguji kode Anda sebelum benar-benar menyatakan itu berfungsi.

Untuk menghindari situasi ini, Anda harus melakukan Pengujian dan Debugging yang benar .

Tentukan "berfungsi" dan uji batas-batas rutin kode Anda.

  • Cobalah menjadi salah satu pengguna yang akan menggunakan fungsionalitas program atau kode Anda.
  • Dorong kode Anda ke batas yang diizinkan dan di luar, dan benar-benar memeriksa apakah itu rusak.

Salah satu cara untuk melakukan ini adalah memiliki serangkaian tes ekstensif yang dijalankan secara otomatis pada malam hari, sehingga sehari setelahnya Anda dapat memeriksa apakah ada masalah dan memperbaiki masalah.


7
Saya ingin memberi Anda dua suara positif - Satu untuk "Jika tidak bekerja hari ini, itu juga tidak berfungsi kemarin." dan satu untuk "ada masalah, dan itu harus dipecahkan". Keduanya adalah ide kunci yang terlalu banyak orang lupakan.
MattBelanger

2
"Jika tidak bekerja hari ini, itu juga tidak berfungsi kemarin." -> Ini terjadi pada saya kemarin melakukan beberapa coding front-end yang mengandalkan cookie. Bekerja dengan baik ketika cookie sudah diatur. Mengetahui itu tidak dibuat dengan benar lagi pada hari berikutnya setelah habis masa berlakunya dan mencoba untuk diciptakan kembali.
Graham

@Graham: lihat "Jika tidak ada yang berubah antara kemarin dan hari ini [...], itu berarti Anda harus melakukan pekerjaan yang lebih baik dalam menguji kode Anda sebelum benar-benar menyatakan itu berfungsi.". Anda harus lebih baik dalam menguji kode Anda, pikirkan apa yang harus terjadi, pikirkan apa yang MUNGKIN terjadi. Mungkin dengan pemahaman masalah yang lebih baik, itu tidak akan terjadi.
Jose Faeti

Adapun 1): Mungkin perubahan yang melanggar ada di perpustakaan tambahan
phresnel

Tidak sepenuhnya benar ...: PI secara tidak sengaja merusak suatu aplikasi, dengan menarik beberapa file cache ke dalam aplikasi saya yang merupakan objek yang telah diserialisasi sepenuhnya dengan cara yang salah. Aplikasi ini baik-baik saja dan itu berfungsi dengan baik, Hanya saja ketika saya melakukan git pull, karena file cache sedang diabaikan, program diperbarui dan perlu objek dalam format yang berbeda. Anda masih mendapatkan upvote;)
Laykes

26

Mencoba mencari seseorang untuk disalahkan tidak konstruktif dan tidak menyelesaikan masalah. Jangan lakukan itu.

Jika sesuatu bekerja kemarin dan tidak berfungsi sekarang, maka apakah Anda memiliki perilaku non-deterministik (seperti kondisi balapan) dan menjadikannya bekerja kemarin hanya keberuntungan, atau sesuatu telah berubah antara dulu dan sekarang, dan Anda perlu mencari tahu apa itu. aku s.

Bagaimana tepatnya Anda mengetahui mana masalahnya dan bagaimana cara memperbaikinya tergantung pada situasi spesifik, tetapi selalu membantu untuk menjadi metodis dalam menghilangkan penyebab, yaitu jangan mengubah 5 hal sekaligus dan berhenti mencari jika itu membantu - cari tahu hal spesifik apa yang menyebabkan masalah, dan mungkin tulis cara memperbaikinya sehingga Anda dapat mencarinya ketika terjadi lagi 3 minggu dari sekarang.

Menggunakan alat diagnostik yang sesuai (debugger, profiler, alat analisis jaringan) juga dapat membuat perbedaan besar.


Mungkin juga membantu untuk membuat catatan tertulis saat menganalisis masalah.
starblue

25

Saya telah bekerja dengan kode yang tampaknya berubah dalam semalam dan setelah beberapa saat saya sampai pada kesimpulan ini adalah karena peri jahat merangkak ke basis kode saya di malam hari dan mengubah hal-hal sedemikian rupa sehingga meskipun faktanya bekerja kemarin, sekarang tidak bekerja sama sekali. Memang dalam gaya Schroedinbug klasik , tidak hanya tidak berfungsi sekarang, juga jelas bahwa tidak mungkin ada cara seperti itu.

Seiring waktu, saya menyadari bahwa mungkin saja faktanya tidak ada hubungannya dengan hal itu dan mungkin "waktu saya untuk pulang, itu sudah cukup" build terakhir tidak mendapatkan pengujian terperinci dan perhatian yang mungkin pantas diterima. .

Asumsi pertama saya ketika saya menemukan ini di pagi hari adalah bahwa itu mungkin salah saya karena saya biasanya yang bertanggung jawab atas fitur saya sendiri atau sudut-sudut perangkat lunak yang saya kerjakan. Asumsi kedua saya adalah bahwa saya mungkin juga mendapatkan kopi itu sekarang. Jika itu bukan sesuatu yang jelas-jelas jelas bahwa monyet bisa mengetahui (yang kadang-kadang memang demikian) maka kemungkinannya bagus bahwa saya telah berhasil menyeret versi lama dari perpustakaan, keliru memutar kembali file yang tidak perlu digulung kembali atau memiliki sesuatu yang di-cache di suatu tempat yang membawanya ke build tanpa memeriksanya. Melewati aktivitas Kontrol Sumber saya baru-baru ini cenderung mengungkapkan hal-hal yang telah saya lakukan, membersihkan bangunan sering kali menghapus versi cache yang salah.

Kadang-kadang itu benar-benar tidak ada hubungannya dengan saya - seseorang memperbarui dependensi tanpa menyebutkannya, WindowsUpdate menginstal sesuatu yang mengubah lingkungan sehingga kode saya tidak berfungsi; ada banyak kemungkinan latar belakang, tetapi biasanya ini adalah kasus berjaga-jaga dan menerima bahwa, seperti kebanyakan orang, pada dasarnya saya seorang idiot.


1
Ini adalah jawaban yang sangat rendah hati dan mencela diri sendiri yang harus kita adopsi. :) Saya biasanya mencatat situasi seperti ini hingga "Hei Moe, Hei Larry, saya mencoba untuk berpikir dan tidak ada yang terjadi!" pada akhir hari. Saya juga menggunakan metode "Berhasil! Cepat, periksa dan pulang sebelum Anda memiliki keinginan untuk memperbaikinya" pada akhir hari, untuk menghindari situasi ini.
Jennifer S

3
Di satu tempat saya bekerja, tidak ada kode yang berfungsi pertama kali di pagi hari. Ternyata ketika kami mem-boot mesin kami Skype akan mengambil port yang ingin digunakan aplikasi saat pertama kali dinyalakan.
guru

Mungkin pixie tidak lebih dari variabel yang tidak diinisialisasi? Kadang-kadang versi debug dapat bekerja ketika versi rilis gagal (crash atau berperilaku berbeda).
Jared Updike

20

Gunakan kontrol versi. Lakukan diff, atau gunakan fungsi menyalahkan VCS Anda .:

  • diff: Setiap VCS. Menunjukkan kepada Anda perbedaan, uhm, versi yang berbeda
  • blame: misalnya git. Menunjukkan Anda secara garis per baris yang telah mengubah apa

Jika tidak ada kontrol versi, selain itu kesalahan Anda sendiri atau bos Anda, Anda dapat melihat tanggal perubahan file dan mungkin melihat fasilitas logging OS Anda.

Terlepas dari itu: Kompilasi ulang semuanya, pastikan juga mengkompilasi ulang perpustakaan bantu.

Tentu saja: Jika Anda menemukan sumber kesalahan, tetap tenang, tanyakan mengapa ada perubahan, jelaskan masalah Anda, dan usulkan solusi yang membuat Anda berdua bahagia. Jangan berteriak padanya, itu akan menjadi racun bagi produktivitas Anda.

Jika tidak ada perubahan sama sekali, saatnya untuk melihat apa yang telah berubah pada sistem. Misalnya, baru-baru ini komputer Mac OS telah memperbarui ke versi baru Apache yang menyebabkan beberapa konfigurasi tidak valid.


1
Diff Ftw. Itulah yang selalu saya lakukan.
Aditya P

2
@AdityaGameProgrammer: Saya menggunakannya beberapa kali sehari hanya untuk melihat apa yang saya kerjakan kemarin atau sebelum istirahat :)
phresnel

Tidak ada kontrol versi ?! Itu benar-benar prospek yang menakutkan.
teman

+1 untuk memberi tahu saya tentang git blame... tidak tahu itu ada, tapi itu FCKING AWESOME
Radu Murzea

11

Nah, ini contoh nyata kode yang "bekerja kemarin" dan bukan hari ini ... Ini dari awal bulan ini.

Aplikasi yang dimaksud menarik informasi dari basis data berdasarkan tanggal, dan perilaku default adalah untuk mendapatkan data untuk hari ini. Ini bekerja dengan baik pada 8 Agustus, tetapi gagal pada tanggal 9. Itu tidak diuji lebih awal dari ini. Ini juga akan bekerja pada 9 September, dan 10 Oktober ...

Petunjuk lain adalah bahwa kita berada di Inggris, basis data yang dimaksud adalah di AS ...

Jadi, jawaban saya untuk pertanyaan Anda tentang apa yang harus diperiksa pertama adalah dengan memeriksa ulang bagaimana Anda memformat tanggal Anda, karena jika Anda mencampur bidang hari dan bulan itu akan berfungsi dengan baik, tetapi hanya pada 1 hari per bulan :-)


5

Perbaiki bug (namun biasanya Anda lakukan). Kemudian jika Anda menemukan siapa yang menyebabkannya, kirimi mereka email yang sopan untuk memberi tahu mereka apa yang salah.

Setiap pengkode membuat kesalahan dan jika Anda mulai menyalahkan maka itu akan menjadi bumerang saat Anda melakukan hal yang sama. (mungkin bahkan bug ini milik Anda)

Hanya jika Anda mencurigai mereka ceroboh seharusnya Anda membuat banyak masalah dari bug.


5

... Anda menjalankan tes regresi dan fokus pada yang gagal.

Sebenarnya apa yang Anda lupa lakukan kemarin sebelum pergi, itu terjadi.

Anda tidak punya? Ok .. apa yang kau katakan? Menyalahkan ? Ya ... itu mungkin berhasil, kalau begitu


5

Hal pertama yang harus dilakukan ketika sesuatu berhenti bekerja adalah bertanya pada diri sendiri - Apa yang berbeda? Apa yang telah berubah?

Ketika sesuatu bekerja semalam tetapi gagal pagi ini, satu hal yang jelas telah berubah adalah - tanggal dan waktu :)

Saya akan mencoba dan berpikir apakah ada bagian dari logika yang saya kerjakan yang tergantung pada tanggal dan mungkin dipengaruhi oleh berlalunya waktu. Sungguh mengejutkan berapa kali itulah penyebab masalah tersebut.

Jika gagal, Anda harus menindaklanjuti saran hebat lainnya yang disediakan di sini.


2
Bug yang melibatkan kekhasan waktu seperti beralih ke / keluar dari daylight saving adalah favorit (pada Oktober dan Maret) ...
Julia Hayward


4

Anda melihat di kotak surat Anda setelah surat yang dikirim oleh mesin Integrasi Berkelanjutan ketika pengujian unit gagal (atau halaman log jika Anda tidak melihat masalah khusus itu), dan melihat siapa yang melakukan check-in sebelum bangunan itu dibangun .

Kemudian bicaralah dengannya.


4

Hanya ada dua kemungkinan alasan mengapa kode Anda gagal hari ini, tetapi berhasil kemarin.

Lihatlah datanya

Ada sesuatu dalam data yang tidak Anda uji dan atau pertanggungjawabkan. Entah data tidak divalidasi dengan benar atau kesalahan dalam logika tidak terungkap sampai kondisi logis Anda tidak mengantisipasi terjadi. Ini berarti bug ada di sana kemarin, tetapi ia bersembunyi dari Anda di bawah data yang valid.

Saya pernah memiliki beberapa kode entri agar berfungsi dengan baik selama berminggu-minggu. Saya pulang ke rumah suatu hari, dan meninggal. Investigasi pada hari berikutnya mengungkapkan bahwa saya memiliki bug yang disembunyikan dalam rantai panggilan fungsi. Dalam bahasa yang diketik dengan lemah, saya menyatakan integer ketika saya seharusnya menggunakan int panjang. Bahasa melakukan konversi antara keduanya secara otomatis sampai tidak bisa karena jumlahnya melebihi apa yang cocok dengan bilangan bulat. Sistem gagal pada nomor pesanan 32768.

Lihatlah Apa yang Berubah

Lihatlah apa yang berubah sejak itu berhasil. Apakah bagian IT mendorong pembaruan OS? Apakah programmer lain memodifikasi kode yang digunakan program Anda? Apakah izin pengguna berubah? Seringkali, jika Anda menemukan apa yang berubah, Anda akan menemukan bug.


3

Chop biner

bekerja sangat baik untuk kesalahan JavaScript yang sulit. Pada dasarnya komentar setengah kode, lihat apakah Anda mendapatkan kesalahan, jika Anda melakukannya di setengah kode. Setengah lagi dan lanjutkan.

Jika kode Anda dienkapsulasi dengan baik, ini adalah alat penghilang stres yang fantastis, menghemat waktu, dan hebat.

Setelah Anda menemukan kode yang salah, sering ada baiknya mengisolasi kesalahan pada halaman pengujian sendiri.


tentu saja jika proyek Anda merentang multi-file ini dapat diperpanjang dengan * batuk secara acak batuk * menghapus setengah dari file proyek Anda, itu jelas merupakan alat penghilang stres yang efektif (pastikan Anda punya cadangan meskipun).
Lie Ryan

Yap, pastikan Anda memiliki cadangan!
chim

3

Dan tentu saja, apa yang dapat dilakukan untuk menghindari situasi seperti itu?

Mengatasi pertanyaan ini, Anda mungkin ingin melihat Integrasi Berkelanjutan (CI) . Sederhananya: CI adalah proses di mana pengembang sering (sebanyak beberapa kali sehari) mengintegrasikan dan menguji semua kode. Idenya adalah bahwa perubahan pada satu modul yang merusak modul lain dengan cepat ditemukan.

Dalam praktiknya, sebagian besar tim yang menggunakan CI menggunakan Server CI (lihat: Daftar Wikipedia ). Server CI biasanya diatur untuk memantau repositori SCM dan mulai membangun ketika melihat perubahan. Ketika build selesai, kemudian akan menjalankan serangkaian tes otomatis dan memposting hasilnya melalui email dan / atau halaman web build dan tes, bersama dengan perubahan apa yang menyebabkan build. Mudah-mudahan, ketika ada sesuatu yang merusak build atau tes, Anda hanya memiliki sedikit perubahan yang ditetapkan untuk dilihat, sehingga itu diselesaikan lebih cepat.

Ada pertanyaan lain di sini tentang Server CI mana yang akan digunakan, jadi saya akan membiarkan Anda menemukannya dengan tertarik. Secara pribadi, saya penggemar berat Jenkins.

[Apa yang harus saya lakukan tentang hal-hal yang rusak.]

Seperti yang sudah dikatakan orang lain, cari tahu apa yang rusak dan cobalah untuk memperbaikinya. Menghabiskan waktu untuk menyalahkan adalah waktu yang dihabiskan untuk tidak menyelesaikan masalah.


Ya di tempat kerja kami menggunakan Jenkins dan itu sangat berguna. Kita dapat memonitor pembangunan di berbagai sistem dan melihat apa yang gagal. Kami bahkan memiliki suar garasi nyata yang mulai berkedip ketika bangunan gagal.
Nikko

3

Reaksi alami saya adalah selalu menyalahkan orang lain, tetapi lama kelamaan saya menyadari bahwa biasanya saya yang bersalah. Selain semua komentar luar biasa di atas, penting bagi Anda untuk mencatat sendiri apa alasan akhirnya. Tidak masalah apakah Anda menggunakan Wiki yang dibagikan dengan anggota tim lain, Twiki pribadi, Evernote, buku log atau memori yang baik. Yang penting, saat ini Anda menemukan jawabannya (dan ingin kembali bekerja!) Adalah mencatat alasannya.


2

Agaknya jika itu tidak berfungsi lagi, Anda telah mengidentifikasi gejala itu tidak berfungsi, yaitu, hang, atau melemparkan kembali dialog kesalahan tertentu kepada pengguna.

Jika satu-satunya deskripsi masalah adalah "tidak berfungsi", hal pertama yang perlu Anda lakukan adalah mengumpulkan lebih banyak informasi tentang gejala-gejala masalah.

Kemudian Anda mulai mencari kemungkinan penyebabnya, baik melalui log atau upaya rekreasi masalah atau kombinasi keduanya - tergantung pada bagaimana sistem Anda diatur, saya kira.

Lalu Anda mulai mengesampingkan mereka.


2

Itulah yang biasanya terjadi ketika saya mengambil liburan :-)

Lebih serius, saya pertama kali akan memberitahu mereka:

  • Saya akan melihat ke dalamnya untuk melihat apa yang salah dan apa yang bisa menjadi root

  • Saya akan menyentuh basis dalam 30-60 menit setelah saya memiliki kesempatan untuk melihat apa yang terjadi

Setelah waktu itu, saya dapat memperkirakan apa yang mungkin terjadi dan berapa lama akan memperbaikinya jika belum diperbaiki dan, jika berlaku, data apa yang mungkin hilang (tetapi saya memiliki cadangan yang baik, sehingga tidak pernah terjadi semoga).


Adapun bagian menyalahkan:

  • jika itu hanya kesalahan ketik kolega, tidak perlu menyebutkannya: omong kosong terjadi dan ketakutan dari bug kemungkinan besar memberinya pelajaran dan mudah-mudahan, dia tidak akan melakukannya lagi.

  • jika dia dengan sengaja melakukan sesuatu yang saya katakan kepadanya untuk tidak (mis. memberikan kata sandi root dari server produksi kepada orang baru dan memintanya untuk melakukan modifikasi secara langsung tanpa pengawasan) (ya, itu sudah terjadi ...), maka saya harus menyebutkannya.


2

Jika metode penelusuran kutu biasa Anda tidak berfungsi dan semuanya berantakan total, akan luar biasa memiliki cadangan yang dapat Anda pulihkan dengan mudah.

Inilah yang saya jalankan secara lokal, secara otomatis setiap jam dari jam 8 pagi sampai 6 sore:

rdiff-backup /path/to/mystuff /path/to/mybackup

Sederhana ya?

Jika Anda harus mengembalikan apa pun, gunakan

rdiff-backup -r 24h /path/to/mybackup/specific/dir /tmp/restored

rdiff-backup hanya menyimpan file yang berbeda. Anda dapat menggunakan rdiff-backup di Linux, mac dan win.

Tentu saja, ini bukan satu-satunya cadangan Anda. Tapi ini cara yang sangat mudah dan murah untuk memiliki cadangan lokal.

Sekarang, saya tidak akan merekomendasikan ini sebagai metode memperbaiki bug yang normal, tetapi jika semuanya gagal, ini adalah mundur.


3
kontrol versi lebih mudah
thepeer

@thepeer: sangat setuju. Namun, ada hal-hal yang menolak kontrol sumber (terutama pada jadwal micro-commit), seperti file biner besar. Saya senang saya bisa menghindari proyek seperti itu hampir sepanjang waktu
lihat

@thepeer: Saya tidak benar-benar berpikir seseorang akan menganggap ini sebagai alternatif untuk kontrol versi. Itu akan menjadi ide saya tentang kekacauan yang terorganisir :) Dengan cara ini Anda memiliki salinan barang-barang Anda seperti kemarin. Tidak peduli siapa yang melakukan apa dan kapan ke sistem kontrol versi. Komit terakhir Anda mungkin lebih dari 2 hari yang lalu. Beberapa proyek memiliki file tertentu yang diabaikan dari kontrol versi.
olafure

@sehe: dengan git, yang saya gunakan saat ini, Anda memiliki repo pribadi Anda sendiri sehingga tidak ada alasan untuk tidak melakukan di setiap langkah.
teman

@olafure: sistem kontrol versi apa pun yang layak harus memungkinkan Anda untuk checkout / mengkloning kondisi lengkap sistem pada titik tertentu.
teman

2

Bug mungkin sudah ada, tetapi disembunyikan oleh faktor-faktor eksternal, atau masalah sistem yang mendalam.

Ini terjadi pada saya. Bug yang dikembangkan antara 2 build dari proyek kami. Secara harfiah, satu - satunya perubahan yang kami lakukan adalah memperbarui ke versi terbaru dari salah satu perpustakaan yang mendasarinya.

Tentu saja kami menyalahkan mereka. Tetapi satu-satunya perubahan yang telah mereka lakukan adalah refactor beberapa header untuk kompilasi yang lebih cepat. Saya setuju bahwa itu seharusnya tidak merusak sistem.

Setelah banyak debug, ternyata masalahnya adalah bug pointer jahat yang telah laten dalam kode saya selama bertahun - tahun . Entah bagaimana itu tidak pernah dipicu sampai refactoring mereka telah mengubah pengaturan executable.


1

itu berfungsi kemarin karena sedang digunakan dengan benar.

Anda menemukan bahwa orang lain menggunakan barang-barang dengan cara yang tidak disangka merupakan cara yang baik untuk memecahkan barang-barang.

selalu baik untuk memperbarui kode sejak dini karena hal ini membuat Anda memiliki lingkungan pengujian yang baik.

Cadangkan!


-2

Saya menemukan pengaturan breakpoints untuk berhenti dan memeriksa data saya sangat membantu, untuk menentukan dengan tepat di mana dan bagaimana itu menjadi buruk.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.