本章内容: 揭秘前端开发工程师 欲精一行,必先通十行 增加代码的可读性--注释 提高重用性--公共组件和私有组件的维护 冗余和精简的矛盾--选择集中还是选择分散 磨刀不误砍柴工--前期的构思很重要 制订规范 团队合作最大的难度不是技术,是人 揭秘前端开发工程师 CSS布局是前端开发工程师的基本功,一定要熟练: 不仅要会使用原生的JavaScript,还要会是使用JavaScript类库和Ajax; 了解一门后台语言 1.有助于编写方便服务端工程师套脚本的模板: 2.在写Ajax应用的时候,可以自…

本章内容: 糟糕的页面实现,头疼的维护工作 Web标准--结构.样式和行为的分离 前端的现状 打造高品质的前端代码,提高代码的可维护性--精简.重用.有序 糟糕的页面实现,头疼的维护工作 工作中最大的考验和最不可回避的问题就是“变化”.我们不仅要实现需求,更重要的是考虑实现代码的可维护性,为未来可能出现的“变化”,提前做好准备. 所有老网页的典型毛病--新手可能会有的问题,中手也可能会有: div和table布局混用 html标签名有大写.小写 html标签属性有的加了引号,有的没加引号 历史遗…

本章内容: 标签的语义 为什么要使用语义化标签 如何确定你的标签是否语义良好 常见模块你真的很了解吗 标签的语义 HTML标签的设计都是有语义考虑的,部分标签的中文翻译图示及本章内容参看:3.1 标签的语义.其中div和span是没有语义的,它们只是分别用作块儿级元素和行内元素的区域分割符. 为什么要使用语义化标签 搜索引擎看不到视觉效果,看到的只是代码,只能通过标签来判断内容的语义. 专注于结构:通过标签可以知道“这是个标题”.“这是个段落”,等等. CSS布局的一个误区:只要不是table布…

最近老大给我们买来一些技术方面的书籍,其实很少搬着一本书好好的完整的看完过,每每看电子档的,也是打游击式的看看这章,瞅瞅那章,在那5本书中挑了一本比较单薄的<编写高质量代码web前端开发修炼之道>,看完觉得不错,它从一个整体架构上来说明如何编写高质量代码,而细处也着重说明一些比较重要的技术点,给人一种从高处俯瞰web开发.很完整的感觉,在这感谢老大,谢谢他让我们不停的进步着.下面是我看书过程中的笔记. 第一章:从网站重构说起 没什么好说的,从一个糟糕的老网页实例说明需要将web的结构,样式和行…

第一章 1.Web标准由一系列标准组合而成,核心理念是将网页的结构,样式和行为分离,所以分为三大部分:结构标准,样式标准和行为标准.结构标准包括XML标准,XHTML标准,HTML标准:样式标准指CSS标准:行为标准主要包括DOM标准和ECMAScript标准. 第二章 1.注释增加代码的可读性:提高重用性--公共组件和私有组件的维护:冗余or精简:前期的构思:制定规范:团队合作 第三章 1.语义化标签 2.table布局的缺点:代码量大,结构混乱:标签语义不明确,对搜索引擎不友好. 3.CSS…

这一节是继上一节高质量的Javascript 7)编程实用技巧 1:弹性 从 一个标签区和内容区的实例(就是点击不同的标签菜单显示不同的内容块)来说明不需要每个tabmenu都设置onclick事件,为了让程序更有弹性,可 以将所有的点击时间封装成一个函数,变化的标签作为参数传入实现点击不同的标签显示对应的内容块,这样标签的数量可自适应,可增可减,而js代码可以不用 变动,只需要修改html的标签就可以.-------------这点我想做过项目的伙伴们都能深深的体会到. 琐碎知识点: js 一…

第五章:高质量的Javascript 这章的内容我看的最久,这是跟我js基础没打好有着莫大的关系,但是还是耐着性子看完了, 不懂的东西都是百度上搜索,理解后再继续.下面是记录下来的笔记. 1)如何避免JS冲突 A:匿名函数 在多人合作一个网站时,每个人都会写自己的JS代码,定义变量的时候有可能会引起命名冲突,如何避免这种冲突隐患呢? 一种最简单有效的办法是“匿名函数”将脚本包起来,让变量的作用域控制在匿名函数之内. 匿名函数:(function (){})() 前面的括号内是函数体,后面的()表…

