必须知道的程序员思维
内容提要
程序员写代码应为公司创造价值、提升社会效率。代码须易懂规范，统一风格工具，命名清晰，注释讲明原因。控制复杂度，理解需求，谨慎加功能，拆分任务估时，避免过早优化。善用开源，拒绝重复劳动，持续学习，先思考后行动，真正解决问题。
延伸解读
代码可读性：从命名到注释的实践
文章强调代码可读性优先于简洁，避免难懂的一行代码。命名要清晰，对于不易理解的功能，即使不会复用，也可包装成函数，通过函数名说明作用。注释应解释“为什么”而非“做什么”，因为代码本身应能看出在做什么。此外，统一代码风格工具如eslint和prettier能减少协作中的格式冲突。
控制复杂度：需求理解与功能添加
控制代码复杂度需要深入理解系统需求，避免误解导致返工。添加新功能前要评估时间，不能破坏原有功能，对不可行需求要勇敢说不。工时预估可拆分任务，并假设一切都会更花时间。对于未来功能可留后路，但不要提早实现自以为需要的功能，以免增加复杂度。
避免重复劳动：善用开源与自动化
文章指出重复是程序员最大的敌人，应善用开源，站在巨人肩膀上，除非现有轮子不合心意。重复性工作应交给计算机处理，例如用node.js写脚本处理文档，活用快捷键修改代码。同时，程序员需持续学习，不局限单一语言，投资自己的大脑，以应对快速变化的技术行业。
解决问题：先思考后行动
文章引用费曼的话，强调如果不能流利解释一个问题，说明还没真正理解。解决问题要明白问题如何产生，先思考后行动。行动无解时可搜索，最终到社区提问，但提问需遵循How To Ask Questions The Smart Way。真正解决问题才能举一反三，提高生产力，而非代码行数。
Q&A
程序员写代码应该以什么为目标？
写程序不是为了炫耀技术，而是要给公司创造价值，切实帮助使用程序的人，并提高社会效率。
如何写出易懂的代码？
首先要有规范，从目录结构到代码风格在项目初期确定并写入文档；使用eslint和prettier统一风格；命名清晰；注释要解释为什么而不是做什么；控制简洁与可读性的平衡，避免难懂的极简代码。
技术选型时应该注意哪些问题？
不要选择没人用的（找不到帮助）、无人维护的（发现bug很痛苦）、很难用的（自己懂也要方便别人懂）技术，选择框架尤其要注意。
如何控制代码复杂度？
理解系统需求，不盲目添加功能，评估新增需求的影响，拆分任务并假设一切都会更花时间，避免过早优化，开发和优化分开进行。
为什么不要重复造轮子？
开源模式让编程界加速发展，可以站在巨人肩膀上，除非你真的很闲或找到的轮子实在不合心意（如老旧、不优雅、功能太繁杂）。
程序员如何持续学习和自我提升？
拒绝996，但在家也要为脑子投资，不要局限学习单个语言，不要因为是前端就完全不学后端，这样才能成为有格局的程序员。
解决问题时应该遵循什么原则？
如果你不能流利解释一个问题，说明还没真正解决。要明白问题如何产生，先思考后行动，行动无解可以谷歌搜索，搜索不到再到社区提问，并注意提问的方法。
