随笔分类 -  构架

摘要：重新回来，回到现在 刚刚登录后，系统提示绑定手机号，欣然绑定。一切都是那么稳定，注册名，邮箱，手机号，翻看历史记录，感谢博客园！ 回来看我的ID，也颇具禅意，子标题是“未来决定现在”，感觉好极了。 （其实写这篇的想法，是我正在做的系统，主要是数据的预测，有一些想法，但是还很模糊，一定要找个地方说说， 阅读全文

摘要：一直跟信息安全较劲，曾经发过一个有关163.com密码的问题，年前又在发现QQ无数的诈骗邮件恶意套取密码，后来发现原来QQ的官方就是在帮助用户泄漏密码，所以在QQ签名上就写上了。后来就出现了CSDN的事，然后我在微博说，很多网站都会存在这个问题，果然，密码事件愈演愈烈。这都是笑谈，我无法预测这些事件的发生，更不能让这些事件不发生。但是我知道，安全，一直是IT的人的一块心病，无论是内部系统，外部系统，无论是桌面程序，还是迅猛发展的云计算 ，一提安全，全都很傻。所以很多以安全为己任的开发商，则可以大事渲染安全问题，让人们相信，有了他们的帮助，信息系统就安全了。安全，很多有有很多论述，我也有一些，. 阅读全文

摘要：上周听收音机，主持人调侃说，她到了一个单位，保安问了她三个问题：你是谁，从哪里来，要到哪里去？保安出于职责，却问出了三个哲学终极问题，其实的确值得每个人去思考。我突然觉得，我们身边的每一件事，是不是都要问一下，你是谁，你从哪里来，要到哪里去呢？我正在准备一个技术课程的资料，突然对Web Service，尤其是Windows环境下的Web Service，发生了很多疑问，而且，这些疑问很久萦绕在思绪中...Web Service，你是谁？你从哪里来，要到哪里去？最初，作为系统互操作的一个简单解决方案，随着internet的兴起，Ws进入了我们的应用，可以简单说明Ws从哪里来。但是，如今的Web 阅读全文

摘要：敏捷可以解决了开发模式的官僚问题，从行动角度应对用户业务需求的变化；构架可以从设计角度应对业务需求的变化问题，甚至在需求调研阶段，能解决需求的收集和确认。需求的变化，一般可以从3个领域发生，界面、流程和规则、组织结构和权限。界面问题一般表现在界面的元素发生改变，如一个订单，原来有几项，关联了一些子表。现在要多加几项，修改其中几项，还要加入一个新的关联，等等流程问题一般表现在一个界面的提交后，可能要跳到一个特定的界面。现在要跳转到另外一个界面，并且有一些新的规则；或者这个用户跳转到这个界面，那个用户跳转到另外的界面；或者根据界面上的某个输入，大于某个条件，就跳到这个界面，小于某个条件，就跳到另外 阅读全文

摘要：敏捷开发从宣言到原则，再到实践，也有组织开始进行敏捷的认证活动。Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan前几天听得一个敏捷基础类的介绍，已经将过程加到敏捷开发时间中，认为可以将Fast同Process联系起来，认为流程或工具是使团队更快速。还是那句个体和交 阅读全文

摘要：信息是什么，信息是事物本身和它的变化过程，当然，关联也是一个事物经验是什么，经验是了解了事物本身，还了解它的变化，知道这个事物还会发展成什么样子。如果知道一个事物下一步的样子？看看这个事物的变化过程，或者看看类似事物的变化过程。一个事物如果没有一个明确的变化，可能是一个难题，这就是大事物，大粒度的事物一个事物如果变化太小，也可能有些困难，需要更精细的粒度划分方法。 阅读全文

摘要：大师们的确不但要总结一些有关敏捷方法的理论，而且要有切实可行的方法去操作，还要有相应的商业模式的配合，否则总是说敏捷宣言原则实践或者经验，没有一点儿理论和商业模式支持，一遇到有关收费的问题就没的可讲的了，谁为敏捷的交流付费，谁为敏捷的变化付费，如何才能通过第三方信任一个敏捷团队，这些都是商业模式的问题。敏捷方法有时需要把各种新鲜的东西都放到敏捷中来讲，以为敏捷保罗万象，有人提个问题，回答得神乎其人，云山雾罩，让人觉得漏洞百出就不好了。或者本来说过程控制不是敏捷，结果在实践中又不得不以形式化过程作为敏捷开发的主要活动。或者在一个项目中敏捷，到了另外的项目就不敏捷了，有的敏捷项目实际上不敏捷，有的 阅读全文

摘要：原则，作为大的方向，影响到构架的设计和实现运行效率和开发效率优先级，可读性和开发效率安全性稳定性负载量团队开发沟通原则　　确定原则就是确定一个总体的方向，当一些可选项发生冲突的时候，就可以根据总的原则进行决断。　　如，当前这个系统需要进行一些技术性尝试，而不是一个生产系统，那么，我们可以不考虑过多的安全，易用，稳定方面的设计，直接实现功能，解决技术问题就可以。　　再如，系统的稳定性比较重要，那么，我们的稳定性设计就一定要可靠又可靠。　　再如，系统的安全性比较重要，那么，数据的安全，访问的安全就要谨慎又谨慎。　　再如，系统代码的可读性和可维护性作为首位重要的原则时，代码的质量，以及规范就非常重要 阅读全文

摘要：有时听到开发人员抱怨系统运行速度慢，开发效率低，代码和重复的工作太多。我都要仔细听来，感慨颇多。这种情况不仅仅是其他人的项目，我自己的项目也有这种情况。最常听到的是，系统分了这么多层次，每次加新需求，加入新的对象，都要在每一层作修改，比如，在服务端，先加在Model层，然后再修改数据持久层，然后再修改业务层，再修改界面或服务层等，修改完了服务端，还要在那些依赖于这些服务的客户端进行逐层的修改。这种... 阅读全文

摘要：继续昨天的话题，引出今天的结论。首先，对于昨天的话题，感谢大家的回复，由于初来园子，有些规矩可能不太懂，但我仔细看过首页原则，自我感觉是原创、经过自己认真思考并能给别人带来收获 的文章。但是由于非技术的东西，太多了总觉得不妥，这次放在非技术区，有趣就看，无趣跳过。所有回复的人中，没有人说这个电饭煲2.0是不是值得开发和讨论，大家有没有收获？我的本意不是讨论具体的技术细节，而是探讨一种思维方式。其实... 阅读全文