3866编号学习计划范文七篇

《3866编号学习计划范文七篇》由会员分享，可在线阅读，更多相关《3866编号学习计划范文七篇（29页珍藏版）》请在金锄头文库上搜索。

1、学习计划范文七篇 学习计划篇 1 网络学习是教师参加继续教育学习的重要途径，具有文 本学习不可比拟的优势，为充分发挥网络学习的优势，为更 好的完成20 xx 年上半年的学习的任务，现制定如下学习计 划： 一、抓好学习内容的时间安排 小学科学课教学指要 5 月 1 日 5 月 15 日学习绪论部分，内容包括“科学、 科学教育和小学科学教育的内涵”、 “正确理解标准的要 求” 、及“国际小学科学教育发展的基本趋势”，重点要理解 科学课标准 ，这对今后在实际课堂授课中有着重要的指 导意义。 5 月 16 日 5 月 31 日学习第一篇生命世界。这一篇共 包括 4 章的内容：多样的生物、生命的共同特征

2、、生物与环 境、健康与生活。 6 月 1 日 6 月 15 日学习第二篇物质世界。这一篇共包 括 3 章内容：物体与物质、运动 与 力、能量的表现形式。 6 月 16 日 6 月 30 日学习第三篇地球与宇宙。这一篇 共包括地球概貌与物质组成、地壳变动与地球运动、天空中 的星体。 新师德与教师教育 5、6 月份的每两周学一个专题，共计四个专题。 二、调节好学习方式及时间 充分抓好在校的空闲时间，在正常做好科学课授课、实 验室及档案的有关工作外，及时利用其散乱的时间到络学习 的内容。 利用在家的休息时间，每天晚上学习半个小时。 三、及时做好教研员留的作业。 当然，在学习过程中为了更深入理解网络内

3、容，要做好 学习笔记并结合自己的教学实践写出心得体会，这是提升自 己能力的一个重要手段。 学习计划篇 2 Web前端开发十日谈一直想写这篇“十日谈”，聊聊我对 Web前端开发的体会， 顺便解答下周围不少人的困惑和迷惘。 我不打算聊太多技术，我想，通过技术的历练，得到的反思 应当更重要。我一直认为自己是“初级”前端开发工程师， 一方面我入道尚浅，只有短短几年，另一方面我自知对技术 的钻研并不深入， 可能是由于环境的原因，当然最重要的是， 我幸运的参与到互联网崛起的浪潮之巅。时势造就了一批技 能薄弱但备受追捧的“弄潮者”，这在很大程度上影响我们 对“技术本质”的洞察力，多年来也一直未有成体系的“前

4、 端技术”布道佳作，以至于当下多数人对前端技术的了解， 盖始于表述并不严谨的岗位招聘描述，而这正恰恰反映了 Web前端开发对自身的模糊定位。对于很多Web前端工程师 来说，初尝禁果的快感无法持续很久，就陷入一轮又一轮的 迷惘，思索自己的职业规划，试图寻找到适合自己的成长道 路、看清自身技能的瓶颈，寻找突破。但遗憾的是，Web 前 端技术被广泛接纳时日尚短，没有多少励志的成功样板可供 遵循。然而情况不总是这么糟，毕竟 Web前端技术是一门 “技 术” ，和计算机科学系出同门，只是因为互联网的高速崛起 而被蒙上了迷雾，遮住了双眼，让我们傻傻看不清时局。 那么，如何定义Web前端技术岗位边界？Web

5、前端技术 的价值体现在何处？前端工程师的价值仅仅体现在物以稀 为贵吗？前端工程师的初级、中级、高级和专家之间到底如 何界定？当前“我”处在什么位置？接下来的路子应当怎样 走？何谓前端技术之 “道”？我想多数人都思考过这些问题， 本篇“十日谈”里的观点可能有些偏激，但抛砖引玉，读者 权且把这些言论当作一个引子吧。 第一日：初尝禁果 万物生灵、阳光雨露盖源于造物之初的工开物，我们无法 想象上帝创造光明之前的世界模样。但幸运的是，前端开发 没有神祗般的诡魅。这个技术工种的孕育、定型、发展自有 轨迹，也颇有渊源，当然，这非常容易理解。不严格的讲， 在杨致远和费罗在斯坦福大学的机房里撺掇出Yahoo!

