Blog

前面一篇文章说了，javascript给我们带来很多的好处，但是它却是搜索爬虫的一道墙，对网站的seo非常不利。那么怎么在不影响网页效果而又对搜索引擎友好的前提下使用JavaScript，又不影响SEO效果呢？ 1、要避免导航及网页链接使用JavaScript。导航和链接是搜索爬虫抓取网页的赖以生存之本，如果搜索爬虫无法抓取网页，则代表了网页不会出现在索引结果中，也就没有排名了。如果有希望蜘蛛抓取的目标页面需要转向，不要使用javascript脚本进行跳转，因为这样做的话蜘蛛完全无法获取到目标页面的地址，采用noscript标记进行目标url指定是一个好办法，因为蜘蛛能够正确识别noscript标记，并且一般情况下不会对浏览器显示产生影响。 2、尽量避免用JavaScript输出内容。特别是与关键词相关部分的内容，尽可能避免使用JavaScript来展现，否则毫无疑问是要降低关键词密度的。虽然ajax是一个好技术，尤其是在一些需要实时性要求比较高的系统中，可以很好的缓解服务器的压力，也可以实现需求时才查询取出数据内容，还可以对框架布局不产生影响，实现更炫的网页效果，但ajax的核心是通过javascript脚本来在需要时获取数据的技术，这样数据就不是在页面展示时就加载完成，那么就出现了第一项中所说的，蜘蛛获取不到这些内容，自然就无法抓取和爬行链接。本项内容可以参考“AJAX技术与SEO”和“QQ空间不能用来做SEO外链”。 3、如果上面两项无论如何都要坚持的话，也不是不行，可以做两套ui，一套有丰富的javascript供用户体验，另一套则为搜索引擎提供爬取支持，但这对维护来说就增加了非常大的难度。 以上的一些方法是消除JavaScript对搜索引擎的不利影响，搜索引擎无法对JavaScript进行识别（虽然Google目前能够做到对少量简单的JavaScript代码做出辨别，但那也应该只是Document write之类的简单代码）。那么换一个角度来说，我们完全可以利用JavaScript来过滤一些垃信息。

Javascript是一种客户端脚本语言，主要目的是为了解决服务器端语言遗留的速度问题，为客户提供更流畅的浏览效果，Javascript不仅仅可以减轻系统的负担，还可以提供各种各样华丽的特效，人性化的交互，几乎所有大型网站都用到了javascript。 然而JavaScript却在SEO中是一个很头疼的问题，一方面我们在网页制作中需要使用JavaScript来实现绚丽的特效，而一方面JavaScript又会对搜索引擎的抓取分析造成不好的影响。 Google的官方文档中很清楚的说明，如果在html中过多的使用 JavaScript、Cookie、会话 ID、框架、DHTML 或 Flash 等复杂功能会使搜索引擎抓取工具在抓取网站时可能会遇到问题。 百度虽然没有明确的说明，但是经过大量的实践，百度也是无法对JavaScript进行识别的。这样就有一个问题，网页中过多的JavaScript代码无疑是对搜索引擎分析网页内容增加难度。 如果网页中的链接已经主体内容也是由不少JavaScript组成输出的话，那么搜索引擎甚至无法顺着链接去抓取网页，也无法获取网页内容。这样的话，过多的使用JavaScript就造成了以下的影响： 1、对搜索引擎分析网页内容造成了干扰。2、严重妨碍搜索引擎抓取网页。3、影响由链接产生的网页权重分布。 总之Javascript给我们带来很多好处的时候，也对搜索引擎带来很大阻碍，所以我们要仔细考虑如何让Javascript和seo怎么更好的合作。

