人家根本不是注册，是你的短信接口被用来做短信轰炸机了。不能修改的话无解，顶多根据号码和 IP 做调用频率限制。

@misaka19000 持续集成说白了就是 DRY 原则的工程体现——所有需要重复的都用自动化解决。持续交付牵扯到项目发布的方式，缩短发布周期，利用 CI 系统快速验证，然后做持续交付。这些都是要一步一步来的，而且项目管理方式的基因也要符合整个思想才能做到产出最大化。

CI 的意义在于快速验证工程结果，符合敏捷开发的思想。 CI 的作用在于用机器代替人来完成各个环节，降低人为因素出错的概率——持续构建只是其中一部分。

无论项目大小， CI 都是有意义的，但是小项目不用盲目追求 CI 覆盖各个环节，自己平衡好投入产出比解决关键问题即可。

淘宝有 TPM 加密卡，不过不知道是不你要的那种接口的。

@poorcai 需要看公司开发流程上的持续集成程度如何，如果只是要你通过现成工具弄个自动打包编译，发布什么的，顶多就是写写脚本，了解下各个平台编译器配置（如果有多平台项目的话）。做得更进一步的话，会有自动化测试、自动交付这些。根据实际情况不同，可能会变成专门写自动测试用例，或者做贴合公司项目的运维工具 /平台。

另外说一下， DevOps 这个虽然已经有概念了，但是小公司来说其实差不多就是一个人所有活都干的意思。

要是问“对编程水平的提高有没有帮助”，只能说还是有帮助的，不过如果跟你的规划有冲突的话，不算是个性价比高的选择。

其实说到底，所谓的编程水平如果只是“工具”的使用熟练度的话，只要工作内容会使用，这方面倒是没啥区别，只是职业 title 不一样罢了。现在招聘开发运维也都是要求有前端技能、数据库这些，看平台的话还要求熟悉 linux 相关的工具链，脚本语言。

另外，我很想吐槽有的公司，招前端的工资开得比开发运维工资高，但是开发运维岗位又要求前端技能一样不少，工资还少......

持续集成是一个工程方法，一种思想， Jenkins 只是一个工具。

要么忍，要么滚。

又一个品牌宝呗，还有什么说的。在中国想做一个 android 党，你得先有一台 iphone 。:doge:

@bumz 哈哈，工程师和艺术家是两种职业。

建筑设计师总归是少数，砌墙工人的收入也比低级设计师高得多——说不定当个包工头比设计院那些加班的那帮苦逼们要滋润多了。

只是为了赚钱，自然有着每个人的最优解，但是，最优不代表最有趣。给我来说如果做程序员却要放弃创造力这种可能，还不如回老家卖猪肉呢。:doge:

野生半个程序员出来说一下吧。

很多情况下，确实用不到算法。这个跟工作内容有关系，毕竟现在分工这么细致了。算法能锦上添花，但是不会算法，也是能解决问题的，虽然会有一些“效率”的问题——但很多情况下“效率”不是问题。

打比方说的话，扫地这个工作谁都能做，但是合理规划能提高效率，问题是上面验收的人只要你一天内完成，至于你是 3 个小时，还是 1 个小时，不好意思——工资是一样的。

同样解决一个问题，写一堆 if else 和一个函数式，水平差距还是有的——最简单的位运算，我这家公司开了 3 个小时会跟前后端开发讲，还有人弄不太明白，而且还有人说，用字符串判断也是一样，更容易做一些。

总的来说，如果你处于底层，那么算法对你的收益确实很低，远没有你学个框架，熟悉一下各种 API 来得高。但是，请看清楚一点，现在各种开源库，框架，工具，文档中文化，让进入这个行业的门槛越来越低，当你上升到一个阶段时，你会发现——各种问题都要算法来解决。

总的来说，机会永远是留给有准备的人。

求个连接

个人觉得，如果楼主真的很了解 http 协议的话就不会发这种问题了。:doge:

@Felldeadbird 貌似金蝶是按年转结的，转结之后第二年是以上年的下存作为期初，如果要改，只能改上一年的结存数据，但是并不会影响次年的期初。没有转结的话，基本上就可以看成多久的单都能改了。不过反审核之后重新审核，审核时间必然会变，应该会影响到统计。

其实财务账和货品进销存还是有区别的，财务一般是借贷记账法，但是货品进销存没貌似没看到有这样做的。

@mhycy @mhycy 说到底是没理解真实的需求。进销存来说，软件上只要你计算方法没有问题，根本就不存在所谓的“不正确”，只有“数据与实物不符”。

这个背后的问题就比较多了，可能是使用者输入数据有问题，也有可能是实物出现了问题。然而，不管是哪种情况，都不是靠软件能解决的。从录入者的角度看，只会说是“数据错误”——因为不是数据错了，就是他有错了。从管理者角度看，出现“数据与实物不符”是要查明原因才行的，否则还不如直接手工得了。

假设管理者并不在意这一块的问题，那么直接允许修改数据看起来似乎是个很简单的方法，但实际会破坏数据的严密性，会造成真正的数据错误。

个人认为允许修改，但必须有修改记录才是正确的解决方案。至于，其他各种有关统计时间的问题，其实都是能解决的——难度问题罢了。不过，进销存说到底最终也就是顶多有个性能问题，反正数据库编程嘛，不考虑性能，实现出来还是没有什么难度的。:doge:

@mhycy 简单说是：记录差异，合并数据。基准加上差异数据，就能取得任一一次修改的结果。用他能理解的方式就是，把月结数据看成一个基准，修改数据看成“差异”，这样以月结作为点，配合差异，就能取到想要的结果了。

@refresh
修改历史数据需要做单。这样不需要修改每月的结存数据，报表统计时，按最近的结存点作为起点，然后把单据参与计算统计结果，实际上这样做也能解决运算量的问题。

修改流水必须要做限制，不能允许修改已经结存的日期之前的流水，如果允许这样操作了，必然会造成客户不同部门之间的数据差异——比如财务已经统计过 10 月份的数据，仓库又去修改了 10 月份的流水，从制度上来说，既然财务已经认可了结存数据，再想修改，必须能让财务知晓。（也有设计成必须删除掉前面一次结存记录才能修改的，这样不需要多做一个专门修改历史数据的模块。）

设计业务逻辑的时候请时刻记住，软件是没法管理到实物的，只能管理数据。所有的数据一旦有确认操作，之后的修改最后是有流水供查询，否则撕逼不可避免。