=Start=
==
以下文章是在逛「伯乐在线」的时候看到的一篇译文（注：转载已征得译者同意），通读全文觉得很有收获，遂转载到这里（对个人比较有感触的地方做了重点标注）方便时常回顾。
==
以下所列是我在这些年来软件开发工作过程中受到的启发，还有总结而来的好经验。
开发
1.从小事做起，然后再扩展
无论是创建一个新的系统，还是在现有的系统中添加新的功能，我总是从一个简单到几乎没有任何所需功能的版本开始，然后再一步一步地解决问题，直到满意为止。我从来没有妄想过能够一步登天。相反，我一边开发一边学习，同时新掌握的信息还可以用于解决方案中。
我很喜欢 John Gall 的这句话：
“复杂系统总是源于简单系统的演化。”
2. 一次只做一件事
当我们在开发时，碰到测试失败和功能无效的情况，如果你一次只研究一个问题，那将会更容易找到问题的关键。换言之，就是使用短迭代。必须确保这个问题解决之后，再转移到另一个问题上。这适用于向下提交。如果在你添加新功能之前需要先重构代码，那么先提交重构，然后再添加新的功能。
（推荐阅读：《只做一件事，并且把它做好！》）
3. 尽早地添加日志和错误处理
在开发新系统时，我做的第一件事就是添加日志和错误处理，因为这两者从一开始就非常有用。对系统来说它比一大把代码更有用，你需要一些了解程序状态的方法。如果系统不能照常工作，那么你就需要知道程序中发生了什么——这是日志的作用。错误处理也是如此——错误和异常越早处理越好。
4. 每一行新代码必须至少执行一次
在你真正完成一个功能之前，你必须对它进行测试。不然，你怎么知道它是不是按照你的想法在执行呢？通常情况下，最好的方法是通过自动测试，但并非总是如此。不过，不管怎么说，每一行新代码必须至少执行一次。
一般，我们想触发某种条件很难。但幸运的是，我们可以作弊。例如，数据的错误处理可以通过临时拼写错一个列名来触发。或者，一个if语句可以暂时颠倒过来（从 if error 变成 if not error），这样来触发那些平时很难触发的条件，这样只是为了确定代码是否正常运行和它会出现什么结果。
有时，我发现有一些行代码永远都不会被运行。当我们做代码检查是它看起来没有什么问题，但就是不工作。你要避免这样的尴尬状况，如果你想你的每一行新代码都会被执行。
5. 在整体测试之前先进行模块测试
先进行部分模块测试可以节省时间。通常说来，我们在整合不同的模块时也会出现问题，例如模块之间的接口不匹配。但是如果我们能够信任各个组件的话，那么跟踪集成问题就会变得简单得多。
6. 所有事情所花费的时间总是比你预期的要长
特别是在编程中，即使一切进展顺利，我们也很难对功能所需的时间做出正确的预算。并且，开发软件时碰到各种意想不到的问题是非常常见的。一个简单的合并操作会导致一系列小bug，一次框架升级意味着一些函数必须改变或者一些API不按照你想象的那样工作。
Hofstadter Law（ 霍夫施塔特定律）其实道出了真谛：做事所花费的时间总是比你预期的要长，即使你在预期中已经考虑了 Hofstadter Law（ 霍夫施塔特定律）。
7. 先了解现有的代码
大多数的编码都需要以某种方式改变现有的代码。即使是新功能，也需要适应现有的程序。所以，在你加进去新的内容前，首先需要了解当前的解决方案。否则，你一不小心就很有可能会打破现有的功能。这意味着，阅读代码和编写代码都是必要的技能。这也是为什么看似微小的变化仍可能需要很长时间才能解决的原因之一，因为你首先必须了解上下文。
8. 阅读和运行代码
幸运的是，对于理解代码，我们有两种互补的方法。你可以阅读代码，也可以运行代码。运行代码的确是个非常棒的好方法。所以，请确保充分利用这两种方法。
故障排除
9. Bug 总是难免的
我不喜欢那些宣称软件开发可以“一蹴而就”的高谈阔论。不论你再怎么努力，bug总是难免的（BUG的定义基本上是:“我们没有想到”）。最好能够做成可以快速故障排除、修复bug和部署修复的系统。
10. 解决故障报告
每个开发人员都应该花时间去处理来自客户的故障报告，并修复bug。这能让你更好地理解客户的意图，明白如何使用系统，知道排除故障的难易程度，了解系统的设计情况。这也是为自己的开发成果负责的好方法。不要错过这些好处。
11. 重现问题
修复bug的第一步就是重现问题。然后你得确保修复之后，问题能够彻彻底底地消失。这样一个简单的规则，可以确保你不会误将非问题当作是问题，并确保解决方案真的能够奏效。
12. 修复已知错误，然后再看看有没有其他不对的地方
有时候，可能同时存在着几个不同的问题。它们之间的互相作用，可能会让你毫无头绪，束手无策。不要纠结于搞清楚发生了什么，先去解决所有已知的问题，然后再看看还有什么不对的地方。
13. 没有巧合
在测试和故障排除时，不要相信会出现什么巧合。就像你改变了定时器的值，那么就会改变系统重启的频率。所以一切都并非是巧合。添加新功能，另一个不相干的功能变慢了？这绝对不是巧合。相反，是你应该仔细调查的内容。
14. 关联时间戳
在故障排除时，事件的时间戳可以作为你的好帮手。寻找偶数增量。例如，如果系统重启了，并且刚刚发出过一个3000毫秒左右的请求，那么可能是触发了某个定时器，才导致出现重启的动作。
合作
15. 面对面的交流最有效
当我们需要讨论如何解决问题时，那么面对面的交流比视频、打电话和电子邮件都要好。我经常在与同事讨论完后发现一个令人兴奋的更好的方案。
16. 小黄鸭调试法
遇到你绞尽脑汁也解决不了的问题时，不妨找一个同事，然后将问题解释给他们听。很多时候，当你在叙述时，即使你的同事一言不发，你可能也会突然灵光乍现找到问题的关键。听起来像魔法，但是这经常起作用。详情看这篇文章：《小黄鸭调试法，每个程序员都要知道的》。
17. 问问题
阅读和运行代码往往非常有助于指出代码的目的和它的工作原理。但是如果你有机会咨询那些更为了解的人（例如原来的程序员），那么千万不要错过。继续问他们具体的问题、后续的问题，这几分钟内给你的信息可能是你需要花费好几天才能获得的。
18. 共享荣誉
不要贪图荣誉，该是谁的就是谁的。例如：“Marcus 想出了这个主意……”(如果真是他想的话)，而不要说“我们想出的……”。大胆的说出那些帮助过你或者贡献过力量的人的名字。
其他
19. 动手去做
如果你不知道某种编程语言功能的工作原理，那么不妨写一个小程序来理解它是如何工作的。这同样适用于测试你正在开发的系统。如果我将参数设置为-1，会发生什么？当我在重启系统时，如果服务当掉，会发生什么？以此来研究它的工作原理。经常做这些会帮你发现bug，在此同时也会加深你的系统工作的了解。
20. 带着问题睡觉
如果你正在解决一个很难的问题，那么不妨带着问题睡觉。有科学研究表明，这样做虽然你表明上并没有在主动思考，但你的潜意思却这么做了。其结果就是，第二天再去研究问题，解决方案已经呼之欲出了。「暗时间」
21. 改变/跳槽
不要害怕角色变化。和不同的人共事，开发不同的产品，感受不同的公司文化是非常有意思的。在我看来，太多的人只是被动地呆在同样的地方年复一年的工作，只有在被迫的情况下才去改变。
22. 活到老学到老
软件行业的一大魅力就是我们随时有机会可以学到新的东西。你可以尝试不同的编程语言和工具，阅读软件开发的书籍，接受MOOC课程。相信我，量变才能达到质的飞跃，这些小小的学习积累，终有一天会大大地提高你的知识和能力。
（推荐阅读：《最好的学习方法是什么样的？》、《别因为要学的太多反而压垮自己》）
=END=
《 “[collect]我从编程总结的22个经验” 》 有 20 条评论
做开发十年，我总结出了这些开发经验
https://www.qcloud.com/community/article/382005001489731581
`
一、对于团队而言，流程太重要了
二、不要炫技，老老实实写代码 # 想清楚了再决定用什么，最好是跟随成功项目的脚步
三、架构上实用+适用
四、既要有攻城之力，也要有熬战之气——BUG
五、自审
六、注释
七、代码结构
八、代码风格
九、安全与逆向
十、开发效率 # 构建公用工具类 / 使用开源的一些包 / 打Log / 借力
十一、安装包体积
十二、UI渲染效率
`
所谓的几年编程经验，潜台词指的是什么？
https://www.zhihu.com/question/59299938
`
所谓几年的编程经验，潜台词就是踩了几年的坑，所以，才有下面这种现象：
简历上，一年经验的写精通xxx，五年经验的写熟悉xxx，十年经验的写略懂xxx。
工作中，一年经验的估算1天完成，实际花了10天；五年经验的估算10天完成，实际花了5天；十年经验的估算5天完成，实际花了4天。
工作经验，就是那些书本上不教的，但实际上很有用的，没有办法简单传授，只有靠自己、花时间，填完了那一个接一个的坑之后剩下的那些东西。
这行工作时间越长胆子越小，踩的坑太多了。应该说是心智成熟了一些，懂了做事要负责，给自己留些退路。
踩过多少坑，学会多少套路，见过多少世面，要多少钱
`
什么是经验，如何积累经验
https://zhuanlan.zhihu.com/p/27626296
`
0.什么是经验？（经验是对小概率事件的评估和应对。经验不是知识，知识是一般，经验是特殊；知识对应大概率，经验对应小概率；知识是标准流程，而经验是异常处理。）
1.经验重要么？（经验的重要性取决于所在领域小概率事件产生的影响。多数时候经验不重要，也没价值；少数时候经验非常重要，也极具价值。）
2.什么是有价值的经验？（标准化程度低的领域；小概率事件影响巨大的领域）
3.如果没经验怎么办？（经验难以学习，只能积累）
4.如何积累经验？（寻找有价值的领域；选择有挑战的机会；不断复盘和总结。）
`
编程到底难在哪里？
https://www.zhihu.com/question/22508677
http://bkzxp.cc/lessons/2013/05/29/man-month-read16
`
人月神话–没有银弹-软件工程中的根本和次要问题
软件开发中的困难分为两类：
Essence，可以译为本质困难或者主要问题，指的是软件开发中不可规避的问题，就是软件本身在概念建构上存先天的困难，也就是如何从问题领域，发展出具体的解决方案。
Accident，可以译为次要因素或次要问题，指的是把解决方案实施到电脑上，所遇到的困难。
他认为软件开发中无法规避的四个特性是：
复杂度；
一致性；
可变性；
不可见性。
他还归纳了在次要问题上我们取得的进步：
高级语言；
分时系统；
统一开发环境。
`
如何有效地报告 Bug
https://zhuanlan.zhihu.com/p/27529023
`
简评：深入浅出，教你如何与程序员沟通 bug 问题，有用。
`
适当地引入防卫性编程
http://harttle.land/2018/02/07/defensive-programming.html
`
· 调试困难。现在可以抛出具有足够信息的错误，便于调试。上述例子中 assert 的第二个参数可以极尽详细地描述错误。
· 容错困难。实现应满足一切合法输入，不再需要在实现的过程中进行容错，减少容错也让正确性更加明显。
· 重构困难。防卫性的接口描述可以做到足够清晰，接口描述不再影响重构。上述例子中，只需要继续支持 POST, PUT 即可保持接口的向后兼容。
`
30 多年的编码经验浓缩成的 10 条最佳实践
https://my.oschina.net/editorial-story/blog/1525762
http://www.techug.com/post/10-tips-for-writing-better-code.html
`
1. 遵循单一职责原则
2. 尽量减少共享状态
3. 将“副作用”局部化
4. 优先使用不变的对象
5. 多用接口少用类
6. 对模块应用良好的原则
7. 避免继承
8. 将测试作为设计和开发的一部分
9. 优先使用标准库而不是手写的
10. 避免编写新的代码
`
软件架构师应该知道的97件事
https://blog.csdn.net/kobejayandy/article/details/9707463
https://blog.csdn.net/ciahi/article/details/6443774
http://vdisk.weibo.com/s/zu2RetglHOgjX
软件工程铁律：设计时间要大于等于实现时间
https://mp.weixin.qq.com/s/WQV_JDLYeGgZUCwHTd-HrA
`
在产品品质管控的圈子里，一直都有这种说法：
产品的品质是生产、设计出来的，不是检验出来的，第一时间就要把事情做好。
这是有科学依据的。统计数据表明：产品的设计开发成本虽然仅占总成本的10%—15%，但决定了总成本的70%—80%。
同样的，软件的质量也是设计出来的。软件开发前期的需求分析和软件设计，就已经决定了软件的质量；在此基础上依照设计进行编码，软件的质量就固化了。之后的软件测试，只能发现软件潜在的一些问题，但并不能改变软件的质量。
`
需求分析的9项任务
https://mp.weixin.qq.com/s/TskBj0S0Xvjx777nVbTE2Q
`
第1项任务：画出目标系统的组织结构图
第2项任务：画出目标系统的业务操作流程图
第3项任务：画出目标系统的数据流程图
第4项任务：列出目标系统的功能点列表，即功能模型
第5项任务：列出系统的性能点列表，即性能模型
第6项任务：列出目标系统的接口列表，即接口模型
第7项任务：确定目标系统的运行环境，即环境模型
第8项任务：目标系统的界面约定，即界面模型
第9项任务：对目标系统的开发工期、开发进度、系统风险等问题进行分析与评估
但是，上述9项任务不是教条，不能完全生搬硬套，而要根据具体问题具体分析，活学活用，举一反三。例如，对于高可靠，高安全的软件系统，除了上述9项任务之外，还应进行软件系统的安全性，保密性，可靠性，以及其他质量因素的需求分析。
通过9项任务来完成需求分析工作，可以使得需求分析有的放矢，有迹可循。
`
程序员你为什么这么累？
https://zhuanlan.zhihu.com/p/28705206
https://xwjie.github.io/rule/
`
大部分程序员的大部分时间都是在「定位问题 + 改代码」，真正开发的时间并不多。定位问题包括开发转测试的时候发现问题和上线后发现问题，改代码的包括改bug和因为需求变动修改代码。
所以说，simple is not easy。很多人就是因为觉得简单，所以功能完成自己测试ok了就算了，没有思考有没有更加好的方式。归根到底是因为编码习惯太糟糕，写的代码太烂，导致无法定位频繁修改频繁出问题。
其实，对于个人来说，技术很重要，但是对于工作来说，编码的习惯比技术更加主要。工作中你面试的大部分技术都不需要用到的。工作中，因为你的编码习惯不好，写的代码质量差，代码冗余重复多，很多无关的代码和业务代码搅在一起，导致了你疲于奔命应付各种问题。
`
阿里巴巴技术专家三画：如何画好架构图
https://mp.weixin.qq.com/s/MZwTb3nINuRsOKy0mLNa_A
`
技术传播的价值，不仅仅体现在通过商业化产品和开源项目来缩短我们构建应用的路径，加速业务的上线速率，也体现在优秀工程师在工作效率提升、产品性能优化和用户体验改善等经验方面的分享，以提高我们的专业能力。
思考了一下，总结下来，我们认为，在画出一个好的架构图之前， 首先应该要明确其受众，再想清楚要给他们传递什么信息 ，所以，不要为了画一个物理视图去画物理视图，为了画一个逻辑视图去画逻辑视图，而应该根据受众的不同，传递的信息的不同，用图准确地表达出来，最后的图可能就是在这样一些分类里。那么，画出的图好不好的一个直接标准就是：受众有没有准确接收到想传递的信息。
明确这两点之后，从受众角度来说，一个好的架构图是不需要解释的，它应该是自描述的，并且要具备一致性和足够的准确性，能够与代码相呼应。
`
什么才算是真正的编程能力？
https://www.zhihu.com/question/31034164/answer/553533545
`
@圆角骑士魔理沙
0：可以完全理解一问题，并且给出对应的代码。
1：能在0之上加上工程方法。
2：对整个计算机stack有认识，能把各种技能混着耍
3：对不理解的CS&数学知识能在遇到的时候快速的补起来。
这些就是我所认为的不会随着时间而失效，也不能被体力劳动+调包取代的，真正的编程能力：
不停扩充自己的toolbox，并对自己的tool或多或少有本质上的理解。（Machine Learning/GPU Programming）
根据自己对这些工具的理解，想出新的组合法。（Deep Learning）
把自己的idea构建成一个复杂，大而全的系统，而不仅仅是一个玩具。（Pytorch）
落实到一个小功能的时候，能通过计算力，通过品味，设计出一个好用的API，编写一个正确高效的实现。（Reverse Mode Automatic Differentiation）
如果要用一句话概况，我猜编程能力是”对不同复杂度的问题（领域级/系统级/问题级），采用相对应工具降低复杂度，最后击破”的能力吧。
@h8liu
计算机科学有两类根本问题。一类是理论：算法，数据结构，复杂度，机器学习，模式识别，等等等。一类是系统：操作系统，网络系统，分布式系统，存储系统，游戏引擎，等等等等。
理论走的是深度，是在追问在给定的计算能力约束下如何把一个问题解决得更快更好。而系统走的是广度，是在追问对于一个现实的需求如何在众多的技术中设计出最多快好省的技术组合。
系统编程能力体现在把已有的代码拿来并变成更好的代码，体现在把没用的代码拿来并变成有用的代码，体现在把一个做好的轮子拿来能画出来轮子的设计蓝图，并用道理解释出设计蓝图中哪些地方是关键的，哪些地方是次要的，哪些地方是不容触碰的，哪些地方是还可以改进的。
怎么提高系统编程能力呢？土办法：多造轮子。就像学画画要画鸡蛋一样，不是这世界上没有人会画鸡蛋，但画鸡蛋能驯服手指，感受阴影线条和笔触。所以，自己多写点东西吧。写个编译器？渲染器？操作系统？web服务器？web浏览器？部件都一个个换成自己手写的，然后和已有的现成部件比一比，看看谁的性能好，谁的易用性好？好在哪儿？差在哪儿？为什么？
更聪明一点的办法：多拆轮子。多研究别人的代码是怎么写的。然而这个实践起来经常很难。原因：大部分工业上用的轮子可能设计上的思想和技术是好的，都设计和制造过程都很烂，里面乱成一团，让人乍一看毫无头绪，导致其对新手来说非常难拆。这种状况其实非常糟糕。所以，此办法一般只对比较简单的轮子好使，对于复杂的轮子，请量力而行。
@ze ran
懂得取舍。
在有限的时间内，几乎没有系统可以做到完美。要快，要安全，高并发，易扩展，效率高，容易读，高内聚，低耦合…
大到一个网站，小到几个class，工程师都要清楚，要取什么，舍什么，这并不是那么容易的事。我们都有自己的性格，有的求新，有的求稳，有的求快，但具体到一个项目时，知道如何取舍对这个项目最好，很重要。
`
架构师能力模型
https://github.com/elithnever/paperreading/blob/master/%E6%9E%B6%E6%9E%84%E5%B8%88.md
https://mp.weixin.qq.com/s?__biz=MzI0MTczNDgyOQ==&mid=2247484195&idx=1&sn=4023a1def4da46509a481b77e297e1f7
`
研发流程的持续改进
归纳抽象和技术泛化能力
业务和需求的分析和理解能力
技术折中和持续改进能力
技术广度和深度
持续学习的能力
技术影响力
沟通表达能力
技术管理能力
坚持正确的价值观
`
研发洞察：如何用数据驱动效能提升？ | 解密蚂蚁研发效能
https://mp.weixin.qq.com/s?__biz=MzU3NzczMDI4Ng==&mid=2247483844&idx=1&sn=46b2ac7f61aa33dc0a3cadfb457d514c
成为优秀程序员的101条准则[每日前端夜话0x97]
https://mp.weixin.qq.com/s/A68c1qbQznG9buP5cAir3w
https://dev.to/emmawedekind/101-tips-for-being-a-great-programmer-human-36nl
`
1. 擅长 Google 搜索
成为优秀程序员的秘诀之一就是学习如何搜索问题的答案。通过有效地学习 Google 到的东西，你将节省大量的时间。
2. 承诺与交付
让你的团队知道自己完成一项任务将花费多长的时间，并以两种方式交付。通过可预知的和可靠的交付，你将建立起信任。
3. 善待你的设计师；他们是你的朋友
设计师为用户的痛点提供解决方案。为了建立有效的产品，要向他们学习，并团结他们。
4. 找一位导师
找一个你可以向他学习的人并从中汲取灵感。如果你需要技术导师，Coding Coach是一个很好的入门之地！（https://codingcoach.io/）
5. 做个导师
成为一个能够分享想法，并使别人可以从中汲取经验的人。
6. 写出有用的评论
写评论时要解释“why”，而不仅仅是“what”。
7. 恰当地为变量和函数命名
函数和变量应该准确地表示它们的用途，因此 myCoolFunction 这样的命名并不能让你上天。
8. 休假
每个人都需要时间去放松。快开始你一直想要的那次旅行吧。你的大脑和同事们都会感谢你。
9. 删除未使用的代码
没有理由累积更多的技术债。
10. 学习阅读代码
阅读代码是一种被低估的技能，但却是一种非常宝贵的技能。
11. 建立健康的工作与生活之间的平衡
经过漫长的工作日，你需要时间进行放松。关闭工作通知，从手机中删除无聊的应用。
12. 只安排必要的会议
可以通过电子邮件或微信解决吗？如果是的话，请避免开会。如果不是，请注意持续时间。瞄准更少。
13. 结对编程
结对编程允许你扮演教师和学生的角色。
14. 写出精彩的电子邮件
通过简洁明了的电子邮件来捕捉受众群体。没有人想去读你冗长的电子邮件。
15. 加入社区
与志同道合的人在一起会激励你走出低谷。
16. 清理你的代码分支
清理你的版本控制分支，就像在你的朋友来访之前清理你的房子一样。如果你不需要它就丢弃，不要把它扔进抽屉里。
17. 不要保守
包容。不要告诉别人他们不够好，不能进入这个行业。每个人都有自己价值。
18. 持续学习
你选择了一门需要不断学习的专业。学会爱它。
19. 不要放弃
这并不容易。但我们都是在同一个起点开始的。你能行。
20. 完成充满挑战的任务
如果它不吓到你，就不会帮助你成长。
21. 在开始之前先搞清要求
在深入研究代码之前，应该先了解验收标准。它将为你节省时间和精力。
22. 有一个工具箱
拥有一套内部和外部都知道的工具。了解这些工具可以用于的目的，以及什么情况下项目可以从中获益。
23. 学会建设性的批评
向受信任的同事和朋友提出建设性的批评。它将帮助你成长为优秀的程序员。
24. 保持开放的思想
技术总是在发生变化，而且变化得很快。不要反对新技术，学习它，然后形成自己的看法。
25. 关注相关的信息
通过关注出版物、博客、播客和科技新闻，及时了解最新的科技新闻。
26. 专注于解决问题
强大的解决问题能力可以解决任何问题。把握解决问题所需的一切。
27. 保持谦虚
无论你的头衔头衔是什么，或者在什么优秀的公司工作，都要保持谦虚。
28. 学会演讲
了解如何吸引观众并进行有效的演示。
29. 在开始之前先审视所有的解决方案
不要直接跳到第一个可能的解决方案。在深入研究代码之前检查所有路径。
30. 找到你擅长的领域
科技行业内有许多部门。找到你最感兴趣的领域并成为专家。
31. 养成良好的习惯
尝试建立一致且健康的习惯，例如消除分心、时间盒子任务、出席会议、以及有限从最重要的任务开始。这可能需要一些时间来适应，但从长远来看它是值得的。
32. 学习调试
掌握浏览器的调试器工具。了解 IDE 的调试细节。通过学习调试问题和跟踪错误的最有效方法，你将能够解决最困搞的错误。
33. 不断增强你现有的技能
如果你现在掌握一项技能就应该去运用它。除非有意识地进行改进，否则技能会随着时间的推移而逐渐消失，而且这个行业发展非常迅速，持续练习也很重要。要摆脱“我一直都是这样做”的心态，并进入“有更好的方法来做到这一点吗？”的思维方式。
如果你现在有一大包甜甜圈，这并不意味着你每天都可以吃一个?并长期保持这种状态。
34. 了解背后的原理
有时你必须表达自己的意见，因此了解其背后的原理非常重要。为什么解决方案 A 比解决方案 B 更好？提供有效的论据，你的意见将更加健全。
35. 了解你的价值
你是一种商品，应该得到适当的报酬。请注意你所在城市的行业平均值。如果你赚的钱少了，就该和自己的经理聊聊了。拿到你应得的。
36. 不要害怕寻求帮助
如果你遇到问题并且花费了太多时间寻找解决方案，那么这时候就寻求帮助了。我们都是人，都需要帮助。向同事寻求支持并不可耻。
37. 学习怎样学习
人们以不同的方式进行学习。有些人通过视频教程学习效果最好，有些人则通过阅读书籍。弄清楚你的学习风格并努力练习。
38. 保持友善
有时你会被要求提供关于某些同事的反馈，请保持友善。你可以表达自己对黛博拉（演员）缺乏主动性的看法，而不是去把她撕成碎片。
39. 休息一下
连续进行 8 个小时的编码几乎是不可能的。你会很快倦怠并犯下很多错误。所以设置一个计时器，提醒自己停下来休息一下。出去走走。和同事一起喝杯咖啡。离开屏幕将会对你的工作效率和工作质量产生积极的影响。
40. 跟踪你的进度
学习编码需要时间，当你看不到进展时会非常沮丧。所以跟踪你的成就和实现目标的进展非常重要。在计算机旁放一个小清单，每次实现某些功能时，请将其写下来，无论多小。聚沙成塔，集腋成裘。
41. 不要过度依赖框架或库
搞懂语言的细微差别比死抠框架或库的细节更好。你不一定需要逐个学习这些框架或库，但理解它们的工作方式将有助于你编写更清晰、更高效的代码。
42. 学会代码 review
让别人阅读并分析你的代码可能会令人恐惧，但也能够为你提供宝贵的反馈，这将使你成为更好的程序员。你还应该努力进行良好的代码审查。
43. 了解外围的领域
了解外围领域相关的一些基础知识，例如设计、营销、前端或后端开发。它将帮助你成为一个更全面的程序员。
44. 不要选择轻松的技术，要选择正确的
每个项目都有不同的需求，因此我们必须选择合适的工具。虽然选择以前用过的技术很舒服，但如果它们不适合项目的需要，就应该探索替代方案。
45. 为你的错误负责
所有人都会犯错误，在整个职业生涯中你会遇到很多错误。所以当你犯错误时，承担责任是很重要的。它帮你与团队成员和管理层建立信任。
46. 审视自己的代码
在进行 pull 请求之前，请审视你自己的代码。如果这是同事的工作，你会发表什么评论？在请求代码审查之前首先尝试诊断问题或错误是非常重要的。
47. 从失败中学习
失败就是没有达到预期的结果，这并不一定是坏事。在我们的职业生涯中有过很多失败。了解你失败的原因，下次是否可以换一个方法？
48. 认清你的弱点
了解自己。你的弱点是什么？也许你总是忘记在提交之前更新测试；或许你回复的电子邮件真的很糟糕。了解你的弱点，以便自己可以积极地解决这些问题。
49. 保持好奇心
这个行业在不断发展，所以好奇心很重要。如果你不了解某些内容，无论是项目要求还是某一行代码，请说出来。没有人会嘲笑或批评你，你会创建更好的代码。
50. 不要试图学习所有的东西
世界上有无限的知识库，根本无法征服它。选择几个主题来掌握就行了。你可以获得有关其他领域的工作或与自己相关的知识，但无法掌握所有的内容。
51. 不要敝帚自珍
写了一些代码并不意味着你需要对它附加情感。没有人喜欢自己的工作被抛弃，但是代码总有一个生命周期，所以没有必要对它有所捍卫。
52. 召回你的团队
优秀的团队拥有彼此的支持。这创造了一个安全的空间来尝试新事物，而不必为成见担心。
53. 在社区中寻找灵感
找一些你钦佩的行业人士。它将激励你完成自己的项目或尝试新事物。
54. 重视你工作的价值
无论你拥有多少经验或你的职位是什么，你的工作都具有价值。给它应有的价值。
55. 保持专注
关闭微信通知、短信、电子邮件和社交媒体，这将有助于你集中精力并最大化你的工作效率。某人不会因为你需要 30 分钟后再回复他的消息而崩溃。
56. 支持
试着并支持你的团队成员，无论是参加重要演示还是他们遇到困难，去帮助他们吧。
57. 给予必要的信任
如果有人做得很好，请告诉他们。赞同与并帮助是与团队成员建立信任的好方法。这样他们也更有可能会帮助你。
58. 测试你的代码
测试很重要。用单元测试、回归测试、集成测试、端到端测试去测试你的代码，你的产品将更加稳定。
59. 做计划
当你收到新需求或新的bug提示时，请先制定行动计划。你需要什么条件来解决这个问题或开发这个功能？即使只花上几分钟来制定计划，也可以帮你节省好几个小时。
60. 学习使用伪代码
伪编码是一项非常棒的技能，因为它允许你在不浪费时间编写代码的情况下思考复杂问题。在纸上写下一个方法，运行不同的测试用例并查看陷阱的位置。
61. 记录你的成就
如果你在工作中获奖，请将其写下来。如果你开发了一个关键功能，请将其写下来。你积累的这些东西，可以帮你进步，或着在艰难的一天去鼓舞士气。
62. 学习编程的基本功
学习一些基本的排序和搜索算法和数据结构。这些是与语言无关的，可以帮助你解决跨语言的问题。
63. 选择长寿和可维护性的技术
虽然测试最新的技术很有趣，但选择那些在企业级应用中易于维护的技术。你的团队将会在未来几年内感谢你。
64. 学习设计模式
设计模式是构建代码的有力工具。你可能不需要在每个项目都去使用它们，但对它们有基本的了解将有助于构建更大的应用。
65. 不要装B
为了可读性和简单性，不要通过编写复杂的代码来炫耀你的花哨的编程技巧。这将使你的团队成员更容易合作。
66. 偿还技术债
技术债可能会产生巨大的性能影响，所以如果可以的话就重构你的代码。
67. 小步快跑
不是每个月进行一次大规模升级，而是应该更频繁地小规模更新。这样可以大大的减少引入错误和破坏性变化的可能性。
68. 尽快并经常提交
尽快并经常提交是确保你工作整洁的最佳方式，并且还减少了恢复因意外引发的代码丢失的压力
69. 知道何时去寻求帮助
你不仅不应该害怕寻求帮助，还应该学会什么时候去寻求帮助。在寻求帮助之前，你应该始终去尝试解决问题，并记录你尝试过的东西。但是当你被一个简单的问题困扰了一个多小时，成本就超过了收益，你应该去求助某一位同事。
70. 有效的提问
在提问时，尽量做到具体。
71. 获得有关未完成工作的反馈
你的工作不需要为了获得反馈而完成。但如果你不确定方向是否正确，请让可信赖的同事检查你方案的有效性。
72. 阅读文档
文档是关于技术的最纯粹的真实来源，因此学习阅读文档可以帮助你快速成为专家。
73. 尝试所有的可能性
没有什么能阻止你尝试解决问题。你有什么损失？
74. 在会议上发言
你的想法和意见很有价值，参加会议将有助于你与团队和管理层建立良好的关系。
75. 跨团队协作
如果你有机会与贵公司的其他团队合作，那就去吧。
76. 有激情项目
当你每周工作40个小时的时候，为激情项目花些时间是很重要的。它们可以帮助你重新激发对编程的热爱，并尝试在工作中无法用到的新技术。（译者吐槽：万恶的美帝没有996）
77. 制定你的职业目标
规划你职业生涯的理想轨迹非常重要。如果你不这样做，就是在无的放矢。
78. 参与对话
评论博客、参与Twitter主题、与社区互动。作为一个活跃的旁观者而不是小透明，你将学到很多东西。
79. 确定任务的优先级
学会确定任务的优先级将有助于提高工作效率。即要保证完成即时的日常任务，也要使长期任务的待办事项列表保持活跃，并按重要程度排序。
80. 不要忽视细节
细节可以在项目中产生重大影响。
81. 相信你的队友
你的队友由于他们的技能被雇用。使用并相信他们可以完成工作。
82. 学会委派
如果你是团队的领导，请学习如何有效地进行委派。它将为你节省时间并减少挫折感。因为单凭你自己是无法完成这一切的。
83. 不要将自己与别人比较
你唯一应该比较的是：昨天的自己。
84. 与志同道合者在一起
学习编程将是一个漫长且艰苦的旅程。志同道合的人会鼓励你继续前进。
85. 不要在一开始就上规模
在一开始就搞大规模是一条走向失败的道路。在构建时要考虑可伸缩性，但在需要之前不要去进行扩展。这样就不会因为不必要的臃肿而压倒团队，同时是你的团队保持了成长的能力。
86. 权衡性能的影响
如果你想使用一种很酷的新技术，应该权衡这样做的性能影响。你可以实现类似的东西而不会受到性能影响吗？如果是这样，你可能需要重新考虑自己的方法。
87. 不要歧视
不要歧视新技术或新想法。对于学习新技能持开放的态度，也不要歧视别人，每个人都值得尊重。
88. 申请你没有资格的工作
你永远也不会满足工作要求中所有的条目。所以只要有机会就去申请！就算失败了你能有什么损失吗？
模块化你的代码
你可以在一个很长文件中编写所有代码，但这很难维护。通过模块化，可以确保我们的代码易于维护和测试。
90. 不要只是复制和粘贴
如果你要从 Stack Overflow 复制并粘贴解决方案，应该完全理解它的作用。搞懂你打算引入的代码。
91. 创造一个激励自己的环境和设置
如果你喜欢自己的工作空间和技术设置，那么你将更有动力去工作。去做你自己吧。
92. 记住你来自哪里
我们都是从同一个起点开始的。随着你的技能和职业的发展，请不要忘记你的初心。
93. 保持乐观
如果出现问题，请尽量保持乐观。明天将会是新的一天。乐观将有助于你的团队充满活力并保证你的心理健康。
94. 不断重新评估你的工作流程
某些东西现在起作用并不意味着它总事会如此。重新评估你的工作流程并在必要时进行调整。
95. 学习如何在家工作
如果你有能力在家工作，请学会有效地工作。找一个单独的办公空间，没有分心。Boneskull 写了一篇关于在家工作的好文章，你应该看看。
96. 无障碍准则
可访问性不是事后的工作，也不一定非常困难。每个人都应该能够使用你的产品。
97. 履行你的承诺
如果你告诉某人将在某个特定日期之前交付一些东西，那么就要履行这一承诺。如果你无法在截止日期之前完成，请尽早说出来。
98. 积极主动
如果你有一些额外的资源，可以用来帮助你的团队！他们会很感激你的。
99. 建立一个令人惊叹的个人作品集
一个很棒的个人作品集会让你与众不同。用它来展示你的编程和设计技巧！
100. 不要忘记你喜欢编程的原因
从事这个职业是因为它引起了你的兴趣。如果你感到沮丧和怨恨，请休息一下。给自己留出空间，重新点燃你对编程的热情。
101. 分享你的知识
如果你学到了很酷的东西，请分享它们！出席当地的聚会或会议。在午餐期间去教你的同事或你带的小弟。分享你的知识可以增强你对它们的理解。
`
【周刊第12期】独立开发者如何学习新技术
https://mp.weixin.qq.com/s/fI8qmteTxG2MmjuOtMGJgA
`
独立开发者应该如何学习新技术呢？一般只要做到以下一到三步就可以。
第一步：了解新技术产生的目的
每一个新的技术都是针对某些问题提供的解决方案。我们要学习新技术首先不是学习新技术本身，而是先要去了解新技术背后所解决的主要问题，也就是这项技术的目的。这样才能清楚自己为何要学习这项技术，这项技术有哪些优点，又能为我带来什么。
第二步：了解新技术背后的原理
当你理解了新技术的目的后，接下来你就要尝试搞懂技术为你带来的这些好处背后是利用什么原理实现的。理解技术背后的原理有两点：
1. 该技术是基于哪些技术实现的，先要理清该技术底层基础的一些技术原理。
2. 之后才是了解该技术的实现原理。也就是该技术使用什么设计，怎么样利用底层基础技术去实现它的特征和优势。
理解技术背后的原理能够让我们清楚它的设计思路，各项功能，以及技术边界。
第三步：学习技术的使用指南
当你理清以上两点之后，这才开始学习该技术的使用指南，而不是一开始就直接跟着指南写例子，这样你会有很多地方没有办法很好的消化。根据使用指南还需要多多的自我练习，由于你之前有了解过新技术的目的和背后的原理，在练习和理解的过程中还可以揣测技术开发者的思路，进行一些举一反三的练习和原理的探究实验。
第四步：了解关键功能的实现细节
做到以上3步你基本就能很好的去使用这项新技术了。然而要很精通这项新技术那就必须要代码级别的去了解该项技术的实现细节。不需要阅读所有的代码，只需要了解其关键功能的实现细节。
第五步：记录总结
学习任何新技术都需要记录和总结，已便日后能快速回忆和复习。记录总结要做到以下三点：
1. 要说的出。也就是把自身对该技术的理解用一段话或一图读懂的方式去记录，能很快的和别人描述这项技术。
2. 要能够用。也就是沉淀一些可以二次使用的代码，记录一些疑难的原理细节，收藏一些相关的API文档，使自己能够在想用的时候能够快速的上手。
3. 要把使用经验归纳成能解决相关问题的解决方案。业务解决方案就相当于一个产品，是完全属于你的资产。
第六步：参与其中
如果你非常热爱这项新技术，你可以更近一步参与其中。你可以在开发者论坛中去讨论用法、发现的bug、使用场景、能否进一步优化、如何扩展。甚至可以参与新技术的开发。除此之外你还可以追踪订阅该技术的最新信息，时刻关注它的发展。
`
2020年软件开发趋势
https://mp.weixin.qq.com/s?__biz=MzA4Nzc4MjI4MQ==&mid=2652403340&idx=1&sn=5faac27e6fea482f6b4e83b721aaa5e9
`
基础设施：终将上云
容器化：Kubernetes 将会更酷
软件架构：微服务成为主流
开发：Python 将吞噬世界
企业级开发：Java 和 JVM 为王
Java 企业级开发：Spring
开发：Rust, Swift, Kotlin, TypeScript 会有一个突破
Web：JavaScript 继续主导
JavaScript Web 框架：React 领先
APP 跨平台混合开发：React Native
API：REST
数据库：SQL 主导，分布式 SQL 崛起
大数据计算：Spark 继续闪耀
大数据流处理：Flink
字节码：WebAssembly 会开始大量应用
`
https://towardsdatascience.com/20-predictions-about-software-development-trends-in-2020-afb8b110d9a0
为什么 80% 的国内开发者缺乏基本功？
https://www.infoq.cn/article/QjDuMC2jewB7Gcv16_Df
`
有人说：“初级程序员才比招式，高级程序员只看内功。”什么是基本功？不是那些高大上、新潮的技术、框架，而是程序员每天做的基础工作。比如，快捷键是否熟悉，测试习惯好不好，代码干不干净，打字速度有多快等等。在 IT 产业高速发展的当下，为何我们还要重申程序员基本功的重要性？一个基本功扎实的程序员应该具备哪些素质？当我们与国内最早导入敏捷软件开发方法的熊节先生探讨这一话题时，他表示，程序员的基本功才是真正影响开发效率，甚至影响整个项目成败的核心。然而，”国内 80% 的软件从业者都存在基本功缺失的问题，其实我想说 90%，太得罪人。“
InfoQ：您认为，基本功扎实的程序员通常具备哪些素质？
熊节：第一，需要具备良好的沟通能力。沟通不仅仅是说话或者写文档，程序员还应该能用自动化的测试作为媒介，准确地框定需求范围。
第二，他应该能有效地拆解任务。要把任务拆解成可以落地、可以逐步实施的小块。这是需要练习的事情。
第三，他应该能在保证质量的情况下，把拆解好的任务快速实现出来，让每一行代码都是有测试覆盖、有质量保证的。
第四项基本能力就是代码质量要好。写完一段代码之后，应该回头看一看，有没有坏味道？用适当的重构方法把坏味道消除掉，让代码质量保持在良好状态。
第五，做前面几件事情的速度要快。只是头脑里知道怎么做，没有用，因为一旦有压力的时候，就很难施展出来，所以需要反复的练习，在压力下也能快速完成这一系列动作。
`
为什么说 80% 的程序员都缺乏基本功？
https://zhuanlan.zhihu.com/p/79090064
开发凭蛮力、需求靠本能，从业18年，“好”程序员的基本功是什么？
https://xueqiu.com/5998107859/131541548
Typing Practice for Programmers
https://typing.io/
编写简洁、可维护代码的好处
Benefits of writing clean, maintainable code.
https://jump24.co.uk/journal/benefits-of-writing-clean-maintainable-code/
`
# Why write cleaner code 为什么要编写更简洁的代码
So, why should you write cleaner code, even if you’re just code your writing for yourself, well, there’s a few reasons
那么，为什么要编写更简洁的代码呢，即使你只是为自己编写代码，也有以下几个原因
* Higher code quality 更高的代码质量
– This is an obvious one, if you’ve sat and thought about your code, and keeping it as clean as possible, then automatically, that code is a higher quality than it would have been had you just written the shortest amount of code to get the job done. – 这是一个显而易见的问题，如果你坐下来仔细考虑过你的代码，并尽可能保持代码的简洁，那么这些代码的质量就会自动高于你为完成工作而编写的最短代码。
* More Readable 可读性更强
– Again, another obvious side effect of writing clean code is that your code will be far more readable and easier for a human to understand, which means it’s easier for the next person to start working in the same code base. – 同样，编写简洁代码的另一个显而易见的副作用是，代码的可读性将大大提高，人类也更容易理解，这意味着下一个人更容易在相同的代码库中开始工作。
* Easier to maintain 更易于维护
– If your code is now cleaner, easier to read, then it will be easier to understand what that code is doing, and then it is far easier to maintain with less risks involved with not understanding any side effects of editing a specific block. – 如果你的代码现在更整洁、更易读，那么你就更容易理解这些代码在做什么，也就更容易维护，减少了因不理解编辑特定代码块的副作用而带来的风险。
* Self Documenting 自我记录
– Remember the days where it was encouraged to write huge doc-blocks in your code describing what it does? If your code is readable and easy to follow, then you don’t need them, your code has become self documenting! – 还记得人们鼓励在代码中写下大段大段的文档来说明代码的作用吗？如果您的代码具有可读性且易于理解，那么您就不需要这些文档了，您的代码已经实现了自我文档化！
* Easier to test 更易于测试
– This is a bit more advanced, but if your code is well structured and sticks to common conventions, such as separation of concerns, and single responsibility, then that code is then far easier to test in isolation, giving even more peace of mind about that block of code – 这有点高级，但如果您的代码结构合理，并遵守常见的惯例，如关注点分离和单一责任，那么代码就更容易进行隔离测试，从而使代码块更加安全可靠
* Easier for new developers to understand 新开发人员更容易理解
– Bringing new developers into an existing, established code base can be tricky, but if that code base sticks to common conventions, and the code is clean, high quality and easy to read/understand, then it will be a lot easier and quicker for that new developer to get started, which means they will spend last time getting onboarded, and more time working on your product. – 将新开发人员引入现有的、成熟的代码库可能很棘手，但如果该代码库遵循通用的惯例，代码简洁、高质量、易读/易懂，那么新开发人员上手就会更容易、更快，这意味着他们将花费更少的时间入职，更多的时间来开发产品。
`