程序员在20岁和30岁分别有什么优势？

程序员在不同的年龄所拥有的思维是不一样的，而且在各自的时期都会有自己的一些突出点。

20时岁的时候:

这是一个年轻人很有作为的一个年龄，年轻人有一个敢干敢搞实践的一个年龄，有些一颗火热向上的心，不服输也不怕，一般都会去网络上查各种代码，折腾各种自己喜欢的东西，有些自己的小理想，遨游在互联网里无比快乐，而且这个是一个爱好学习且熬夜的年龄，很多的老程序员都是这么坚持的走过来的。没有这些经历可以这么说，就不是一个合格的程序员！

30岁的时候:

这是一个事业有成的年龄，家庭事业双双收获，拥有着一颗沉稳的心，在处理许多程序问题上都有些一颗自己认真负责的心，相比年轻人的浮躁，更加突出这个年龄该有的平静，这更是一个为了日后更好生活而去奋斗的一个绝对好的年龄，一般来说许多老的程序员都会慢慢的转型去当管理层，许多公司的高管都是程序员出身，程序员当高管，有些特殊的有点，思维快，想法多，能举一反三，这都是30岁的程序员天生成为高管的优点！

每个程序员都是热爱着自己职业的，都会为他们努力的东西的奋斗，可能有一些时候他们有点宅，但是他们的内心都是特别有意思的，如果你身边有一个程序员，你就会发现他是一个有趣的人，大脑里充满着各种逗比，这也是他们幽默的一点点吧！

总之，一个时间段每个程序员所做的事情和奋斗的目标都是不同的！

所谓工装是指的根据工作需要定制的服装。穿上工装会让公司的统一性提升，能增加员工的自我认同感，提升工作效率。也能提升公司的形象。而程序员无疑是各个工种中比较特殊的一群人，网络上有很多对程序员的描述，那些地铁上穿着格子衬衫，脚上穿着拖鞋，头发稀疏的人可能并不是宅男，而是一名程序员。一般情况下程序员是不穿非常正式的工装的，可能也是由于工作性质决定的，因为程序员的工作要求充满创意，不拘泥于形式。

很多人认为非要给程序员统一服装会限制他们的创造力，比如谷歌、facebook这些互联网巨头都不提供正式的工装，但是比如IBM、微软这些公司也有大量程序员，但是他们就提供工装，所以公司如果给程序员定制工装的话，需要在公司形象跟员工创造力方面找到平衡，下面就程序员的工装，个人说说哪些比较适合：

1、格子衬衫

现在互联网上都认为格子衬衫是程序员的标配了，一个公司在没有工装的情况下，几乎80%的程序员都会穿搭格子衬衫，没有别的原因，就是因为容易搭配，随性。所以如果公司给程序员定制格子衬衫作为工装的话，会让他们很习惯，对公司的客户来说也算是有了一个统一的形象。

2、绝对的正装

西装领带黑皮鞋，虽然这样穿的程序员很少，无疑这样的工装会让程序员由外到内散发出一种精英气质，对公司形象无疑是巨大的提升，也能从其它方面提高程序员的效率。有些大的公司，比如IBM就是这样的工装，但是谷歌的员工会嘲笑IBM员工不是程序员，而是推销员。

当然选择啥样的工装还得看公司自己，符合公司风格的工装无疑是最好的，你如果是程序员会喜欢什么样的的工装呢？欢迎留言讨论。

转载自it之家同名文章

一位 20 年老程序员分享的编程经验突然火了，在 Hacker News 上，一天之内就收获了 467 热度。

其实这篇帖子所包含的观点大都是编程圈子里较常见的概念，但是这些年来有的话题一直很具备争议性。对他的大多数经验，网友很赞同。比如：代码终究还是给人写的，注释是为了让未来的自己和其他同事能看懂

20 年浓缩成 20 条经验

1. 不要与工具作斗争

所谓工具，包括库、语言、平台等。尽可能多地使用原生的开发方式。这样可以保证程序或软件的数据都存在于本地，能够及时检索，保证程序或软件的合作速度和流畅度。不要被技术捆绑，也不要被问题捆绑。应该为工作选择合适的工具，而不是为了工具寻找合适的工作。

举个例子：编程实现在一个文件中找到给定单词出现的位置并统计出现次数。如果用 C++ 写的话需要 92 行代码，而使用 Python 的话只用 26 行代码就可以完成了。

由此可见，对于同一个问题，换一个工具也许可以简化编程，提高效率。

2. 写让人可以看懂的代码

