《简单之美》场景故事连载5
《简单之美》场景故事连载4
《简单之美》场景故事连载3
《简单之美》场景故事连载2
《简单之美》场景故事连载1
《简单之美——软件开发实践者的思考》终于上架了，从年初定稿到现在转眼又4个月，希望看过的朋友都能喜欢。 贴下每章之前的话，推广下本书中的想法。 第1章 无极生太极 在进入软件开发领域之前，我们必须要做一些思想上的准备。这种思想上的准备高于方法论，以及任何一项具体的工作内容，它可以使我们站在一个更高的角度来认识软件开发这件事。思想认识是解
年初，《简单之美》这本书基本上完稿了。当时还没有确定书名，为此和福川讨论了很久，想到过大道至简、道法简单、软件开发之禅、求简、简法，最后定了简单之美，我们感觉这个名字比较朴素，也充分表达了本书的意思。另外，好像“之美”还有一个系列。在网上搜了搜，也没有找到名为简单之美的书。 其实，因为自己的原因，交稿晚了几个月，感谢福川的宽待处理。在最后的冲刺阶段，几乎天
目录 第0章 前言 0.1为什么写这本书 0.2谁应该阅读本书 &nbs
在将近半年的时间里，写了一系列围绕简单是王道的杂谈文章。这些文章涉及了软件开发中的一些有趣的话题，但所有的话题都是点到为止，没有深入和展开。在不久的将来，也许我会重新拾起这些话题，以书籍的形式，更完整地表述自己的想法。希望看过我的博客的朋友们多提宝贵意见，共同探讨，或许经过我们大家的努力，可以找到使软件开发者的生活变得更美好些的办法。 敏捷软件开发是一种软件开发过程的方法论。没有
1995年，GoF推出了设计模式一书。业界公认这本书在面向对象编程/设计领域具有划时代的意义。那么，如果你读过了这本书，你是如何来认识它的划时代意义呢？你是如何来应用这本书引荐的设计思想呢？我的设计之路是从这本书开始的。6年的时间里，我阅读了很多遍，认识和收获也在不断的增加。从最初对模式进行记忆到现在对系统进行想象，越接近GoF的思想，就越觉得简单带来的快乐。 模式就像中国功夫中的套路： 形意
今天朋友介绍了Martin Fowler刚写的一篇文章。单纯针对规则引擎这种工具来说，有些想法和我们的接近。关于工具，前面的博客中已经讲过两次。下面的文章是从一个侧面提醒我们，工具的使用要非常地谨慎。另外，Martin没有提到的是，当你用了工具实现了系统，也许在很长的一段时间内将无法摆脱噩梦。 以下翻译： 规则引擎提供了一种新的计算模型。和一般的命令模型（带条件和循环的顺序执行指令）不同，它提
上一篇文章中提到建立外科手术式团队的想法，一个隐含的也是最重要的想法是建立软件开发的责任制。前两天和一个朋友聊起这件事，他也是深有体会。让我们在聊讲故事之前，先来讲讲故事。 朋友所在公司的研发部门老总最近在向一线的项目开发部门兜售研发成果，结果遭到抵制。一个大的背景是，一线的项目开发部门以疯狂的加班精神赢得了老板的心，所以可以优先说不。听完朋友的介绍，我的态度是不站在任何一边。为什么呢？因
在软件工程中，最重要的因素是人。要确保软件项目的成功，最重要的是合适的团队成员以合适的工作方式开展工作。这两句话听上去都不错，可以作为一个原则，但是还无法成为可操作的指令。 工作方式是可以指定的，而合适的团队成员则需要合适的领导者来甄选。这里不谈人的问题，只谈工作方式。 在传统的成熟的行业，早就形成了一些固定的工作方式。例如外科手术，主刀医生会确定手术方案，会安排同行医生会诊疑难问
在谈开发模型之前，先聊聊CMM（现在叫CMMI）。网上看了不少评论，大都对CMM不屑。很多人认为CMM只是带来了大量的文档工作。事实上，国内很多公司在通过了CMM认证之后，软件开发仍然没有章法。原因在哪里呢？CMM真的很烂吗？CMM真的在国内行不通吗？ 三年前，为通过CMM的认证我和我的团队断断续续努力了一年。我知道了软件资产的概念；知道了软件公司应该如何积累知识的价值；知道了软件开发的成
上篇文章中提到一些不合理的工具，如业务规则管理系统（Business Rule Management System, BRMS)，因为它的畸形发展，而且嵌入应用系统的内部，给系统带来了不必要的复杂性。今天再围绕这个问题，深入地探讨一下。我会从下面四个方面来展开。 什么是BRMS？BRMS如何工作？问题在哪里？更好的方案。 什么是BRMS？首先声明一点，在应用系统中，业务规则是大量存
看到很多滥用工具的TX，开口闭口是工具，还要面向工具来编程。在企业信息系统的开发中，滥用工具有点像走火入魔。那些TX忘了本质上要做的东西。 什么是工具？工具是我们做事时候的帮手。等做完事，这些工具不会在我做的事上留下任何影子。就像改锥，拧完螺丝，还得把改锥搭在机器上一块去卖吗？因为只有那把改锥，我的所有螺丝都得按改锥的型号设计吗？不会啦，有人说，我可以换一把改锥。哈哈，恭喜恭喜，这样说看上
软件系统的开发有点像举办一场音乐会。首先是筹办（资源就位），了解希望来买票的观众是古典还是流行口味（需求），确定演奏什么曲目（SOW），演奏（开发）。为什么有点生硬地扯到音乐上来？因为本人想引出一个关于编程模型的比喻。原谅我继续生硬地把比方打下去。我们有了美妙的声音（Java），有了发出美妙声音的乐器（Eclipse），有了乐谱（系统设计），有了使用乐器的技巧（Java和Eclipse都很熟了），
昨天有TX看了简单是王道《一、开篇》，认为简化系统的想法是有道理的，但似乎没有什么用，就像天人合一的思想在现实中无法实现一样。感谢这位同学的Challenge，我今天写的这篇文章，就是和大家交流一下我在简化之路上的心得，同时也想和大家一起探讨简单的原则有没有实现的可能。昨天还写一篇文章叫做简单是王道《二、用组件化重构系统的思考》，那篇文章是今天所谈内容的思路和线索。 先给大家看一张图（见图
目前公司的系统存在很多问题，最大的问题是没有好的架构。什么是架构呢？打个比方，建一栋高楼，首先要有概念设计，然后是建筑蓝图，然后是各种预算，然后是有计划的施工。这个过程的每一步是统一在一个整体当中的，要经过预先的有系统的思考，再经过论证，再不断进行细节的修正。我把整个过程和过程中对各种要素的规划称为架构过程和架构。再打个比方，医生的一次手术，首先要进行各种术前检查，然后对检查结果进行分析，然后确定
从事了很多年的企业信息应用软件的开发，深有感触。最大的感触是，在软件系统的构建中，一定要把握简单的原则。用简单的眼光来看待信息，用简单的手段来组织信息。 提到原则，很多人不以为然，通常原则是些非常显而易见的道理，就算有争议的原则，像这里说的--简单是王道，每个人肯定一目了然。但是在运用原则的过程中，总是有很多人会背道而驰。 在我看来，企业信息应用系统的内容非常复杂，但是系统本身的实
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