6、时， Web前端技术就已经开始进入公众视野，只不过当时没有一 个响亮的名字。从那时起，“基于浏览器端的开发”就成了 软件开发的新的分支，这也是Web前端技术的核心，即不论 何时何地何种系统以及怎样的设备，但凡基于浏览器，都是 Web前端开发的范畴 （当然， 这个定义很狭隘， 下文会提到）。 在 20 xx 年之后浏览器技术渐渐成熟，Web产品也越来越 丰富，中国有大批年轻人开始接触互联网，有一点需要注意， 大部分人接触互联网不是始于对浏览器功能的好奇，而是被 浏览器窗口内的丰富内容所吸引，我们的思维模式从一开始 就被限制在一个小窗口之内， 以至于很长时间内我们将“视觉”认为是一种“功能”， W

7、eb产品无非是用来展现信息之用。起初的入行者无一例外 对“视觉”的关注超过了对“内容”的重视，先让页面看起 来漂亮，去关注html/css，沿着“视觉呈现”的思路，继续 深入下去。因此，这类人是被“视觉”所吸引，从切页面入 行，着迷于结构化的html 和书写工整的css，喜欢简洁优雅 的 UI 和工整的页面设计，之后开始接触视觉特效，并使用 jQuery 来实现视觉特效，以此为线索，开始深入研究Dom 、 Bom和浏览器的渲染机制等，html/css在这些人手中就像进 攻兵器，而JavaScript则更如防守的盾牌。 还有另外一群人从另一条道路接触Web前端，即工程师 转行做前端，他们有较多的

8、后言开发背景，从读写数据 开始，渐渐触及浏览器端，接触JavaScript库，起初是在 html 代码上加 js 逻辑，后来开始涉及html 和 css，他们喜 欢 OO 、逻辑清晰、结构悦目的代码，更关注界面背后的“程 序语言”和数据逻辑。html/css在这些人手中则更像盾牌， 而 JavaScript更如进攻的兵器。 应当说这两类人是互补的，他们各自了解浏览器本质的 一部分，一拨人对渲染引擎了如指掌，另一拨人则将JS 引 擎奉为至宝，其实任何一部分的优势发挥出来都能做出精 品。大部分前端工程师都能从这两条渊源中找到自己的影 子。但，这两类人的思维模式和观点是如此不同，以至于形 成了一些不

9、必要的对抗，比如在某些公司，干脆将Web前端 技术一分为二， “切页面的”和“写js的” 。这样做看上去 明确了分工提高了效率，但他对员工的职业发展带来巨大伤 害。在第二日“科班秀才”中会有进一步讨论。 我应该属于第二类，即在学校正儿八经的学习C/Java 和 C#之类，以为大学毕业后能去做ERP软件、桌面软件或者 进某些通信公司写TCP/IP 相关的程序。校园招聘时选择了 中国雅虎，因为当年（08 年）雅虎还是有一点儿名气，而且 我听说雅虎比较算技术流的公司自此就上了贼船，一发 不可收拾。 在雅虎的这段时间，我有幸接触到一股正气凛然的技术 流派，也形成了我对前端技术的一些基本看法，这些基本观

10、 点一直影响我至今。 【优雅的学院派】 当年雅虎的技术流派正如日中天，拥有众多“之父”级 的高人，所营造出的Hack 氛围实在让人陶醉的无法自拔， 那段时间我甚至宁愿加班到深夜阅读海量的文档和源代码， 感觉真的很舒服，我深深的被雅虎工程师这种低调务实、精 工细琢的“服务精神”所打动，而这种不起眼的优秀品质很 大程度的影响雅虎产品的用户体验和高质量的技术输出。那 么，何谓“服务精神”？即你所做的东西是服务于人的，要 么是产品客户、要么是接手你项目的人、要么是使用你开发 的功能的人，所以技术文档成为伴随代码的标配。因此，工 程师之间通过代码就能做到心有灵犀的沟通。这是工程师的 一项基本素质，即，思

11、路清晰的完成项目，且配备 了有价值的技术文档，如果你的程序是给其他程序员用 的，则更要如此，就好比你制造一款家电都要配备说明书一 样。因此， YDN成了当时最受全球程序员最喜爱的技术文档 库，这种优雅务实的“学院气息”让人感觉独具魅力。 让人感觉奇怪的是，在中文社区始终未见这种学院派。 甚至在具有先天开源优势的Web前端技术社区里也是波澜不 惊，可见写一篇好的技术文案真的比登天还难。我所见到的 大部分所谓文档索性把代码里输出数据的语句块拷贝粘贴 出来，至于为什么数据格式要设计成这样、如果字段有修改 怎么做、编码解码要求如何等等关键信息只字不提，或者开 发者也没想过这些问题呢。因此，我们一直在强

