qingflyer的专栏

  今天看到这篇文章觉得不错，收藏了，也分享给大家。  1. 毕业了，你的档案转吗?　　近年来，大学毕业生对自己的档案不管不问，已不是个别现象。据了解，在各院校、各级毕业生就业主管部门和各地人事部门人才交流中心，被大学毕业生遗弃的档案都不少。超过择业期，毕业生的档案会被学校退回原籍。　　从郑州大学毕业两年的杜玉峰，毕业后辗转了两三家单位，没把档案当回事。谁知道今年评职称，他才想

设计实践1、你已经做过多次迭代，并且从众多尝试结果中选择最佳的一种，而不是简单选择第一次尝试的结果吗？2、你尝试用多种方案来分解系统，以确定最佳方案吗？3、你同时用自下而上和自上而下的方法来解决设计问题吗？4、为了解决某些特定的问题，你对系统中的风险部分或者不熟悉的部分创建过原型、写出数量最少的可抛弃的代码吗？5、你的设计方案被其他人检查了吗（无论正式与否）？6、你一直在展

1、软件的首要技术使命就是管理复杂度。以简单性作为努力目标的设计方案对些最有帮助。2、简单可以通过两种方式来获取：一是减少在同一时间所关注的本质性复杂度的量，二是避免生成不必要的偶然的复杂度。3、设计是一种启发式的过程。固执于某一种单一方法会损害创新能力，从而损害你的程序。4、好的设计都有是迭代的。你尝试设计的可能性越多，你的最终设计方案就会变得越好。5、信息隐藏是个非常有价值的概

类的质量核对表：1．抽象数据类型1.1 是否把程序中的类都看做时抽象数据类型了？是否从这个交大评估它们的接口？2．抽象2.1 类是否有一个中心目的？2.2 类的命名是否恰当？其名字是否表达了其中心目的？2.3 类的接口是否展现了一致的抽象？2.4 类的接口是否能让人清楚明白地知道该如何使用它？2.5 类的接口是否足够完整，能让其它类无

1、对现实世界中的对象建模2、对抽象对象建模3、降低复杂度4、隔离复杂度5、隐藏实现细节6、限制变化所影响的范围7、隐藏全局数据8、让参数传递更顺畅9、创建中心控制点10、让代码更易于重用11、为程序族做计划12、把相关操作放到一起13、实现特定的重构

防御式驾驶：你永远不能确定另外一位司机将要做什么。你要承担其保护自己的责任，哪怕是其他司机犯的错误。防御式编程的主要思想：子程序应该不因传入错误数据而被破坏，哪怕是有其他子程序产生的错误数据。 8.1 保护数据免遭非法输入数据的破坏1、检查所有来源于子程序外部的数据的值。2、检查所有输入参数的值。3、决定如何处理错误的输入数据库。 8.2 断言断言是指在开发期间

第七章，高质量的子程序前言子程序是为实现一个特定的目的而编写的一个可被调用的方法或过程。7.1 创建子程序的正当的理由1、  降低复杂度。当内部循环或内部嵌套层次很深的时候，就要考虑从子程序中提取出新的子程序了。子程序以其抽象，封装，信息、细节的隐藏来实现管理复杂度的功能。2、  引入中间、易懂的抽象。通过命名将一段代码重组织，使其更易理解。3、  避免代码重复。4、

第九章，伪代码编程过程9.1 创建类和子程序的步骤概述        创建一个类可以有多种不同的方式，但一般而言这都是一个迭代过程，先对一个类做总体设计，列出这个类内部的特定子程序，创建这些子程序，然后从整个上复查这个类的构建结果。创建一个类的步骤1、  创建类的总体设计：设计一个类的过程中包含一些特有的设计任务——定义类的特定职责，定义类说要隐藏的“秘密”，以及精确的定义

变量名的力量11.1选择好变量名的注意事项       你可不能像给狗取名字那样给变量命名----仅仅因为它很可爱或者听上去不错。狗和狗的名字不一样，它们是不同的东西，变量和变量名就本质而言却是同一事物。这样一来，变量的好与坏就在很大程度上取决于它的命名的好坏。在给变量命名的时候需要小心谨慎。 最重要的命名注意事项       为变量命名时最重要的考虑事项是，该名字要完全，准确

第十章， 使用变量的一般事项前言利用构建活动来填补需求和架构中存在的细小间隙是一种行之有效的做法，但把蓝图设计得精细到已经能完全展现出所有的细节则实在是一种低效的做法。10.1 数据认知创建数据的第一步是了解所要创建的数据的种类。10.2 轻松掌握变量定义隐式声明：是指你在使用一个未定义的变量的时候，编译器会自动为你声明此变量。隐式变量声明对任何一种语言来说都是最具危险

常见设计模式模式描述Abstract Factory(抽象工厂)通过指定对象组的种类而非单个对象的类型来支持创建一组相关的对象Adapter(适配器)把一个类的接口转变成为另外一个接口Bridge(桥接)把接口和实现分离开来，使它们可以独立的变化莫测Composite(组合)创建一个包含其他同类对象的对象，使得