第四章:高质量的css 1)怪异模式和标准模式 在标准模式中,浏览器根据规范表现页面:而怪异模式通常模拟老式浏览器的行为以防止老站点无法工作. 他们两者之间的差异比较典型的表现在IE对盒模型的解析:在标准模式中,网页元素的宽度=padding+border+width;而在怪异模式中,width本身就包括了padding和border. 在怪异模式中:设定width,然后margin:0 auto;是无法居中的.标准模式中可以正常工作. 于是我们尽量避免怪异模式,而选用标准模式,这样就出现了DT…

结构样式行为的分离 结构标准包括XML标准.XHTML标准.HTML标准:样式标准有CSS标准:行为标准主要包括DOM标准和ECMAScript标准. 通常的项目会按照如上的方式进行分离,但自己曾今做过的一个项目整个网站架构是按照模块进行分离的: 需求:设计一个网站,该网站的用途是根据用户需求生成网站, 例如一个企业展示网站,需要主页A,主页A包括布局(例如头部容器,导航容器,焦点图容器,然后之后再一个三列的容器,然后再页尾容器). 每个容器中的模块都是根据用户需求加载,该页面A主要加载的模块:…

JavaScript是基于原型的语言,通过new实例化出来的对象,其属性和行为来自于两部分,一部分来自于构造函数,另一部分是来自于原型.构造函数中定义的属性和行为的优先级比原型中定义的属性和优先级高,如果构造函数和原型定义了同名的属性和行为,构造函数中的属性和行为会覆盖原型中的同名的属性和行为.如下图—— 当我们声明一个类时,其实同时生成了一个对应的原型,例如我们定义Animal这个类时,会生成一个与Animal类对应的原型,通过Animal.prototype可以指向这个原型,原型可以通过co…

我觉得还蛮实用的一本,推荐看看,主要涉及到这些: 标签语义化.css模块化. css的一些东西,比如haslayout 文档流,还有如何实现水平.垂直居中. js代码组织与js分层.js压缩 编码规范.注释规范.命名规范…

