Justin Etheredge 最初在各类小型和初创企业中担任软件工程师，之后进入了咨询行业并开始为大型企业服务。Justin Etheredge 表示过去二十年以来的经历塑造了他对于软件的理解，并产生出一些坚定的信念。他把这些信念整理成一份明确的清单，希望能为大家带来一点帮助与启发。
引起网友激烈讨论的二十条建议：
1. 我懂的并不多
“你怎么会不知道什么是 BGP“你难道没听说过 Rust
类似的问题可能每天都会出现在我们面前。没错，投身于软件行业的很多人之所以热爱这份工作，就是因为它敦促着我们终身学习。
在软件领域，无论我们朝哪个方向前进，都有着广阔的知识空间不断延伸而且每一天都有所变化。换句话说，这是一份能够承载我们度过几十年的职业生涯，而两位在类似岗位上分别工作了几十年的人之间也很可能存在巨大的知识差距。我们越早意识到这一点，就能越快摆脱“冒充者综合症”，成为一个乐于向他人学习、也乐于教导他人的积极分子。
2. 软件里最难的部分，是构建正确的东西
我知道这种话大家肯定听过无数遍了，但大多数软件工程师仍拒不承认，理由是这种说法似乎在贬低他们的工作成果。我个人觉得这样的心态大可不必，这类表达其实是在突出软件开发环境中的复杂性与非理性因素，而这些都会加剧我们面临的挑战。我们当然可以设计出在技术上最令人印象深刻的东西，但却没人愿意用——这类困境随时都会出现。
软件设计主要是一种聆听活动，开发者往往身兼软件工程师、通灵师乃至人类学家等多重角色。而我们对这种设计能力的每一点投资，无论是引入专业的用户体验师还是接受更进一步的自我教育，都能给开发成果带来巨大提升。毕竟与打磨设计能力相比，开发一款“没人用”的软件成本还是太高了、太高太高。
3. 顶尖软件工程师会像设计师那样思考
伟大的软件工程师会深入思考代码成果的用户体验。虽然使用的术语或者切入点不同，但无论是对于外部 API、编程 API、用户界面、协议还是其他接口，优秀的工程师都会考虑由谁来使用、为什么要使用、如何使用以及对用户来说哪些因素真正重要等。总之，牢记用户需求才是实现良好体验的核心所在。
4. 最好的代码就是没有代码，或者说不需要维护的代码
“程序员就是管编程的”，而且跟其他专业人士一样，我们也会在自己最擅长的方面犯错。这是人的本性，没办法。大多数软件工程师编写出的代码总是有点错误，而且往往无法用非技术方案来解决。
另外有一种很神奇的现象，越是有大量相当成熟的解决方案存在，工程团队就越是想“重新发明轮子”。想表达自我、加快专业成长当然是好事，但还请大家分清场合与需求，过度泛滥的发明欲望恐怕不利于编写出无需维护的代码。
5. 软件是达成目的的手段
任何一位软件工程师的主要工作都是交付价值。但我发现大部分软件开发者并不理解这一点，能够将这个理念内化进日常工作的开发者就更少了。但只要能够完成内化，我们解决问题的方式、看待工具的角度都会有所变化。如果您真心相信软件要服从于结果，那就一定能找到“真正适合工作的工具”，而这种工具也许压根就不是软件。
6. 有时候，你压根没时间磨刀
都说“磨刀不误砍柴工”，但刀磨久了反而让人心浮气躁、难以投入真正的工作。代码编写也是一样，研究多了容易让人陷入“分析瘫痪”。
一旦出现这种状况，请马上给自己设定一个截止日期，之后再探索解决方案。在着手解决问题时，我们很快就能找到思路与线索、引导自己一步步迭代向更好的产出。
7. 如果没法理解所有可能性，就设计不出优秀的系统
这也是我个人一直在努力解决的问题。我的职责变化导致自己距离常规软件工程任务越来越远，我发现跟上开发者生态的发展速度越来越难，有时候自己甚至不理解哪些趋势真正重要。总之，如果不能理解特定生态当中的那些可行性与可用选项，那么我们根本没办法为所有问题找到合理的解决方案。
总而言之，务必警惕那些已经很久没写过代码、也没设计过系统的所谓“大牛”。
8. 每套系统最终都很差劲，要勇于接受这一点
Bjarne Stroustrup 有句名言，“世界上只有两种语言，人们抱怨的语言和没人用的语言。”大型系统也是同理。并不存在“正确”的架构，我们永远无法偿还所有技术债务、设计不出完美的界面、也不可能永远拥有迅如闪电的测试速度。但做不到不代表什么都不做，这只是一种参考视角。优雅和完美本身就是种终极目标，我们当下的任务就是不断改进并创造一个更友好的系统环境，保证团队至少还用得下去、并以可持续的方式交付价值。
9. 通于探索，不断追问
相信大家都听过“我们向来这么处理”之类的鬼话。这时候请关注那些新加入的成员，看看他们在哪里遇到了问题、又提出了哪些质疑。这些质疑中，是否存在某种有意义的功能诉求保证您明确理解他们提出的目标，以及驱动这种功能诉求的原因。如果得不到明确答案，就不断追问下去、直到弄明白为止。
10. 相比于寻找 10 倍程序员，最好是消除 0.1 倍程序员
10 倍程序员就
《一线大厂Java面试题解析+后端开发学习笔记+最新架构讲解视频+实战项目源码讲义》
【docs.qq.com/doc/DSmxTbFJ1cmN1R2dB】 完整内容开源分享
是个愚蠢的笑话。
没有任何一个人能在一天之内搞定另一位同样有能力、工作态度端正而且经验丰富的程序员需要两个礼拜才能做完的工作。我只见过 10 倍代码量程序员，他们写出来的 bug 也是 10 倍。或者说，10 倍程序员唯一的存在可能性，就是身边有个 0.1 倍程序员——就是那种浪费时间、不关注反馈、不测试代码也不考虑极端情况的家伙……所以相较于寻找神话中的 10 倍程序员，及时清除团队中的 0.1 倍程序员才是正道。
11. 高级工程师与初级工程师间的最大区别之一，在于二者形成意见的具体方式
如果某位高级工程师对现有工具或者软件构建流程没有任何意见，那我实在是感觉不太正常。我宁愿有人能反馈出强烈的批评意见，也不愿他们压根没有任何意见。只要正在实际使用工具，那大家或多或少会有正面或者负面的批价；对其他语言、库和范式的应用也是类似的情况。而这种对于工具及技术的评判与探索，往往可以快速提升我们的技能水平。
12. 人们并不真正想要创新
人们经常讨论创新，但实际想要的只是更廉价的胜利与新鲜感。如果真正进行创新、改变人们处理工作的方式，那么对方大概率会给出负面反馈。但如果您真的相信自己的决定代表未来、相信这一切能改善产出，那请做好打一场持久战、拉锯战的准备。
13. 数据是系统当中最重要的组成部分
我见过很多以数据完整性作为主要保障目标的系统。但在这类系统中，任何预期范围之外的操作都会产生某些“脏”数据，它们会在后续处理中演变为一场噩梦。
请记住，数据的存在周期往往比代码库更长，所以请花点精力保持数据的清洁和有序。从长远来看，这种好习惯必然带来高回报。
文章知识点与官方知识档案匹配，可进一步学习相关知识Java技能树首页概览91437 人正在系统学习中
微信名片 
来源：澎湖Java架构师
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！