码农请进，谁遇到过这种情况？

Sternzeichen · 发表于 2014-2-5 22:00

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

您需要登录才可以下载或查看，没有账号？注册

×

本帖最后由 Sternzeichen 于 2014-2-5 21:05 编辑

本人码农一枚，刚工作不久，最近遇到一个难题，想请教下大家怎么解决。

本人是informatik专业毕业的，读的是纯info不是 wi-info. 现在在一家公司做银行方面的软件，问题是：

工作虽然是编程写代码，但商业逻辑十分复杂，而且都是经济方面的知识和概念，编程倒成了次要的了，本人虽然刚工作不久，但从开始工作到现在下班以后从来没有看过专业书，也就是说本人掌握的informatik知识完全可以应付工作，因为该系统不需要非常前卫的技术，只需要如java SE，oracle 之类的基础知识即可，关键难在商业逻辑上，该系统十分复杂，类超过50000个，代码总量几十万以上，但坑爹的是该系统没有任何文档和说明，只有一些银行的规格说明书，本人每天工作进行不下去并不是因为编程问题，而是业务逻辑搞不清楚，不知道代码该写到哪儿，如果知道正确的地方，往往马上就可以开发完成，本人感觉现在根本不是程序员了，而是BWLer，而本人之前一点经济课程都没学过，真是苦不堪言。

本人想问下各位码农，你们也遇到过这种情况吗？这种商业逻辑成为工作中的最大难点，而info技术放在一边的情况吗？本人现在时常疑惑，自己到底是学info的，还是学BWL的！

想问下各位码农，大家平时工作都是以啃业务逻辑为主，还是以做info技术为主？

还有对于码农来说，是做纯技术一点的工作更好呢，还是这种商业逻辑为主，info技术次要的工作好？

谢谢前辈们指点！

chinapope · 发表于 2014-2-5 22:11

本帖最后由 chinapope 于 2014-2-5 21:12 编辑

逻辑上抽象，结构上分层分模块

这种系统级的设计文档必须得有，除非这代码库是从别处偷来的。

我估计你的工作也只需要改部分代码，把相关上下层搞清楚就可以。

aua · 发表于 2014-2-5 22:11

不用疑惑，工作需要，学习新知识，多问多沟通。

@Deutschland · 发表于 2014-2-5 22:20

我靠，真的假的，银行系统没java doc？敢问那家银行？

tkkk3 · 发表于 2014-2-5 22:40

绝大多数informatiker（码农）的日常工作都要涉及点业务知识，可能在研究所的同学，或者那些在大公司里不接触一线产品的神级人物会多些理论研究。

非常同情楼主接手“三无”代码，除了自己一点点啃，没别的好办法，放轻松心情，各个击破吧，就是一工作，关键是别把自己搞“抑郁”了就行。

Sternzeichen · 发表于 2014-2-5 22:40

@Deutschland 发表于 2014-2-5 21:20
我靠，真的假的，银行系统没java doc？敢问那家银行？

java doc 也没有，但我说的是商业逻辑的说明文档，例如这个类实现的业务功能，目的，原因？

当然也包括一些技术文档，比如这个业务功能技术上大概是怎么实现的，这个模块是做什么的等等，结果什么都没有，一点都没有！

tkkk3 · 发表于 2014-2-5 22:44

Sternzeichen 发表于 2014-2-5 21:40
java doc 也没有，但我说的是商业逻辑的说明文档，例如这个类实现的业务功能，目的，原因？

当然也 ...

好的代码，本身就是文档，当然，如果能有what, how, why，那算是锦上添花。

Sternzeichen · 发表于 2014-2-5 22:49

本帖最后由 Sternzeichen 于 2014-2-5 22:01 编辑

tkkk3 发表于 2014-2-5 21:40
绝大多数informatiker（码农）的日常工作都要涉及点业务知识，可能在研究所的同学，或者那些在大公司里不接 ...

谢谢安慰，不过自己啃的可能性不大，代码都可以看得懂，就是目的是什么，干什么用的，因为商业逻辑不懂，根本搞不懂，这个最愁人了。

问问上级该怎么办，上级说只能靠大家在一起探讨，他们平时也是通过互相讨论来开发的，没有物质性文档，只能靠程序员经验积累，所有的东西都记在脑子里了，去问问老人吧，可惜同办公室的同事都不怎么友好，不愿意告诉本人，所以唯一的一条渠道也被堵死了，当然也可以理解，1. 平时都有自己的活都很忙，人家没义务教你 2. 同事之间是竞争关系，人家不愿意无偿把自己的经验传授给你，3.这几个同事本身也不是nett的人，对外国人也无好感

