业务、技术和架构
2004-09-30 14:11
561 查看
这两天准备要接手天津商行的项目。但是在接手的过程中,对整个项目的理解却是非常的困难。最大的问题,就是对业务的不理解。
天津商行的这个项目不大,核心的业务就是日结,及其围绕在日结之周围的一些相关业务。其实也并不是特别的复杂,但是转来转去,开账闭账,凭证科目什么的,的确对一个财务的门外汉是异常的头痛。虽然有还算明细的需求文档,但这些需求更多表述的是业务的表现,而对于业务过程和相关的知识却没有什么描述。
业务上的不理解,也就造成了即使看代码也没有多大的帮助,更何况代码的质量也不甚良好。代码大多都是平铺直叙的代码,如果单就一个方法(业务方法)而言,理解起来还算是很容易的。可是问题是,这类里足足有七十多个这样的业务方法,没有分类,注释也只有简单的描述,如果你不理解业务,那这就是噩梦,根本不知道从何下手。这样的类大概有二十多个,纯粹的描述业务的类,极度郁闷。
对于技术、业务还有架构,常常会有各种各样的疑惑,但更多的就是究竟要更侧重那一个方面,也就是所谓的鲁棒性了。
目前,社区内对于技术还有架构讨论的是有模有样的,但是真正能符合这些复杂业务的开发吗?或者说用这些热门的东西,来实现我的这些业务,真的能达到易于扩展易于维护吗?
有没有讨论这些业务的社区呢?大家都在更关心架构等纯技术的东西,可实际应用中,难道不是业务才是公司的利润之本么?
也许,就没有真正正确的答案。
天津商行的这个项目不大,核心的业务就是日结,及其围绕在日结之周围的一些相关业务。其实也并不是特别的复杂,但是转来转去,开账闭账,凭证科目什么的,的确对一个财务的门外汉是异常的头痛。虽然有还算明细的需求文档,但这些需求更多表述的是业务的表现,而对于业务过程和相关的知识却没有什么描述。
业务上的不理解,也就造成了即使看代码也没有多大的帮助,更何况代码的质量也不甚良好。代码大多都是平铺直叙的代码,如果单就一个方法(业务方法)而言,理解起来还算是很容易的。可是问题是,这类里足足有七十多个这样的业务方法,没有分类,注释也只有简单的描述,如果你不理解业务,那这就是噩梦,根本不知道从何下手。这样的类大概有二十多个,纯粹的描述业务的类,极度郁闷。
对于技术、业务还有架构,常常会有各种各样的疑惑,但更多的就是究竟要更侧重那一个方面,也就是所谓的鲁棒性了。
目前,社区内对于技术还有架构讨论的是有模有样的,但是真正能符合这些复杂业务的开发吗?或者说用这些热门的东西,来实现我的这些业务,真的能达到易于扩展易于维护吗?
有没有讨论这些业务的社区呢?大家都在更关心架构等纯技术的东西,可实际应用中,难道不是业务才是公司的利润之本么?
也许,就没有真正正确的答案。
相关文章推荐
- 第五章 业务架构,5.3 千亿访问量下的开放平台技术揭秘(作者:风胜)
- 关于业务高速发展的互联网公司技术架构演化的一些看法
- 构建一个较为通用的业务技术架构
- 如何构建一个较为通用的业务技术架构
- 001_谈阿里核心业务监控平台SunFire的技术架构
- 业务架构平台的技术实现环境
- 业务架构平台的技术实现环境
- 业务、架构、技术,我们应该关注什么
- 架构如何为业务和技术“服务”(1)
- 业务架构、信息架构、技术架构三位一体
- 业务架构平台的技术实现环境
- 业务架构平台的技术实现环境
- 创业之初的技术题:如何构建一个较为通用的业务技术架构
- 一起谈.NET技术,走向ASP.NET架构设计——第五章:业务层模式,原则,实践(后篇)
- 系统架构、软件架构、物理架构、总体架构、业务架构、应用架构、数据架构、技术架构
- 架构如何为业务和技术“服务”(2)
- 业务架构平台的技术实现环境
- 【大型网站技术实践】初级篇:搭建MySQL主从复制经典架构 一、业务发展驱动数据发展
- 架构漫谈(九):理清技术、业务和架构的关系
- 业务架构平台的技术实现环境