随笔分类 - Chatter
摘要：新技术不是不能用，而是堆了新技术，接手的人就要学会这些。这边对于新技术的定义，是很广泛的定义为系统中没有使用过的技术。在系统一开始的时候，技术需求就是一片空白，后续设计的时候，每次加入的没有用过的技术，都需要去考虑是否有延续性、是否要定义为基础技术...等等考虑。大一点就像是要不要使用Design Patterns、DDD、TDD，或是MVVM要不要用、ASP.NET MVC不错要不要推。小一点的就像是版本控管要用哪种、版本分支、合并的策略是甚么。这些都是需要依照目前团队、未来目标等等方面去考虑。每个系统都有隐藏的项目天赋表，天赋就是系统里的技术，开发人员点满天赋才能吃透系统。--以开发人员的
阅读全文
摘要：通勤时看小说「数字风暴」，里面有一段话很有趣。程序员的成长固然和经验和熟练度有关，但到了一定的境界，熟练度这回事越来越无关紧要了。决定一个程序员的水平的，是想象力，是数学、物理等方面的功底、是对计算机的最底层的东西的洞察。 忽然有感悟，学会了OOP、OOA、DDD、TDD等等技能，学会这些就跟画家学会用各种颜料来作画一样，不过只是基础。要如何运用这些基础技能，解决真实世界的问题，努力成为某个领域的专家，建立起自己的风格、自己的道路。我想这是每个开发人员，有一天都需要面对、思考的问题。
阅读全文
摘要：这篇文章用来记录重构系统架构时，遭遇到的问题内容，以及当下处理的解决方案。应该会不定时更新 XD2012/07/03命名规则定义问题内容 : 命名规则没有标准化规范，维护程序代码困难。解决方案 : 采用微软标准命名规则，提高程序代码质量。系统架构分层问题内容 : 架构分层不明确职责散落各处，容易改东坏西。解决方案 : 架构分层重新设计，一层一层分离职责。系统架构模块问题内容 : 架构模块不明确职责散落各处，容易改东坏西。解决方案 : 系统模块重新设计，一块一块分离职责。系统架构通讯问题内容 : UI逻辑紧密相依WCF，必须要整套系统架起来除错，增加除错困难。解决方案 : 采用IoC切割通讯职责
阅读全文
摘要：在撰写程序的时候，错误处理是一件很重要的事情。在「C++编程规范」这本书的第71个条款里，依照不同的错误处理结果，定义出三种「安全保证」等级： No-fail保证、Strong保证、Basic保证。这三种安全保证等级以执行方法遇到错误并且处理之后，是否会影响到数据或状态来做等级区分。开发人员在撰写每个方法之前，先决定方法的错误处理是属于哪个等级，可以减少思考的范围、避免一些不必要的过度设计。No-fail保证所谓的「No-fail保证」是说：执行方法一定成功、不会发生异常。在系统里有些方法，必须设计为提供No-fail保证等级，例如：解构子、资源释放、Log纪录…等等。这些方法通常会在错误处理
阅读全文
摘要：今天去面试，面试官希望我多聊一些有关架构设计，当场回答了一些部落格上分享的架构模式。回家的路上，认真的思考了这个问题：「架构设计是做甚么?」对我来说，架构是用来处理软件系统上的各种非功能性需求。不管是增加系统的扩充性、降低开发人员的最低能力、减少维护人员的负担，都是架构设计该处理的问题。以部落格上写过的架构模式来说：「Database Migration」抽象化数据库部属升级，减少维护数据库的成本。「Repository」抽象化系统储存装置，增加系统可移植性。「Device Projection」抽象化设备管理功能，聚焦开发人员的思考逻辑。这些架构模式，处理各种面向的问题，内容包山包海。但能.
阅读全文
摘要：Design Pattern很硬很难懂，但是它绝对是一个值得开发人员投资的项目。最大的好处是可以透过学习、理解Design Pattern，学习、理解到对象几大原则： - 单一职责原则 (SRP，Single Responsibility Principle) - 开放封闭原则 (OCP，Open Closed Principle) - 依赖倒置原则 (DIP，Dependency Inversion Principle) - 接口隔离原则 (ISP，Interface Segregation Principle) - Liskov替换原则 (LSP，Liskov Substitution P
阅读全文
摘要：『面向对象的架构』是怎么样的东西，今天忽然顿悟该如何用文字将他定义。将在开发软件项目的时候，遇到的各种不同功能面对象，归类并取一个好记的名字。反复重整功能面对象跟名词，最终就会产生一个属于自己的架构。以DDD(Domain-Driven Design)的Domain Layer来说。1.系统有个User对象。DDD将他归类的成Entities，它的职责就是一个有唯一辨识的对象。2.User要存在储存设备。这个储存设备的功能DDD将它归类成Repository，它的职责就是让Entities可以进出系统边界。3.系统还有一个定时检查User生日发送祝福信件的功能。这个定时执行的功能DDD将他归类
阅读全文
摘要：三层式体系结构里面的"层"，其实应该分为Tier跟Layer。这两个中文翻译都是"层"，但是他们是相同却有差异的两种"层"。相同的地方在于，将系统依照功能切割为 Presentation、Business Logic、Data Access。差别的地方在于，一个将系统切割成三个子系统(Tier)，Presentation Tier、Business Logic Tier、Data Access Tier。一个将系统切割成三个层(Layer) : Presentation Layer、Business Logic Layer、Data
阅读全文
摘要：跟朋友聊天，得知他们公司采用 WebService来做软件架构的分层。这在软件架构上是对的，但执行时容易有一些些的偏差。1. 提供信息的服务器端，WebService的 Function直接捞数据库回传。 WebService里面的 Function做的事只是建立数据联机+取数据，这样其实只是把 Stored Procedures写在程序代码内。 就本质来说还是『捞数据+排版显示』的数据库导向系统，只是把『捞数据』这一段从 Sql改成 WebService而已。 WebService使用的时机，应该是『软件系统提供给其他系统使用的服务』。 这边软件系统的定义是指有自己 Domain know
阅读全文
摘要：常常有人用车、汽车、模型车，来解释对象的继承。可是却没有特别解释，是因为上层的程序使用了车，汽车跟模型车是用来抽换的下层。反而去解释，因为汽车跟模型车都有一些共通的功能，所以才用继承。就面向对象语言面来说，这样是正确的。就面向对象设计面来说，这样是误导的。
阅读全文
摘要：昨天跟朋友哈拉打屁，引发了一些想法 :「程序设计有分深度跟广度」。 程序设计的深度，指的是技术背后的精神与实现。 程序设计的广度，指的是技术工具的使用与应用。当一个新技术发表，两个不同角度的人一起去看。 最终的结果都是能掌握，但在的路途上却是分歧的。 以ASP.NET MVC来说 : 从深度去看，看到的是。MVC的精神是甚么、微软怎么实现MVC架构。 从广度去看，看到的是。ASP.NET MVC有哪些方法可以用、在项目上怎么应用。这又延伸出了一个问题，一项技术该学到甚么程度。 从深度去看，学习掌握。深入了解核心精神、怎么实现的手法。就算懂了，剩下的实做时候再去翻数据。 从广度去看，学习掌握。深
阅读全文
摘要：程序设计这件事本质上: 就是在无数工程师创造的世界规则上，建立属于自己的作品。 在CPU的世界上，建立汇编语言。 在HTTP通讯协议的世界上，建立网页程序。 在Microsoft的世界上，使用.NET开发程序。 ...就整个程序设计来说，有太多规则需要去学习体会。 不是每一条规则，都需要去透彻的了解才能写出程序。 掌握规则的程度高低，却是决定了功力高低的指标。 就像是开车的人不一定会修车、赛车手比一般人更会用车。随着程序设计的世界在进步，规则一层一层的架上去。 却有越来越多工程师，不去学习工具背后所隐藏的规则。 这不是一件坏事，这是高度抽象化的成果。 而且毕竟人的精力有限，开发出程序能收钱就好
阅读全文
