posted by wap, platform: iPhone

汽车行业码畜表示楼主说都软件编程相关全都看懂了，但整篇文章仍然没懂
对于一个函数好几千行以及使用了递归等等，笑而不语，不一定是外包干的，日本本土也有渣程序员
现在做德国项目，其实质量真心不如日本的好…

引用:

原帖由 Kuzuryuusen 于 2013-11-2 21:27 发表
posted by wap, platform: Firefox

纯属外行，哪儿写得不对望业内斧正啊

我就是觉得Barr的调查思路很奇葩啊：
1、设计业余。一个函数超过1300行代码怎么了，超过7k行的函数我都见过。这就一定出现Bug么？全局变量多也一定会产生Bug么？当然我也很讨厌这种设计，但不能说明他有Bug，如果想证明的话，需要找出实质证据。
2、代码不符合编码规范。我又惊了，这在业内太正常了吧？估计是使用了PC-LINT或是什么工具检查了一下编码规范就蹦上来，说这会产生Bug。
递归就一定产生Bug么（递归我还真就用过一回，在后续的派生项目里还真就出现内存分配不足死机的bug）
有的程序员会这么写
malloc();
while(1){
//bulabula
break;
}
free();
如果想证明不符合编码规范，请找出证据
3、变量保护其实也是编码规范的一种，同上。

然后Barr为了证明这些代码的确有问题，使用了单元测试的方法
人为地改变了内存中的一个地址的值，于是出Bug了
那么，这个Case在实际情况中真的会发生么？

正常的路子应该是先根据用户提供的现象以及操作步骤去尝试再现这处Bug，（或者还有Log等），再结合代码，逆向分析出这个Bug的原因。
或者我就单纯分析代码，分析出至少一条能够导致出现这个Bug现象的Case，然后去再现它。
还人为地翻转一个特定字节，你怎么不去把用于通信的线缆都剪折了然后再测测？也能出Bug，出不了Bug你再把刹车拆了
难道陪审团里没有懂编程的？

最后照例乱喷一通：MBD现在经常新员工直接上（包括日本人与德国人），各种奇葩代码层出不穷，我艹。
至于前面有人提到的德国人的严谨，我更是懒得喷，能有多严谨，stop的时候不释放内存，原来是架构里根本就不支持（贼tm长见识）
PS：另外DTC模块的代码我也写过一小部分，头回知道DTC全称，寒自己一个

引用:

原帖由 Kuzuryuusen 于 2013-11-2 21:37 发表
posted by wap, platform: Firefox

就是法庭判丰田承担责任（Liable），丰田马上同意给钱息事宁人。
300万不能说多，意义在于开先例。可以想象那些职业状棍们一定觉得捞到金猪了，都摩拳擦掌等着捞一笔呢。预计丰田 ...

的确啊
以后随便找辆车，不停地改写系统里内存的值，直至出错
然后又能拿到300W了