@ding2dong #32

谢谢！原来还有这种操作，以前我都是搞不清楚有啥活动就不参加了。

同样的问题，感觉全世界都和自己作对一样，后面看了一些书，感觉比较好了，OP 可以试下阅读《 the master key system 》、《像水一样吧，朋友》。

@ding2dong #26

> 我把我的购物清单让客服合计下最终价格和能参加的活动
是发送购物清单给 店铺的客服 还是说 什么客服

@tetora #13

> 主要是上班都一堆破事了，下班还哪来精力看这些
* 所以就得看相同花费的时间用来工作的收益高，还是用来薅羊毛的收益高。出来工作之后，我一般都是要买的时候就直接买。最多领个券，那些要 完成任务 什么的，我一般都不管的。

> 他妈还是下半年项目多的时候才有活动，天生和打工人冲突的活动
* 这个，没办法。对于你来说是冲突，对于他们，项目的业绩都堆到下半年了，所以才推出这么多活动。我这边差不多也是这样的，一些 ”改造” 、”对接、支持第三方券” 也是在下半年。

还真是，扣扣嗖嗖的，又要玩什么小游戏，又要这、那的

挺赞同 #46 的。同时，我认为想这些这么 ”远” 的，只不过是对当前的不满，同时又不愿意真正从内改变自己，从而以此进行逃避。实际上，如果自己真的像自己口中说的，我想做啥做啥的，为什么不现在就做呢？
感觉有点像是：开口闭口就说各种设计模式，各种性能调优。但实际上一行代码都不写。为啥？因为如果落实到真正开发的话，就会有实打实的挑战。难道当前的项目是卡在性能优化吗？那肯定不是啊，MVP （最小可行性产品）都没弄出来，调个毛优。


以编程中的 ”You Arent Gonna Need It” 原则进行指导，以健身为例：

if 健身需要的时间 > 24 小时 - 工作时间 && 喜欢健身 > 喜欢工作:
{
辞职投入健身;
}
else:
{
一边工作一边健身;
}

+1 我还是遗传的，不仅手出汗多，身子也容易出汗。搞到连牵手都不敢了...

@tikazyq #2

感觉会人因此不想去用，至少我被劝退了

不登录就没办法使用吗？

1. “目前只支持单个转换 不能并行转换” 这个指的是用户 A 每次只能转换 1 个，还是说用户 A 、用户 B 、用户 C 加起来只能转换 1 个，若 A 转换中，则 B 、C 阻塞？

2. 你有什么比得过 https://freesubtitles.ai/ 的？无恶意，单纯觉得人家已经有了你所说的 “后续提供 api 接口直接调用，提供付费服务” ，那么是否意味着你比人家的功能还少？莫非你打算通过推广来赢得市场还是啥？

3. 免费用户一直用脚本调用你的功能，你咋办？因为我正好有音频转文字的需求，未登录的用户，你该如何防止？还是说需要登录才能使用功能，通过登录用户来进行精准限制。

接上 #70

首先你的需求是：
1 、脂肪肝-->健康身体
2 、焦虑症-->快乐

问题 2 可能会在解决问题 1 的时候修复，且问题 2 是比较难验证的，故这里只提如何解决问题 1 。我并不是非常明确实际脂肪肝的症状，所以只是举个例子。我的刻板印象是 脂肪肝=胖 ，故消除脂肪肝等于消除肥胖。所以问题 1 的解决目标是：消除肥胖。而阶段性的验收标准姑且设立为：早上空腹量的腰围比上个周期要少 2cm 。

那么迭代的优化指标有了，接下来就是找技术实现。可基于 “健身” 框架，采用力量训练及有氧训练两种技术栈进行实现。首先先进行简单的实现（直接堆代码上去）：随便看几个视频，左动动，右动动。发现性能提高了一点（腰围少了 1cm ），但是又感觉实现得不太优雅（动作错误等），继续学习对应技术栈（可考虑付费等），然后不断循环进行迭代，直至完成需求 1 的性能要求。

“对生产环境要保持敬畏” 。若你使用“力量训练”技术栈进行功能（减脂）实现时，没有注意好代码规范、内存安全等（指的是：动作标准），有可能会导致生产环境崩溃、异常等（指的是：身体损伤），如果生产环境出的问题足够大，这家公司可能就倒了，所以建议要么找认识的老师傅带，要么自己埋头钻研知识，或者是花钱找老师。最好还能有 codereview （别人帮忙看你的动作 / 计划）。

定需求、定指标、进行开发、验证、持续迭代，这个系统慢慢就会好起来了。

而对于是否需要裸辞，我认为需要明确造成现有问题是否需要通过裸辞来解决。裸辞带来时间和精力，如果裸辞可以带来的时间和精力分别都为 10 等级的话，验证是否需要裸辞的方案可以是控制变量法：逐步递增自己可支配的时间和精力，查看自己的问题是否有延缓。若无，则自行找其他方案看看如何减缓问题。若有，则可以增加到某个等级的时间和精力，测试，是否真的需要 10 级才能解决这个问题，否则，可找个能满足可分配时间和精力等级足以解决问题的工作。

实际的系统很复杂，而且我不是你们公司的，我不懂你们的系统，OP 你是你们公司的老员工，这座屎山，堆了这么久，只要你坚持[童子军原则]( https://mouse0w0.github.io/2018/10/04/Programming-Principles/)，相信你的系统迟早可以变成高可靠性，高可扩展性，高可维护性

“多年工作身心临近崩溃边缘脂肪肝焦虑症，目前是有房有车无贷款且有 15w 小金库一年饿不死，辞职健身一年是否可行”
“多年堆积的代码屎山导致无法拓展、有隐藏的崩溃风险，目前是正常运行且当前系统的完备程度可以使得未来一年无需强制发版，一年不迭代是否可以修复这坨屎山”

看到了你的附言：
“我尽量保证不脱产的情况下加大训练强度再试试看，如果实在精力不够了再完全脱产去调整”
“我尽量保证坚持迭代的情况下，每个小版本慢慢重构，如果发版压力太大的情况下，再停止发版，进行重构”

而大家提出、或者 OP 最终选择的方案，让我联想起编程开发中的某些思想
[Do The Simplest Thing That Could Possibly Work]( http://wiki.c2.com/?DoTheSimplestThingThatCouldPossiblyWork)