关于命名约定:软件项目的基础结构

关于命名约定:软件项目的基础结构

Infrastructure for a software project

我很快会领导一个新项目。 我一直在思考软件项目的基本基础架构是什么。 这些是我认为每个项目都应该具备的内容:

-编码样式约定

-命名约定

-标准项目目录结构(例如,Maven标准目录布局等)

-项目管理和问题跟踪(例如,trac,redmine等)

-连续集成服务器(例如,哈德逊,巡航控制等)

我不确定是否错过了什么。 有人要添加吗?


作为初步答案,请检查Joel测试:
http://www.joelonsoftware.com/articles/fog0000000043.html

只是一个开胃菜:

  • Do you use source control?
  • Can you make a build in one step?
  • Do you make daily builds?
  • Do you have a bug database?
  • Do you fix bugs before writing new code?
  • Do you have an up-to-date schedule?
  • Do you have a spec?
  • Do programmers have quiet working conditions?
  • Do you use the best tools money can buy?
  • Do you have testers?
  • Do new candidates write code during their interview?
  • Do you do hallway usability testing?

    • 版本控制系统(例如subversion,cvs,git)


    除您之外,我将:

    • 单元测试策略
    • 整合测试策略
    • 定义过程
    • 发布(交付)策略(如里程碑,工作包等)
    • 源代码控制分支策略

    • 那文档呢?如何(代码中的注释,高级规范),时间,数量,人员
    • 测试方式-单元/验收/用户测试
    • 代码版本控制,一些SVN / Git(或者它包含在跟踪中?)
    • 团队角色和职责-需要在您的项目中完成

    配置管理计划。您需要对开发工作流有一个成文的方法,在之后的工作中如何合并,等等。


    我也会把文件共享服务器也混在一起。我以为版本控制是如此基础,以至于我都不想把它放在列表中。但是它是一个不错的版本控制。


    功能测试是任何项目的必需部分。单元测试很棒,并且对于敏捷项目非常有效,但是功能测试仍然是必需的。您至少需要一个基本的测试计划。如果您打算有多个项目或子项目,则可以使用"测试策略"文档或Wiki页面。
    测试用例,验收测试用例等可以由您的用户故事或它们的等效项来驱动,但它们仍必须以某种形式存在。


    知识管理至关重要。由于您已经计划使用Wiki(例如Trac或Redmine),因此也可以将其用于KM。


    推荐阅读