单例模式和工厂方法可以说是在软件设计模式中目前用得比较多的，目前在公司做的项目也经常会接触到，他们都实现了类的创建封装，让代码维护变得更加简单。 首先说单例模式，单例模式可以保证整个系统中一个类只有一个实例，而且该实例易于外界访问，从而方便对实例个数的控制并节约系统资源，如果只希望在系统中某个类的对象有且只能存在一个，单例模式是最好的解决方案。 对于某些系统来说，有些类只有一个实例很重要，如最常见的数据库连接配置对象。它在整个系统中只需要一个就足够了，多了就会产生很多不必要的开销，造成资源浪费。 工厂方法则非常复杂，这里只说比较简单的简单工厂模式，而感兴趣的读者可以去看看工厂方法模式。从设计模式的类型上来说，单例模式和简单工厂模式都是属于创建型模式，简单工厂模式又叫做静态工厂方法，是由一个工厂对象决定创建出哪一种产品类的实例。 简单工厂模式一般会分三个角色，第一个工厂（Creator）角色，它是负责实现创建所有实例（产品）的内部逻辑。工厂类可以被外界直接调用，创建所需的产品对象。第二个抽象产品（Product）角色，为所有不同类型的产品，定义一种借口。第三个实例产品（Concrete Product）角色，是简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。 单例模式和工厂方法都为实例对象的创建提供了封装特性，有利于整个软件体系结构的优化。但是这些模式亦不能乱用，比如单例模式，在一个系统中如果需要有多个实例的时候，使用单例模式甚至会出现功能错误。所以在使用设计模式的时候我们需要多方面考虑，让模式为我们带来真正意义上的优化。 简单工厂图示

设计模式，英文名为 Design pattern，它起源于建筑学，由Erich Gamma等人在1990年代从建筑设计领域引入到计算机科学的。它是对软件设计中普遍存在也是反复出现的各种问题，所提出的软件解决方案。 经过这么久的编码，让我越来越感觉到设计模式的重要性，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样，要是砌得不好，仅仅是想改变一下大厦房中的格局，就要把整栋大厦推倒重建，当然，这是万万不可的。 如今的设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结，使用设计模式可重用代码、让代码更容易被他人理解、保证代码可靠性。一个好的设计，往往会包含各种各样的设计模式，它就像一个可以活动的大厦一样，自由转动大厦里面的各个房间，改变他们的格局，而不会让大厦倒塌。 现在简单介绍一下面向对象的几个原则，为什么会有这些原则？根本原因就是为了代码复用，增加可维护性。其中一项开闭原则具有理想主义的色彩，它是面向对象设计的终极目标。而设计模式就是实现了这些原则，从而达到代码复用、增加可维护性的目的。 开闭原则：原文是："Software entities should be open for extension,but closed for modification"。就是说模块应对扩展开放，而对修改关闭。 里氏代换原则： 如果调用的是父类的话，那么换成子类也完全可以运行，反之则不成立。 依赖倒转原则：抽象不应该依赖于细节，细节应当依赖于抽象，要针对接口编程，而不是针对实现编程。即是抽象就像大的解决方案，细节是实施的具体方法。 接口隔离原则：定制服务的例子，每一个接口应该是一种角色，不多不少，不干不该干的事，该干的事都要干。 遵循着这些原则，设计模式已经被人们发展出最为常用的23种设计模式，这些模式已经非常成熟，得到大多数人的认可。目前我也在学习，可以说能够掌握的也就只有四种模式而已，但仅这四种也为我带来了很多思想，灵感，往后我将我掌握的这四种模式会与大家分享。 最后推荐一部好书：《软件秘笈：设计模式那点事》

