知易行难，大家都希望自己别遇到屎山代码，但真到赶需求的时候是否能遵循原则 。 推荐 B 站好视频

BiliBili

我覺得「複雜」在每個人看來確實是不同的，應該和思維習慣有關係，我覺得最簡單的代碼結構是不用參數，除了 initialize 的時候。

例如對一個有參數的方法，

class A
  def m b
  end
end

我會考慮寫成這樣：

class AxB
  def initialize a, b
    @a, @b = a, b
  end

  def m
  end
end

一般來說AxB是會有一個更適合的名字，可以反哺給產品用，這樣溝通起來比較方便。但總之是，給定一個 type 我們可以知道它一定有哪些 property，這些 property 的有效性是 unconditional 的。如果大部分代碼都這樣組織，那麼加東西的時候就找找要加的東西依賴哪些，加到合適的層級就好了，改動應該會比較小。

这个我会看情况，如果方法行数短，放在 A 类里也无所谓。

class MemberOrder
  def apply_festival_discount(discount)
    member_price = @amount * @base_discount

    if @amount >= discount.threshold
      member_price -= discount.bonus_amount
    end

    return member_price.round(2)
  end
end

如果行数长，我会考虑拆分。而拆分又分 3 种情况：在当前类中拆分，在参数所在的类中拆分，在新类中拆分。

需要新建类来拆分的，就是我上面这个例子：即有当前类属性和方法的深度参与，又有参数所在类的方法的深度参与。我换一个长一点的代码：

# 请忽略各种硬编码等等与讨论主题不相关的 bad smell，例子是我让 AI 按我的要求临时生成的
class MarketingCampaign
 def remaining_budget_ratio
   (@total_budget - @used_budget) / @total_budget.to_f
 end

 def calculate_success_rate
   case @campaign_type 
   when "seasonal" then 0.8
   when "flash" then 0.6
   when "normal" then 0.4
   end
 end

 def budget_adjustment_factor
   if remaining_budget_ratio > 0.7
     1.2 
   elsif remaining_budget_ratio > 0.3
     1.0  
   else
     0.8  
   end
 end

 def calculate_advertisement_cost(platform_info)
   # 基础广告费计算
   base_cost = platform_info.base_price

   # 根据平台受众规模调整费用
   audience_factor = case platform_info.daily_active_users
     when 0..10000 then 0.8
     when 10001..100000 then 1.0
     when 100001..1000000 then 1.2
     else 1.5
   end
   adjusted_cost = base_cost * audience_factor

   # 根据活动成功率调整费用
   success_factor = 1 + calculate_success_rate
   adjusted_cost *= success_factor

   # 根据预算情况调整费用
   adjusted_cost *= budget_adjustment_factor

   # 根据平台评级调整费用
   rating_factor = case platform_info.platform_rating
     when "S" then 1.3
     when "A" then 1.2
     when "B" then 1.1
     when "C" then 1.0
   end
   adjusted_cost *= rating_factor

   # 根据广告位置调整费用
   position_factor = case platform_info.ad_position
     when "homepage" then 2.0
     when "search_result" then 1.5
     when "recommendation" then 1.3
     when "category_page" then 1.2
   end
   adjusted_cost *= position_factor

   return adjusted_cost.round(2)
 end
end

calculate_advertisement_cost 中即有参数 platform_info 的 base_price，daily_active_users，platform_rating 等方法，也有本类的 calculate_success_rate, budget_adjustment_factor 等方法，这时候你说的 AxB 就很好用了：

把 MarketingCampaign 的实例和参数 platform_info 传入新类 CalculateAdvertisementCost 的构造方法，当作新类的成员变量 @marketing_campaign 和 @platform_info。然后把 calculate_advertisement_cost 里所有的内容全移过去，再在新类里对其进行拆解。

class CalculateAdvertisementCost
  def initialize(marketing_campaign, platform_info)
    @marketing_campaign = marketing_campaign
    @platform_info = platform_info
  end

  def calculate
    # ...
  end
end

这样的话，@marketing_campaign 和 @platform_info 作为新类的成员，作用域是整个类，在整个 CalculateAdvertisementCost 里都可见，拆分就容易得多了。我想你说的“這些 property 的有效性是 unconditional 的”也是这个意思？

但再回到前面短一点的那个例子，你说非要把它移到 AxB 里行不行呢？我觉得也是可以的，也很赞同。但同时我觉得不移也行。在这种比较边缘的情况下，我自己会有一种选择，要是同时别人用了另一种选择，我也没意见，因为我自己有时候也会选择另一种。我觉得写代码很多时候存在这种情况，你即可以进一步，也可以退一步。许多重构手法都有相应的“逆手法”。比如你即可以“提炼方法”，也可以“内联化方法”；即可以“引入命名参数”，也可以“移除命名参数”。

不过如果你的意思是方法一个参数都不能有，不分情况，那在我看来又似乎有点过头了：

def apply_festival_discount(discount)
  member_price = @amount * discount
  if @amount >= 1000
    member_price -= 50
  end
  return member_price.round(2)
end

像这种只有 1 个简单数值（非对象）参数的方法，代码还是挺正常的。如果有 2 个或以上，我会开始注意它：如果这个方法的计算过程长，那这里的参数带来的坏处跟临时变量差不多——会把方法越拉越长，需要考虑把它变成成员变量。

这里的关键，是“改变内部结构”、“不改变外在行为”。理解了这一点之后，“重构把代码改出 bug”这样的认知错误自然就不存在了。

有测试才行

那要是没有测试怎么办呢？

可以以产品经理的身份在产品的角度优化一下

这个国内有叫需求让步的，英文里是 trade-off，软件/系统设计常用手段。

设计的话，个人喜欢这本 Principles of Computer System Design: An Introduction

前司更喜欢聊架构，代码方面的没人花心思说。技术负责人，有不少开源项目，代码质量没啥问题。不过他不会强调这些，也没人聊这个。