我的天

理清思路比其它都重要，搞清楚整个流程，知道自己在做什么，比非常勤快地不断地猛做靠谱。今天早上，我总算在7:30之前，完成了昨天数据的汇总。因为经过昨天的各种记账以后，我有点明白那到底是怎么回事。的确，上级的要求很变态，通常要求你按批次去汇总，一个批次里面可能有多个单位，通常来说他们会要求每个单位都分开。有些时候只需要一个批次的总数。这还不是最烦的，更烦的出现在某些账目里，需要分列客户的属地，于是一个批次里面有N个客户，可能会有M个属地，也可能会有N个属地。N和M的关系非常难说，具体情况会如何，运气好的话就刚好是一个客户一个属地，运气不好的话可能是多个客户一个属地，但是却仍然有多个属地。账里要求你把同一个属地的所有批次都写进去，等于那是按照属地分的，但问题是得把多个标的的加起来。而更多时候报送时别人总是要求你分批次分客户。其实这些对应不难，但是却很烦。尤其是当你一个批次的东西还放在接近30个仓里面，每个仓都有变动的时候。今天之前我在烦的东西，除了这些批次客户还有什么船号。但今天我想通了一个问题，船号是什么根本不重要，对我来说重要的只是仓号。批次客户仓号就是我需要的全部。船号和车号对我来说都是一样的无所谓。当然如果我要做另外的统计汇总，船号就比其它都重要，因为有可能要做某个客户所有船号或者不同船舶吨位的分类汇总。所有的这些信息只有在一开始的时候就理清思路，如果往后再回过头来，基本上已经没办法再搞清谁是谁了。如果连我这种愿意折腾的人也搞不清，别人就非常有可能更加是乱成一团。之前让我混乱的是某个客户中了两个批次的标，所以从心理上说，因为客户名称是一样的，我很难把它分出来。但今天我想清楚，其实之所以有这样的困难是因为批次这个分类字段没有被加进去，如果我一开始就是按批次区分的，无论那个客户出现在多少个批次多少次都无所谓，对我来说那个客户名字上是一样的实际上身份不同，你直接把它当成客户的分身就可以。名字是一样的，但性质不同。

因为变化汇总的要求很多，如果没有对数据进行透视表方式的处理基本上是不可能完成任务的，我很庆幸，在搞这一摊东西之前，我越发的熟悉数据透视表这个功能。有了这个东西只要我的基础数据分列得足够详细，我就可以得出我想要的汇总结果，可以按仓、可以按批次的、也可以按客户。当然如果你硬性要求还得分什么车多少船多少，会有点难度。但是这个也未必不可能，因为从我们现在的这个称量单号生成规律还是可以把车跟船轻易地分离开来。但是要做到这个，最恰当的方式是一开始的时候就做好分类标识，就像我在那些分类标识里面又添加了批次这个选项一样。自从单位开始有船进出以后，我都每天都过得很郁闷，首先烦那些船的数据到底有没有输入，其次是那些船到底属于哪个单位、属于哪个标的，。没有一个系统是完全靠谱的，所以最终我还得自己搞清自己到底想怎么样。今天是这个月最后一天，估计我们单位的不会让我好过，所以不可能在今天下班之前就结束这个月的账目。但是月末这个数耗在那里显然麻烦非常大。为了这个我已经郁闷好几天了。

有种被掏空的赶脚。

去做一些，对别人来说几乎是不可能的事对我来说有相当大的成就感。昨天我就花了接近五个小时的时间去做这种事，但实际上一开始的时候，我并不知道我可以做到。甚至在开始的时候，我想都没想过我要做这种人，因为我只是打算找出我自己的毛病，结果却找出了系统的毛病。这种错乱可能早已存在，托利多这个世界上最有名的称量产品制造公司可能早就知道他们的东西有这样的不足，但是我却是这个单位里第一个发现这个问题的人。为什么别人就没有发现？我却发现了呢？因为一定程度上，我对自己写的程序有信心，我觉得那不可能出错，如果出错了，唯一的可能性只能是，我之前遵循的那条规则以外还有一些特例。

