关于编程的感悟

写代码感觉不难，难的是维护，增改功能，转移给别人。

代码逻辑最好与业务需求一致，虽然当前需求问题有千万解，但需求方未来的调整，是基于过去的需求的，代码就是对业务逻辑的描述，转译给机器。码农就是会编码的农民，没有什么高大上的，钻研算法也许更应该叫数学家，或笼统一点计算机科学家。

需求方不懂编程，自然也不懂什么面向对象，所以需求通常是流程的，和基于流程的介入，这其实完美对应了函数调用和lambda，需求通常没有副作用，即对变量a的修改影响到所有对a的引用这种意外（当然也有同步式的需求，模型，通常使用数据库，也轮不上面向对象）。

所以面向对象语言需要转译，千方百计去归纳一个原本（需求中）不存在的模型，也许性能高，也许重构容易，但追求性能就应该拒绝需求吗？现在明明可以做到对需求的平铺直译，也不要去搬弄那些高大上的东西，自己不懂砸自己的脚，自己懂了别人也不一定懂，代码的第二原则是给人看的，要别人能接手维护，业务逻辑本来就复杂到需求方自己都搞不清楚，再加上语法限制难免的转换（如面向对象）和神秘优化、高科技，就是祖传代码。

别谈重构方便，自己不一定是需求方会去重构，逐条业务逻辑积累下来，代码不会撒谎，不像自然语言灵活解释。

什么算法优化是底层调整，不改变语法的。

如果你的代码里使用了haskell，接手人就必须会haskell，但haskell难学，人才少，公司就得开高薪，对于程序员和haskell是有利的，但不一定能和使用js主导的公司竞争。目前来看js是最流行的lambda脚本语言，当然我会选择自己的S-Lisp，不过不太成熟。

js的隐式转换为人诟病，但事实上你使用的时候，会允许隐式转换吗？如果没有隐式转换，该报错还得报错，测试少不了，还得小心翼翼保证字符串和字符串对比，数字和数字对比。隐式转换画蛇添足还添出了矛盾，但因此而舍弃是不明智的。C系语法其实一组精练的Lisp宏，最终还得回归Lisp本质，但我现在还不清楚宏泛滥是否有问题。

面向对象模拟现实有众多对象，但现实中的对象是人类的归纳，物质总在转化没有保持常态，现实中的对象已经够让人烦恼，面向对象也是每一个类型都得现学。事实上编程一直在处理字符串，列表，字典这些基本的东西，将字符串转成数字来计算。面向对象有自己的特长，但不是万应锭，为了获得重构能力与低端错误检查，将什么都往面向对象上套，orm什么的。也许未来会以DSL为主，各种类似面向对象的检查语言遍地开花，比如我试用过PLSQL的存储过程，免ORM获得很多检查，还不必抽象成面向对象（当然PLSQL有别的问题）。面向对象有对象来解决问题；Lisp(S-Lisp)有列表语法糖，js数组字典嵌套比json更灵活，都方便做DSL按特定逻辑来解释这个结构数据。

当然程序员工作也种类繁多，有的人写点前端页面，有的人写业务流程，有的人会去做语言性能优化（不改变语法），但也是分层的需求向下实现，这时自己就是需求方，需求是某种理论上能优化性能的方案。

编程给社会带来——轻松，简单。代码也是追求简单，简单地描述业务需求，不增不减，增肥减瘦。学院派发明了众多原则，不切实际的，于是就被拿到工作中来实验（工作成了实验品）。“不要跟我谈理想，我的理想是不上班（当然是不缺钱的前提）”，同样的，不要谈原则，原则是不写代码——当然是少写一行少维护一行少一行出bug。

你非常热爱编程，是因为它对你还有些神秘，编程不是终点，不可能只靠编程活着，幻想——当然你写出了一些只有自己能理解的代码，公司离不了你。

转载于:https://my.oschina.net/wy2010344/blog/1930217