12月25, 2011

项目开发过程中的四种语言工具

总结一下项目开发中所使用的语言工具吧,,虽然大家限于紧张的人力或排期,无法实现理想的开发模式,,但必须朝着理想的方向去努力,否则项目会因复杂度(业务复杂度及技术复杂度必须得到分解),最终导致混乱。 1 代码: 代码是对程序流程最翔实,也是最即时的描述,但代码的问题在于,,代码中太多和程序流程无关的技术细节,比如: 对系统api的封装, 对debugger的辅助, 对运行环境的探测及兼容, 对第三方系统接入的适配等等。 所以,代码是每个模块的实现细节的描述,,但代码缺乏直观性,概括性。

2 即时口头交流: 即时口头交流,,大家围绕当前的程序中的某模块,创建一个探讨的上下文,,多人随之展开口头交流,其实时性较强,,但限于地域,,其持久化保存和共享性不强。

3 图: 图是最直观的工具,如UML图,直接表现了对象的分解方式与关联方式,但对象的哲学概念,对象行为细则,则必须以文字注释的方式添加到图上,,但是这种细节太多,,又会让图本身的直观性淹没在细节中。。所以图要简洁直观,描述项目的整体架构。

4 文档: 文档和图都有一个问题,,其即时性不强,,在项目进行的过程中,,代码在快速迭代,,但文档和图却不具备即时性,,也就是 图和文档 会因为得不到更新,,而不具备即时性。(所以文档必须是针对大版本的,当一个大版本成为历史时,该文档必须归档为历史文档,否则会对最新的开发环境造成困扰) 项目文档的编写,要注意的是,代码自我解释了实现的细节,,所以文档不应该再记录实现过程的细则(细则会淹没大比例结构),,而应记录实现目的和方式。 另外,代码不一定具备解释性,,当代码的自我解释性不足的时候,,文档必须来补充。

总结:
文档和图,其分工是不同的,图是概括整个项目的架构,及模块间的分解方式和关联方式,,但图并不解释模块的概念与模块的行为,,而文档则是在总结概念与行为,但文档也不解释实现细则,,实现细则由代码自身来说明自己。

过时的文档如果不与版本关联起来,归档为历史文档,就会对项目的开发产生混淆并伤害项目的开发,所以,文档不可以去描述实现细节,而应该去描述模块的概念,行为,以及作用。

提到用代码自身来说明自己,,就想到了敏捷开发:
XP的本质是依靠代码的自我说明,来形成良好的代码结构,,XP适合功能架构已然明确的项目进行小版本迭代,,但XP并不适合复杂系统的设计, 以及僵化的遗留系统的重构,,外部系统的接入整合等等场景。

本文链接:https://75team.com/post/项目开发过程中的四种语言工具.html

-- EOF --

Comments

评论加载中...

注:如果长时间无法加载,请针对 disq.us | disquscdn.com | disqus.com 启用代理。