@charset "utf-8"; /*CSS reset*/ html{color:#000;background:#FFF;} body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,button,textarea,p,blockquote,th,td{margin:0;padding:0;} table{border-collapse:collapse;border-spac…

1.怪异模式和DTD 标准模式:浏览器根据规范表现页面 怪异模式:模拟老浏览器行为防止老站点无法工作(为了兼容老式浏览器的代码),如果漏写DTD(Document Type Definition文档定义类型)声明,firefox会按照标准模式来解析网页,但在IE中就会触发怪异模式. 两种模式的差异比较大,比较典型的是IE对盒模型的解析:在标准模式中,网页元素的宽度是由padding.border.width三者的宽度相加决定的,而在怪异模式中,width本身就包括了padding和border的…

原创地址:http://www.cnblogs.com/bnbqian/p/3735565.html 转载请注明出处 今天我们要读的书是Web 前端开发修炼之道 第1章 从网站重构说起 1.1 糟糕的实现,头疼的维护 曾经, 网页代码很乱. 1.2 Web 标准,结构,样式和行为的分离 分离了. 1.3 前端的现状 人员参差不齐. 小结: 本章相当于引论. 第2章 团队合作 小结: 团队和沟通这个永远是个凑字数的好话题. 第3章 高质量的HTML 3.1 标签的语义 标签是有语义的. HTML…

编写高质量代码改善python程序91个建议学习 第一章 建议1:理解pythonic的相关概念 狭隘的理解:它是高级动态的脚本编程语言,拥有很多强大的库,是解释从上往下执行的 特点: 美胜丑,显胜隐,简胜杂,杂胜乱,平胜陡,疏胜密 python定义 #python排序 def quicksort(arr): less=[];greater=[] if len(arr)<=1: return arr pivot=arr.pop() for x in arr: if x<=pivot: less…

前言 这两周参加公司的新项目,采用封闭式开发(项目成员在会议室里开发),晚上加班到很晚,所以没时间和精力写原创博客了,今天就分享下这篇<编写高质量代码--Web前端开发修炼之道>读书笔记吧.     正文 欲精一行,必先通十行. 在前端开发这个领域,一专多能更是非常必要的. table布局缺点: 代码量大,结构混乱: 标签语义不明确,对搜索引擎不友好. css布局:div+css,或者(x)html+css. 代码量少.结构精简.语义清新. 代码量少,浏览器端下载时间就会更短: 语义清晰就会对…

编写高质量代码:Web 前端开发修炼之道/曹刘阳著. —北京:机械工业出版社,2010.5 第一版 涉及到的知识点: 1. CSS Sprites 在国内很多人叫css精灵,是一种网页图片应用处理方式.它允许你将一个页面涉及到的所有零星图片都包含到一张大图中去,这样一来,当访问该页面时,载入的图片就不会像以前那样一幅一幅地慢慢显示出来了.对于当前网络流行的速度而言,不高于200KB的单张图片的所需载入时间基本是差不多的,所以无需顾忌这个问题. 2. border-collapse 属性设置表格的…

编写高质量代码:改善Java程序的151个建议(第一章:JAVA开发中通用的方法和准则) 目录 建议1: 不要在常量和变量中出现易混淆的字母 建议2: 莫让常量蜕变成变量 建议3: 三元操作符的类型务必一致 建议4: 避免带有变长参数的方法重载 建议5: 别让null值和空值威胁到变长方法 建议6:覆写变长方法也循规蹈矩 建议7:警惕自增的陷阱 建议8:不要让旧语法困扰你 建议9:少用静态导入 建议10:不要在本类中覆盖静态导入的变量和方法 建议11:养成良好习惯,显示声明UID 建议12:避免…

编写高质量代码:改善Java程序的151个建议(第二章:基本类型) 目录 建议21:用偶判断,不用奇判断 建议22:用整数类型处理货币 建议23:不要让类型默默转换 建议24:边界还是边界 建议25:不要让四舍五入亏了一方 建议26:提防包装类型的null值 建议27:谨慎包装类型的大小比较 建议28:优先使用整型池 建议29:优先选择基本类型 建议30:不要随便设置随机种子 建议21:用偶判断,不用奇判断 判断一个数是奇数还是偶数是小学里的基本知识,能够被2整除的整数是偶数,不能被2整除的数是…

前言 由于最近工作重心的转移,原来和几个同事一起开发的项目也已经上线了,而新项目就是在现有的项目基础上进行优化延伸扩展.打个比方,现在已经上线的项目行政案件的Web管理网站(代码还没那么多相比较即将要做的刑事案件吧),而新项目是刑事案件的Web管理网站,之后行政和刑事这两个网站是要合并的.前段时间也和同事以及上司的讨论结果就是新建一套项目,考虑将原有系统各种组件进行重新封装.优化.提升扩展,然后先开发刑事案件的网站,待刑事案件开发完毕将原有项目按照刑事案件的思路重新整合. 最近刚开始进行查看老代…

原文发表在我的博客主页,转载请注明出处! 建议二十八:区别对待可变对象和不可变对象 python中一切皆对象,每一个对象都有一个唯一的标识符(id()).类型(type())以及值,对象根据其值能否修改分为可变对象和不可变对象,其中数字.字符串.元组属于不可变对象,字典以及列表.字节数组属于可变对象. 来看一段程序: class Student(object): def __init__(self,name,course=[]): self.name = name self.course = c…

原文发表在我的博客主页,转载请注明出处! 建议四十一:一般情况下使用ElementTree解析XML python中解析XML文件最广为人知的两个模块是xml.dom.minidom和xml.sax,作为主要解析XML方法的两种实现,DOM需要将整个XML文件加载到内存中并解析为一棵树,简单但是内存消耗大:SAX是基于事件驱动的,虽不需要全部装入XML文件,但是处理过程复杂.一般情况下选择ElementTree便可以,cElementTree是其Cython实现,速度更快,消耗内存更少,性能上更…

今天是我看<编写高质量代码:改善C#程序的157个建议>第二遍的时候了,看完这本书的确是受益匪浅,学到了很多东西,也明白了很多道理. 里面的代码我每个都调试了一遍,有时候是有些出入的,可能是作者写的书比较早,使用的开发环境比较旧,也许是我的学习还不到家,今天在看建议17的时候,发现了一些小问题,不是很大,是小问题,记录下来,当别人看到的时候可以起到修正的作用. 可能很多人和我一样,没有太在乎for和foreach的区别,也没有深究其底层发生的一些东西,看了文章才发现里面的东西还真是不少. 好了…

 题记:这是自己的观后感,工作两年了,本来打算好好学习设计模式,或者作为客户端深入了解GPU编程的,但是突然发现还有这么一本书. <编写高质量代码改善建议>,感觉这正是自己需要的. 我是做游戏开发的,最近一段时间工作,接触到了数学编程,涉及到大量的计算,策划那边增改需求也很多,加上我的项目对性能要求很高.微量的计算影响到 性能.所以对代码质量要求很高,明显自己的代码质量已经不达标了.所以,我还是打牢固基础,编写高质量代码才是王道. 之前工作经历了很多其他人的代码,什么工作三四年,甚至四五年的代…

编写高质量代码:改善Java程序的151个建议 --[36~51] 工具类不可实例化 工具类的方法和属性都是静态的,不需要生成实例即可访 问,而且JDK也做了很好的处理,由于不希望被初始化,于是就设置了构造函数private的访问权限,表示出了类本身之外,谁都不能产生一个实例: class UtilsClazz{ public UtilsClazz(){ throw new Error("Don't instantiate "+getClass()); } } 避免对象的浅拷贝 sup…

最近读了陆敏技写的一本书<<编写高质量代码  改善C#程序的157个建议>>书写的很好.我还看了他的博客http://www.cnblogs.com/luminji . 前面部分选择什么,该怎么用我没有怎么消化.看了他写的一篇关于自动化测试的工具,能够录下人的操作,然后可以在多台机器上调用,因为是windows开发的,我没有亲手实验,先记录在这里,以后要用可以找,"Code UI Automation" 文中大量都是通过对比IL代码,来区分哪个方案更好.我在看&…

建议155:随生产代码一起提交单元测试代码 首先提出一个问题:我们害怕修改代码吗?是否曾经无数次面对乱糟糟的代码,下决心进行重构,然后在一个月后的某个周一,却收到来自测试版的报告:新的版本,没有之前的版本稳定,性能也更差了,Bug似乎也变多了.也就是说,重构的代码看上去质量更高了,可实际测试结果却不如人意. 几乎每个程序员都因为此类问题纠结过.我们要修改的代码也许来自某些不负责任或经验欠佳的程序员,也许这些代码是自己一年前写的,但是看上去已经惨不忍睹.我们想要修改这些代码,却担心重构出别的问题.…

建议154:不要过度设计,在敏捷中体会重构的乐趣 有时候,我们不得不随时更改软件的设计: 如果项目是针对某个大型机构的,不同级别的软件使用者,会提出不同的需求,或者随着关键岗位人员的更替,需求也会随个人意志有所变更. 如果竞争对手增加了新需求,我们也不得不为正在研发的新产品调整设计方案. 刚开始的架构太糟糕了,这可能源于设计经验的不足或者架构师的不负责任. 以上分别从外部和内部描述了必须修改需求和设计的几种场景.也就是说,在软件开发过程中,变化几乎总会发生. 为了捕捉需求上的不断变化,软件开发必…

建议152:最少,甚至是不要注释 以往,我们在代码中不写上几行注释,就会被认为是钟不负责任的态度.现在,这种观点正在改变.试想,如果我们所有的命名全部采用有意义的单词或词组,注释还有多少存在的价值. 即便再详细的注释也不能优化糟糕的代码.并且注释往往不会随着代码的重构自动更新,有时候我们可能会在修改代码后忘记更新那段用来表达最初意图的文字了.所以,尽量抛弃注释吧,除非我们觉得只有良好的代码逻辑和命名仍旧不足以表达意图. 当然,有些注释可能不得不加,如一些版权信息.另外,如果我们正在开发公共API…

建议148:不重复代码 如果发现重复的代码,则意味着我们需要整顿一下,在继续前进. 重复的代码让我们的软件行为不一致.举例来说,如果存在两处相同的加密代码.结果在某一天,我们发现加密代码有个小Bug,然后修改了它,却又忘记了角落里的某处存在着一份相同的代码,那么这个Bug就会隐藏起来. 让我们重现这个例子: void PagerEncrypt() { //加密代码 } void AnswerEncrypt() { //相同的加密代码 } 在这段代码中,方法PagerEncrypt和AnswerE…