InfoQ|反 996 有理：催程序员交代码，写不出好软件( 三 )

synchronised to avoid corrupting max bid*/ synchronizedvoidsetHighestBid( longbidCents){ if(bidCents > highestBid) { 评点：你是否有过这样的经历：你的软件快速通过了 QA 测试，但在进入生产环境时就崩溃了？捕获竞争危害的一个好方法是在典型负载下运行软件，同时构建并分析指示软件健康状况的指标。但这听起来像是一个以时间压力为导向的组织想要的东西吗？以我的经验来看，不是这样的！
性能不佳一个工作流程本需要几个小时才能完成，而实际上只花费了几分钟。
迫于时间压力下完成的代码
背景：在整个后端代码中，应用了一种重复的架构模式，在该模式中，对象将持久化，并每次从数据库中获取一个子对象。这将会导致响应时间非常慢，但如果负载很轻的话，效果尚可。
/*Person object has several dirty one-by-one*/ person.persist;精心编写的代码
/*Note: Persist framework function refactored to batch SQL updates*/ person.persist; 评点：当你对项目的架构提出质疑时，有没有被人“嘘”过？如果你推送复杂测试呢？负载测试是众所周知的软件项目按时交付的祸根，因为它往往会使像上面例子一样的架构问题暴露出来。如果团队有足够的压力来满足这个截止日期，他们就会很高兴地进行负载测试，并将其交付，而客户将会发现软件的性能问题。然而，许多组织在进行负载测试时，并没有健康度量的指标，以使客户满意负载测试的执行情况。而如果没有度量指标显示一定负载下暴露出的不良行为，那么软件通常会顺利地通过，即使软件在经常被忽略的诊断日志中出现了大量有关问题的信息。
支付处理逻辑人们有时不付款就把产品买到手里，这简直是客服的噩梦！
迫于时间压力下完成的代码
//todocheckforerrors database.recordPurchase paymentGateway.startPayment paymentGateway.completePayment精心编写的代码
database.startPurchase try{ paymentGateway.startPayment }catch(Exception e) { log.error(e) database.recordError returnFailedStartPayment(e) } try{ paymentGateway.completePayment altPayLog.recordError log.error(e) database.recordPError returnFailedCompletePayment(e) 评点：你是否曾经在处理复杂的错误情况时被经理打断，问你能否按时交付？这种时间压力是否激励你进行一些出色的错误处理？时间压力往往会让人们不再考虑软件失败时会发生什么情况；只愿意在快乐路径上进行编码。换句话说，错误处理被抛在一边，只顾满足周五的检查截止日期。
哪些会被修复？当然，时间压力并不会导致所有的混乱被忽视。下面我列出的内容，是往往会被修复的。但是，这些被修复的内容给了组织一种虚假的安全感。