“这是个坑” 项目中的人与程序

jinglixixi

“这是个坑” 项目中的人与程序 [复制链接]

说到“这是个坑”的话题，使我想到在一个项目中对人和程序的体验。

当初我们接手一个私企的项目，而且我们绝对不是接收该项目的第一家，因为我们做的时候就已经有一套设备在那工作了，当然性能还没达到老板的目标。这次我们是做下位机的硬件设计，由另一方的一个人做上位机的软件设计。起初还好，大家都一起去厂里来制定方案，并规定接口问题，然后就自己干自己那部分了。

由于硬件设计，不但要涉及相关的程序设计，还牵扯到硬件板卡的制作，自然我们在初期就被编写上位机程序的甩到了后面，在沾沾自喜之余也开始对我们指指点点。

由于该项目是一个材料分析方面的课题，自然就少不了分析报表的生成功能，最初企业是要求生成指定格式的WORD文档，后来他达不到企业的要求就要求改成了PDF格式。慢慢地我们硬件的进度也赶了上来，且逐渐完成了线下的测试。然而，企业要求在上位机实现的是曲线动态缩放以适应显示窗口的尺寸，这个功能他却始终搞不定，于是就把矛头指向了我们，说不明白我们提供的是怎样的数据，要求我们必须向他提供程序源代码。因为当初是有接口协议和格式规范的，我们自然不能把开发的源代码提供给他。于是以此为借口，他就不做了，最终还向企业要了一部分钱就撤了。

企业投了资，哪能就这样收场，让自己的投资打水漂，于是又找到一个毕业没几年的研究生来接着开发上位机。这次开发所用的工具也改了，由原来的c++变成了LABview，自然上次碰到问题也就轻而易举地排除了，因为LABview自身就具有企业所需要的那种功能。

到了联合调试阶段，新的问题又来了。我们设计的硬件在同自己设计的VB测试软件配合时完全正常，然而接到他的LABview软件上，就会时不时地出现数据跌落为零的情况，且很随机。于是扯皮就又开始了，你说你有理，我说我没问题。

但扯皮解决不了问题呀，最终对方只能坐下来从最简单的通讯接收数据及波形绘制来分析。最后得到的分析结论你可能不会想到，原来是LABview在串行通讯过程中只支持字符，而不支持二进制数。一旦遇到二进制的零，它就会破坏通讯过程，自然从图形上看就是不规则的数据跌落，从而完全破坏了数据的连续性。正式在双方都放下偏见的情况下，才最终发现了潜藏在现象背后的实质。当然问题的解决并不复杂，只要在发送前将数据转化为字符型就可可以了，只是发送的字节数会翻上一番。

对于人为的坑，要谨慎不能轻易跳入；对于不经意间的技术坑，往往采用有针对性的测试就能使其原形毕露，只是费些时间罢了。

扫IC网`Allen

shinykongcn

这些情况项目协作中应该比较常见。。

zhaichun136

学习了啊！

zhaichun136

不过感觉现在在企业都这样啊，修改修改再修改，明明说好的，好要改，改好后又要改回去，问题多多，一个项目有可能得弄一年，大多时间是花在修改上

jinglixixi

zhaichun136 发表于 2016-9-27 21:35
不过感觉现在在企业都这样啊，修改修改再修改，明明说好的，好要改，改好后又要改回去，问题多多，一个项目 ...

其实有时企业自己也说不清最终该是什么样，它会不断地修正你，合同也难规范。例如本来说是检测交流电的状态，最终却搞到一个8通道的电压值检测判别系统。

jinglixixi

闁哄被鍎冲﹢鍛村嫉椤掆偓缁楁﹢宕楅妸鈺佸姤閻犱降鍔忛鎴︽晬瀹€鍐惧殲闁谎嗩嚙缂嶏拷闁瑰瓨鐗為埀顒婃嫹婵炲鍔岄崬锟�

weizhongc

闁哄被鍎冲﹢鍛村嫉椤掆偓缁楁﹢宕楅妸鈺佸姤閻犱降鍔忛鎴︽晬瀹€鍐惧殲闁谎嗩嚙缂嶏拷闁瑰瓨鐗為埀顒婃嫹婵炲鍔岄崬锟