摘要：以及之前说过的，当程序员就是为了提高社会效率。写高效的代码是每个程序员的追求，写易懂的代码是每个程序员的美德。让正确的程序更快，要比让快速的程序正确容易得多。我觉得这样才能当一个有格局的程序员。
在博客阅读：https://ssshooter.com/2019-04...
工作写程序不是为了炫耀自己的技术，是要给公司创造价值，要确实帮助使用这个程序的人。以及之前说过的，当程序员就是为了提高社会效率。
写高效的代码是每个程序员的追求，写易懂的代码是每个程序员的美德。
易懂的代码首先是有规范的，从目录结构到代码风格，在项目建立初就应该确定，可以写进项目文档中，文档用于给初见项目或是接手的程序员一个概览,介绍一下整体结构，技术栈，以及一些坑。
技术选型注意不要选择没人用的（找不到帮助）、无人维护的（发现 bug 会让你很痛苦）、很难用的（你自己懂也有可能要方便被人懂，选择框架尤其注意，这也是 Vue 热门的原因吧）。
控制代码风格可以使用 eslint 和 prettier。前者用于代码规范控制，后者用于格式化代码。统一的格式化工具配置也是十分必要的，尤其在协作的时候，如果两边的格式化格式不同的话，diff 也是地狱般的体验。
编码不规范，维护两行泪
在有规范之后，还要注意不要为了追求极简写些难懂的代码，你必须控制简洁和可读性间的平衡，例如
i = i ? (i < 0 ? Math.max(0, len + i) : i) : 0
而有时候，hack 是无可奈何的事情，这个时候必须做好注释。但是需要注意，注释描述的不是做什么（what），而是为什么（why）。
一段可读性过关的代码中完全能看出它在干嘛，看不出来做什么的代码很大几率是不及格的代码了。
可读性主要由命名入手，变量名称对整段程序理解的重要性不言而喻；另外，对于一些功能不太好看出来的几个语句的集合，即使不会复用，也可以将其包装成函数，通过函数命名告诉读程序的人（而不是电脑）这一段代码的作用。
/* 还有一个例子是把对象绑到 vue 的 this，然后不 import 直接用 对于这个做法...看你喜欢吧 毫无疑问对于模块化的项目，一个模块就不应该挂在其他地方 （虽然这么挂上去可能会省掉 webpack 的模块调用，让你的程序快一丁丁丁丁丁丁丁点） 如果你真的懒到不写 import 请一定要在绑定的变量加上 $ 至少你这个时候全局搜索还是很容易找到来源的 */ Vue.prototype.$axios = Axios
有了规范的编码，仍不足以让整个代码库足够简单，控制代码复杂度是下一个目标。
一定要理解你的所做系统的需求，否则只会在误解和错误的恶性循环中越陷愈深，浪费珍贵的时间。
我最近就接手重构一个前后端耦合的项目，业务逻辑很是复杂，理解需求这一步绝不能逃避，只能一个个细节问清楚。
不要看到大佬提什么需求都一股脑加进去，即使所提的需求很简单，但你需要有足够的时间评估这个功能。
新增需求和需求修改上也是一个道理，不能破坏以前的功能，保证整个系统的纯洁。
所以优雅地添加功能真的很耗时间。
至于真的不可行的需求，请勇敢说不。如果对结构影响很大的需求最好不要改了。不过这是理想，中国程序员好像没有什么地位
在工时预估方面，可以尝试拆分任务，并且要假设一切都会更花时间。
拆分任务不仅可以让你更准确地估计实现时间，还能让你的工作更有条理。
至于优先度，还请结合上司指令和实现难度自己衡量吧。
总之，一个完美的系统不是一步就能造好的。
对于未来的功能，你可以留个后路，但不要提早瞎做“自以为需要”的功能。不然到时候写了一堆没用的代码都是浪费时间，还可能让提高程序复杂度。
优化方面，参考著名的“不要过早优化”。让正确的程序更快，要比让快速的程序正确容易得多。开发和优化当作两个独立的步骤来做。
Premature optimization is the root of all evil.
维护是软件开发重要而困难的一环。不过如果你按着上面所说的做，我相信...维护不会是难事。
但是如果你的代码写得很恶心，你会为之付出代价。
答应我：宁愿在实现功能时很痛苦，也不要在维护的时候更痛苦。
日常重复的轮子
伟大的开源模式让整个编程界发展加速。
可以站在巨人肩膀上，就别重复造轮子。
除非你真的很闲（工作不饱和哦～）,或者你找到的轮子实在不合心意（如老旧、不优雅、功能太繁杂）
重复的工作
「重复」是程序员最大的敌人！
计算机就是负责给你做重复的事情，程序员为什么还要做哦？教计算机做就好了！
你可以依赖 node.js 写处理程序处理你的文档，在编辑代码的时候可以活用快捷键修改代码。
自我开发
程序员拒绝 996，但是在家不意味着闲着，你仍需要为自己的脑子投资。
这一行变化还挺快，虽然我也真的完全不会看未来走向，不懂什么语言和技术会在以后更有价值，但是尽量不要局限与学习单个语言，也不要因为是前端就完全不学后端。
我觉得这样才能当一个有格局的程序员。
解决问题
If you can"t explain something in simple terms, you don’t understand it. — Richard Feynman
如果你不能流利解释一个问题，那说明你还是没懂，也就是还没真正解决这个问题。若是没真正解决问题，便不能举一反三解决更多类似问题。
解决问题要明白问题如何产生，先思考，后行动。行动无解可以到谷歌搬救兵，搜索不到的话……
最终方案就是到对应社区提问，但是提问同样是一个学问，请看 How To Ask Questions The Smart Way。
生产力
不是代码越多生产力越高，程序员应该都懂，至于老板怎么看，就不得而知了
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/103526.html
摘要：由于文章内容较长，所以我把它分成两篇小文章，在第一篇优秀架构师必须掌握的架构思维中，我会先介绍抽象分层分治和演化这四种应对复杂性的基本思维。另外，上面的算法是两路归并，也可以采用多路归并，甚至是采用堆排序进行优化，但是总体分治思路没有变化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介绍 架构的本质是管理复杂性...
摘要：由于文章内容较长，所以我把它分成两篇小文章，在第一篇优秀架构师必须掌握的架构思维中，我会先介绍抽象分层分治和演化这四种应对复杂性的基本思维。另外，上面的算法是两路归并，也可以采用多路归并，甚至是采用堆排序进行优化，但是总体分治思路没有变化。 showImg(https://segmentfault.com/img/bVbeYpP?w=642&h=400); 介绍 架构的本质是管理复杂性...
摘要：也就是说我们只是知其然，并没有知其所以然。相反，那些牛人就不会忘记自己设计的算法。刘未鹏在知其所以然三为什么算法这么难中探索了编码的思维历程，值得一看。之后，将当前入栈，更新栈内的递增序列。 原文地址 相信大部分同学曾经都学习过快速排序、Huffman、KMP、Dijkstra等经典算法，初次学习时我们惊叹于算法的巧妙，同时被设计者的智慧所折服。于是，我们仔细研读算法的每一步，甚至去证...
摘要：下面就是我的另一篇文章你真的了解和吗中的思维导图。但是托尼布赞并没有沉沦，而是寻找解决方法，最终发明了思维导图。本节的思维导图就是典型的折中型思维导图。安排合适的间隔合适的间隔能够很大程度提高思维导图的审美性。 天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣。——《为学》 引言 我猜发布文章的同学肯定都有一个目标，那就是获得更多的推荐。推荐越多，表示得到别人的认同越多，自我满...
摘要：下面就是我的另一篇文章你真的了解和吗中的思维导图。但是托尼布赞并没有沉沦，而是寻找解决方法，最终发明了思维导图。本节的思维导图就是典型的折中型思维导图。安排合适的间隔合适的间隔能够很大程度提高思维导图的审美性。 天下事有难易乎？为之，则难者亦易矣；不为，则易者亦难矣。——《为学》 引言 我猜发布文章的同学肯定都有一个目标，那就是获得更多的推荐。推荐越多，表示得到别人的认同越多，自我满...
阅读 661·2021-11-24 09:39
阅读 2314·2021-11-22 13:54
阅读 2197·2021-09-23 11:46
阅读 3245·2019-08-30 15:55
阅读 2679·2019-08-30 15:54
阅读 2403·2019-08-30 14:18
阅读 1546·2019-08-29 14:15
阅读 2732·2019-08-29 13:49