昨天一开始的时候，我只是想核对一下数据，接着发现数据差太远，有些根本没办法核对，造成那个的原因是操作人员在实际执行过程中没有完全按照正确操作去做。这是没办法挽救的，也只能按照他们记下来的那个时间点去计算，几乎可以这么说，那些数据是无法核对的。但另外有一些能核对的却很神奇，因为我那个程序计算出来的数值跟他们记录下来的就只差那么一点点。可能是两公斤，也可能是四公斤，也可能是八公斤，为什么会造成这个问题呢？之前程序之所以不能完全使用是因为第一称和最后一称的问题，但显然这公斤级的问题不是那个，问题到底出在哪里？我找了一条不算大的船检查，只有157斗。然后沿着斗数一个一个往下看，157斗数量没错，净重也没有出现逻辑以外的东西。斗数没错，净重也没有神经病，但为什么累计重量却不一样呢？到了这个程度，靠人肉去看是不行的，所以我直接把净重和累计重量连贴出来，然后用Excel累加一下。结果发现了惊天大秘密，某个数，如果按照上一个斗的累积重量加这一斗的净重得出某个数值。但实际上系统记录的累积重量却比那个数值少了两公斤。于是这也就很好理解为什么我调用的净重计算总是会比他们记录下来的累计重量多那么一点点。抽查了这几天的一些记录。发现了起码四处这样的问题。这些问题出现的频率很难说，有可能是40分钟，也有可能是一个小时。发生这种事感觉挺反人类，因为做一个程序设计的，不是应该首先得出净重，然后用净重去计算累计重量吗？但显然他们可能不这么干。至于托利多编程的人是怎么想的，真的不知道。如果有一天客户要求打印每一斗的详单，这该怎么办呢？当然不是每个死变态都会把净重全部加一遍，看一下跟累计重量是不是一致，因为所有人都会默认，累计重量就是从净重加出来的，实际上从这个系统看来，却不是这样。这个问题简直就是未解之谜。两公斤刚好是散粮称的最小刻度，一跳就是两公斤了。如果几百吨的船，出现两公斤的误差，完全可以接受。如果我们的人最终打单的时候选择选择我们自己写的查询程序，只要之前他的操作，一直都没错，也没有问题。这种事情居然被我发现了，我莫名的感感到很大成就感。我们单位的中控那里一共有四台散粮称。出现这个状况的貌似只有其中一台，其余两台用过的，对了一些可核对的数据，都没有问题。四台散粮称的程序完全一致，所以发生这种毛病也就只可能是某一台秤的某个传感器不知道哪里出问题了。出问题这很正常，毕竟这套设备买回来已经接近十年了，虽然从前我们用得不多，但是电子元件这种东西即便你不用，过了好长一段时间，也是会有毛病的。有毛病不是问题，重要的是你得把它发现出来。然后才好说后续要怎么办。

折腾的人生是痛并快乐着的。

昨天还说我要适应的是两个系统，但从今天开始两个变成了三个。这就让人相当的郁闷。为什么三个系统加起来才等于一个完整的数据体系？为什么三者的数据之中总会出现一些数据某些地方没有你必须在另外一些个地方打开？跟国内软件全部都做得高大全完全不一样，我们这里的数据简直就是一团糟。在这样的情况下，根本就没办法对大数据进行分析，因为数据都是零散的。真想不明白那个所谓新的智能粮库管理系统的设计者到底是什么思维。估计他们觉得用这个系统的人可以完全信任他们的系统，所以你只是在里面查询数据而已，而不需要用另外一种方式检验或者备份。这样就会相当的危险。而且他也没考虑过，在我们这种特殊的单位，总是有无数多的表需要报送，而且他们需要的还不只是一个汇总数，连明细都需要，如果没有导出没有分得足够细的分块功能，怎么能做到这些呢？之所以发生这种事，其中一个原因也和我们自己人有关。因为我们的人跟他们一起谈要求的时候并不知道我们库居然有这种要求。当然负责这个项目的人不可能什么都知道，但既然有一些不清楚的地方，就应该找专业了解这一块的人认清需求。但显然，在整个智能系统开发的过程中，他们只是选了一些他们觉得应该了解情况的人，但实际上那些人加起来了解的情况是不是就等于全部呢？显然不是。在实际使用过程中我们就发现了很多问题，凡是做过的人都会知道那不合理，但就是因为曾经被他们拉入某个小组的人并不知道这些情况，所以他们跟设计都是蒙的，而且他们蒙的方式还很随便。当真正要使用的人去使用那个东西，会发现完全执行不了，或者说相当的麻烦。对某些人来说，那种麻烦程度已经等于那是完全不能用的，直接会让人望而生畏的。他们不可以，把所有东西都想得很细，但有时那种麻烦已经让我的工作已经无法开展的时候，我自然就会有这么一个念头。是不是因为他们太自私，所以完全没有以发散的方式考虑别人可以怎么做呢？有些东西其实稍微扩展一下，你就会明白。而更多的情况是，如果你对那一片完全不了解，为什么你还不提出要求呢？既然你提不出要求，你就找个能提出要求的人来实现不就好了吗？显然负责开发我们系统的那些人脑子不太好使，你经常跟他说要这么干，但是出来却是另一个效果，因为他的理解能力有限，又或者说他们的实现能力有限。有些时候他们实现不了的东西甚至要我们帮他们想办法该怎么做到。编程的人脑子不好使问题很严重。一开始我就说过，如果做我们系统的这些人不是在现在他们这个单位，而是在其它软件企业，早就被炒鱿鱼了。也正是因为他们有这个单位做保护伞，所以他们才可以持续这么糟糕。现在我不是领导，如果我是领导，我就不会选择这样一家单位去开发我们的系统。老是选择一些血缘相近的单位去开发，最终的结果就是很糟糕，但是你还不得不接受。

