gdpglc
- 浏览: 93707 次
- 性别:
- 来自: 长春
-
最新评论
-
masuweng：
:i总结的很好dea:
客户需求及骨头与肉的分工方法 -
夜神月：
DAO这个东西想象很美丽
Dao的作用 -
eyesmore：
"比如某连接池中有2个连接对象。有两个线程分别占用了 ...
数据库连接池死锁的原因和处理方法 -
gdpglc：
呵呵... 这例子很有启发。我说的情况是对已有对象加入新功能时 ...
OO的环境下，需要控制对象 -
悲剧了：
比如在web开发里，登录用户信息存放到session里面，需要 ...
OO的环境下，需要控制对象
文章列表
你说10条，他听7条
你说深入，他听表面
听时点头，还能接话
表演过后，就会忘了
反复沟通，拉天测试
明显不对，视而不见
脱离代码，如脚登空
坚守瀑底，我的世界
真神奇也！
今天新感悟，因为找到了一些新的方法改善人员能力。之前的抱怨也许都能解决！
OOP的作用有二：
一、当需要进行数据和罗辑封装时。只用函数封装不行，必须用对象。
二、当需要把一般罗辑和特殊罗辑进行分解时。这时需要用到多态。
其他的所有OOP应用，都是上述2点的组合。
软件功能的一些信息是无法包含在代码里的，比如：
1.基于用户环境抽取的数据格式信息。
2.用户录入的具有特定业务含义的数据格式信息。
3.平台支持用户自定义数据结构，而代码硬编码了用户定义的字段。
4.特定业务需求导致的特定功能。只从代码无法反向理解功能含义。
在这些情况下，如果不仔细维护这些代码之外的信息，代码在不远的将来，老员工一旦流动，软件的修改就会遇到巨大困难。
尤其对于有产品化计划、开发实施分离的软件（可以跨多用户环境使用），信息丢失，导致的重复造轮子工作（重新梳理已开发功能的业务场景、理清数据结构和数据含义、然后按新的情况调整），就是灾难。
上述信息，维护到程序设计文档里，是很 ...
注意：这里的程序设计特指针对代码的设计活动。
我遇到很多人。
能严格约束自己，在开发前进行严谨的程序设计活动的人，很少。
之前我一直坚持写代码前做类协作设计，后来我基本放弃了。只做必要的接口设计、数据库 ...
1.为用户创造价值
2.Give our client what they like.
1.文档编号
软件开发离不开设计文件的编写与审核。开发的每一个阶段都会产生很多文档。通常文档是通过svn在团队内共享的。当一个阶段下的文档数目超过50个的时候，在一个目录里查找某个文档是个痛苦的事。常常有文档的名称很长且类似的情况，这导致找到需要的文档很费时。
这里有一个简单的解决办法。为每一个文档分配一个两位的编号，每一个文档必须以文档编号开头。比如：
00.xxx功能需求分析与设计.doc
如果想看某人提交的文档，只要知道他提交文档的编号就行了。
个人认为文档编号两位就好，冗长含义众多的文档编号是无用的。
2.文档版本号
写 ...
迭代开发是开发未知领域新产品的必然选择。但没有经历真正的迭代开发时，常常只能通过书籍雾里看花。
书籍里描写的经典场景是：一个迭代收尾，然后发布半成品给用户使用获取反馈，用户会说：“喔这里看上去不错，但是实际使用时我需要在这里看到...”，当迭代开发中发生这样的场景，说明迭代开发过程是有效的，产品在不断迭代和改良。
之前经历了一些号称是迭代开发的项目，很少发生这种情况。常常是内部一个迭代完成，测试，然后下一个迭代接着做。现在看，这样的迭代过程，不是真正的迭代开发，因为没有用户反馈。
最近的项目历时两年，前期也是处在类似的过程里。做完了拿给用户看。用户看看，也在尽量 ...
1.客户需求
对客户需求分析后可以进行产品功能设计。而产品功能设计又会衍生出新的功能性需求。
2.骨头与肉的分工方法
1.team leader 负责客户需求分析和功能的概要设计，概要设计给出的是功能的骨架和应用的核心技术。
2.team member 负责详细的功能设计、程序设计和开发。即在骨头的基础上丰富出软件的肉。
3.开发团队规模5人最佳。1名高级，2名中级，1名初级人员，1名需求与架构人员。
4.美工与测试人员，需要时聘请。
5.领域专家，需要时聘请。
6.实施人员1名。
一个感悟：
团队规模取决于team leader 能掌控的需求和概要设计的效率，当团队开发效率大 ...
1.封装支持了信息隐蔽。
2.针对接口编程是封装的结果，支持信息隐蔽。
3.内聚和耦合用来衡量封装的优劣。
4.时序图的主要作用是促进合理的封装。使设计人员可以在方法级进行思考，从而在方法级得到 一个合理的结构。
在方法级和业务逻辑通常有简单的对应关系，增强了软件的可读性、可修改性、可扩展性及鲁棒性。
为什么代码明明可用，还要按标准改好。
- 博客分类：
- 而立
1.好的代码是团队的要求。因为好代码，功能正确、bug少、通常更好编写、可读性强、可扩展性强。
2.不可能按每块代码是否因为代码质量更好受益来要求是否需要编写良好的代码。没法制定这样的标准。且也不需要这样，最好的办法就是统一要求代码质量良好。这就像类的getter 和 setter方法，又像是战争中的覆盖式打击。
如果在写代码时还需要挖空心思的思考差的代码是否能用，那就是再给写代码增加负担。何不直接去写良好的代码。
3.团队养成了编写良好代码的习惯，自然就会解决许多在代码层面可以解决的问题。
.
1.结构不会消失
型也不会消失，要么是显示的，要么是硬编码的在代码里的。
2.代码质量标准
基本：可以清楚完备的考虑。
容易修改。需要遵守针对接口编程的基本思想，规避内容耦合。
举例：
...
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周的时间太浪费了。
...