工作也快四年了, 算上大学的时间, 和代码打交道也快 7 年了. 其实没有好好的去想过我正在做的这件事情. 一开始只是我的一腔热情, 我觉得写 code 非常的酷, 我创造了一些东西, 其实到工作后才发现, 你做的是一个螺丝钉, 至少在大公司是这样, 你是和你的团队在一起创造, 或者维护一个东西. 它不完全是你的个人主义式的创造, 会有很多的限制, 以及考量. 除非你做到了非常高的位置, 或者在小公司, 你完全可以自己决定怎么去做这个东西.
我突然回想起来再大三暑期学校实习的时候, 实践课的老师说, 大家出去后更多的是去做开发, 是工程类的工作, 完成工程开发中的一部分. 一些细节, 深入的的东西其实不会想太多, 比如一个类库的底层是怎么实现的. 我就算不知道原理, 我也仍然可以完成, 实现我的工作, 实现想要的功能. 这也是你身为一个工程师的基本素养和能力, 就是解决当下的问题. 深入的研究和创造那是后面的事情, 或者说是你自己的事情.
工程的角度
从工程的角度来说, 或者从程序员的这个岗位, 公司给你薪水, 要求你给出的回报. 首先是解决当前的问题. 原理什么的, 可以无需关心.
对于普通的程序员来说编程是搭积木完全不为过, 说句不好听的是你就是搬砖的, 利用已经有的砖头, 水泥, 钢筋. 怎么拼凑, 搭建起一个稳固的高楼大厦.
普遍意义上的语言, 框架, 不外乎是一些知识性的东西, 你看了文档, 学习了就会使用. 是工具型的东西, 对一个有几年编程经验的人来说, 学习一门新的编程语言, 或者框架, 不过是几个小时或者几天的事情.
所以知识本身也不重要, 重要的是你去搜寻知识, 分析问题, 整理方案的能力.
所以要善用 google, 去搜寻你需要的资料, 分析, 整理, 然后成为你的解决方案, 代码.
写代码的本质
从写代码本身来说, 或者怎么样去写好代码, 写代码的目的一部分是为了解决工程问题, 一部分是本身的研究, 提升, 内化, 或者说内功.
写代码究竟算不算一门艺术? 好的代码, 好的思想经久不衰, 比如前端领域正在颠覆的, 其实在别的领域已经有很成熟的方案, 和思想了 (比如桌面的软件开发).
再比如每次面试都会问题的排序算法, 各种设计模式等等, 也有数年的历史了吧. 仍然散发魅力. 好的东西, 总是能经历时间的考验.
当我们写代码的时候是在干什么?
是你用你的逻辑思维去解决一个问题. 所以一定要先想好怎么解决, 然后才开始写.
在开始一个项目的时候, 可以先去画草图, 写文档, 如果文档写得非常清晰, 方案足够详细, 那么去实现的时候也不会有太大的问题. 代码只是描述思维过程的工具. 代码是招式, 是途径, 思维的过程才是灵魂.
何谓框架, 设计 , 架构?
框架是一种抽象思维, 抽离出这个问题最本质, 最核心的部分. 所谓的设计, 也就是抽象的过程. 一个好的设计, 往往是比较稳定的, 能满足扩展性的.
架构这是一个比较大的话题, 会专门写一篇文章来讨论. 我们说量变引起质变, 万丈高楼平地起, 一个稳固的大项目, 都需要一个良好地基, 与周边生态. 当你在做这部分工作时, 你其实已经不完全是在写代码了, 你是蓝图的设计者.
搞开发比算法简单?
开发其实是一个工程问题, 要考虑的问题非常多. 算法是一个数学问题 , 侧重点是不同的. 可以理解为一个是广度, 一个是深度.
开发你需要从代码的可读性, 扩展性, 语言生态的特定问题, 软件工程, 开发效率, 甚至相关领域的业务知识. 是一个综合问题, 并不比算法简单.
编程世界的迷惑
在编程的世界我认为有很多迷惑人的东西, 让人本末倒置. 在无尽的业务当中, 我们就慢慢的迷失了自己, 所以你要明白, 你喜欢的是什么, 是写好代码这件事, 还是解决问题的能力, 还是你所解决的问题, 业务, 工程. 一开始踏入 heloworld 的大们, 我想都是因为热爱代码本身吧, 为他神奇的魔力, 可以做到那么那么厉害的事情. 可是围绕代码这件事情, 也会有很多的分支, 就像是各式各样的武功秘籍, 让人眼花缭乱. 怡情可以, 较真就没必要了.
编码工具
我曾经花费了大量的时间在编辑器的配置, 先是 notepad++ editplus eclipus idea subline text VIM Emacs 都折腾了一遍 , 什么字号, 颜色, 快捷键, 插件. 等等. 被折磨的死去活来后, 感谢 vscode 的出现, 让我停止了魔怔, 我好想突然苏醒, 倒腾了那么多也没什么卵用, 代码写得更好了么. 写得更快了吗, 似乎也没有. 反倒耗费了大把的时间和心力. 或许是那段时间对编程的真心热爱, 让我变得极客, hhkb 也买了. 然而并没怎么用, 大屏幕也埋了, 但也用不习惯. 简单, 长久, 通用或许才是最好的东西, 越久过时, 收益来看是更划算的.
我并不是说编码工具不重要, 但我不认为那是最重要的一件事情, 它是锦上添花, 内功还是得靠你自己
代码风格
代码风格, 缩进, 字号等等, 我看见有的人会折腾很久, 如果缩进不对, 他就写不了代码. 其实吧, 按照大多数的那一套规范就可以了, 一般都有成熟的工具, 和默认的配置,
在团队中也是, 重点不是以什么样的风格, 重点是有一个统一的规范. 如果你真的有闲暇的时间去折腾, 那也无可厚非. 只是这也仍然是锦上添花的东西. 没有, 并不会真的影响你的多少代码质量, 以及功能能不能完成.
框架类库
一个火热的技术就像是一个信仰, 一个宗教. 各自在招揽者它的信徒 , 它的价值随着它的信徒增多而增多, 随着信徒的减少而减少. 选择框架, 选择技术栈, 就像是在选则前途, 选则命运. 选对了, 至少短时间内, 炽手可热, 选错了, 代表着淘汰的边缘. 所以我们该思考的事情是什么, 技术总会一代, 一代的被革命. 没有所谓的永远的铁饭碗. 在这快速淘汰的洪流中, 怎么让自己被淘汰得慢一点. 你的学习能力, 你学习的效率, 你举一反三的能力. 假设同样的时间, 你学到的东西更深入, 更持久, 那么你的能力就越强, 你可以迁移的东西就越多, 你学习的速度也就越快
别盲从于新技术, 之前使用一个开源库 sharp,GitHub 上有 9000 多星, 以为靠谱了, 然而使用的过程中才发现, 有非常多的问题. 我们相信了星数. 却忽略了很多别的东西, 比如实际的使用效果, 社区反馈等等. 比如 express 和 koa, express 的使用人群更多, 社区更健壮. koa 是很新, 很时髦, 然而很多问题就得你自己的去解决. 新奇, 和它能否解决实际的问题是两码事
盲目的设计
人的大脑只能同时处理好这 1 件事情, 设计的时候, 就不要考虑实现 , 实现的时候就不要考虑设计.
也不要去过早的优化, 那会耗费大量的时间, 甚至让你忘记了你最重要的事情. 在什么时候去做优化? 在即将碰到, 和已经碰到问题的时候, 做优化的事情会比较有目的性, 也容易得到支持, 从而把优化做好. 因为老板会更容易看到它的意义. 我觉得这叫顺其自然. 因为在量级没到那个程度的时候, 其实随便怎么写都可以. 但也不是说完全不考虑设计与优化, 架构师普通程序员的区别是, 他知道未来会怎么发展, 也知道目前急需要解决的问题, 在 2 者之间去做一个平衡, 会留一些钩子, 或者做一些简单的优化, 或者为今后过渡打下的基础, 不至于今后完全做不了, 或者成本太高. 只是说你要知道当下最重要的事情是解决当下的问题, 而不是在别的事情上面
思考与启发
其实从写代码的过程让我学会了, 要保持简单
无论是写代码还是生活, 都充满着非常多看似令人痴迷的五彩缤纷的东西, 你一定要学会透过现象去看到它的本质, 否则我们就会盲目的追逐, 精疲力竭. 用佛法的话来说, 永远在经历着轮回, 不要执着某一样东西, 这个世界是无常的, 唯一不变的就是变化. 科学不就是不停地的否定, 去推翻自己之前的定论么. 没有什么铁饭碗, 也没有什么所谓的真理. 保持简单, 保持自己的可塑性.
在这个飞速变化的时代, 或者我们能做的, 就是去找到那些本质的东西, 而这些东西往往不容易贬值, 是简单的, 基础的 , 长久的 , 稳定的 , 是可以积累的. 随着时间的推移, 你会越来越强大, 得心应手. 反复咀嚼, 进入新的境界. 锦上添花的东西, 有更好, 没有其实也无伤大雅. 保持简单, 是一种哲学.
来源: http://www.jianshu.com/p/855e77b1f807