- 博客(7)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 软件工厂是否真的可能存在？
一点说明：作为程序员，通常心里是讨厌软件工厂的，但很多时候问题自身皆有其内在理性，并不以个人的偏好而改变其发展的轨迹。所以程序员一旦谈及和自身喜好相关的问题时，尤其要摒绝个人好恶，否则就会离问题的真相越来越远，而只有一腔情绪。就我个人观察软件工厂大致处在这样一种地位：经营管理者迫于成本的压力，总是潜在的期望其可能实现；而程序员群体自身则总是对其嗤之以鼻。为什么在经营层面软件工厂有如此大的诱惑力？这
2012-03-28 00:04:21
4208
7
原创 【设计 = 编码】 VS 【设计 ≠ 编码】
在1992年，Jack W.Reeves发表了一篇名为：Code as Design的文章，这篇文章可以在《敏捷软件开发 原则、模式与实践》一书的附录中找到。这篇文章的核心观点是：编码也是设计，而软件开发中与建筑行业中的施工所对等的工作，已经被编译器代理了。这是几近20年前的文章，但时至今日，类似的争论仍未休止。好像是在《软件架构设计》里，在讨论架构设计时，作者就点了一句：这总不能说是设计就是编码
2012-03-21 00:12:55
4129
原创 国内外软件开发上的差距与分析
--愿与勇于正视现实的人共勉在开始任何其他文字之前，首先有必要正视一个根本现实：国内外软件开发的水平是有差距的。这一结论的最直接证据是每一轮新技术的发起者基本上都是国外的人或公司：从方法论（CMMI，敏捷等）到各种框架（近来很热的Hadoop等）再到新的编程语言都是如此。总的来看这类差距似乎可以概括为“原创的缺失”，大多时候，我们只是处在一种“跟随者”的角色上。RUP出来后我们跟谁RUP，敏捷出来
2012-03-19 00:03:27
14793
25
原创 编码会不会逐渐消亡？
很多年来始终有一种声音：编码自身会逐渐消亡，软件开发会越来越像一种组装工作。也就是说，程序员会越来越像IT工程师，他们很少自己从头做什么，而是靠搭配来达成各种目标。我身边就有持这种观点的人。而在《代码整洁之道》一书中，Robert C Martin在开篇处加了这样一段文字：有人也许会以为，关于代码的书将有点落后于时代---代码不再是问题；我们应当关注的是模型和需求。确实有人说过我们正在临近代码的终
2012-03-14 00:01:16
18448
72
原创 并行中的正负两面
大多情况下，并行对复杂度影响过大，并间接导致测试困难---多线程或多进程导致的问题往往是有时发生，有时不发生，一般的测试手段并不足以发现这类问题。所以原则上应该尽可能不用，除非收益足够大。或则说在满足需求的前提下，线程数和进程数应该尽可能少。 以多线程和多进程而论，确定“什么时候适合使用这种技术”是比“怎么使用这项技术”困难的多的事情。现实中人们往往对事件，信号灯等同步处理手段关注过多，而对究竟应
2012-03-12 00:05:14
4136
3
原创 代码复用的考察
复用可以说是任何一个软件企业都不能漠视的课题，因为复用可能对软件的开发效能产生绝大影响，而开发效能直接影响利润，甚至生存。 但复用本身将增加当前项目的成本，是一种以当前投入来换取远期收益的行为。与此同时远非所有代码都可以复用，复用本身也有自己内在的一些规律，让我们来试做一些分析。 从结论上来说，只有满足下面两条原则的程序，才可能真正的被复用，否则的话只能采用代码级别的复用。 第一条原则是，程序本身
2012-03-07 07:42:17
3354
原创 项目管理中的导向性
众所周知，领导与管理意义不同，领导者要决定的是未来的走向和基本的原则策略。管理者则要使用具体的手段，达成既定的目标。但现实中的管理上的问题往往并不只类似于数学，只需要计算和推理，而更类似于社会学，需要许多判断，这也就意味着做管理的时候最终会涉及导向性的问题。 软件项目的管理尤其如此。 建造一栋房屋和构建一个软件，其不同在于建造房屋的工人需要的是按照设计图纸严格执行，因此纪律要比文化重要。但在软件开
2012-03-05 00:32:44
4719
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人