12、调代码的质 量和可维护性，但一直以来都未见效，盖源于缺少这种“服 务”意识的灌输。这种意识在下文中还会多次提到，因为它 能影响你做事的每个细节，是最应当首先突破的思想纠结。 除了意识问题，另一方面是技术问题，即文笔。这也是 工程师最瞧不上眼的问题，难以置信这竟然是阻碍工程师突 破瓶颈的关键所在。我已看到过数不清的人在晋升这道关卡 吃了大亏，很多工程师技术实力很强，但就是表达不出来， 要么罗列一大堆信息毫无重点、要么毫无趣味的讲代码细 节，不知云云。除非你走狗屎运碰到一个懂技术的老板，否 则真的没办法逃脱码农的宿命。但大部分人还振振有词不以 为然。而在Web前端开发领域情况更甚。前端工程师是最喜

13、 欢搞重构的，但在快节奏的需求面前，你很难用“提高了可 维护性”、 “提升了性能”这类虚无缥缈的词藻为自己争取到 时间来搞重构，说的露骨一点，可能你真的对某次重构带来 的实际价值无法量化，只是“感觉代码更整洁了”而已。我 会在下文的“伪架构”中会展开分析前端工程师的这种浮躁 献媚的技术情结。而这正是前端工程师最欠缺的素质之一： 用数据说话，用严谨科学的论据来支撑你的观点，老板不 傻，有价值的东西当然会让你去做。 当然，情况不总是这么糟糕，我们看到中文社区中已经 锻炼出了很多写手，他们在用高质量的文字推销自己的技术 理念，这是一个好兆头，好的文笔是可以锻炼出来的。而在 职场，特别是对前端工程师这

14、个特殊职位来讲，这种基本技 能可以帮你反思梳理需求的轻重缓急，从凌乱的需求中把握 七寸所在。因为当你开始认真写一封邮件的时候，这种思考 已经包含其中了。 所以，雅虎技术的推销是相对成功和远播的。关键在于 两方面，扎实的技术功底和高超的写手。而真正的技术大牛 一定是集两者与一身，不仅钻研剑道，还能产出秘籍。这也 是 Yahoo! 优雅的学院派气息的动力源泉。国内很多技术团体 想在这方面有所建树，应当首先想清楚这一点。 【规范的破与立 1 】 雅虎的技术运作非常规范，刚才已经提到，包括技术、 组织、文化，一切看起来有模有样，也堪称标杆，自然成了 国内很多技术团队和社区的效仿对象。一时间各种 “规范

15、“成 风、各色“标准“大行其道，结果是质量参差不齐。 我们到底需要什么样的规范？雅虎的技术规范到底有 何种魔力？以何种思路构建的规范才是货真价实的？规范 有着怎样的生命周期？想清楚这些问题，能很大程度减轻很 多 Web前端工程师的思想负担，看清一部分技术本质，避免 盲目跟风。 我们的确需要规范，但好的规范一定是务实的，一定是 “解决问题“的。比如针对项目构建的DPL可以收纳公用的 视觉元件以减少重复开发、规定某OPOA项目的事件分发原 则以确立增量开发的代码惯性。反之，糟糕的规范却显得过 于“抽象“，比如页面性能指标、响应式设计原则。另外， 尽管他山之石可以攻玉，但拿来主义有一个大前提，就是你

16、 了解你的项目的关键问题，你要优先解决的是些关键问题， 而外来规范正好能解决你的问题。因此规范是一本案头手 册，是一揽子问题的解决方案，应当是“字典”，而不是“教 程 “ 。 可 见 规 范 的 源 头 是 “ 问 题 ” 。 所 以 ， 当 你 想 用 CoffeeScript重构你的项目时、当你想引入CommonJS 规范 时、当你想在页面中揉进Bootstrap时、当你打算重复造轮 子搞一套 JS 库时、当你想重写一套assets 打包工具时，想 想这些东东解决了你的什么问题？会不会带来新的问题、把 事情搞复杂了？还是为了尝鲜？或者为了在简历中堂而皇 之的写上使用并精通各种新技术？ 规范之立应当有动因，动因来源于项目需求，项目需求 则来自对产品的理解和把握，这是Web前端初级工程师走向 中级甚至高级的一次重要蜕变，软件工程领域早就有“架构 师”角色，而架构师往往存在于项目需求分析和概设、详设 阶段。我看到的情况是，Web前端工程师的思维过多的限制 在“界面”之内，向前和产品需求离的太远（认为这是视觉 设计师的事） 、向后和数据逻辑又隔离开来（认为这是后台