程序 = 实践 + 思考 (Programming = Practice + Thinking)

写Self Documenting Code很重要；这里有一个不错的帖子，它的讨论更好，有兴趣的朋友可以看看。

完成功能其实非常初级功能的稳定性　可扩展性　如何规模化　性能优化　这些是后端程序员要考虑的对UI工程师而言，考虑的不应该是2 pixel 而是用户流程和体验不过哥就是考虑的太多　　不爱立刻完成．．．．虽说有些事情不是普通程序人员做的，更像是架构使或者technical leader做的事情；但是，你有了这样的思维，从长远/整体的角度看问题(系统性思维)，对个人成长是

为什么使用if else分支语句不好？不是说不能用，而是说在业务逻辑层等比较抽象的地方使用冗长的if else不好。首先能想到的一点就是代码违反了 open close原则（open to extesion & close to modification）。每一次有新的逻辑变动，都需要了解原有代码的逻辑，并在适当的地方增加分支语句。这要求程序员对编写非常完整的逻辑。打个比方，在一个继承

先说Three-tier。简单点说，                   客户机---应用服务器-----数据服务器典型的情况下有多个db服务器和多个客户端。应用服务器也可以有多个。应用服务器指 对客户端的请求进行分析，平衡，再将其分配给db服务器。对db服务器返回的结果集分析，平衡，发送至不同的客户端。一个最简单的例子：  client1,client2发出两个相同的se

有一个著名的原则，叫做KISS --  keep it simple and stupid。大概就是说，能简单就简单，简单的实现方式更可靠，过犹不及。以处理new中的exception为例。为了编写完美的异常安全的代码，有必要保持对任何已分配资源的跟踪并且时刻准备着当异常发生时释放他们。我们既可以将代码组织为无需回收资源的方式（参考http://blog.youkuaiyun.com/fishhg

