gdpglc
- 浏览: 84749 次
- 性别:
- 来自: 长春
-
社区版块
- ( 0)
- ( 413)
- ( 9)
最新评论
-
masuweng：
:i总结的很好dea:
客户需求及骨头与肉的分工方法 -
夜神月：
dao这个东西想象很美丽
dao的作用 -
eyesmore：
"比如某连接池中有2个连接对象。有两个线程分别占用了 ...
数据库连接池死锁的原因和处理方法 -
gdpglc：
呵呵... 这例子很有启发。我说的情况是对已有对象加入新功能时 ...
oo的环境下，需要控制对象 -
悲剧了：
比如在web开发里，登录用户信息存放到session里面，需要 ...
oo的环境下，需要控制对象
文章列表
- 博客分类：
- 而立
1.文档编号
软件开发离不开设计文件的编写与审核。开发的每一个阶段都会产生很多文档。通常文档是通过svn在团队内共享的。当一个阶段下的文档数目超过50个的时候，在一个目录里查找某个文档是个痛苦的事。常常有文档的名称很长且类似的情况，这导致找到需要的文档很费时。
这里有一个简单的解决办法。为每一个文档分配一个两位的编号，每一个文档必须以文档编号开头。比如：
00.xxx功能需求分析与设计.doc
如果想看某人提交的文档，只要知道他提交文档的编号就行了。
个人认为文档编号两位就好，冗长含义众多的文档编号是无用的。
2.文档版本号
写 ...
- 2017-03-29 15:51
- 浏览 5213
- 分类:研发管理
- 博客分类：
- 而立
迭代开发是开发未知领域新产品的必然选择。但没有经历真正的迭代开发时，常常只能通过书籍雾里看花。
书籍里描写的经典场景是：一个迭代收尾，然后发布半成品给用户使用获取反馈，用户会说：“喔这里看上去不错，但是实际使用时我需要在这里看到...”，当迭代开发中发生这样的场景，说明迭代开发过程是有效的，产品在不断迭代和改良。
之前经历了一些号称是迭代开发的项目，很少发生这种情况。常常是内部一个迭代完成，测试，然后下一个迭代接着做。现在看，这样的迭代过程，不是真正的迭代开发，因为没有用户反馈。
最近的项目历时两年，前期也是处在类似的过程里。做完了拿给用户看。用户看看，也在尽量 ...
- 2017-03-27 15:09
- 浏览 852
- 分类:研发管理
- 博客分类：
- 而立
1.客户需求
对客户需求分析后可以进行产品功能设计。而产品功能设计又会衍生出新的功能性需求。
2.骨头与肉的分工方法
1.team leader 负责客户需求分析和功能的概要设计，概要设计给出的是功能的骨架和应用的核心技术。
2.team member 负责详细的功能设计、程序设计和开发。即在骨头的基础上丰富出软件的肉。
3.开发团队规模5人最佳。1名高级，2名中级，1名初级人员，1名需求与架构人员。
4.美工与测试人员，需要时聘请。
5.领域专家，需要时聘请。
6.实施人员1名。
一个感悟：
团队规模取决于team leader 能掌控的需求和概要设计的效率，当团队开发效率大 ...
- 博客分类：
- 而立
1.好的代码是团队的要求。因为好代码，功能正确、bug少、通常更好编写、可读性强、可扩展性强。
2.不可能按每块代码是否因为代码质量更好受益来要求是否需要编写良好的代码。没法制定这样的标准。且也不需要这样，最好的办法就是统一要求代码质量良好。这就像类的getter 和 setter方法，又像是战争中的覆盖式打击。
如果在写代码时还需要挖空心思的思考差的代码是否能用，那就是再给写代码增加负担。何不直接去写良好的代码。
3.团队养成了编写良好代码的习惯，自然就会解决许多在代码层面可以解决的问题。
.
- 2016-09-18 11:57
- 浏览 355
- 分类:研发管理
- 博客分类：
- 而立
1.结构不会消失
型也不会消失，要么是显示的，要么是硬编码的在代码里的。
2.代码质量标准
基本：可以清楚完备的考虑。
容易修改。需要遵守针对接口编程的基本思想，规避内容耦合。
举例：
� ...
- 2016-03-24 10:37
- 浏览 554
- 分类:企业架构
dao在实践上常常被用到，但能用好dao却需要明确dao的作用。
dao 即 data access object 数据访问对象。
dao 的作用是为了简化业务逻辑的编写。将业务逻辑中用于处理特定技术的代码，单独写入到dao中进行封装，从而尽量将业务逻辑的主要过程独立的进行表达。
这就是dao的作用。
service逻辑的编写，可不可以没有dao？
当然可以，不过有了dao显然更好。
dao里的逻辑是不是业务逻辑？
当然是，只是dao里的业务逻辑不得不和数据访问技术紧耦合。比如利用hql进行的组合查询。
- 博客分类：
- 而立
两周的工作量。
管理性需求，涉及及的方方面面都不了解的情况下，所做的功能设计，能完全正确的可能性小。
1.领导很重视的功能，为什么不拉着领导催下属确认一下界面设计。
2.已经实现的功能，领导很重视。为什么不催促确认一下是否正确。
发现问题后，两个解决思路：
1.小修小改先对付用。
2.大改，有2/3的设计要推翻。
如果需求仍不能确定准确，应该采用小修小改方式，尽量投入使用。这样可以避免再次的拍脑门。最终获得准确的需求。
注意：迭代式开发，不是拍脑门定需求的借口。2人周的代价比较大，再加上之前按单用户进行的配置的一版开发投入（需求确定的太轻率），应该也有1周。
3周的时间太浪费了。
...
- 2016-03-03 20:08
- 浏览 533
- 分类:研发管理
最近有时间看看书补补理论。
看了一些软件体系结构(software architecture)的资料。终于理解了spring的基本思想。
spring是在cbd思想指导下开发的轻量级构件模型。
为什么会把spring和ejb进行比较呢？原因很简单，因为spring和ejb都是java的构件标准。都适用于cbd开发方法。
还有一些其他的构件标准：com/dcom/com 、corba
我们平常采用的web程序结构：action->service->dao 其实背后的原理是cbd。
在实际的开发中cbd只是提供了开发思想，落地时会有很多的具体问题。比如，cbd并不会规定，web ...
- 2016-02-24 09:33
- 浏览 1057
- 分类:企业架构
- 博客分类：
- 而立
一般软件开发可分为如下阶段。
1.需求分析
2.概要设计
3.详细设计
4....
其中概要设计，我觉得起到的作用，就是从需求过度到详细设计阶段的一个中间过程。这种划分方式，不是从软件开发本身的需要出发的，而是按实际的项目过程控制需要划分的。因为不同的项目，需求在理解难度上、抽象程度上，千差万别。因此到达实际的产品功能设计和程序设计（即详细设计），所需要的信息，也差别很大。需求分析阶段侧重于从用户那获取原始需求。而所谓概要设计，就是要把到达详细设计中间缺少的信息补全。
所以，所谓概要设计文档，内容是五花八门的，没有确定性质的内容。有人还在找概要设计的模板，这实在可笑。而后文列举的一些原因将导 ...
- 2016-01-27 13:35
- 浏览 2807
- 分类:企业架构
- 博客分类：
- 而立
大型项目会涉及到多个子系统。每个子系统的开发工作的管理和控制和单个系统的研发有很大区别。不能简单的将单系统的研发经验直接应用在多子系统的项目里。其中的区别如下：
对于单系统的情况：
1.系统的业务和技术相对单一，并且系统内是具有强关联性的，各部分必须严格一致。
2.需求规模有限，可以被一个人完全掌控。
3.用户需求可由一个人与用户协调确定。
但对于多子系统的情况，比如：有展现、有监控、有大数据
此时：
1.各个子系统的技术都很复杂,难以由一个人来全面掌握，系统间具有协作关系。
2.需求规模巨大，难以由一个人控制所有细节。
3.每个子系统的需求，需要由各子系统的负责人和用户沟通确认。
这 ...
- 2015-10-30 13:06
- 浏览 1238
- 分类:研发管理
- 博客分类：
- 而立
软件开发必须过程化，必然需要文档的辅助。需要写文档是毋庸置疑的，这包括：需求分析文档、设计文档等。但没搞过这个的项目团队，往往抓不住重点，走入一些误区。
1.没有大而全的模板
没有大而全的文档模板，能照着模板写文档。软件开发本身是一个认知和设计的过程。文档的内容就是认知和设计的结果。怎么可能在认知和设计没发生的情况下，就事先有一个模板告诉你该写什么。
模板最多提供一个固定的文档形式。但该有什么内容、如何组织这个是写文档的人的事。形式是为内容服务的。
文档模板可以起到一点提醒作用，但这也是次要的。关键在于内容。
如果能够把握住要写的内容，模板显然没有大用处。
2.评审的重点是内容
评 ...
- 2015-10-20 10:27
- 浏览 1645
- 分类:研发管理
- 博客分类：
- 而立
一、代码复查的作用：
1.查找bug。
逻辑上的bug，从代码层面最容易发现。一些对需求的不理解，手误等也很容易发现。
2.查设计一致性。
软件的功能组织、数据表示、公用代码等每一个软件都会形成自己的实现模式。新加入项目的程序员由于不熟悉原有软件的设计约定，很可能会按自己的方式编写功能，从而导致软件设计不一致。
这对于无mvc框架的oo程序这是致命的，最终会导致软件的各种功能实现，纵横交错，五花八门，无法理解和管理。
3.查一般代码规范、命名规范
4.快速提高开发人员的能力、帮助开发人员养成良好的开发习惯
二、代码复查方法：
svn 对比，增量复查。
新手代码和复杂逻辑代码重点 ...
- 2015-10-17 22:06
- 浏览 948
- 分类:研发管理