所以挺悲剧的，大家还有谁也遇到过类似情况，怎么解决比较好呢？

Sternzeichen · 发表于 2014-2-5 22:55

tkkk3 发表于 2014-2-5 21:44
好的代码，本身就是文档，当然，如果能有what, how, why，那算是锦上添花。

代码看起来没问题，都能看懂的，关键是它代表的商业逻辑非常专业，真的不是简单的从代码上就可以看出来的，不像一些简单的系统，或者常见的业务系统，从代码上能差不多能理解商业逻辑了，它们这个是银行的业务，非常非常spezial那种，其实就算有说明书都不一定看得懂，例如一些概念 value date, due date 这些概念，非经济专业的很难理解.

Sternzeichen · 发表于 2014-2-5 22:57

本帖最后由 Sternzeichen 于 2014-2-5 21:58 编辑

chinapope 发表于 2014-2-5 21:11
逻辑上抽象，结构上分层分模块

这种系统级的设计文档必须得有，除非这代码库是从别处偷来的。

是改部分代码，但根本不是上下层那么简单，弄不懂逻辑根本不知道该在哪里该，该往哪里写，而且需要非常精确，一点错误都可能使结果不对，客户就要返工重做，甚至连测试部门那里都通过不了

adgjl · 发表于 2014-2-5 22:58

我也理解你的处境，但你得从另一个方面看：
1，没有捷径，只能一天一天积累
2，你的职位经验十分重要，而非其他和商业流程无关的纯编程，比如把网页美工的设计编程实现，这种工作经验就没那么重要了。
3，需要经验的工作位置一般来说是很稳定的，因为你感觉很难进步，换一个新人也一样。纯技术水平可以在家自学来练，而你的职位就没法通过自学提高。
4，你的职位的know how本来就不是纯技术。就好像SAP的程序员，本身ABAP纯技术角度上讲不难，但是SAP的流程太博大精深，以至于门槛很高。
5，你只能尽量忽悠你的同事多讲一点给你，看你忽悠的水平了。直到有一天你也可以心带窃喜地看着信任来忽悠你……

Jiao-Zi · 发表于 2014-2-5 23:00

本帖最后由 Jiao-Zi 于 2014-2-5 22:05 编辑

Sternzeichen 发表于 2014-2-5 21:40
java doc 也没有，但我说的是商业逻辑的说明文档，例如这个类实现的业务功能，目的，原因？

当然也 ...

找一下 Feinspezifikation Doc，文档再少也应该有的。
如果真的没有Doku,那楼主也不用担心了，责任不在你。

前几周，我做个SEPA的改动，很少的Apassungen，都要写好几页很详细的文档。
银行的系统，如果没有文档，不敢想象。

aua · 发表于 2014-2-5 23:01

想走捷径，只有直接找银行沟通了。你问问上级行不行。

Sternzeichen · 发表于 2014-2-5 23:25

Jiao-Zi 发表于 2014-2-5 22:00
找一下 Feinspezifikation Doc，文档再少也应该有的。
如果真的没有Doku,那楼主也不用担心了，责任不 ...

你说的那个是升级文档，那个本人也写，这个文档没什么用，我说的是商业逻辑的说明，或者软件系统本身的说明文档，可惜没有

确实是银行的系统，几家银行都在用这个系统，不过其它银行用别的系统的话，就是另外一套逻辑，所以也有局限

Jiao-Zi · 发表于 2014-2-5 23:41

Sternzeichen 发表于 2014-2-5 22:25
你说的那个是升级文档，那个本人也写，这个文档没什么用，我说的是商业逻辑的说明，或者软件系统本身的说 ...

Feinspezifikation 不是升级文档，里面详细的定义了各种接口功能，模块儿的互相调用关系。
可能你们公司不这样命名，但是没有就太夸张了。

另外，我现在有点明白你指的“商业逻辑”是什么了。
个人觉得，你去跟你们银行的BWLer们聊一聊吧。估计真的是Banking知识欠缺。

Sternzeichen · 发表于 2014-2-5 23:49

Jiao-Zi 发表于 2014-2-5 22:41
Feinspezifikation 不是升级文档，里面详细的定义了各种接口功能，模块儿的互相调用关系。
可能你们公 ...

