我寫了一些多線程批處理來處理數據。當我完成實施并再次測試不同的數據集時，每個數據集大約有 100 行，一切都按預期工作。但是當它真正移動到 prd 時，有些事情會失敗。死鎖、空指針異常、數據沖突和錯誤輸出等。我的問題是如何確保您的代碼有效？我用樣本數據做了測試，但我真的不能對數百萬個數據做測試，對嗎，太耗時了？但是如果我不這樣做，我的測試代碼將由于測試期間沒有發生的一些錯誤而失敗。有沒有人們用來驗證的某種做法，還是很常見？在這方面需要一些指導。
1 回答
楊魅力
TA貢獻1811條經驗 獲得超6個贊
根據我與包括硅谷在內的世界各地的大公司和小公司合作的經驗，我想說從一開始就使用最佳實踐并堅持下去，例如：
了解并為工作選擇正確的技術/語言 - 您可以使用 C++03 或使用 Java、GO 或 Rust，您將獲得截然不同的體驗
在該領域擁有昂貴的、技術嫻熟的程序員，并選擇了足夠的語言或足夠熟練以在一定的正常運行時間后處理每項技術
不要強迫他們，否則他們會做出妥協（記住質量 - 速度 - 價格三角形）
在團隊中有認真的同行代碼審查文化
如果可用，運行靜態代碼分析并修復警告
編寫所有有意義的單元測試（在類/模塊級別，此級別沒有多線程，理想情況下基于 SOLID 的軟件，使用模擬測試）
創建集成測試（多線程、真實文件、真實數據庫、真實云、真實可擴展性）
讓一個 QA 部門在現實生活條件下一遍又一遍地使用實際硬件設置進行回歸測試......
如果可能，還讓 QA 和開發人員使用內存檢查器（例如 valgrind）和/或分析（取決于語言和技術）進行測試
讓它在真實條件下運行也很重要（也就是生產中的測試......好吧，我們稱之為公開測試版）。用你所擁有的一切攻擊它。這包括你所有的黑客工具和一群野猴。
即使對于在他們的軟件上投入大量資金的最大公司來說，也總會有一些隱藏的錯誤或安全問題（以及可能在以后修復的已知問題）。因此，請確保您有一些事后處理程序，例如堆棧跟蹤、應用程序日志、系統日志、屏幕截圖等。
在當今的軟件復雜性中，正確性和穩定性非常昂貴。不過，對于小型項目，稍微少一點努力可能是可以的（取決于傷亡人數，或者今天更重要的金錢損失，如果我會說空指針）
添加回答
舉報
0/150
提交
取消