Matrix 首页推荐
Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。
文章代表作者个人观点，少数派仅对标题和排版略作修改。
常识本应是理所当然的认知，然而今天常识不再是共识，似乎每一项常识都需要争论一番。为捍卫常识，捍卫价值观，程序员出身的我，写一些我认为的程序员应该知道的常识。
都说程序员需要持续不断的学习才能跟上时代，这不完全对。计算机行业的新技术确实层出不穷，但绝大多数新技术都不是根本性的革新，而是逐步的演进。而且经常会出现回退，即某项新技术经过一段时间的实践被发现方向是错误的。你跟得太紧，反而会被忽悠。
新技术虽然花样百出，基础是不太会变的，所以程序员最需要做的，是掌握基础的底层技术。有了基础，再学习新技术就会轻松很多，万变不离其宗嘛。而且，你会用批判的眼光去看这项新技术解决了什么问题，同时又引入了哪些新问题，可能的坑在哪里需要格外注意。
如何掌握基础技术？自然是读经典著作。很多计算机领域的专家写了很多编程方面的书和文章，程序员只要看每个领域最经典的那几本就够了。我一直认为，学习一项知识或技能，最好的办法就是读经典著作。计算机行业的好书很多，但是烂书更多。读错一本书，耽误时间不说，看得糊里糊涂、甚至被误导，从入门到放弃。
从哪里找经典著作呢，看豆瓣评分和豆瓣书单可以找到很多好书。已故计算机专家陈皓（左耳朵耗子）在极客时间的「左耳听风」专栏，也是找到经典著作的极好的来源。专栏最重要的价值不在于他讲解了什么，而是他提供了一个非常完整的知识体系，包括大量经典书籍和文章。有了这些基本上就不需要看其它的书单或书籍推荐了。摘录一段陈皓在专栏中的话：
我在《程序员练级攻略》后期的文章中罗列了很多文章资源，有的读者很不能理解，他们觉得我多少应该导读一下或是写上一些自己的想法，而不是只是简单地罗列出来。这里请允许我辩解一下，我之所以这样做，并不是因为偷懒，我完全可以把这些信息资料全部隐藏起来，翻译也好，搬运也好，导读也好，自己消化完后再写出来。那么，我可以写出多少个专栏来？我觉得，只要我有时间，极客时间上的所有专栏都不用写了，我一个人就 OK 了。我可以写得又快又好，而且超出所有的人。那我可以挣到很多钱。但我不想这样，我想把我读过的好的文章推荐给大家，就像推荐书一样。那些是信息源头，已经写得非常不错了，我不用再多废话。
另外，工作中核心业务代码用到的技术框架，一定要清楚其基本原理、通读官方手册，英文的也要硬着头皮读。读完之后，你就成为团队里能够「托底」的那个人。遇到问题，你会大概知道从哪里开始查，而不是满世界求助。其实网上的很多比较水的技术文章都是抄官方手册的。
我认为绝对需要。
有人认为，如果开发设计写得足够准确完整，程序员照着做就可以了，不需要懂业务。你可能会觉得这个观点的前提有问题，现实中很少能有准确完整的详细设计嘛。
没错，但我想说的是，即使这个前提可以满足，它仍然是错的。因为它把程序员当成了冰冷的机器而不是活生生的人。或者说它是站在领导的立场，而不是程序员自身的立场。试想一个星际飞船系统的程序员，他所做的，只是根据文档中描述的星球重力加速度、大气密度、轨道参数等，编写飞船自动登陆程序，他不关心这程序是用在训练中，还是真实的火星探险，他也不关心宇航员是如何与软件互动的。当飞船成功登陆火星，团队发出激动的欢呼时，他能理解吗，他是否想知道自己在其中做了哪些贡献呢？
人需要知道自己做事情的意义，需要成就感，所以程序员需要知道自己写的程序是在什么场景下如何被使用的，这是他与社会连接的方式。
另一方面，完美的详细设计文档从何而来？还不是由前一代优秀程序员成长而成的首席程序员或资深程序员写的嘛，写详细设计文档需要看懂产品经理写的 PRD，肯定需要懂业务。这其实是一个程序员职业发展的问题，程序员年龄大了以后出路是什么？一是继续当程序员，如果不能成为懂业务能写设计文档的资深程序员，满足于当一辈子基础程序员的话，迟早被更年轻成本更低的程序员取代；二是成长为架构师，架构与业务是密切相关的，架构师肯定需要懂业务；三是转行产品经理、项目经理、团队领导等，这些岗位就更需要懂业务了。
当然程序员不需要像产品经理那样懂业务，你需要对用户的行业有一些基本了解，并且能看懂产品经理写的 PRD。这样你就有一种掌控感，也为将来的职业发展做好准备。
超前设计本质是预见到未来可能的需求，提前进行针对性设计，使得程序结构更容易适应将来的需求，改动较少，从而降低总体成本。
过度设计则是对未来需求进行了错误的估计，白白做了额外的工作，并没有命中未来的需求；有时候程序员甚至为了炫技，为了使用某种技术而增加没用的功能。
如何避免过度设计？要靠经验。经验从何而来？还是得懂业务。如果你不了解行业、不了解客户、不了解业务场景，你就无法预见未来可能的需求，只会做出想当然的超前设计。实际上，一项需求将来出现的可能性，产品经理更有发言权，程序员如果感到需要做超前设计，应该和产品经理探讨一下。
超前设计是会增加成本的，它本质是一种赌博，用今天增加的投入来赌明天的节省成本。在大环境好的时候，对超前设计的容忍度较高，比如半年甚至一两年后才命中需求，也可以接受；而在当今的普遍降本务实的大环境下，超前设计更应该慎重，因为如果消耗的成本太多，你的企业可能活不到命中需求的那一天了。
非常丢人。
有的程序员把写程序调侃为「写 Bug」，这很不好，因为语言是有魔力的，时间长了会反噬人的心智，对 Bug 习以为常，在我看来这是极其错误的价值观。实际上所有人都讨厌 Bug 多的程序员，领导有时候说「程序有 Bug 是难免的」，那只是在安慰你，千万别当真。特别是连主流程都没走通就提交程序，让测试去发现 Bug，这是对测试人员的不尊重，浪费大家的时间。别以为自己工作辛苦就是有 Bug 的理由。
发现 Bug 后，改得一定要快，特别是在生产环境发现的 Bug，要有紧迫感，争分夺秒解决。另外态度要好，改的过程中及时反馈进展，比如「已经查到原因了正在解决」、「已经改好了正在测试」等等，给焦急等待的项目经理和客户一点希望。
程序员的黄金时代已经过去了，不要再觉得自己是天之骄子，可以改变世界云云。你连你的产品经理都改变不了。所以老老实实尽量写出没有 Bug 的程序，才会得到别人的尊重。
会，但那需要很长很长时间，等那一天到来了，人类就该退出历史舞台了，或者换一种方式存在。所以我认为程序员将是最后一个被AI取代的职业。
题图：Shahadat Rahman on Unsplash
> 下载少数派 客户端、关注 少数派小红书，感受精彩数字生活 🍃
> 实用、好用的 正版软件，少数派为你呈现 🚀
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。