主要的构建实践核对表：编码  1、 你有没有确定，多少设计工作将要预先进行，多少设计工作在键盘上进行（在编写代码的同时）？  2、 你有没有规定诸如名称、注释、代码格式等“编码约定”？  3、 你有没有规定特定的由软件架构确定的编码实践，比如如何处理错误条件、如何处理安全性事项、对于类接口有哪些约定、可重用的代码遵循哪些标准、在编码时考虑多少性能因素等？

读《代码大全》笔记，需求核对表：针对功能需求：1．是否详细定义了系统的全部输入，包括其来源、精度、取值范围、出现频率等？2．是否详细定义了系统的全部输出，包括其目的地、精度、取值范围、出现频率格式等？3．是否详细定义了所有的输出格式(如：web页面、报表等)？4．是否详细定义了所有硬件及软件的外部接口？5．是否详细定义了全部外部通信接口，包括

WMV网页播放器代码详解 WMV是流媒体,用专门的代码播放,效果会更好一些.这里只举WMV（MediaPlayer9.0及以后）的网页内嵌播放器代码。(默认0为否,-1或1为是)程序代码：                                                                                 http://www.XXX.com/

 1、深刻理解程序各句法的特点 2、乘法 左移 除法 右移（除数要是2的幂） 3、尽量用数学公式简化如求1-N的整数和（n+1)*n/2 4、表达式折叠如：x = x + 1 ；x += 1 5、判断的语句优化，概率性高的提前 6、switch 优化 if elseif 在只有一个判断多值分支条件下有switch代替if多分支 7、循环优化，

在制作网页以及编程的时候，适当的进行注释，不仅使自己的思路清晰，极大地减轻了维护的难度，而且方便项目组其他人了解你的代码，方便对代码的理解以及修改等，但最近在用div+css布局时，经常会遇到一些意想不到的麻烦，而这些麻烦在解决的过程中居然都是注释所引起的。麻烦一：注释所引起的文字溢出  图1这个是比较常见的问题，例如上图1中，多出的“地图”两个字就是由于注释所引起的，去除

想必大家都注意到的不循环滚动，所以出现了很多替代脚本，或iframe或JS输出，不管怎么做，都略显麻烦。下面说一下这个相对简单的实现思路：一个设定宽度并且隐藏超出它宽度的内容的容器demo，里面放demo1和 demo2，demo1是滚动内容,demo2为demo1的直接克隆，通过不断改变demo1的scrollTop或者scrollLeft达到滚动的目的，当滚动至demo1与demo2的交界处时

自动备份基本思路是windows自带的计划任务+winrar压缩工具+BAT自动批处理。在自动批处理文件里用winrar命令方式写要要备份的命令行，加把这批处理加了系统的计划任务里，其实说起来比较简单，但要基本功扎实，批处理文件的编写，winrar命令行参数熟悉，计划任务的设置等。下面是我把我的备份方案：1、问题：对网站的文件进行备份，同时也要备份网站的数据库，我的数据

你是PHP菜鸟，如果你：1. 不会利用如phpDoc这样的工具来恰当地注释你的代码2. 对优秀的集成开发环境如Zend Studio或Eclipse PDT视而不见3. 从未用过任何形式的版本控制系统，如Subclipse4. 不采用某种编码与命名标准，以及通用约定，不能在项目开发周期里贯彻落实5. 不使用统一开发方式6. 不转换（或）也不验证某些输入或SQL查询串（译注：参考PHP相关函数）

一、关于工作与生活　　我有个有趣的观察，外企公司多的是25-35岁的白领，40岁以上的员工很少，二三十岁的外企员工是意气风发的，但外企公司40岁附近的经理人是很尴尬的。我见过的40岁附近的外企经理人大多在一直跳槽，最后大多跳到民企，比方说，唐骏。外企员工的成功很大程度上是公司的成功，并非个人的成功，西门子的确比国美大，但并不代表西门子中国经理比国美的老板强，甚至可以说差得很远。而进外企

无论现在看帖的你怎样看待这个问题，我个人认为动漫世界终究不是完美的。 世界是有缺憾的，所谓残缺才是美。世上没有完美的事物，包括完美的人。 而从火影忍者的世界中，我看到了当今社会的一些影子。 所以火影创造出的世界不完美，而不完美才是美。 因此我爱火影，在火影中可以学到很多东西。 也许是我偏执，完美与否往往仅隔一线。 废话不多说了，乱弹开始，如果不喜欢这一话题的，请点网页右上方的小叉，谢谢！ 1.

针对各架构主题  1、 程序的整体组织结构是否清晰？是否包含一个良好的架构全局观（及其理由）？  2、 是否明确定义了主要的构造块（包括每个构造块的职责范围及与其他构造块的接口）？  3、 是否明显涵盖了“需求”中列出的所有功能（每个功能对应的构造块不太多也不太少）？  4、 是否描述并论证了那些最关键的类？  5、 是否描述并论证了数据设计？  6

程序员的时间换算表----为什么程序员不擅长估算时间原文链接：Programmer Time Translation Cheatsheet -or- Why Programmers Are Bad at Estimating Times一个曾经与我一起工作过的经验丰富的项目经理声称，他拿到程序员的时间估算以后，先将它乘以π，然后转化下一个时间数量级后，才能得到真正的值。1 天转化成3.