做了几个月的项目了，意识到有时候技术并不是最为关键的东西，往往困扰我们的是平时开发最不关心的软件需求，需求的变化经常会导致技术的无用功。 一般人听到需求分析这个词都会很陌生，但是对于IT行业来说，却是一个非常至关重要的一个环节。一款软件、一个项目的好坏最根本的判断依据就是它是否满足客户、用户的需求，与需求背道而驰的东西可以说是彻彻底底的失败品。 既然需求分析那么重要，什么是需求分析呢，综合网络信息，我总结出需求分析是指对要解决的问题进行细致的分析，弄清楚问题的要求，包括需要输入什么数据，要得到什么结果，最后应输出什么。也可以说，在软件工程中的“需求分析”就是要确定计算机“做什么事情”。 也许有人会讲，为什么还要需求分析呢，口述说明一下不就行了。但问题是需求分析并不仅仅是告诉开发人员要做什么，它贯穿参与整个项目的各个人员，如测试人员。 简单的来说，需求分析有一下几个目标：1、对实现软件的功能做全面的描述，帮助用户判断实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前周密地、全面地思考软件需求；2、了解和描述软件实现所需的全部信息，为软件设计、确认和验证提供一个基准；3、为软件管理人员进行软件成本计价和编制软件开发计划书提供依据。 那么需求分析由什么组成呢，综合网络信息以及以前的项目经验，我总结出大概由以下这几部分组成：引言，综合描述，外部接口需求，系统功能需求，其他非功能需求，词汇表，数据定义，分析模型，待定问题等。 其中系统功能需求和数据定义至关重要，待定问题最好可以把模糊度降到最低，以确保开发的可用性。 最后需求分析的工作可以主要由以下几步组成： 1.分析用户活动，产生业务流程图 了解用户的业务活动和职能，搞清其处理流程（即业务流程）。如果一个处理比较复 杂，就要把处理分解成若干个子处理，使每个处理功能明确，界面清楚，分析之后画出用户 的业务流程图。 2.确定系统范围，产生系统关联图 这一步是确定系统的边界，在和用户经过充分讨论的基础上，确定计算机所能进行的数 据处理的范围，确定哪些工作由人工完成，哪些工作由计算机系统完成，即确定人机界面。 3.分析用户活动涉及的数据，产生数据流图 深入分析用户的业务处理，以数据流图形式表示出数据的流向和对数据所进行的加工。 数据流图（DataFlowDiagram，简记为DFD）是从“数据”和“对数据的加工”两方 面表达数据处理系统工作过程的一种图形表示法，具有直观、易于被用户和软件人员双方都 能理解的一种表达系统功能的描述方式。 最后推荐一本好书:掌握需求过程.

有段时间对项目做了重构，有不少感触，分享一下。 首先什么是重构，网上比较靠谱的一种说法是：重构（Refactoring）是指在不改变程序现有功能的基础上，通过调整程序的代码，改善程序的质量、性能、提高复用性、更易阅读。使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。 或许有人会问，在项目开始时多花些时间把所有设计都做好不是更好吗，为什么要以后花时间来重构呢？没错，谁都想这么做，但是一个完美得可以预见未来任何变化的设计，又或者说一个灵活得可以兼容一切扩展和改变的设计几乎是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法掌握控制每个细枝末节，其次是软件永远不变的就是变化，提出需求的用户往往会在软件成型后，才开始"品头论足"，因为设计人员毕竟不是先知先觉的神仙，所以功能的变化导致设计的调整再所难免。现在以"测试为先，持续重构"作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。 现在我们看两个问题：在不改变功能的情况下，去改变系统的实现方式，为什么要这么做？投入的精力不都用来满足客户最关心的需求，而是仅仅改变了软件的实现方式，这又是否是在浪费客户的投资呢？ 上述问题先不解答，我们带着问题思考一下。考虑到成本和时间等因素，当然不是所有的需求变化都要在软件系统中实现。但是总的说来，软件要适应需求的变化，以保持自己的生命力。这就产生了一种糟糕的现象：软件产品最初制造出来，是经过精心的设计，具有良好架构的。但是随着时间的发展、需求的变化，必须不断的修改原有的功能、追加新的功能，还免不了有一些缺陷需要修改，我们现在也时常遇到这种情况。为了实现变更，不可避免的要违反最初的设计构架。 经过一段时间以后，软件的架构就千疮百孔了。bug越来越多，越来越难维护，新的需求越来越难实现，软件的构架对新的需求渐渐的失去支持能力，而是成为一种制约。最后新需求的开发成本会超过开发一个新的软件的成本，这就是这个软件系统的生命走到尽头的时候。 现在我们可以很好的去解释问题了，重构就可以最大限度的避免这样一种现象。系统发展到一定阶段后，使用重构的方式，不改变系统的外部功能，只对内部的结构进行重新的整理。通过重构，不断的调整系统的结构，使系统对于需求的变更始终具有较强的适应能力。 通过重构可以达到以下目标：持续纠错和改进软件设计。重构和设计是相辅相成的，它和设计彼此互补。当然有了重构，预先的设计仍然还是不可缺的，但不必是最优的设计，只需要一个合理的解决方案就够了，拥有大的方向，如果没有重构、程序设计会逐渐腐败变质，愈来愈像断线的风筝，脱缰的野马无法控制。重构其实就是整理代码，让所有带着发散倾向的代码回归本位。 最后介绍一本好书：重构 --改善既有代码的设计