标签：c++ 问题： 3.1 python 不可 灾难 客户 java 消息
经过这一周的集成，发现以前做的工作的确是远远没有达到预期。
马上这周就要结束了，很明显计划的任务完不成了。
那为什么到了集成的时候手忙脚乱，甚至要改设计，改代码？
为什么之前的工作没有做好？ 为什么甚至之前自己觉得做的挺好的地方，甚至都出了很多问题？
总结起来其实就是细节，但是说要把细节做好，好像总是没有什么实质性的帮助。
好像总是需要自己不断地跳坑，填坑才能长上记性。既然跳坑不可避免，那么尽量少跳几次吧。
这里列举一些个人算是细节的地方。
如何读需求。需求文档不是一般的文档，不能只是当做需求的描述、更不能当做只是一片文章来读。读完需求文档
应该知道用户要什么，什么数据？什么功能？
还要知道用户的要的数据如何展示，百分数？小数？保留几位？需要缺省？
用户要的数据我给的了吗？数据在哪里？我如何拿到？
拿到的数据是否需要再做转换(Y/N变成是/否)？
用户要的数据、或者功能技术可行性？实现方案？带着以上这些问题或许能够帮助自己更有效的读需求。但也绝不是读一次就能完全了解的。为什么？因为一个系统做出来之前所有人都是在想象这个系统应该能做什么！
定义接口。做开发的人对于接口这个词再熟悉不过了。甚至有个词语叫接口程序员，形容不需要知道细节，只需要知道接口满足调用需求，依赖接口存活的程序员。可见接口的重要性。接口也可以说是一种协议，即双方都按照某个标准来，满足系统功能、数据的交互。所以接口可以说是开发人员工作非常重要的一部分。因为做开发，不是在给别人提供接口，就是在调用别人提供的接口。目前我所接触到的接口基本都是数据传输。比如和C++、python的数据使用protobuf转换，和前端交互当然是json。所有这些接口，都需要一个详尽描述，作为提供和使用双方的协议。接口文档，是大家赖以生存的重要资源，如果有人跟你说要改接口，千万别说哦，我知道了。正确的回答是：改接口，没问题，请给我接口文档。
呵呵，又来了。什么又来了？可能看完后觉得有道理，说的不错。但是跳过坑的人可能会提出问题：详尽描述？有多详尽？经过这次的跳坑，我个人的回答是详尽到
每个字段的数据类型是什么？double float int32 int64...
举例说明这个接口返回的某个字段数据到底是什么样子的：保留两位小数，例如 3.14。
需求中说的需要做转换的数据这个接口到底转了没有，返回的到底是Y/N,还是是/否?如果没转换，请告诉我Y到底是是，还是否。
设计和沟通。我也知道这两件事情没有什么太大的关系，但是既然是自己写自己的就随意写吧。参与到本次的项目中，其实我只是一个顶层程序员。不同的系统设计方案，会导致接口传输不同的数据。比如C++和Java的接口。由于对于底层程序员的设计理解一直不到位，导致找C++讨论接口总是处于下风，最终底层程序员给我评价：不怕麻烦，委屈自己成全别人，对C++同事充分友好。所以，可能在开发的时候，我们真的是顶层程序员，但是还是要尽力做好自己的设计、理解别人的设计，真的不理解，就找底层多了解一下呗。只有自己真的了解实现，才会存在有效的沟通。
所有的工作都应该是催着完成的才对，自己要的接口，要催，自己要的文档，要催、自己要的评审、要催。千万别认为他会准时给你。开发一定是与人合作，与人合作往往就存在一些事情，有的事情不知道到底该谁来做、好像这几个人做都说得过去，有的时候开发组群里抛出一个问题，没有具体到人，没人回复，具体到两个人，两个人不回复，具体到一个人，没看见消息。呵呵。。我就想问一句：跑的了吗？
行文至此，算是一边吐槽，一边督促自己如何做好自己的工作，自己工作做不到位，说话都是似是而非、也不硬气。其实大多数坑还是自己挖的。做好自己的工作，坑自然就少了。
标签：c++ 问题： 3.1 python 不可 灾难 客户 java 消息
原文地址：https://www.cnblogs.com/Mr-O-O/p/10388231.html
