在我所负责的产品项目中，在代码编码模式上，使用了函数式编程的方案。约定唯一的命名空间，提供namespace、mixin等基本的语言扩展功能。或者这并没有什么，重要的是一套编码模式。在linux中来说，就是将一个任务细化为一个细小、单一的功能。在我的方案中，基于目前公司开发流程上的约定和线上代码的发布方式，使用一个唯一的命名空间，之后通过这命名空间来维护代码的组织，将一个功能细化，尽量细化到功能单一，保持每一个函数都能够在20行代码以内，并且提供语义化清晰的命名，以及结构化的注释方式，这样代码看起来就整齐有道，极富特点，看起来愉悦，其中一个主要的是提高复用度和较少重复代码和重复功能。
在维护阶段，因为由于维护人员的不同，以前的做法是使用闭包的方式，来包含每一个人新增的代码，保持代码不影响其他的功能。这种方式是可取的，但是这样不容易形成统一的编码方式，在大方式上抓不住，特别在codereview的时候，不能形成统一的阅读方式；而且，使用闭包的方式，在代码复用度等方面基本是难以把握的，基本是代码堆砌，无视之前的实现代码中是否有能够复用的功能函数。使用函数式的方式，那么在维护方面，可以很方便的在原来的代码中复用功能，或者添加、删除功能，因为都在同一个context上下文中，同在一个命名空间下。
使用了函数式编程的方式之后，在我最近的一次项目中，得到了很好的实践，在频繁的需求更改中，由于将功能细化，实际上就是一个大功能，由一堆小功能函数根据不用的条件组织而成。那么在修改功能的时候，只是需要修改其中的小功能函数，或者是删除、增加某个小功能函数，都显得很方便，也很快速，在功能切换上也能够很快的过度。
尽量保持一个函数在20行以内，会让维护者看代码的时候很兴奋。
你能贴点代码么，方便理解啊。
另外，貌似你这个不叫“函数式编程”吧…
闭包的方式，return好接口，还是挺方便的。
说道函数，提供输入输出，只做运算，不做修改，复用性一般都很好。
不过js中涉及太多的‘动作’，做起来经常比较棘手。
第一次来，逛逛。博主你的博文不错的啊
是啊,你这不叫”函数式编程”,这个就是一个函数只做一件事情,颗粒化.易于单元测试
乱用了下概念了，说白了就是将功能细化，函数颗粒度高，便于各种堆砌
项目还没上线，不好发布一些代码。
js动作再多，无非就是一些事件逻辑，将事件和应用逻辑分离；将可配置的数据提到外面来配置；抽取重复代码为一个功能函数等等之类，都能够很好的玩转 函数，在添加功能和去掉功能都非常的方便，还有下面Q大说的单元测试的便利等。
下面是我的一点项目技术总结：
1.将事件逻辑跟应用逻辑相分离。优点：自动化功能测试的便利；一些不依赖于触发事件来实现的功能可以得到很好的实现。
2.将功能逐渐细化，保持每一个功能函数的简洁和具备语义化。
3.做好稳步退化，对于一些核心的功能需要js来实现的，那么就需要考虑在js出错或者加载错误影响了该功能之后不会导致页面交互无法进行。
4.延迟加载资源，当用户需要使用到该功能的时候才去加载资源，避免在页面初始化的时候就加载。同时，还要避免重复加载资源。
5.将常量数据从函数中分离开来统一管理，做到一处修改，处处生效。
6.在一些事件逻辑中，比如mouseover、mouseout等发生比较频繁的事件，在事件处理程序中，如果是相对静态的数据、或者是配置类型的数据、以及一些变量的声明等等，建议是放到事件处理程序的外部来处理。
尽量保持一个函数在20行以内，会让维护者看代码的时候很兴奋
呵呵，博主倒是挺会为人着想的！