在麻烦自己的问题上，大概只有我在做加法。

归档：2017-09-28 Ghajini

星期三 2017-09-27 18:05
平均心率153，最高心率171，平均配速614。今天感觉继续很热，事后看看天气，果然很热。这真的是秋天吗？秋天在哪里？！今天是广马半马抽签公布的日子，我木有中签，感觉很坦然，松了一口气，今年的状态出不了PB，甚至有可能半马需要220开外，不如不比。#xrspook未行够#

为了能做到一键复制，我不得不把两个系统通过Excel导出，然后用另外一个Excel处理，最后复制粘贴。步骤有点繁琐，但起码这样不会出错。Excel在单元格填数字方面还是很强的，但问题是另外一个系统的来源与去向真的让人太抓狂。光从设计的角度，他们那么干无可口非、可以接受，但是从数据处理的角度，那绝对是坑爹的。地磅系统的数据就不这样，区分来源与去向是从类型那里分出来，一个是出货，一个是进货。或许信息系统这两个类型不能完全表达清楚，但还是可以在那里分列导入导出转入转出。仓号就是目标的仓号，而客户则无论是进货还是出货都写在那里，如果是倒仓，就写不是目标仓的那个仓号。这些其实都很容易解决，如果你把它放在数据库层面归类的话。

有一个我觉得很神经的是既然你前面已经写了那边是进货还是出货，为什么后面你还得把出货的数据加一个负号呢？加负号这种操作，只有在统计库存的时候有用，你总不能数据库写入的时候就直接给它加负号吧。如果是我设计那个系统，我就会有一个辨别的操作，如果是进就乘以1，如果是出就乘以-1。这个相乘后数值的操作只针对库存而言，其它地方进货和出货都是一个正数。也只有这样，才能在明细列表导出的时候，让最后的总数靠谱。试想一下，你在明细导数据，无非想看一下一个时间段里面进出货是多少，但如果在那个时候出货已经是个负数，就让你纠结死，你还得把负数全部都加一遍，然后把正数再加一遍，最后把那两个和加起来。这种操作显然是反人类的！而之所以那么干，非常有可能是软件设计的人没有考虑到这一点。而他们之所以没有考虑到是因为他们只是按照他们的思路去做，但是他们却只是一直在写代码，而没有进行过整个流程的实际操作。只要他们做过三天的账，他们就明白这样整法，是不可行的。

数据必须从两个地方倒出这个事实我已经接受了，无法改变。从之前的一个仓里面有多个客户的多条数据，到现在一个客户里面有多个仓的多条数据，我也接受了。幸好我用作汇总的是数据透视表，所以到底是客户在前仓在后还是仓号在前客户在后，我都可以用很轻松的拖拉方式实现。问题只是什么时候用什么方式得由我去决定。在做这个决定形式之前，我就必须得先判断到底哪一个才更方便。无论是按照客户汇总，还是按照仓号汇总，总会出现某些客户或某些仓多次出现。这就变成了一道找共性的题目。无论我用什么方式排序，还是会存在这个问题。正常来说，我们当然希望这种事情不发生，但实际上这种事情却天天都发生。你唯有改变自己去适应。记得好像有个搞笑诺贝尔奖里面，其中一个获奖者就用流体力学证明了猫是固态，也是液态。因为液态的描述是可以根据容器的形状改变自身。我们也需要这样做。就像李小龙说的那样，我们要像水流，要不断随着河床改变自己。让别人去适应我们，或者让事实都按照我们料想的方式发展，这绝对是不可能的。但我们却可以让工作尽可能地舒服一点。但要做到这样，首先你要有这样的心，然后你得有这样的技术。

随着月末的来临，我感觉压力逐日在增大。