找不到啊，难啊唉

Sternzeichen · 发表于 2014-2-5 23:55

本帖最后由 Sternzeichen 于 2014-2-5 22:57 编辑

adgjl 发表于 2014-2-5 21:58
我也理解你的处境，但你得从另一个方面看：
1，没有捷径，只能一天一天积累
2，你的职位经验十分重要，而 ...

说的不错，很对

确实跟SAP一样，关键是流程比较复杂，程序也就是info技术本身并不难

关键跟sap还有区别，sap是通用系统，市场巨大，而这个系统只是几个银行在用，其它银行又是另外一套逻辑系统，所以局限很大，也就是说，虽然你学通了之后比较稳定，但你也只能在这个公司工作，不然你这个经验放到别处没有用处，只能跟公司绑定了，哪也动不了了

类似网页美工之类的纯技术，也有好处，就是通用，市场需求广泛，如果做好了，可能更好，换哪个公司都行，工作位置多多，跳槽机会多

tkkk3 · 发表于 2014-2-5 23:59

Sternzeichen 发表于 2014-2-5 21:49
谢谢安慰，不过自己啃的可能性不大，代码都可以看得懂，就是目的是什么，干什么用的，因为商业逻辑不懂 ...

靠人不如靠自己，我几年前也遇到过类似的情况，自己扛过来了，没啥大不了的。不要把同事想太坏，人家不愿意告诉你，也可能是问题太初级了，觉得你自己可以搞定，就这么简单，所以，问题关键还是要靠自己，当然，如果换了是我，有些难搞的东西，有新同事来问，我肯定愿意把我知道的告诉他，如果遇到这样的问题，同事依然不愿意帮忙，那么，只能说明这个团队有问题，换了是我，是不会在这个公司里待时间长的。

tkkk3 · 发表于 2014-2-6 00:03

Sternzeichen 发表于 2014-2-5 21:55
代码看起来没问题，都能看懂的，关键是它代表的商业逻辑非常专业，真的不是简单的从代码上就可以看出来的 ...

既然关键词都找到了，就查资料，一个一个搞清楚它后面的含义，再把这些关键词串起来，慢慢就把业务搞明白了，码农是手艺人不是科学家，别把事情想太难，也别想的太简单烦低级错误就行。还有，你提到你们有测试组，测试用例你自己不能跑跑看吗？调整程序直到把测试用例跑通，再提交不成吗？

tkkk3 · 发表于 2014-2-6 00:07

Jiao-Zi 发表于 2014-2-5 22:41
Feinspezifikation 不是升级文档，里面详细的定义了各种接口功能，模块儿的互相调用关系。
可能你们公 ...

开发程序无Spec的公司多如牛毛，有Spec说明至少公司的流程还是很正规的。另外也说明楼主在的公司管理很混乱。

Sternzeichen · 发表于 2014-2-6 00:15

tkkk3 发表于 2014-2-5 23:03
既然关键词都找到了，就查资料，一个一个搞清楚它后面的含义，再把这些关键词串起来，慢慢就把业务搞明白 ...

测试用例十分复杂，这个公司测试部门都是bwler在做，或者 wi-info在做，因为是银行的逻辑，测试也十分复杂，需要专业的来做，本人曾经跟上级提出过类似要求，但上级不赞成，但在本人强烈要求下把测试用例发给本人，结果根本不会测试，需要非常专业的配置各种参数，在你不明白商业逻辑的情况下，根本不知道各个参数代表的意义，参数值大小，不光参数，包括系统配置，执行，运行下来需要十几步，才明白上级的意思，最后只能放弃了, 交给测试部门的做了，这个公司测试部门的不懂编程，有一个即懂商业逻辑又懂编程的，是上级的上级，根本没工夫搭理本人...

tkkk3 · 发表于 2014-2-6 00:26

Sternzeichen 发表于 2014-2-5 23:15
测试用例十分复杂，这个公司测试部门都是bwler在做，或者 wi-info在做，因为是银行的逻辑，测试也十分复 ...

Unit Test，Functional Test,/Integration Test，还有就是人去挑错，那你们公司没有程序员可以执行的测试吗？如果没有，我只能说银行确实是个神奇的地方。参数再复杂，总有规律可循呢，就不能把一些最简单的规律写下来，自动去跑吗？叫你这么一说，我都想去你公司申请个职位挑战一下了。

