※ 引述《m13m13m (奇怪 还没收到??)》之铭言：
: 各位好~
: 我目前是网站工程师一枚. 这几年有一个很深的感觉
: 就是后端愈来愈竞争, 可能是许多优秀好用的框架: Laravel,
: ror, node.js, Django...陆续出现.
以后还是会出现更多种框架的，
但出现更多框架，不代表更加竞争。
能与你竞争的只有上手速度比你快的人。
这里的快，不单纯是指学习能力，或个人的资质聪明与否。
而是能快速将新技术，应用
在遭遇过，
或 未遭遇过的 工作情境之中。
这二种应用是有情境上的差别，根天资本质无关，
而是思考风格比较相关，遇过的用得上，
那就是套路 (template) 练过，简单、送分题
(只要你适时回忆起这段经历)
单纯来谈学习的话，先贴个参考资料。
面对学习材料，我们需要适当的分类，并决定花多少力气，
与如何施力较省时省力
=======================================================
http://www.celt.iastate.edu/wp-content/uploads/2015/09/
RevisedBloomsHandout-1.pdf
http://bit.ly/2uOatHC
一般的学习，我们要面对：
* 事实知识
* 概念知识
* 程序知识
=======================================================
这样的东西，基本花时间，手动做过练习，或对新学的材料，
实作过 proof of concept 的验证，就大致有个‘手感’知道，
‘在这情境下，这么用快又有效的’
下回遇到一模一样，或是简单的变形，但还能识别出是同样的问题时，
你就能快速解决它。
(它是一种‘学习迁移’的现象，通俗点叫‘举一反三’)
单纯拿 web framework 来说，
你不会换了一个 framework 都得从 html syntax 开始学吧。
若过去是 MVC Framework，那你应该会快速地想知道，
他如何对应 model 与 view 的关系，
而 view 是用什么样的 template engine
是否有个 dispatcher 或 router 去将 request 导向适当的逻辑
而 db 部分的处理，有哪些 sql/nosql 方案，
或是直接提供 orm 的基础建设。
你不是‘从无到有’在学习同样的领域，因为你已经学过了。
不用再经历一次，什么叫 model，什么叫 view，什么叫 controller
这些具体的‘名词、术语’都是一种‘事实的知识’，
也是‘初学者’最喜欢花时间‘记忆’的内容，
当然，你已经有工作经验了，我觉得你应该认同不会花太多时间在上面
它可能只是换了框架后，目录结构有一点改变，这些需要花时间记忆的东西
初期应该做个小抄、大抄、速查表什么的，来参考就好。
同理，对应上 template engine 的 syntax 也是一样，
我们不花时间去记它，而是弄个速查表，边写边参考，多写几次就熟了。
那么，既然是一个有经验的工程师，我们上手新框架，
要从‘概念的知识’学起，先确认是不是有该学的新‘概念’
概念的前一层是事实，但样命名为 MVC 的 M, V, C 在不同的
Framework 可能是不同的概念，或是因为‘惯例’不同，
而代表着不同的概念 (或是作者的执念)。
所以，经验人士得先由概念核对开始，在这过程，也许会觉得难以调适
因为跟过去同样术语指称的概念可能不同，
入境随俗，只好放下过去，迎向未来。
比起初学者阶段苦于记忆力不佳的烦恼，
概念识别阶段比较要担心钻牛角间太久。
我认识一些优秀的开发者，对自我要求比较高一点 (不像我比较没节操)
其中有一部分的人认为掌握一向技术是由
‘事实知识’‘概念知识’可以完全不依赖书本或任何形式记录，
都记在脑中才认可自己的学习成果。
对我来说不是这样的，我同时也劝学习能力不好的人不要这样逼死自己
(学习能力，以我们过去的教育通常特别是是记忆力与记忆力的衍伸功用)
对面概念知识，只要你看着书或笔记能回忆起来，
并且用适当的术语与同事交谈就行了，
像是你知道 controller 负责在处理一些逻辑，
当你跟同事在讨论 bug 或某个无法描述的现象出现在某个地方时，
你不会跑去 view 找问题，然后找不到问题，让同事觉得你在鬼打墙。
面对概念冲突时，就花时间接受它，或先不要抵抗它，试着 follow 它几次
走过同样的思路后，脑袋自然顺畅了。这阶段就是克服心魔而已，
(由于有 mentor 不同人的经验，对成长期的开发者来说，
大都卡在钻牛角尖而无法茁壮，只能花时间等他自己过得了那关，
接纳自己可以这么想..)
若你意识到自己‘卡’很久，那推荐另一个方法，是先进入‘程序性知识’
通常就是书上写的‘动手做看看’的部分，
因为教学的书通常会告诉你实作的顺序，特别是在介绍完：
* 基本术语与名词解释 -> 事实知识
* 观念、概念 -> 事实知识被组织的脉络 -> 概念知识
* 实际上该怎么操作 -> 程序知识
以作为学过几套框架的经验为底的情况，先撇开语言不同要熟悉语法
大致能快速推进到程序知识，并在实作过程中交错复习著概念知识与事实知识
是有机会变成‘初阶’的即战力的，可加入‘生产’的行列。
但是写得够不够‘在地化’得靠经验者指点，
至少不会换任何框架，都写得像你原本的母语那样的 style。
这会让你与你的团队格格不入。
: 工作上遇到一层不变的薪水, 和难以跨越的门槛(做某一个框架
: 几年, 想换到另一个想去的公司但是框架不同, 好的话,年资是从新算,
: 常常是遇到根本没机会, 即战力第一. 久而久之,路变得有点窄.
: 想请问各位如果继续待在web这块, 想跳去不同框架, 有没有什么建议
: 个人的观察是php缺最多, 再来"应该"是java, ror, node.js, python
: 比较久一点的公司大多会用Java/php/.net, 新创会用python, node.js, ror
: 关于薪水和未来发展,我研究了很久都没有头绪. 如果想跳框架(目前用Laravel)
: , 想请问前辈建议. 主要考虑未来的技术发展和$$, 个人以为java和.net国内外有
: 很多大公司在用? 所以应该是首选???
$$ 这件事的源头是：
(0. 公司的薪资策略)
1. 你的公司有赚 $$
2. 你的公司觉得你的贡献跟他赚的 $$ 挺有关联的
公司有没有赚 $$，如果是上市的看财报就知道
(其实我们大部分都在小公司，所以不知道公司有没有赚钱)
身为在小公司工作的乡民，我会这么想，有 2 个基本的方向：
1. 作为后端工程师大概能知道公司有没有花钱，
而至少赚得要比花得多，或者说不能亏太多。
直接观察固定在主机花费，继是否继续成长 (至少你在的 team 要成长)
2. 业务成长的速度，
若是直接 Web 服务，那直接看 log access 数量也知
或看看业务部分的人数是不是稳定成长的趋势
或是有用云服务的话，看帐单用量也略知一二
另外，你直觉来看，觉得公司发展的专案或产品是否有前景，或至少你也喜欢。
先确定 $$ 在你的公司是有成长的，你自己投入那边才会有机会一起成长。
: 如果跳出web的话, 写java好像大多是在Android,别的应用比较少??(小的孤陋
: 寡闻,故来请示), python应该就是往data走是趋势,不过这块主要吃数学和读paper?
: 如果不做web,以我会的主要是python, java, js, 好像就只剩data && android
: data目前正在跟,但是离业界要求还有不少距离. Android则是跟不上了...
: 想请问前辈们给一些职涯意见
: 打结的大脑
$$ 源头确定有足够的‘可能性后’，再来是你怎么支持你的公司。
这时就不是讨论是不是要用哪个语言，或哪个框架的问题了。
在基于目前的 tech stack 的前提下，如何对业务的成长做出适当的反应
(不是人做反应，是架构做出反应)
或提出改善的策略。
像推文有人建议你由 DevOps 与高 QPS 架构下去，都是挺好的方向。
单纯以 Programmer 的角度，会推荐你先由 CI/CD 下手，
写写各种测试，建立整合测试环境，然后部署到 dev/staging server
这时会渐渐意识到，不是单纯把东西实作出来就好，
还要考虑它在目标的机器上跑起来好不好，
最好它坏掉时，我比老板早一点知道
刚入手这领域的 Programmer 可能部分未有过不同系统的维运经验，
像是在 Windows/OSX 上开发，部署到 Linux。
或是在个人 Windows Desktop 环境开发，
部署到 Windows Server 等级的环境。
较常见的抵抗心境是‘我只是来写程式的，为什么要搞 server’
这一关要先过去去，你才能顺利玩得起其他的东西。
而 DevOps 就是更强化开发与维运一起思考的原则，
开发不再只想着眼前著 code 是怎么实作，还得考虑怎么实作比较好部署
多亏这几年很风行，有许多好用的工具出现。
虽然它同样的概念散在 CI/CD DevOps SRE 的领域，
最终我们的目标是整个系统由出生(新 release)到死亡(写验尸报告)
都能竟可能的记录下来，并由尸检由讨论出如何下一次不再发生一样的悲剧。
你会开始关心，哪些地方该留下监测 log，哪些事件该直接 alert 相关人员
虽然一开始常有，‘啊，没 log 到这一段数据’无法写出验尸报告的悔恨
但多失败几次，次次逼进 root cause，一次一次加上防护机制，
与架构改善，我们就能渐渐增加系统的健康度。
随着业务增长，你的系统也在茁壮中。
开始的监测只是知道系统健不健康的开始，
我们在监测的历程与几次业务推展，可以大略抓出设计上的弱点。
这么一来，就有机会拟定架构改善的计划。
大方向是让系统能具有 scale out 的能力，而它的本质是要区分出
stateful 或 stateless 的操作，尽可能地最小化 statefull 资料
让你在系统中将状态有规则的收纳，例如典型的数据库读写分流。
我们建立多个 replication database 让不会变系统状态的动作使用
只有少数会变更系统状态的操作会动到能写入数据库的部分。
当系统再更大时，也许会试着将 stateful 适当分割，也就是 sharding
这么一作，也就会让系统能承载更多的压力。
(虽然代价会让架构更加复杂)
或是除了同一个地理区域的 sharding，还有全球分散策略。
网上有各种架构文章能参考，左岸也很多，反正他们人多这种事超需要的。
像我很喜欢一些经验的文章:
技术揭秘12306改造（一）：尖峰日PV值297亿下可每秒出票1032张
https://www.csdn.net/article/2015-02-10/2823900
或微信红包的架构，或搜寻版上讨论‘售票’的讨论。
以前也有在追一些 RSS
http://highscalability.com/
https://medium.com/netflix-techblog
https://medium.com/aws-activate-startup-blog (搬家了)