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