工作中关于合作一些的思考

关于在完成项目的过程中，很多时候需要团队内部或者团队间的合作。

合作分三类，代码级合作，设计级合作，项目级合作。

首先关于代码级合作，

其次关于设计级合作，

最后关于项目级合作。

 

代码级合作：

根据《人月神话》的推论，当一个项目进行到后期，如果加入新人不仅可能无法缩减开发时间，还有可能增加开发时间。后来网上根据这个也有很多讨论，说这个推论有适用的前提。当一个项目的复杂性很高，模块间耦合性极强，对于一个新人来说，首先就要花费很多时间来理解代码间的关系。可能这个时间，就需要很长。《人月神话》所提出的应该是针对于这种情况的。所以为了避免出现《人月神话》讨论的情况，我们需要采取措施，尽量避免那种情况。随着，软件工程的发展，这些也越来越多受到关注。

功能模块化，模块化编程，高内聚，低耦合。这些都是有利于避免后期加入新人，缩减开发时间的情况。当然，代码的规范性，可读性，影响到新人理解代码的时间。

综上，首先为了避免中途加人造成的时间开销，需要在开发代码的时候，注意：

功能模块化：将功能分解为一个一个最小单元。对于每一个最小单元，能够最快的理解。

模块化编程：在设计程序结构的时候，将各个功能分模块化实现，或者分层实现。避免不同模块间的代码耦合，这样只需要专注于一个模块就可能理解当前所做的事情。减少了需要关注的量，就相应提高了理解代码的时间。

高内聚，低耦合：对于模块化编程，需要注意高内聚，低耦合。否则，只是有模块化编程之名，而无模块化编程之实。各个模块间的交叉调用，增加了理解一段代码需要关注的代码量，也就增加了理解的复杂度。

变量，函数命名规则统一：对于代码中，用统一的方式命名变量和函数，能够便于其他人阅读时更快的理解代码，也有利于自己很长一段时间后，回头修改程序时，更快的理解程序。对于风格熟悉的代码，能够提高理解代码的速度。

使用具名常量：避免程序中出现数字，使用有意义的名字代替这些数字。这样对于阅读代码时，能够一眼看出代码的含义，也便于以后修改代码，只修改具名常量定义的地方，关于这个常量所以使用的地方都会做了修改。避免有遗漏的地方。

一定的代码缩进方式：代码缩进统一，对于书写者是一种好的习惯。对于阅读者，是一种熟悉的阅读环境，便于他们更快的进入代码逻辑的分析，而不是停留在找寻相关代码。

一定的规范，是人与人之间的协议，这样便于人与人之间的交流（通信）。这样，即使加入新人，功能模块化，模块化编程，高内聚低耦合，可以尽可能减少新人要做的工作量；代码的规范性与可读性，减少了新人熟悉工作内容的时间。这样，尽可能会做到：增加新人，减少时间。

设计级合作：

一个嵌入式产品的设计涉及到硬件与软件的双重设计，以及不同独立模块间的设计，而他们之间的协同工作，能够直接影响最终产品完成的时间。这就是系统设计的重要性所在。从一个整体上考虑他们之间的关系，合理选择任务分配：由硬件实现OR由软件实现；由A模块实现OR由B模块实现。当多个部分同时进行开发的时候，如何提高并行开发的个数，尽量减少最长时间链。 这些需要由系统设计来统筹。

在硬件设计的时候，硬件与软件之间的交互要和软件设计协同进行；软件上对于脱离硬件的部分软件可以独立设计。有联系独立模块之间，通信协议的约定需要协同完成。多个功能可以在不同独立模块上实现，需要协同设计，实现每个模块上均等的开发任务。

上述，各种协同工作的最终目的是，尽可能减少产品开发需要的时间。

硬件与硬件协同：分配好每一个独立模块需要完成的功能，在保证符合相应规格要求（标准）的前提下，保证每一块都有最短的完成时间，以及每块之间可以独立工作，这样便于每个模块的独立测试。同时每个模块间的接口要在开始实现前，在设计的时候定义好，并且在以后的过程中不轻易改动，目的在于：1、实现前后版本的兼容，2、减少在最后时刻，因为接口问题导致的延期；

硬件与软件协同：在确定好需求，开始设计时，首先要分清楚，哪些工作软件实现，哪些工作硬件实现；之后，根据要实现的功能，硬件给出设计接口，并在以后的设计过程中不轻易改动。软件根据硬件提供的接口，设计底层驱动程序，再设计的过程中，不直接使用特定端口，而是使用宏定义调用这些端口，目的在于如果硬件发生改动，软件上做到最小改动，规避因硬件改动带来的程序修改。同时，将硬件相关程序与硬件无关程序独立开来，最小化硬件相关代码，方便以后的不同硬件平台的移植。

软件与软件协同：软件与软件协同开发时，一部分参见“代码级合作”。还要注意的是，保持函数接口的稳定不变性，使用面向对象的思想来编程。

接口的设计（硬件与硬件之间的接口，硬件与软件之间的接口，软件与软件之间的接口，函数接口，通信协议），是模块与模块之间协议。在确定宏观功能的前提下，将项目分为各个部分，分而治之，多个部分同时协同进行，且做到最大能的并行开发，尽可能的缩短开发时间。

项目级合作：

每一个大项目都可以分为许多个小项目，适当的若干个个小项目组合起来可以构成一个大项目。项目的无所谓大小，小可大，大可小。只有沟通上的难易。一个项目牵扯的人越多，在沟通上需要的时间就越多。而且随着人员的增加，沟通的难度度会越来越大。以一个大项目中分隔开的若干个小项目而言，如果，要进行设计工作，必须理解各自要承担的部分，以及评估自身成员的能力，能否及时、按质完成项目；如果中间有难度，需要项目间的相互配合，尽可能做到每一个项目需要时间最短。从而做到，整个大项目的时间最短。

1、根据需求，进行项目间初级任务分配与预估；

2、根据各自项目的预估结果，决定是否接手项目，或者进行项目任务的重新分配，做到每个项目组适其才，尽其用；

3、根据任务分配，做好需要做的事情，保证进度与质量；

结束：

总体而言，现在理解到的是这些。不论是代码级，设计级，还是项目级，有两个共性：高效沟通，忽视细节（面向对象）。

代码级：功能模块化，模块化编程，是为了让别人忽视实现细节；其他的编码规范，是为了做到高效沟通；

设计级：面向接口设计，是为了做到忽视细节，同时也是沟通的结果。

项目级：任务的分配与评估，是沟通的结果；之间的合作，是为了让项目组之间，忽视其他的细节；
 

注：由于存在对象 渗漏 法则，虽然尽可能做到忽视细节，但是永远不可能不关注细节。