Walleve | 理想就像内裤,要有,但不能逢人就去证明你有

1、项目团队的核心约定就像一个部队固有的暗号和约束一样，平时可能往往会影响大家的工作效率，但是一旦“战事”袭来，这种核心约定往往就成了团队取胜的法宝。这也是“无规矩不成方圆”的最直观的体现。 不论项目团队的成员有几个，我们的眼光都必须放的久远一些，今天可能是A参与项目，明天就可能是B，那么B如何能够快速参与进来呢？A当初工作的一些规律和约束就必须告诉B，如果A自己都不知道，B不疯掉，起码也要犯晕。不论我们在协作开发(svn等)又或者是单枪匹马的开发，都应该有一个很明确，而且是每个人都必须遵守的约定，例如svn，每个人的代码上传时都必须有明确的说明，以及代码每天更新的次数和频率，代码的锁定与清理，都应该有定期可执行的约束，不然A一天上传svn100次，而且从来不写注释，那么一旦出现问题的时候，A不在场的时候，参与解决问题的其他人心里一定在痛骂A。 2、成员的效率控制。这个往往是考研团队leader的时候，他必须清楚的知道团队成员的能力，做事风格甚至是他们工作时候的情绪，以及哪一天情绪如何等，都应该细致入微，因为一个小小的差错，就可能影响到整体项目的进度。并且我们应该养成一个坏习惯，就是不见兔子不撒鹰，尽可能的量化每个人的工作，这并不是说要去强制要求每天的工作，而是要每个成员都养成良好的工作评估，前期不一定有效，但是一旦进入开发白热化状态，每个人如果对工作都有很好的把握，那么leader就可以每天睡到中午了。 另外就是尽量在效率控制上避免重复工作和错误工作的出现，当然需求更改是每个项目都会遇到的问题，但是如果由于leader或者成员误解造成错误的结果，后果也是比较危险的。 3、大局观。这个话题说起来比较大，但是做起来却需要相当的细致，参与开发的每个人必须了解各自负责部分的详细需求和开发细节，同时也必须了解自己的工作如何和partner配合/整合，同时也要知道自己的或者partner的工作是否会影响到彼此，尽量将冲突解决在整合之前。在工作中，时常会发现有一些工作完成的很顺利，但是往往一旦进入测试或者即将整合的时候，我们发现这一部分是如此的糟糕，最坏的结果就是这一部分需要重新开发，成本控制就成笑谈了。 这也要求每个开发成员要想成为优秀的开发者，必须具备这样的大局观，你完成的不仅仅是工作，而是项目。工作和项目是两个完全不同的概念。 4、测试人员是负责保驾护航的副手。测试人员的介入从开发的哪一个阶段介入？或许在很多小公司甚至没有测试人员的介入，往往是开发人员同时兼任测试，但是我的建议是最坏的结果也必须有一个业余的测试员，并且他不应该是这个项目的直接开发人员，因为对测试人员的要求不仅仅是发现代码bug或者流程bug，更多的他们应该尽量保证开发结果和需求的一致性，甚至是对开发产品的质量把关。他们往往是质量的最终守护者，一个程序员可能写出了上千行漂亮的代码，但是如果这些代码运行的结果与实际需求大相径庭，那么这也是一堆垃圾。 5、项目团队的激励机制。团队内部应该是激励机制，而不应该是惩罚机制；程序员的情绪会直接影响开发的效率和开发结果的好坏，如果他们因为一些小小的错误并且被惩罚的话，他们的情绪往往会很低落，再继续开发，我相信结果也不会太好，起码不是最好的结果。并且团队内部成员之间应该勇于承担责任和将自己的问题解决在自己的手中，要相信队友，但是不应该将自己的问题留给队友，虽然我们往往需要协作解决问题，但是这是一个原则，每个人都应该为自己的工作负责。同时这也是激励队友不断进步，并肩前进的好做法。 6、常规问题：注释自己的代码，换行的必要性，变量函数定义的白痴化，解决问题的抽象思维，尽量不要修改别人的代码，尽量避免开发过程中不必要的增量开发，尽量避免重复的函数和变量等，避免重复的判断…. 自己在参与项目中遇到的一些问题整理一下，有一些可能已经是一些在别人看起来很幼稚的问题，但是往往这些幼稚充斥在我们的工作中。 仍需要不断的学习，理论往往能够给我们一个很好的理由，但是实践往往告诉我们可行的方法。

