工作也快四年了，算上大学的时间，和代码打交道也快7年了。其实没有好好的去想过我正在做的这件事情。一开始只是我的一腔热情，我觉得写 code非常的酷，我创造了一些东西，其实到工作后才发现，你做的是一个螺丝钉，至少在大公司是这样，你是和你的团队在一起创造，或者维护一个东西。它不完全是你的个人主义式的创造，会有很多的限制，以及考量。除非你做到了非常高的位置，或者在小公司，你完全可以自己决定怎么去做这个东西。
我突然回想起来再大三暑期学校实习的时候，实践课的老师说，大家出去后更多的是去做开发，是工程类的工作，完成工程开发中的一部分。一些细节，深入的的东西其实不会想太多，比如一个类库的底层是怎么实现的。我就算不知道原理，我也仍然可以完成，实现我的工作，实现想要的功能。这也是你身为一个工程师的基本素养和能力，就是解决当下的问题。深入的研究和创造那是后面的事情，或者说是你自己的事情。

工程的角度

从工程的角度来说，或者从程序员的这个岗位，公司给你薪水，要求你给出的回报。 首先是解决当前的问题。原理什么的，可以无需关心。
对于普通的程序员来说编程是搭积木完全不为过，说句不好听的是你就是搬砖的，利用已经有的砖头，水泥，钢筋。怎么拼凑，搭建起一个稳固的高楼大厦。
普遍意义上的语言，框架， 不外乎是一些知识性的东西，你看了文档，学习了就会使用。是工具型的东西，对一个有几年编程经验的人来说，学习一门新的编程语言，或者框架，不过是几个小时或者几天的事情。
所以知识本身也不重要，重要的是你去搜寻知识，分析问题，整理方案的能力。
所以要善用google，去搜寻你需要的资料，分析，整理，然后成为你的解决方案，代码。

写代码的本质

从写代码本身来说，或者怎么样去写好代码，写代码的目的一部分是为了解决工程问题，一部分是本身的研究，提升，内化， 或者说内功。
写代码究竟算不算一门艺术？好的代码，好的思想经久不衰，比如前端领域正在颠覆的，其实在别的领域已经有很成熟的方案，和思想了(比如桌面的软件开发)。
再比如每次面试都会问题的排序算法，各种设计模式等等，也有数年的历史了吧。仍然散发魅力。好的东西，总是能经历时间的考验。

当我们写代码的时候是在干什么?

是你用你的逻辑思维去解决一个问题。所以一定要先想好怎么解决，然后才开始写。
在开始一个项目的时候，可以先去画草图，写文档，如果文档写得非常清晰，方案足够详细，那么去实现的时候也不会有太大的问题。 代码只是描述思维过程的工具。代码是招式，是途径，思维的过程才是灵魂。

何谓框架，设计 ，架构?

框架是一种抽象思维，抽离出这个问题最本质，最核心的部分。 所谓的设计，也就是抽象的过程。一个好的设计，往往是比较稳定的，能满足扩展性的。
架构这是一个比较大的话题，会专门写一篇文章来讨论。我们说量变引起质变，万丈高楼平地起，一个稳固的大项目，都需要一个良好地基，与周边生态。当你在做这部分工作时，你其实已经不完全是在写代码了，你是蓝图的设计者。

搞开发比算法简单?

开发其实是一个工程问题，要考虑的问题非常多。 算法是一个数学问题 , 侧重点是不同的。可以理解为一个是广度，一个是深度。
开发你需要从代码的可读性，扩展性，语言生态的特定问题，软件工程，开发效率，甚至相关领域的业务知识。是一个综合问题，并不比算法简单。

编程世界的迷惑

在编程的世界我认为有很多迷惑人的东西，让人本末倒置。 在无尽的业务当中，我们就慢慢的迷失了自己，所以你要明白，你喜欢的是什么，是写好代码这件事， 还是解决问题的能力，还是你所解决的问题，业务，工程。一开始踏入heloworld的大们，我想都是因为热爱代码本身吧，为他神奇的魔力，可以做到那么那么厉害的事情。 可是围绕代码这件事情，也会有很多的分支，就像是各式各样的武功秘籍，让人眼花缭乱。怡情可以，较真就没必要了。

编码工具

