文章摘要
文章讲述了程序员因使用函数式编程引发同事和管理层不满，最终被迫改用非函数式编程的经历。作者通过代码示例展示了如何在避免函数式编程的情况下完成任务，尽管最终代码仍带有函数式编程的影子。
文章总结
标题：如何停止函数式编程
以下内容虽未亲身经历，但常有所闻。
你上班时发现，同事对你写的代码感到不满，因为他们看不懂。他们向经理反映，认为你使用他们不理解的编程方式是在制造问题。经理擅长解决冲突，于是决定避免使用引发问题的工具——在你的案例中，就是函数式编程。
就这样，你被告知：不能再使用函数式编程。
经理认为这对公司有利，而你则觉得听从指示对保住工作有好处。
你回到座位，从JIRA中领取了一个任务：在内部员工目录中添加一个页面，列出某人的同事。首先，你写了一个需要的函数。
scala
def userCoworkers(u: User): List[Employee] =
u.departments.flatMap(_.employees)
但这是纯函数式编程！得停下来。
scala
def userCoworkers(u: User): List[Employee] = {
val coworkers = ListBuffer[Employee]()
for { d <- departments }
coworkers ++ d.employees
coworkers.toList
}
虽然引入了副作用，但整个方法还是纯的。你仍在进行函数式编程！
scala
def userCoworkers(u: User): List[Employee] = {
logger.info("Collecting coworkers")
val coworkers = ListBuffer[Employee]()
for { d <- departments }
coworkers ++ d.employees
coworkers.toList
}
现在这个方法有了一个外部副作用。这够了吗？在“不使用函数式编程”的要求下，你被要求每个方法至少有一个副作用，但我们并不清楚理想的副作用数量是多少。希望你能通过代码审查。
通过这次练习，你学会了如何轻松地避免函数式编程。
你把结果展示给产品经理。他们没意识到每个人有这么多同事，页面显得非常庞大。他们要求你只显示一个数字。
你需要在非纯函数的情况下进行数字相加。这需要你好好思考一下。
也许你应该问问经理该怎么做。祝你好运。
评论总结
以下是评论内容的总结：
关于函数式编程（FP）的争议
FP并非问题根源
- skybrian认为FP难以理解不在于写纯函数，而在于团队需要共同习惯（"It’s not writing the occasional pure function"）。
- flohofwoe指出长链式数组操作才是可读性差的元凶，而非FP本身（"overly long chains of array-processing functions"）。
FP的适用性与误解
- cies认为FP代码通常更易读且受欢迎（"FP code is often easier to read"），但Haskell的纯函数风格可能损害了FP声誉。
- seanhunter批评作者混淆了FP与非惯用Python代码（"he’s just writing unnecessarily non-idiomatic python code"）。
代码可读性与团队协作
代码风格与团队一致性
- apalmer强调团队需统一编程风格（"align on the style of programming"），混合风格会导致维护困难。
- astrobe_提出代码应针对读者水平编写（"think about the 'audience'"），但无需过度简化。
管理与人际问题
- busterarm吐槽工程师的脆弱自尊（"software engineering types are fragile creatures"），常导致架构推翻重做。
- aleph2c认为管理者应促进内部培训而非禁止技巧（"perfect time to set up peer-to-peer training"）。
语言选择与开发体验
小众语言的代价
- imtringued指出选择Scala等语言需承担培训责任（"accommodate the inexperienced developers by training them"）。
- ChrisMarshallNY自嘲为雇主写代码时需妥协（"write code as if I just started yesterday"）。
OOP与FP的对比
- nor0x表达对OOP抽象化的反思（"drifting towards classes and abstractions"）。
- jondwillis提到近年语言正吸收FP特性以降低门槛（"making functional programming look more like imperative spaghetti"）。
其他观点
- 极端言论：tsss认为无法理解复杂代码就该转行（"reconsider your career"）。
- 讽刺调侃：yohbho模仿管理层对FP的恐慌（"Management was clear that this would not be tolerated"）。
关键分歧：FP的支持者认为其优势被误解，反对者则认为问题在于滥用或非惯用实现，而团队协作与代码可读性标准才是核心矛盾。