我是外企外包，男朋友以为我是正编，跟他坦白了会被分手吗？

刚看到个贴子，有网友说自己在外企外包岗位，男朋友一直以为她是正编，她很纠结要不要坦白，怕坦白了就被分手。

评论区还有个前985阿里程序员说，自己被裁员后前任马上态度变冷了。

程序员圈子其实很现实。你是外包、是正编，大多数时候别人根本不关心你的努力，只看“价值”标签。职场也是这样，老板和同事很多时候认的就是你的“产出”和“title”，就像刷代码性能，跑分摆在那里，别人不会关心你调试多辛苦。

网友说被裁后态度变化，其实反映的就是“社交的本质是交换”——能提供什么资源、机会、面子。

不过话说回来，坦白身份没什么可丢人的，真在意你的人，不会只盯着你是不是正编。换个角度想，外包也好正编也罢，生活总归还得自己去debug，别太在意外界怎么judge你。【备注:文末可领最新资料】

算法题：计算产品最终价格

我前几天晚上十一点多，就是在我们小区门口等外卖的工夫，小李给我发微信问我，说他要写个“计算产品最终价格”的方法，用 Java，结果有点绕晕了。

其实这个东西吧，生活里还挺常见。你看，咱买东西，原价嘛，然后有满减、有折扣券、还可能要加上运费、税啥的，最后那一串加加减减，脑子糊涂点就出错。我说你别慌，我来给你扯两句，别上头。咱就以最简单的超市买东西为例。

算法的事，还是得结合场景

你说有时候，有促销——比如原价199的那个运动裤，给你打个八折，或者满100减20。然后又叠加个什么5元优惠券。还有的时候电商搞活动，折上折，这算法要是写死了，第二天老板说活动改方案了，你就得全改。我印象里前年双十一我就在办公室改过到凌晨三点，头都大。

思路简单点，就三步：先把原价拿出来，挨个应用各种优惠，最后加减杂七杂八的费用。最麻烦的地方，就是优惠一堆，顺序、叠加规则还经常改。所以要写得灵活点。代码大概长这样：

publicdoublecalculateFinalPrice(double basePrice, List<Discount> discounts, double shippingFee, double taxRate){
double price = basePrice;

// 先应用所有折扣
for (Discount discount : discounts) {
        price = discount.apply(price);
    }

// 加运费
    price += shippingFee;

// 算税（比如税是按折扣后加运费的价格）
    price = price * (1 + taxRate);

// 保证价格不会是负的，现实里也有最低支付金额的说法
return Math.max(price, 0);
}

上次我有点困，少写了个小数点保留，这里要记得最后保留两位小数比较保险，不然前端会找你麻烦。

你再说点实际的，别太空

有一次啊，我们组的老王买iPhone，叠加各种券，最后那数字都快看不懂。他那天还专门问我：到底先满减还是先打折？我说一般先满减，再打折，最后用券。但电商平台各有套路，有的平台券先用。这事你要是写死了，明天就被怼。

所以最好把每种优惠做成独立的类，有个接口 apply(double price)。比如：

publicinterfaceDiscount{
doubleapply(double price);
}

publicclassPercentageDiscountimplementsDiscount{
privatedouble percent;
publicPercentageDiscount(double percent){ this.percent = percent; }
publicdoubleapply(double price){ return price * (1 - percent); }
}

publicclassFixedAmountDiscountimplementsDiscount{
privatedouble amount;
publicFixedAmountDiscount(double amount){ this.amount = amount; }
publicdoubleapply(double price){ return Math.max(price - amount, 0); }
}

有啥新优惠，直接加新类就行，逻辑不冲突，晚上脑子糊涂也能写出来。

别忘了校验和异常

之前有兄弟用double算，结果被坑了，一堆小数点后很多位，前端一看直接不认账。还有那种价格负数的情况，必须要兜一下底线。不然用户买东西还倒给他钱，那是真得离谱。