Sternzeichen · 发表于 2014-2-6 00:44

本帖最后由 Sternzeichen 于 2014-2-5 23:47 编辑

tkkk3 发表于 2014-2-5 23:26
Unit Test，Functional Test,/Integration Test，还有就是人去挑错，那你们公司没有程序员可以执行的测试 ...

没有uni test, integratin test 只有1,2个人在做，其中一个也就是我的上级，测试部门不做这个，测试部门都是bwler和 wi info, 绝大部分是bwler， wi info的罕见，wi也几乎不接触程序，它们测试的内容就是，把各种参数，数据和文件，配置好，输入进去，执行运行系统，最后查看结果，是否达到了需求文档上要求，结果是否正确，就这些了，举个最最简单的例子吧，比如系统每个季度都需要自动录入德国银行代码，从14年开始德国银行除了代码之外新引入8位 iban 号，系统要求现在能够从银行发过来的文件中自动读取这个iban号，并显示在账单表格中，那测试部门他们只是向系统发送文件，看看是不是所有的iban号都正确读入了，他们测试就是做这个，这只是个最简单的例子，涉及复杂商业逻辑的测试非常复杂的，他们要计算各种结果和数据是否正确

你说的那个uni test intergration test, 这个公司不太常用，1,2个人管这个就足够用了，我觉得可能是系统比较成熟了，模块都很成熟了，平时都是最上层的功能上的一些改进，测试部门主要就是看这些功能是否实现，结果是不是正确，至于集成什么的，几乎没什么问题，至于uni test 那个一般都是底层模块还没成熟时，还在开发过程中才经常用.

ealincoln · 发表于 2014-2-6 00:46

我觉得如果想在这个公司做得开心一些，还是趁业余时间去学点金融吧，凭你学Info的这点智商，金融的基础知识不难的

polo · 发表于 2014-2-6 00:49

我刚毕业那会儿就想进银行搞IT，偏题了

R2D2 · 发表于 2014-2-6 00:50

许多专业领域的IT确实业务层面的说明文书很少，有些是Quick and dirty，有些是非IT的人员开发的，同时他们由于许多因素，IT管理是纯瀑布的方式，或者以本行业的PM方式出发，而不是IT的PM，在IT管理上存在缺陷。

Fachlich的知识是不可能消失的，这些条框很多都在aeltester mann in Dorf的脑子里，或者在Project manager的那些文书里，我在Logistik行业呆过，业务层是纯WMS相关的，情况也很像。

tkkk3 · 发表于 2014-2-6 01:09

Sternzeichen 发表于 2014-2-5 23:44
没有uni test, integratin test 只有1,2个人在做，其中一个也就是我的上级，测试部门不做这个，测试部 ...

程序员不能直接去（集成）测试拿反馈，这样写程序太累了，也可能银行的业务就只能这么做，有他的特殊性？但就IBAN的例子，你们的QA（测试组)完全可以把参数设置好，让N个测试系统跑起来，再把实例文件，期待的输出值交给程序员去用，这样程序员就很快可以拿到反馈，更快的发现程序里的问题。

xianshibian · 发表于 2014-2-6 01:56

很正常的，做哪个领域的软件就要知道那里面的逻辑。我有认识的人，工作看半年编码，就为看懂的，也有画图画好几个月理清思路的，都是自己摸索多，如果同事不nett的话。

灵感涂鸦 · 发表于 2014-2-6 10:27

没文档没注释太正常了....有的有文档烂的都让你看不明白。没捷径只有和同事，其他程序员交流，然后时间磨。我觉得楼主这个情况挺好的，难做公司才请你的，好做不换谁都行了，干几年这系统代码都搞明白了，公司就怕你炒他们了

henrychina · 发表于 2014-2-6 10:36

楼主有前途有发展阿！你自己也说啦，又懂代码又懂商业逻辑的人是你上级的上级。。那你现在利用业余时间补一补商业方面的知识，钱途一片光明啊。
你们没有上岗培训之类的流程么？还是说你作为技术岗位没有给你产品逻辑方面的系统培训? 如果没有的话你找一找BWLer新人到你们单位能拿到的培训资料？或者干脆主动申请跟他们一起培训试试。。

账号		自动登录	找回密码
密码			注册

[职业生涯] 码农请进，谁遇到过这种情况？

马上注册，结交更多好友，享用更多功能，让你轻松玩转社区。

浏览过的版块