tet*_*eto 7 java version-control build-automation project-management
我是一名初级开发人员,最近开始在一个非常小的办公室工作,他们在那里进行大量的内部开发.我从未参与过涉及多个开发人员的项目,或者与这些开发人员一样大而复杂.
问题是他们没有充分利用所有可用的工具(版本控制,自动构建,持续集成等):主要是项目是eclipse/netbeans中的一个大项目,使用cvs进行版本控制,所有内容都已检入(包括库jar),当我开始为小任务分支并将它们合并回来时,他们第一次开始使用分支.随着项目变得越来越大,越来越复杂,问题开始出现依赖关系,项目结构与IDE相关联,建设有时可能是PITA等等.最好是忙碌.
我想要的是建立一个开发环境,其中大部分问题都将消失,我将节省时间和精力.我想以独立于使用版本控制的IDE的方式设置项目(我现在倾向于SVN),避免依赖混乱并尽可能地自动构建.
我知道有多种方法和工具,并且不希望看到圣战开始,我真的很感激基于经验的实用建议以及在面对类似问题时你发现有用的东西.所有项目都是Java项目,范围从Web应用程序到"通用"项目,我大部分时间都使用Eclipse,但如果需要也可以使用Netbeans.提前致谢.
Esk*_*sko 18
你似乎几乎完全处于我工作的地方,那是我在1.5年前开始工作的地方,唯一不同的是你开始玩弄树枝,这实际上是我在工作中仍然没有做的事情但是在这个答案的后面会有更多的内容.
无论如何,你列出了一套非常好的工具,可以帮助一家小公司和那些非常好的工作作为副主题,所以不用多说,
最常见的小公司目前使用的是CVS或SVN,没有什么不好的,事实上我真的很担心如果没有真正使用版本控制.但是,你必须使用版本控制权,只是有一个不会让你的生活更轻松.我们目前正在使用CVS并正在研究Mercurial,但我们发现以下在使用CVS时可以作为一组很好的约定(我也怀疑SVN):
永远记住,对于软件公司来说,源代码是您的收入来源并包含您的所有业务价值,因此请以此方式对待.此外,如果你有额外的70分钟,我真的建议你通过观看这次谈话莱纳斯Thorvalds了在谷歌大约GIT中一般和(d)VCS,它是真正有见地.
实际上这些差不多.每日构建是一个公关笑话,除了一些非常基本的"它是否编译？"之外几乎与实际软件的状态几乎没有相似之处.的问题.您可以编译许多无法执行任何操作的可怕代码噪声,保持软件质量与编译代码无关.
另一方面,单元测试是保持软件质量的一种很好的方法,我可以用一点个人的自豪感说严格的单元测试可以帮助即使是最糟糕的程序员也能提高很多并且能够捕获愚蠢的错误.实际上到目前为止,我编写的代码到目前为止只有三个错误已达到生产环境,我认为在18个月内这是一个非常好的成就.在我们的新生产代码中,我们的指令代码覆盖率通常为+ 80%,大部分为+ 90%,在一个特殊情况下,一直达到98%.这部分是非常活跃的领域,你最好使用谷歌搜索以下内容:TDD,BDD,单元测试,集成测试,验收测试,xUnit,模拟对象.
我知道,这是一个冗长的序言.以上所有内容的实际内容是:如果您想要自动构建,请在每次有人提交时使用它们,并确保生产代码的单元测试数量不断增加和改进.拥有您选择的持续集成系统(我们使用Hudson CI)运行与项目相关的所有单元测试,并且只有在所有测试通过后才接受构建.不要妥协!如果单元测试显示软件已损坏,请修复软件.
此外,持续集成系统不仅用于编译代码,而且还应用于跟踪软件项目度量的状态.对于Hudson CI,我可以推荐所有这些插件:
这是一个有争议的问题.基本上每个人都同意,拥有一个统一的结构是很好的,但由于有几个营地有不同的要求,习惯和观点,他们往往不同意.例如,Maven人真的相信只有一种方式--Maven方式 - 做事情就是这样,而常春藤支持者认为项目结构不应该受到外部各方的抨击,只有依赖关系需要妥善管理并以统一的方式.只是它不是不清楚,我们公司只是喜欢常春藤.
因此,由于我们不使用外部各方强加的项目结构,我将告诉您一些我们如何进入我们当前项目结构的内容.
最初,我们使用单独的项目进行实际软件和相关测试(通常命名为Product和Product_TEST).这非常接近你所拥有的,一个巨大的目录,用于所有具有依赖关系的JAR直接包含在目录中.我们做的是我们从CVS中检出了两个项目,然后将实际项目链接到Eclipse中的测试软件项目作为运行时依赖项.有点笨重,但它的工作原理.
我们很快意识到这些额外的步骤完全没用,因为通过使用Ant - 顺便说一下,你可以直接在Hudson中调用Ant任务 - 我们可以告诉JAR/WAR构建步骤忽略所有文件名(比如一切)以Test或TestCase结尾)或源文件夹.很快我们将我们的软件项目转换为使用简单结构的两个根文件夹,src并且test.从那以后我们一直没有回头.我们目前唯一的争论是,如果我们应该允许spikes在我们的标准项目结构中存在第三个文件夹,那根本就不是激烈的争论.
这非常有效,并且不需要任何IDE的任何额外支持或插件,这是一个很好的加分 - 我们没有选择Maven的两个原因是看到M2Eclipse如何基本上接管了Eclipse.因为你一定想知道,拒绝Maven的第一个原因是Maven本身的笨拙,无数冗长的XML配置声明和相关的学习曲线被认为是我们从使用它得到的太大的成本.
相当有趣的是,稍后提交给Ivy而不是Maven,这让我们顺利地进行了一些Grails开发,它使用文件夹和类名作为构建Web应用程序时几乎所有内容的约定.
关于Maven的最后一个注释,虽然它宣称推广约定优于配置,如果你不想完全按照Maven的结构说你应该做的事情,你会因为上述原因而陷入痛苦的世界.当然,这是具有约定的预期副作用,但没有约定不应该是最终的,总是必须至少有一些改变的空间,弯曲规则或从某一组中选择适当的.
简而言之,我的观点是,Maven是一个火箭筒,你在一个房子里工作,你的最终目标是让它免受攻击.即使你挑选其中任何两个,这些都是好的,并且工作也很好,但这三个一起不起作用.
只要您的代码中心人数少于10人,您就拥有做出重要决策所需的所有灵活性.当你超越它时,你必须忍受你所做的任何选择,无论它们有多好或多坏.不要只相信你在互联网上听到的东西,坐下来严格测试一切 - 哎呀,我们的高级技术人员甚至写了关于Java Web框架的学士论文,只是想弄清楚我们应该使用哪一个 - 并且真正弄清楚你是什么真的需要.不要因为你可能需要它在遥远的未来提供的某些功能而承诺任何事情,选择对整个公司可能产生最小负面影响的事情.作为我在公司工作的第10个人,我可以用我自己的血液在这一段中指出一切,我们目前有16个以上的人在工作,改变某些惯例在这一点上实际上有点可怕.
我们的开发堆栈(由10多名开发人员组成)
此设置被认为是我们公司的标准,因为许多部门正在使用这些工具,并且有很多经验和社区支持.
你尽可能地尝试自动化是绝对正确的.如果您的同事在开发阶段的各个方面自动化时开始看到好处,那么他们将鼓励他们自己改进.当然,每一项新技术噱头("工具")都是一种新的负担,必须加以管理和维护.这是努力的动向.节省时间,例如当maven自动执行您的发布时,您将浪费时间管理maven本身.我的经验是,每次我介绍一种新工具(上述之一)时,都需要时间来采用和关注,但最终它会在真正的价值经历时为整个团队带来优势 - 尤其是 在工作压力时,工具需要手动完成大部分工作.