不同于某些“难于上手、难于精通”的职业，前端这一岗位就像暴雪公司的游戏设计一样：“易于上手、难于精通 ”。
一个库是一系列对象、方法等代码，您的应用程序可以把这个库 “链接 ”进来。这个库起到了重用代码的作用，为您省下了重写这部分代码的工作量。
而一个框架是一个软件系统中可重用的一部分。它可能包含子程序、库、胶水语言、图片等一些“资源”，这些资源一起组成了软件项目。框架不像库，可能包含多种语言，某些功能可能通过API的方式让主程序调用。所以框架是一个更加灵活和宽松的名词，在具体的情景中，它可能指一个库、多个库、脚本代码，或者多个可单独运行的子程序的集合。
技术是服务于市场的，在市场发生变化的时候，如果开发者不能顺应变化，就有被淘汰的风险，毕竟很多开发者所服务的这个岗位诞生都不到十年，消亡可能也会在十年之内发生。对于目标是全栈工程师的人来说，技术能力更是多多益善。
风投在评估一个创业项目是否会成功的时候，有一个指标就是创始人是否是自己产品的目标用户。如果不是，那产品很有可能会失败。
在大公司，一些工程师士气低迷往往就是这个原因，成功来得很慢，失败也是。因为大家害怕失败，所以想把产品调整得完美无缺才发布。但是世界上成功的软件都不是完美的软件，而是在合适的时间发布的、刚刚够用的产品。如果它能活下来，在后面的版本中，它才有机会越来越好。
《精益创业 》中有一句话：“客户需求只有在实际使用中才能辨明，再多的前期调研也只能发现客户认为他们想要什么，而不是客户实际上想要什么。因此在不了解客户真实需求的情况下，只会多做多错。”
iOS原生AppiOS原生App开发的技能树相对比较新，需要学习Objective C这门语言，以及Xcode的一些操作方法——主要是sto ryboard，以及各种官方类库的使用方法。它带来的收益也很高，对于独立开发。AppStore仍然是地球上最好的软件市场，对于团队，在未来5年都不会缺少对iOS开发者的需求。
Android原生App使用Java编程，如果有Java编程经验，Android原生App是最好的选择，因为用户量和用户比例都在稳定增长。
混合模式App（Hybrid App）同时使用Web技术与原生程序语言开发，通过应用商店区分移动操作系统分发，需要用户安装使用。就像混合动力汽车使用汽油和电力两种动力一样，混合模式App使用两种技术制造。
混合模式App对于用户来说跟其他App一样，需要去苹果AppStore或者Android应用商店下载。所以App需要对应的操作系统平台的技术，比如Objective C或者Java制作整体框架。App启动后，它的全部界面或者部分界面中，使用网络视图（WebView）技术来实现。WebView能加载显示网页，可以将其视为一个浏览器，它一般使用WebKit渲染引擎加载显示网页。
混合模式App一些常用的优化方法如下：
PhoneGap通过对各个平台底层功能进行封装和抽象，然后通过JavaScript暴露出一致的API，让开发者可以通过JavaScript编写跨平台的原生APP。
虽然看上去“一次编写、到处运行”的愿景很美，但是PhoneGap有这样几个缺点。
当然，PhoneGap的优势也很明显 。
SVN集中式代码管理的核心是服务器，所有开发者在开始新一天的工作之前必须从服务器获取代码，然后开发，最后解决冲突，提交。所有的版本信息都放在服务器上。如果脱离了服务器，开发者基本上可以说是无法工作的。
在企业内部，使用SVN没有什么问题，服务器压力和内部带宽都能够承受所有员工一起操作SVN。但是在开源世界，这种架构方法就不行了，著名的开源软件的开发人数太多了，因此诞生了Git。
GitGit是一个分布式版本控制软件，是天才工程师、Linux内核开发者Linus开发，目的是更好地管理Linux内核源码。其第一版于2005年发布，它与SVN最大的不同之处就是基于分布式的理念。
鼓励频繁的提交SVN践是频繁地提交，而不要等到代码没问题了再一次性提交。对于可能损坏主干原则的代码，不要直接提交到主干，而是创建一个分支，在分支中频繁提交。
确定分支流程基本上所有的特性和较大的bug修复都应该使用分支来修改。
定义主干原则，并且坚守它我们团队的主干原则是“主干对应的代码必须是可以发布并且不会产生bug的”，如果不能保证新增的或者修改的代码符合这一原则，就在分支提交代码。任何人破坏这一原则引起bug，就请大家吃饭。
不要把逻辑的修改和代码格式化操作混在一起如果您做了一些代码格式化的操作，就单独提交这次修改。比如您去掉了代码中所有的空行，那就单独提交一个 commit，然后再做一些逻辑的修改，再提交。这样可以避免“天哪，所有的东西都不一样了”，出现问题之后更容易追溯。
不相干的代码分开提交也就是说不要在一次提交里修复两个bug。
保持工作代码库的“干净”如果您有文件不想也不需要提交，就加入到忽略列表（ignorelist） 。不需要提交的文件包括编译后文件、配置文件和第三方依赖等。这样的好处是，您每次打开SVN提交界面，如果没有修改过任何代码，就会看见一个空的列表 ，如果修改过代码，就显示修改过的代码。这能提醒您不要漏掉任何需要提交的文件。
为什么需要包管理？
在我们日常工作编写的软件中，可能有绝大部分代码都不是我们自己输入的。我们“依赖”一些第三方的框架或者库。在Web前端开发中，我们依赖各种框架、库、静态资源等；在PHP开发中，我们依赖各种框架、库；在iOS App开发中，我们依赖各种库、模块、资源等。在复杂一点的依赖环境中，您所引入的第三方库也依赖其他的“第四方库” “第五方库”… …如何保证互相之间都不会出现冲突很重要。
如何让我们依赖的资源有条不紊地在一个地方进行管理和更新，而不用重复“搜索、下载、移动”这一系列繁琐的手工操作？这就要引入“包管理”。
npm如何引入依赖组件？
因为node_modules文件夹里全都是第三方代码，实际上是脱离于自己项目的代码库的。所以应该在.gitignore或者 SVN的忽略文件列表里忽略掉node_modules整个文件夹，而且所有项目成员也不应该修改node_modules里的任何东西，否则在将来npm安装的时候可能会丢失您的修改。如果发现某个模块有修改的必要，要向原作者提出issue。或者推送请求。
首先需要良好的架构
Make和依赖关系Make是一个经典的构建工具，现代很多构建工具（比如Grunt、Gulp等）都参考了它的一些基本原则来设计。 Make的基本模型是：定义一个任务时首先声明依赖关系，然后说明根据这些依赖调用哪些应用程序来生成目标文件。因为每一步都需要使用不同的应用程序调用不同的数据，所以这里面需要设置依赖关系。
另一方面，使用包管理工具可以把项目需要用的第三方包，以及每一个包的特定版本，都集中在一个配置文件中。此后，我们通过一句命令，就可以下载这些包到本地的开发环境。每个软件包都会涉及其他的软件包，软件包里程序的运行需要有一个可执行的环境（要求有其他的程序、库等），软件包依赖关系正是用来描述这种关系的。
所以， “依赖关系”既属于“包管理”，同时又属于“构建工具”。
Grunt和GulpMake很强大，而且在全世界范围内几乎所有的计算机领域用了几十年，它的稳定可靠经过了广泛验证。不过从学习成本角度来说，它需要学习者具备一些Linux编程的基础，难度较高。所以，Grunt和 Gulp诞生了，它们都是用 JavaScript来实现的构建工具。
Grunt引爆了前端架构工具的概念，得到了广泛的应用。现在，Grunt的生态环境已经非常庞大，越来越多的开发者着手Grunt开发，为它添砖加瓦。但是Grunt有几个问题 。
所以虽然Grunt有先发优势，但是由于它有几个痛点没有很好地解决，所以又诞生了Gulp。
Gulp的意思是 “大口吸” ，它最初的logo是一杯饮料，上面有一根吸管，很形象地跟它的宣传语相呼应：“基于流的构建工具” 。与Grunt最大的不同就在于，Gulp基于 “流 ”的理念。
从语法风格上来讲，编写任务的过程更像是 “编程 ”，而不是 “编写配置” 。Gulp通过对接前一个任务的输入和后一个任务，就像一个管道，二者可以同时进行，不输出在磁盘中，没有多余的中间产物，性能更加高效。
当前，Gulp的社区还远不如Grunt成熟，有些功能的插件，Gulp可能就没有。不过从个人偏好来看，我更倾向于Gulp，它的技术理念更好。
通用用途语言 VS 特定领域语言很多编程语言倾向于通用解决方案，而不是只解决具体问题。这些语言都被设计为可以在任何领域使用，比如C、Java、Python和XML，它们被称为 “通用语言 ”（General Purpose Language， GPL）。我们可以看到用 C编写的所有类型的软件，从游戏到客户端软件，从服务器端软件到手机端软件。
与之相对应的，有些编程语言被设计为特定领域专用，叫做 “特定领域语言 ” （DSL）。DSL的目的是解决特定领域的问题，而不是像GPL一样可以解决任意的软件问题。DSL在计算机软件开发中十分常见，比如前端开发中常见的HTML和CSS就是一种DSL，专用于Web开发。MySQL是一种DSL，专用于操作数据库。Make是一种DSL，专门用来处理Shell脚本操作系统文件输入和输出。
如果您是一个以解决问题为目标的全栈工程师 ，我建议您在考虑发明一个DSL之前先考虑以下方案 。
框架和库拓展了语言在快速开发中，真正重要的是库，全栈工程师的目标往往是快速解决商业问题，不一定需要长期完美的方案。使用方便好用的框架能大大节省学习成本和开发时间，所以有些时候我们的技术选型步骤是：先选择框架，然后选择语言。
一个误解，Swift是一种语法很像脚本语言的编译语言。脚本语言跟编译语言的差异不在于语法，而在于编译机制。
脚本语言，是指支持用脚本的方式编写程序的语言，它无需编译即可直接在运行时环境中解析。在操作上，它缩短了传统的 “编写编译链接运行 ”过程。脚本语言通常具有简单、易用的特性，而且常常很短小。
相比编译语言脚本语言有更高的开发效率，但是在执行效率上会有所牺牲。由于现在的趋势是硬件成本越来越低，而工程师的人工成本越来越高，所以脚本语言的使用空间越来越大，有一些脚本语言（ Python、Ruby ）已经在成熟的商业网站中使用。
不同的脚本语言有不同的设计原则，但是它们往往有一个共同的目标，就是以简单的方式，快速完成某些复杂的任务。
脚本语言不需要编译脚本语言的特点是无需编译即可运行，它在对应的运行环境中直接运行，运行时通过解释器来逐句解析。
因为语言跟对应的解释器（或者编译语言跟对应的编译器）是分开的两个概念，所以从科学上讲，只要给定合适的运行时环境和库支持，任何语言都可以作为脚本语言来使用（也就是编写脚本） 。也就是说， “编写脚本”是对语言的一种使用方法 ，而称某种语言为脚本语言是一种工程上的约定俗成的用法，而不是科学上的定义。
脚本语言常常不需要关心清理内存因为脚本语言的设计目标是快速写出能运行的程序，它更倾向于取悦工程师，而不是优化性能。所以在语法上就忽视内存管理，而该语言的解释器则各显神通，把清理内存垃圾的重担揽在自己的黑盒里面，无需工程师关注。
脚本语言常常会对特定领域优化
脚本语言常常是动态类型语言
脚本语言的抽象层常常更高
脚本语言常常有包管理器
虚拟专用服务器（VPS）是把一台服务器分割成多个虚拟专享服务器的优质服务。每个VPS都可分配独立公网IP地址、独立操作系统、磁盘空间、内存、 CPU资源、进程和系统配置，模拟出 “独占 ”使用计算资源的体验。
比较廉价的选择是虚拟主机（Virtual Host），又称虚拟服务器或虚拟空间。虚拟主机将一台服务器的某项或者全部服务内容逻辑划分为多个服务单位，对外表现为多个服务器，从而充分利用服务器硬件资源。
如果使用虚拟主机，跟其他人共享CPU和内存等资源，这就像是合租。如果其他人在使用卫生间，您就没法用了。虚拟主机的好处是很便宜，国内一些服务提供商提供年费仅几十元的虚拟主机。虚拟并非指不存在，而是指空间是由实体的服务器延伸而来，其硬件系统可以是基于服务器群，或者是单个服务器.
为什么推荐一个全栈工程师买一台VPS自己玩玩？对网站全貌有所了解如果采用第三方的托管服务来搭建博客系系统，新建一个账号就可以开始写了，好处是很方便，缺点是在自定义功能上比如绑定独立域名，安装插件和修改路径格式代没那么灵活。
如果有瘾vps搭建一个博客网站就麻烦一些。
看上去很折腾，不过这种折腾是有意义的，因为他那里在操作的过程中理解了web工作原理。
时间就是金钱推荐使用vps的第二个原因就是稳定。如果您想把精力集中在有用的技术上，而不是服务器无响应或者IP北墙等一些无聊的琐事，那么vps是最有性价比的选择。
部署自己的环境
学习Linux
每个人都有不同的需求，不过选择vps的原则都差不多，首先需要考虑的当然是性价比，主要参数是内存、CPU、硬盘和流量。
操作系统的选择
域名解析一般来说，域名购买商和服务器提供商都提供DNS解析的能力，不过域名在哪里注册和域名在哪里解析是两回事。
因为国内网络环境比较复杂，用户可能来自电信、联通、移动、教育网等网络，所以建议把域名的域名服务器设置为国内的智能DNS提供商，比如DNSPod。DNSPod除了可以根据用户IP来给出最佳的IP以外，还提供额外的功能，比如网站监控等增值服务。
云服务器
阅读英文资料
消除重复工作
番茄工作法
过去跨界学习的成本很高，大部分人都不敢轻易尝试，但如今互联网时代给我们带来了机遇，每天上网都可以看到其他领域名人写的文章和微博，通过查看这些内容，我们就能对于原本完全陌生的领域有一个感性的认识，时间一久我们就能够在潜移默化中理解另一个领域的从业者的思维方式，当您开始跨界学习之后，就会增加更多的机会。
或许每个工程师会在不同的环境中，跨不同的界，但是在未来，我认为跨界出来的那部分能力才真正定义了“您”。
首先，一个事实是：过去的工程师普片不在意设计。有意无意，他们忽视设计的重要性。
知乎网站上有一个帖子，问题是“为什么部分开发工程师不喜欢调节界面UI细节？”。我比较赞同下面这个回答：
我发现程序员大致可以分为科学家和工程师两类，科学家关注技术是否优越，而工程师关注产品是否完美。和科学家类型的程序员合作项目往往是件痛苦的事情，他们太过关注自己手中的的锤子是否先进，却不在意自己敲进去的钉子是否平整光滑不扎屁股，更不要说这可钉子是不是跟其他钉子对齐里。那些“资深”程序员更是如此，那个年代很多用户体验技术不成熟，能做出一个能用的东西已经不易，更不要说做出一个性能还算不错的产品。抱着这个想法走到今天，大多数应该被淘汰的程序员反而做到更高的位置，开始拿这种过时的想法熏陶小弟。（来自陈鑫的回答）
在传统Web设计流程中，我们也参考里工业化的流水线：按交互设计、视觉设计、前端开发、后台开发的流程来生产一个产品。按照这种细致的分工，设计师就要输出3个以上的页面：手机、平板、超大屏幕的电脑等。设计师在交付设计稿的时候如果有需要调整的地方，3个页面就要重新调整，只要设计发生里调整，就要更改每个对应的样式，大量的人力和时间就浪费在不必要的“流程”中。
另一个例子，我们想在页面或者App中创建一些动画效果。在老式Web设计中不会有很多动画，但是现在，页面和App更强调每一个操作都给用户动画反馈，有些是为了更炫，有些是为了给用户操作反馈。但是浙西动画很那在设计稿中体现，这会给设计师和工程师带来很大的沟通成本。
推荐一本书，Robin Wiliams的《写给大家看的设计书》，本书调理清晰简单易读，一个周末的下午或者每天半小时，持续一周就可以读完。但它的理论会如此深刻地停留在您的脑海里，每次看到不符合这些理论的设计，对应的理论就会迸发出老。
设计的四大基本理论是：亲密性、对齐、重复、对比。
所以“设计感”其实是“科学”而不是“艺术”。这些只是理论或者“规则”，规则总是可以被打破的，但是前提是要熟练掌握这些规则。在没有掌握这些规则之前，请遵循规则。
作者讲了一个把一本英文书籍交给两个很有兴趣做翻译的年轻人的故事，结果由于各种各样的理由延期交稿，延期里也不主动告知，而他们完成的部分也只能算勉强及格，错译、漏译的情况常常出现，可能存在一些能力问题，但他们给我们的感觉却是根本就不上心。
如果想拖延一件事，或者不想做一件事，总是能找到理由。懒惰的终极原因就是您想逃避这件事。对于所有刚开始工作的年轻人，我告诉你们：老板给您的任务，根本不关心您有sm理由，只关心您完成没有。
新人没有经验、知识不丰富，这都可以理解，但是以此为理由输出不合格的产品，那就是自己的问题。
不是每个人都有足够的自律和积极性。虽然作为全栈工程师，我们的学习目标一直是提升个人的技术能力。但是在组织中工作，并不需要特别强的个人能力或者天赋、更需要的是稳扎稳打、虚心学习，不要害怕批评，而应该真诚沟通、珍惜每一次机会，完成每一个承诺。
好的管理者能让平凡的员工做不平凡的事
高效能的管理者并不奢求完美的人才，他能让平凡的人成就不平凡的事业
《卓有成效的管理者》中的核心是5个思维习惯，这5个思维习惯环环相扣，非常经典。
每一条都会花一章的篇幅来展开说明，每一章都有些让我醍醐灌顶的部分。比如“有效的管理者重视对外界的贡献”。
重视贡献，才能使管理者的注意力不为本身的专长所限，不为其本身的技术所限，不为其本身所属的部门所限，才能看到整体的绩效，同事也才能使他更重视外部世界。
一个事实是，程序员的沟通能力所带来的价值被大大低估来。在我们的招聘流程中，技术能力过关，但是因为沟通能力这一项不过关，而直接被拒绝的面试者比例还是很高的。但是为了避免不必要的争议，大企业的HR往往不会把拒绝的原因传达给应聘者，所以对方也不知道自己为什么会被拒绝。
沟通能力的评判往往是非常微妙和主观的，并没有一份考题能证明您的沟通能力好或者差，只是面试官能根据自己的判断来决定。为了避免无休止的争论，所以刚脆不告诉拒绝原因是最好的。
沟通是软技能针对目标听众佛家有一个词叫“度己度人”，就是在帮助别人的过程中，其实也在帮助自己。所以反过来想，作为需求的请求方，最开始就得找到那个很关键的人，对于他来说，帮助您对他是很有好处的。也就是说他能把这件事当作i自己的冠军任务。如果您的要求对于他人纯属累赘，那么他人自然不愿意帮助您了，任您多么会沟通，最终都不管用。
所以，授权给平级的同事的时候，最好的方法就是诉诸对方的利益。如果一件事情可以对双方的KPI都有好处，那么对方也愿意帮助您一起分担这个任务。如果您把不擅长的事情授权给对方，而作为交换，能给对方一些资源，那也是诉诸利益的一个好方法。
其次的方法就是把问题上升到上级领导，让上级领导安排资源，但是这种方法不能经常用，否则上司会认为您不会主动解决问题，只会提出问题。被授权的那一方也觉得您在拿领导压制他，可能会存在负面的情绪。
有方法麦肯锡的金字塔原理就是，任何事情都可以归纳出一个中心论点，而此中心论点可由3至7个论据支持，这些一级论据本身也可以是论点，被二级的3至7个论据支持，如此延伸，状如金字塔。使用金字塔方法的前提是，您的有一个中心目标。不能是两个，更多更不行，只能是一个。