我曾经花费了大量的时间在编辑器的配置，先是notepad++ editplus eclipus idea subline text vim emacs 都折腾了一遍 ，什么字号，颜色，快捷键，插件。等等。 被折磨的死去活来后，感谢vscode的出现，让我停止了魔怔，我好想突然苏醒，倒腾了那么多也没什么卵用，代码写得更好了么。写得更快了吗，似乎也没有。反倒耗费了大把的时间和心力。或许是那段时间对编程的真心热爱，让我变得极客，hhkb 也买了。然而并没怎么用，大屏幕也埋了，但也用不习惯。简单，长久，通用或许才是最好的东西，越久过时，收益来看是更划算的。
我并不是说编码工具不重要，但我不认为那是最重要的一件事情，它是锦上添花，内功还是得靠你自己

代码风格

代码风格，缩进，字号等等，我看见有的人会折腾很久，如果缩进不对，他就写不了代码。其实吧，按照大多数的那一套规范就可以了，一般都有成熟的工具，和默认的配置，
在团队中也是，重点不是以什么样的风格，重点是有一个统一的规范。如果你真的有闲暇的时间去折腾，那也无可厚非。只是这也仍然是锦上添花的东西。没有，并不会真的影响你的多少代码质量，以及功能能不能完成。

框架类库

一个火热的技术就像是一个信仰，一个宗教。各自在招揽者它的信徒 ，它的价值随着它的信徒增多而增多，随着信徒的减少而减少。选择框架，选择技术栈，就像是在选则前途，选则命运。选对了，至少短时间内，炽手可热，选错了，代表着淘汰的边缘。所以我们该思考的事情是什么，技术总会一代，一代的被革命。没有所谓的永远的铁饭碗。在这快速淘汰的洪流中，怎么让自己被淘汰得慢一点。你的学习能力，你学习的效率，你举一反三的能力。假设同样的时间，你学到的东西更深入，更持久，那么你的能力就越强，你可以迁移的东西就越多，你学习的速度也就越快

别盲从于新技术，之前使用一个开源库sharp，GitHub上有9000多星，以为靠谱了，然而使用的过程中才发现，有非常多的问题。我们相信了星数。却忽略了很多别的东西，比如实际的使用效果，社区反馈等等。 比如express和koa， express的使用人群更多，社区更健壮。koa是很新，很时髦，然而很多问题就得你自己的去解决。 新奇，和它能否解决实际的问题是两码事

盲目的设计

人的大脑只能同时处理好这1件事情，设计的时候，就不要考虑实现 ，实现的时候就不要考虑设计。

也不要去过早的优化，那会耗费大量的时间，甚至让你忘记了你最重要的事情。 在什么时候去做优化？在即将碰到，和已经碰到问题的时候，做优化的事情会比较有目的性，也容易得到支持，从而把优化做好。 因为老板会更容易看到它的意义。我觉得这叫顺其自然。因为在量级没到那个程度的时候，其实随便怎么写都可以。 但也不是说完全不考虑设计与优化，架构师普通程序员的区别是，他知道未来会怎么发展，也知道目前急需要解决的问题，在2者之间去做一个平衡，会留一些钩子，或者做一些简单的优化，或者为今后过渡打下的基础，不至于今后完全做不了，或者成本太高。 只是说你要知道当下最重要的事情是解决当下的问题，而不是在别的事情上面

思考与启发

其实从写代码的过程让我学会了，要保持简单
无论是写代码还是生活，都充满着非常多看似令人痴迷的五彩缤纷的东西，你一定要学会透过现象去看到它的本质，否则我们就会盲目的追逐，精疲力竭。用佛法的话来说，永远在经历着轮回，不要执着某一样东西，这个世界是无常的，唯一不变的就是变化。科学不就是不停地的否定，去推翻自己之前的定论么。没有什么铁饭碗，也没有什么所谓的真理。 保持简单，保持自己的可塑性。
在这个飞速变化的时代，或者我们能做的，就是去找到那些本质的东西，而这些东西往往不容易贬值，是简单的，基础的 ，长久的 ，稳定的 ，是可以积累的。随着时间的推移，你会越来越强大，得心应手。反复咀嚼，进入新的境界。 锦上添花的东西，有更好，没有其实也无伤大雅。 保持简单，是一种哲学。