程序员们不是为机器编写代码，而是为了同行们和未来的自己编写代码。写代码的终极目标往往是完成一个项目或给后来者作为参考。

3. 善于合作

任何重要且有价值的软件都是协作的结果，有效沟通和公开合作很重要。能用众智，则无畏于圣人矣。

4. 对各模块分而治之

编写相互联系却又彼此保持独立的单个模块。先分别测试每个部分，然后一起集成测试。既要保证测试接近实际，也要测试边缘实例。

6. 安全是分层的

分层安全是一种应用多种安全措施的实践，每一层都与前一层和下一层重叠，以创建一个安全控制网络，这些网络可以一起工作以保护技术系统。每一层都需要单独评估，但也需要与整体相关。

7. 代码也有生死

要认识到，每段代码都有一个生命周期，并且会最终失效。有时，一段代码甚至还没上线发布就被废弃了。程序员要学会放手，弄明白 4 类特征的区别，然后想清楚应该在哪些方面投入时间和精力：

核心：就像 汽车 的引擎。没有它，产品就没有意义。

必要之处：就像 汽车 的备用轮子。它很少被使用，但当需要时，它的功能决定了系统的成功。

附加值：就像 汽车 的杯座。有它很好，但产品没有它也完全可用。

独特卖点：人们应该购买你的产品而不是你的竞争对手的主要原因。

8. 保护好个人信息

程序员不要将个人身份信息附加到代码中，也不要把其他人的身份附加到他们的代码上。人是独立于他们的工作产出物之外的。不要把别对代码的批评当成是针对个人的，当然也在批评他人的代码时也要谨慎。

9. 尽量规避技术债务

技术债务是开发团队在设计或架构选型时，为了快速地解决问题，而采取的不规范的方案。偶尔的技术债务是可以接受的，但如果长期负债往往会快速地扼杀产品。

10. 可参考以下优先级

为解决方案做决定时，假设其他条件都是一样的，可以按照这个优先级：

安全性 >可用性 (可访问性和用户体验) >可维护性 >简单性（开发人员体验 / DX）>简短性（代码长度） >性能

但是也不要盲目地遵循这个规则，还要考虑到产品的性质。例如，在设计 游戏 引擎时，性能是最重要的；但在创建银行应用程序时，安全性是最重要的因素。

11. 复制粘贴会带来 Bug

有时复制粘贴后，会出现 Bug，这个几乎无法避免。为了检查是否有问题，每次都需要搞明白复制过来的内容，并审核导入的内容。

12. 不要只为乐观场景写代码

还要写出好的错误提示，回答其为什么会发生，如何检测到它，以及如何解决它。

13. 尽量不要使用依赖库

若调用一个动态库 A 时，A 需要调用动态库 B，则 B 是 A 的依赖库。

尽量不要使用依赖库，除非导入、维护、处理边界情况时出现 Bug，或者当代码不满足需求时，重构的成本远远低于你拥有的代码。

14. 不要盲目跟风

可以去了解热炒的新技术，但不要被拽着走，要坚持自己对技术的品位。

15. 坚持学习

16. 最好的代码都有良好的注释

一些人认为，代码写的够好，就不用写注释了。但最优秀的的代码中往往都包含着良好的注释。这样，即使是没有经历过这段代码的调试、测验过程，且暂时不具备写出此代码能力的人都可以使用它。

可以说，未文档化的功能是不存在的功能，不存在的功能不该有代码。

17. 尽量避免重写、继承和隐藏信息

写纯函数 (Pure Function)。对于纯函数，相同输入总是会返回相同的输出，执行过程中不产生副作用，且不依赖于外部状态。它们更容易测试和推理。

在执行一个非纯函数时，除了得到函数的返回值以外，还在函数调用时产生了附加的影响，如：修改了全局变量的状态，修改了传入的参数等。

任何非纯函数都应该是类，任何具有不同函数的代码构造都应该具有不同的名称。

18. 弄清楚问题后再开始编程

面对一个问题，首先要弄清解决思路，再开始编程。在编程过程中还需要逐步经历“编码-测试-改进”周期，并不断深入 探索 ，直到完成。

19. 不要去解决不存在的问题

不要进行投机性编程。只有在确定代码将来会被扩展时，才去花功夫提高代码的扩展性。

因为当代码要被扩展时，有很大的可能性问题定义已经与代码初次编写时不同了。

20. 巧用社区、积极探讨

参考链接

[1]. https://alexewerlof.medium.com/my-guiding-principles-after-20-years-of-programming-a087dc55596c

[2]. https://blog.daftcode.pl/hype-driven-development-3469fc2e9b22

---