Rails 如何用代码描述问题而不是过程式思考？
领导说写代码要转变思维模式，不是过程式的，需要你用代码将问题描述清楚？我想说我的思维一直停留在如何解决问题，解决问题的步骤，请问 rails 高手们，怎么转变思维，用描述性代码实现功能？
建议你从设计 api 的角度来写 code。比如你要实现一个功能，你希望你的使用 api 是什么样子，先写出你的 api，然后再写测试，从测试的描述中让自己更清楚自己要做什么，测试出错的结果是你想要的结果时，再动手写 code。 比如我想实现所有的 model 按照时间来分组的功能，那么我希望的是：
User.aggregate({created_at.lt: Time.now.....})
Order.aggregate(.....)
Product.aggregate(.....)
那么你就发现你其实希望的是所有的 model 做分组的结构应该是一样，这样你大致能想到自己要做什么了。
@knwang 受益！但是有些看到不太懂，没到你那个层次呢，
def grades assignments.map(&:grade).uniq end 这个里面&是什么？
#18 楼 @zhangyanan 这个是 Ruby 的 symbol to proc. 相当于
assignments.map {|assignment| assignment.grade}.uniq
既然这个问题是领导提出的，我想领导应该有比较合理的答案。
除此之外，我的建议是：
- 首先，99% 的情况下，不要考虑性能。
- 把写代码当成写作文。
- 用函数名 解释 你要做什么？（用 动词 或者 陈述句）
- 用类名 和 变量名 解释 他是什么？（用名词）
- 把代码的注释，变成 类名 函数名 变量名。
- 永远不要写注释。
- 不停的思考，如何把代码写的更好读。
- 坚信“解决问题”比“描述解决方案”更容易。
- 坚信“描述解决方案”比“解决问题”更重要。
- 如果你不打算写出好的代码，忽略以上所有内容。
很多问题不是只能用面向过程的步骤才能完成的吗...
我觉得应该是对估计会频繁的写的过程式代码做一些归纳， 确定不太改变的几个状态，再用过程式代码去完成这些状态， 这样能避免很多重复性的过程式代码. 至于状态，用类或者用函数去模拟就不一定了.. 而且过程式的代码还是不可少
@knwang 我大致懂得你说的意思，但是这些我理解的不透彻，能麻烦你解释下吗？ In comparison, imperative programmers often approach a problem imagining themselves as the computer - "I am going to do this first, then if this condition is true I do x, otherwise I do y.", "I need to use this variable to hold this value, then increment it as I go through this array". Here is the news: we humans are more productive and happier thinking like humans than pretending to be computers.
如果你手边有《Everyday Scripting with Ruby》，可以看看第 7 章“假设式脚本编写法”。
或者如果有《The RSpec Book》的话，看看第 8 章第 2 小节“The Code You Wish You Had”那一部份。
或者如果你读过《重构》，可以试试把这句话倒过来理解一下“我们应当遵循这样一个原则，每当感觉需要注释来说明一些什么的时候，就将要说明的东西写进独立函数，并以其用途（而不是实现手法）命名。”——既然要把细枝末节的代码写进独立的函数，何不一开始就定义好你要的那个函数（方法）而不是把这些逻辑散落在外面之后再回头整理？
过程式的思考方式是想一步步的"实现步骤"，然后抽取步骤重构出高的抽象层，是从下而上的；声明式是先勾勒出高层的框架，描述出问题本身或者解决方案的框架，在用具体步骤来实现，是从上而下的。Ruby 的语法很适合这种思维方式，对复杂的问题可以写成 DSL 来描述，然后解决。
`如果你手边有《Everyday Scripting with Ruby》，可以看看第 7 章“假设式脚本编写法”。
或者如果有《The RSpec Book》的话，看看第 8 章第 2 小节“The Code You Wish You Had”那一部份。
或者如果你读过《重构》，可以试试把这句话倒过来理解一下“我们应当遵循这样一个原则，每当感觉需要注释来说明一些什么的时候，就将要说明的东西写进独立函数，并以其用途（而不是实现手法）命名。”——既然要把细枝末节的代码写进独立的函数，何不一开始就定义好你要的那个函数（方法）而不是把这些逻辑散落在外面之后再回头整理？`
面向过程的编程是没有错的。它有自身适合的范围，比如面向初学者的教学时，用过程式的编程更容易理解，也更容易理解 if，else，when，case 这种基本得判断。
面向对象的编程是用来解决高级一点的问题，这个时候观点是不一样的。
面向过程是被需求引领着思考，我要做什么，我怎么做。 面向对象是从功能来思考，这个功能给它什么，它给我什么。
以上是我的理解。
@liwei78 我觉得面向对象就是管理代码复杂度的一种方法。我想代码之所以复杂，一是因为逻辑重复、二是因为不好的命名、三是因为过于细节，层次不分明以致于人脑处理不过来。
程序员可以用面向对象语言的封装、多态等机制来去除重复、隐藏细节、良好的命名以表达意图。
那些设计模式、重构手法，讲的都是这些东西。