Google和众多开源社区的开发者都使用Eclipse IDE，Google开发者用Eclipse开发了Android、App Engine、Google Chrome，以及大量Web应用程序。现在Google宣布与Eclipse基金会合作，促进Eclipse生态系统，他们的合作结晶是Eclipse Labs。 Eclipse Labs的目的是让更多人知道Eclipse平台上的开源和商业插件项目，目前还是beta版本。Eclipse开发者可以创建，或将自己的项目迁移到Eclipse Labs。 在去年9月份，Eclipse基金会讨论并确定了很多2010年要投入的项目和工作，这些项目中，最吸引人的，也是反响最大的就是Eclipse Labs。上周，Eclipse Foundation非常激动的宣布了该项目已经进入实质阶段，这应该非常感谢Google的支持和投入，并且Google已经推出一个基于Eclipse的Workspace Mechanic项目。 　　Eclipse是一个非常庞大并且充满活力的商业和开源社区，并且经过了多年的积累和时间考验。对于Google Code、SourceForge、Codehaus等机构来说，无论是从产权角度来说，还是从投入成本来说，重新开发一个Eclipse都是不值得，也是不划算的，并且也很难达到Eclipse的影响力。因此完全可以寻找一个更适合的途径，来解决这些机构之间的资源协调问题。 　　去年，Eclipse开始与那些在Google Code上托管项目服务的机构进行了合作领域的讨论，寻找适合的Google Code与Eclipse合作途径。非常高兴的是，很快大家就达成了一致，决定成立一个Eclipse Labs，一个全新的，结合Eclipse与开源项目之间的桥梁。 　　什么是Eclipse Labs? 　　如果你参与过Google Code项目，那么你可以很快了解什么是Eclipse Labs。通过Eclipse Labs 可以快速访问问题跟踪系统以及源代码库，达到快速创建开源项目的目的。缺省情况下，通过Eclipse Labs创建的项目，采用的是EPL协议，但是也可以采用其他Google Code所允许的协议。任何人，在任何时候，都可以通过Eclipse Labs来创建项目(前提是要接受Google Code和Eclipse Labs使用条件)。另外Eclipse Labs推荐的命名空间是org.eclipselabs，但是这不是强制要求。 　　Eclipse Labs 也推荐在项目的描述信息中使用或创建特定的标记或标签。Eclipse已经在Eclipse Labs的搜索页中提供了一系列这样的标签，同时也将在未来的几个星期内提供一套与搜索这些标签相关的API。为了更好的合作和推广Eclipse Labs，Eclipse希望在采用Eclipse Labs的项目主页上带有明显的Eclipse Labs标识。例如在Eclipse BIRT项目中，会列出所有采用Eclipse Labs开发的插件，并且给出相应标记。同时Eclipse也希望能够将与Eclipse Labs相关市场结合起来，相信，通过Eclipse Labs平台，将为开源项目创造更多合作与发展的机会。 　　Eclipse Labs不能做什么? 　　Eclipse Labs与Eclipse之间是存在区别的，是开源社区与Eclipse之外的第三个选择，因此不能称其为Eclipse项目。因此如果希望在Eclipse中使用Eclipse Labs项目，需要经过合理的授权过程。如果某个项目希望通过这个过程受益，必须首先成为Eclipse成员之一。 　　前景 　　现在Eclipse Labs已经对商业开放，不过还处于beta阶段，所以希望大家能给更多的反馈。我们希望在Eclipse基金会的众多项目中，Eclipse Labs能够快速成为一个突出的项目。我们也希望这一过程更为简单，让大家体会到基于Eclipse Labs开发开源项目一个非常激动的事情。并不是所有的项目都必须直接进入Eclipse基金会，我们希望途径是项目从Eclipse Labs，到一定阶段之后，可以选择进入Eclipse基金会。 　　非常感谢Google 　　整个过程，Google员工一直参与其中，再次显示了Google对开源社区的承诺和支持。现在，没有Google的自持，Eclipse [...]

Ubuntu 是一个基于 Linux 的开源操作系统。开源可以促进知识被充分利用，推动产品设计和生产技术发展。它既是理论，也是具体的实践。开源的广泛实践使得软件用户可以获得他们所使用软件的源代码，并且知识产权限制很少甚至没有，这允许用户对软件进行修改，或者利用获得的代码编写并发布新的软件，使其满足自身需要，或者进行互相协作以改进开源软件。开源和 Linux 都是在逐步变化的过程中，形成今天的样子的。 自由分发的源代码的想法是为了鼓励人们自愿地、相互协同地开发软件。用户不断参与增强软件、修复缺陷、开发新功能并且和其他人分享。 大量的程序员参与到软件协作开发之中，用户可以获得质量和性能比专有软件更好的开源软件。开源软件鼓励用户对软件进行自定义，使其满足自身需要。这是一个巨大的进步，软件不再是一成不变的。 开源项目不只需要程序员，还需要其他各个领域的人才。许多项目还需要艺术家、音乐家、用户界面设计人员和文档撰写者来一起做出完整的产品。

现在，越来越多的人意识到在解决方案中引入工作流的重要性。然而，在面临如何具体实现的时，自建亦或是使用（现有工作流）？争论仍在继续。在Bernd Rücker的新博文“工作流引擎？动手整一个……”中，他重拳出击，讨论了围绕在这个问题周围的一些常见误解。

人们一般都认为：如果团队中每个人都能发挥最大能力，那么这个团队一定是最有产出的团队。与之相反，Steve Bockman认为这个假定不一定永远成立。在有些情况下，可能有必要 放慢团队速度，少干点儿活，而不是全速前进，最终目的是为了迅速提高产出和利润。