编写异常安全的代码，最困难的地方不在于抛出或捕获异常，而是在抛出和捕获之间我们应该怎么做:必须清理所控制的任何重要资源。以下为例。string& string::operator = (const char * str) {   delete [] s_;   if (! str) str = "";   s_ = strcpy( new char [ strl

大多数人对“抽象”一词的第一反应是形容词的抽象（abstract），于是总不自觉地将之与“深奥”、“模糊”、“不直观”、“不具体”等相关联，这固非大谬，然而在编程设计中，人们关注或强调的抽象更多地当是名词的抽象（abstraction）或动词的抽象（abstract，指“抽象化”）。比如著名的针对接口编程（programming to interface）原则、依赖反转（Dependency In

抽象有很多种，有数据的抽象和过程的抽象。数据的抽象就是从问题领域中提取出一些能反映问题本质的对象；这是面向对象OO的基本功。OO中，在定义类的层次关系时，有几个重要的概念；如果能从抽象的角度来理解他们，有助于设计出更好的架构，能使解决方案更好的模拟/描述问题空间。                Public Inherit:                          Is-

题目：   找出两个单向链表相交的位置   请考虑周全提示：  除了普通情况外，还要考虑环以及2者首尾相连。参考答案：最普通的情况下，可以这样做：  1. 算出两个链表长度。  2. 假设长度差为n，扫描长的链表n个节点。  3. 同时扫描两个链表，碰到第一个相同的就是公共节点。如果有环呢？（别人的方法）  判

What is “DLL Hell”?dependency hellWhy it occurs? Sharing code in a wrong wayincorrect registration: all applications share one registration entryincorrect memory sharing: only one instance l

1.exception的代价比较大，要避免(至少减少)使用2.在可控范围内，或者说可预料的情形，不要使用exception，而要使用error covering logic来替代. exception不能用来control flow。 3.在不可预料的情况下，只能使用exception了。比如，打开系统文件，但是找不到，应该抛出一个exception；而打开一个自己创建的l

最近在看别人写的代码，发现不少问题。这些问题除了业务错误外，很多逻辑错误都是可以通过状态机分析来发现的。最常见的状态转换模式是 initialize -> use -> [ loop entry] reset/clear/refresh -> use again -> [loop exit] release；这是一个完整的生命周期。或者说Think code with a comp

考虑一个事件驱动的模块，这个模块管理很多个用户，每个用户需要处理很多的事件。那么，我们建立的驱动表就不是针对模块了，而是针对用户，应该是用户在某状态下，收到某模块的某事件的处理。我们再假设用户可以分为不同的级别，每个级别对上面的提到的处理又不尽相同。用面向对象的思路，我们可以考虑设计一个用户的基类，实现相同事件的处理方法；根据级别不同，定义几个不同的子类，继承公共的处理，再分别实现不同的处理。

普通代码----------------------------------------------------------------------------------------------------------------------------void msg_proc(const char *msg_type, const char *msg_buf){

Perl was originally developed by Larry Wall in 1987 as a general-purpose Unix scripting language to make report processing easier.[7]According to Wall, Perl has two slogans. The first is "Th

很多时候一个program会调用其它辅助exe；不过这些exe很快运行完毕，一闪而过；来不及通过attach的方式来debug。有几个小技巧可以用用：getchar();//这个还不错，不过有的时候可能不起作用，因为getchar拿到非你manual输入的东西sleep(3000);//这个时间设置的长点，肯定来得及attach的ASSERT(false);//这个只对debu

1996年6月4日，阿丽亚娜5型运载火箭的首航，原计划将运送4颗太阳风观察卫星到预定轨道，但因软件引发的问题导致火箭在发射39秒后偏轨，从而激活了火箭的自我摧毁装置。阿丽亚娜5型火箭和其他卫星在瞬间灰飞烟灭。　　 后来查明的事故原因是：代码重用。阿5型的发射系统代码直接重

发信人: conezxy (小鱼，lp说我懒得很有耐性), 信区: Programming标  题: Re: 面试程序员，你会提什么问题？发信站: 水木社区 (Sat Apr 23 00:06:40 2011), 站内我每次必考的问题----不用库函数，实现字符串

从重用角度看几个主要编程概念http://www.cnblogs.com/idior/articles/606938.htmlSA: (结构化编程)  通过模块OO: (面向对象)  通过封装, 继承, 多态

How to debug a solution1.    F5 + break point 2.    run xxx.exe + attach its solution to this process (No rebuild on solution)3.    vsjitdebugger xxx.exe + select its solution in VS (No rebuild on solution)

公司基于WPF自己开发了一套control，发现不少性能问题。列一下我发现的几个吧1) grid control的hit count挺多的。一个grid中的各个row presenter有很多很多，但是度是同一个format的。所以不必每次都调用row presenter的constructor，除了第一次之外；余下的全部调用clone来实现。    同样的，row presenter

周围有不少同事买了不是c++的书籍，什么object model，看的很起劲。但是真的有必要看这种书吗？对很多人来说，学C++使为了应用，并非研究语言本身。我们必须掌握必备的编程知识，一边能够胜任应用领域的开发；成为语言专家当然可以，但更重要是业务领域的专家。就C++学习

有一座寺庙的香火很旺，多少年来人们总踩着那些石阶来到佛像面前进香。终于有一天，石阶们不服气了。石阶对佛像说：你和我们都生自同一块山石，为什么人们总踩在我们的身上，而却要对你顶礼膜拜？佛像淡淡地说：因为你们只经过六刀就到了今天这个位置，而我却是经过千刀万剐，才最终成佛...---

个人观点：软件设计首要的就是考虑需求,考虑适应变化应该是第二位的；当然，一个生命周期非常长的商业软件，稳固的架构设计非常重要了。http://blog.youkuaiyun.com/Slin000/archive/2008/02/25/2119287.aspx软件设计的学问很深，学一点可以开

Generally, function names should be simple, understandable (self-description) and correct.

1. WCF序列化的错误   2. Combo Grid的selected item：在对应的presenter中以new一个item的方式赋新值，但是combo grid中没有更新。也就是说，前后不同步.

昨天在fix bug；拿到之后吭哧吭哧就可以debug了。费了一下午，总算跟踪到最后那部分代码了；结果发现数据库的已经有相同数据，不能覆盖，程序退出了。连bug的现象都没有复现出来！浪费了不少时间，还得回头重新找数据！要吸取教训了！分析bug之前，要先复现！ 所谓磨刀不误

有一张很有意思的图片，能反映部分公司的状况。

借用一下这个很大很夸张的标题。内容都是摘录自coders at work"Coder" is strongly associated with the smallest and most narrowly focused part of that whole so

1999 年“火星气候卫星” 因导航出现重大错误而坠入火星大气层。从Peter Norvig(在NASA 工作的时候参与了调查)在coders at work的问答中，我们可以看到一个大略的错误发生过程:1)      软件外包公司对于 mission-critica

http://book.douban.com/subject/4719230/ 27位杰出的编程语言设计师的访谈录，很不错，值得一读。但是中文版翻译得不行，在douban被批了；应该很快再版了.    做点小笔记：-------------------

据传，在冷战时期，CIA曾成功向前苏联“输出”一个有设计缺陷的控制软件，该软件用来控制天然气主管道。（KGB从一家加拿大公司窃取该软件。）那个植入的Bug最终引发了1982年的西伯利亚天然气管道大爆炸。　　 CIA前高/官里德回忆道：“那次爆炸的结果是非常惊人的，它是除了

why?they make debugging easier.The time consuming part of debugging is tracing a problem from the symptom you first notice back to the error in the code. Well written assertions will make the sy