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

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

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

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

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

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

求个连接

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

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

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

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

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

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

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

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

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

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

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

做单冲减，不要直接修改，以免数据统计结果不符合用户预期发生撕逼。另外，性能这种事情就直接事先告知，书面留底，后面出现性能问题再来加收费用或要求升级硬件。

@aias 其实两边都是年轻人，你只是把一个可以预见的结果说出来了，而且 HR 居然也较真了——谁都知道一个人在同一家公司干一辈子那是基本没可能的。

也许有一天你也会很从容的说一些让双方面子上都能过去的辞藻，这个 HR 遇到向你今天一样的人也只会微微一笑，甚至说一些恭维的话语，然后转身刷掉面试者。

至于说谎倒是没必要，可以先讲一些自身的技术方向的规划，对职业生涯的期望，然后非常官方表示：好的企业会给予员工能力对应的待遇与回报，期望和公司一起发展，收获巴拉巴拉。如果觉得对方不爽，可以加一句：即使企业没有给予，相信市场也不会亏待能力强的人之类的。

企业喜欢能力强的没错，不过企业同时也不喜欢“聪明”人——各种意义上的。
从某种意义上说，这 HR 和你是一类人，所以说同性相斥还是有道理的。:doge:

总结一下，死要面子活受罪。

@bleaker 没什么问题，配合 docker on windows 可以解决很多问题。 agent 跑 docker 里面就能解决编译环境问题，而且只是 android 的话 windows 下面加好 java 编译器参数也是一样的。
假设带宽不是问题，首先需要一个公网仓库，通过 git hook 触发 ci 构建，构建完成后上传。
gradle 本地脚本中要增加下载，安装 apk 的 step ，基本上就能实现了。

小孩子才分对错，成年人只看利弊。

我反正是很反感一些人上来就先贴个标签，带个帽子然后把别人批判一番——这跟以前的红卫兵小毛孩有什么区别？

技术选型、推进说白还是博弈，每个人的利益点不同。当然，有些人就根本不是理性经济人，这种人你就不要和他一般见识就好了。

如果当前项目管理方式没有问题，或者问题还不大——大不了加加班，也能解决。作为管理层，如果新技术不能带来“利益”自然是没什么动力推进的，再说了，很多混到管理的“大龄前码农”，下班了还得去抱老婆带孩子。学习成本再低那也是成本，而且风险再低那也是风险不是？

作为下面的码农，这些依赖管理工具， CI 理念又不能直接加工资，毕竟大多数公司招人最重要的还是靓丽的履历表，那些高大上的技术关键字才符合 HR 的基本价值观。

道不同不相为谋。楼主稍微推一下就行了，公司项目代码管理什么的就别掺和了。该继续加强自己就继续，没什么加强的就准备换换环境——就算没法改变世界，改变一下自己还是可以的。

带宽不够的话，还是得泡咖啡。:doge: