uiaxm 发表于 2012-9-16 20:34 static/image/common/back.gif
你还在慕里黑吗?
我可能也要搬到那个破城市去了!!
我倒是不想离开南德，但是不看我的意愿。 慕尼黑就是太沉闷了，其他条件都还好。
uiaxm 发表于 2012-9-16 20:37 static/image/common/back.gif
南德的中餐厅和亚超据说都很差啊!!
而且住房也差!!!
天气好，空气好，治安不错，城市整洁。
uiaxm 发表于 2012-9-16 21:14 static/image/common/back.gif
冬天太冷啊!
德国到处都差不多吧，冬天冷不怕，就在暖气房里
本帖最后由 swordheartde 于 2012-9-16 21:37 编辑
uiaxm 发表于 2012-9-16 21:19 static/image/common/back.gif
汉堡那边不错啊!
冬天不冷,
而且中餐厅和亚超据说都是德国最好的!!
还有大闸蟹吃！太歪了，我们两个又歪楼了。
adgjl 发表于 2012-9-14 14:18 static/image/common/back.gif
我使用的算法从来不用group的数据，我也从不使用SQL的count之类的方法。每个程序员都有自己的编程风格和原则 ...
你说的多用FM的问题，我现在就遇到了。我来吐下苦水. 我换到我们公司SAP的方向，因为SAP咨询是公司的主要业务，我想SAP的开发会专业些。目前我vertreten一个我们这里的一个SAP的hauputentwickler, 他去urlaub一个月， 人家大哥的titel是SAP Entwicklungsberater. 估计他都是我们这里少有的几个会开发的了，大哥都不爱用FM, 都直接去抓表。最近要修改一个文档附件打不开Bug, 本来一个BDS_GOS_CONNECTIONS_GET的调用就能搞定的问题，人家大哥写了n多代码抓去不同的表，不过有些问题还是没有考虑到，搞得一些附件找不到。这些程序跟其他程序都缠绕在一起，弄得我都没法改，好多东西都要删掉从写。本来一个bug的修复，工作量搞得巨大。
swordheartde 发表于 2012-9-16 21:24 static/image/common/back.gif
还有大闸蟹吃！太歪了，我们两个又歪楼了。
歪楼就歪楼，倒了重建。拉动内需{:5_320:}
adgjl 发表于 2012-9-14 17:28 static/image/common/back.gif
我在此处谈的不是闲着没事儿专门写消耗内存的程序，而是以消耗内存为代价减轻数据库的负担。因为一来内 ...
这就是空间与时间的平衡，我的观点一直是这样，省了空间那一定是以牺牲时间为代价的，牺牲了空间当然要换回时间上的优势。在优化的时候，当然是更期望二者都达到最小值。至于在什么地方来平衡，每个人可能有不同的解决放案，就算SAP的HANA未必是最优的，正如您说的，实际应用中往往是在不好的和更不好的之间选择，其实真的让人很无奈。
sbtree 发表于 2012-9-16 23:15 static/image/common/back.gif
这就是空间与时间的平衡，我的观点一直是这样，省了空间那一定是以牺牲时间为代价的，牺牲了空间当然要换 ...
帮定客户帮公司挣钱最重要，代码写的让别人无法接手。
雪候鸟 发表于 2012-9-17 00:17 static/image/common/back.gif
帮定客户帮公司挣钱最重要，代码写的让别人无法接手。
不错，工作中让我认识到了这一点的重要性，也认识到了对工作稳定的重要作用！！
雪候鸟 发表于 2012-9-16 23:17 static/image/common/back.gif
帮定客户帮公司挣钱最重要，代码写的让别人无法接手。
也有这么一说。这也有两个层次，一个是由于使用了高级编程技术和设计模式使得别人出于技术水平原因无法接手，还有一个是程序结构混乱使得别人无法接手。区别在于，对于前者，其他高水平的程序员不但可以接手，而且很容易维护和扩展，并且保持程序的高效和扩展性。而后者，往往只有作者自己进行头痛医头脚痛医脚的修修补补。可惜，实践中的确后者才是大多数。
adgjl 发表于 2012-9-17 11:07 static/image/common/back.gif
也有这么一说。这也有两个层次，一个是由于使用了高级编程技术和设计模式使得别人出于技术水平原因无法接 ...
{:5_344:} 没错，咱们想到一起去了。 我昨天本来还想和sbtree说这两个都让人无法接手的办法，无奈儿子一哭就草草提交了。我想换公司的原因也是因为所有的项目基本都是头痛医头脚痛医脚的修修补补，天天在给人擦屁股。高级编程技术和设计模式的层次确实也只能高手接手，但是只要找到合理水平的高手，新的release中产品的扩展和错误的修复都在可控范围以内。头脚痛医脚的修修补补的层次产品一大就开始失控，基本每个release修改错误的aufwand都比添加新功能本身高出很多倍，弄得项目经理根本没法aufwand schätzen.
雪候鸟 发表于 2012-9-17 11:42 static/image/common/back.gif
没错，咱们想到一起去了。 我昨天本来还想和sbtree说这两个都让人无法接手的办法，无奈儿子一哭 ...
我的感觉是，你的代码在工作中没什么人关心，关心的都是软件的功能。没有大软件公司的经历，也不知道在德国是不是都这样。貌似很多公司提倡Agile，Extreme Programming，你们是不是也这样呢？
我们公司小，虽然也讲XP，可是实际上十分之一的原则也做不到啊，除了狂写代码，看不到什么设计啊，仅有的就是PowerPoint，主要还是针对用户的。在公司干了几年了，也没看见个设计文档什么的，就算是Prototype，还都是用代码写出来的。大家都这样，这几年也就这样跟着混下来了，感觉虚度青春啊！
sbtree 发表于 2012-9-17 14:20 static/image/common/back.gif
我的感觉是，你的代码在工作中没什么人关心，关心的都是软件的功能。没有大软件公司的经历，也不知道在德 ...
总说国内软件开发怎么个不规范，其实这边大多数公司也一样。
雪候鸟 发表于 2012-9-17 14:46 static/image/common/back.gif
总说国内软件开发怎么个不规范，其实这边大多数公司也一样。
我到觉得国内还好些，我曾经在的公司起码文档齐全，一个产品从需求分析到用户手册都有人做。
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性，要么过于具体（比如外包文档），以至于限制了程序员的发挥空间。而写文档的人通常不懂得设计模式，他写的越具体，你可能越难应用设计模式。所以我不觉得文档对于高水平的程序员有多重要。
而且，高水平的程序其实可读性是很强的，写得好的程序我一看就懂，写得滥的我看文档也一样看不懂。
低水平的程序一方面是技术因素，另一方面是很多程序员的确不懂得使用设计模式，你再给他时间也没用。再一个是时间因素，给你一个新需求，你可能也没时间学习这方面的设计模式，只要草草完成交差。所以年度谈话的时候要尽量和头儿争取一定的自学时间。
当你的头儿对你的水平有了信任之后，你就不必头疼了。需要你维护一个写得很烂的程序，你就告诉头儿，这个程序是永远改不好的，要么重写，要么找别的同事去改 :-)
adgjl 发表于 2012-9-17 15:13 static/image/common/back.gif
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...
我不敢自称你所谓的高水平程序员，但是文档对我很重要，尤其设计文档。直接看代码当然也看得懂，再滥的程序起码还可以单步调试去了解上下文中的变量内容，终究有办法搞懂。但是看这样的程序费时费力，项目一大，根本抓不住要点。设计文档是一个程序的中心思想的最简明的表达，对于程序员来讲，任何文档都可以缺，但设计文档不能缺。
adgjl 发表于 2012-9-17 15:13 static/image/common/back.gif
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...
个人体会，设计模式不是用来生搬硬套使用的，他本是是人们的经验总结，就像是公理，你可以在实际中应用它，但你不能对一个实际问题那个公理来套它，因为在细节上，任何一个公理对于一个实际问题都是不适用的，所以公理只是一个最高的概括，从众多实例抽象出来的东西，当然不能在细节上一一用到。
sbtree 发表于 2012-9-17 16:34 static/image/common/back.gif
我不敢自称你所谓的高水平程序员，但是文档对我很重要，尤其设计文档。直接看代码当然也看得懂，再滥的程序起码还可以单步调试去了解上下文中的变量内容，终究有办法搞懂。但是看这样的程序费时费力，项目一大，根本抓不住要点。设计文档是一个程序的中心思想的最简明的表达，对于程序员来讲，任何文档都可以缺，但设计文档不能缺。
我同意你的说法，也收回我原来的看法。
通常我不是单纯的程序员角色，所以在初步设计和详细阶段就已经参与，所以写文档之前已经通过各种会议了解了文档里的需求部分，所以实施过程很少再看文档，至于文档里的实施部分反正我是不看的:-)，我会按照自己的想法去实现需求。
DDD / DSL 才是正道， PPP是下一个方向。
adgjl 发表于 2012-9-17 22:21 static/image/common/back.gif
我同意你的说法，也收回我原来的看法。
通常我不是单纯的程序员角色，所以在初步设计和详细阶段就已 ...
作为团队的一员，无论是设计师，还是程序员，在项目的实施的每一步骤中，多少都会参与其中的，如果是一个人独揽项目，也无所谓怎样实施，最终能有一个漂亮的报告和程序运行的结果那就是工作成绩。即使在一个团队中也没人太关心你份内的一个具体函数的编写，所以自己怎样想就可以怎样写。如果你编写的是一个接口或者框架那你就要更多的考虑你团队内的其他成员的工作了
adgjl 发表于 2012-9-17 15:13 static/image/common/back.gif
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...
要么重写，要么找别的同事去改 :-) 顶这句
sbtree 发表于 2012-9-17 22:34 static/image/common/back.gif
作为团队的一员，无论是设计师，还是程序员，在项目的实施的每一步骤中，多少都会参与其中的，如果是一个 ...
恩， Fachkonzept还是很重要的
adgjl 发表于 2012-9-17 15:13 static/image/common/back.gif
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...
adgjl你在SAP领域工作几年了
本帖最后由 雪候鸟 于 2012-9-18 23:34 编辑
"adgjl我说的没法改的程序很多恰恰是国内的Extern编的…… "
你要是看到我们这边的代码，人会疯掉的。举例，在传给一个batch程序的übergabe对象，怎么说应这个对象应该是一个纯粹的data object吧，里面竟然有GUI的reference, 而且这个reference竟然和其他几个字段组成key. 一个dynpro在头一次初始化的时候立即用level to program退出，为了只是需要初始化text editor作为临时变量，用来存储字符串，tmd这个字符串寸哪里不行啊，我看到这种程序都崩溃了。程序里到处的抓表，不用标准FM, 美其名曰我要面向对象编程，调用FM不容易县向对象。我现在就天天在这种程序里找错。。。
woo2333 发表于 2012-9-17 22:34 static/image/common/back.gif
DDD / DSL 才是正道， PPP是下一个方向。
能给解释解释吗？太多缩写了
sbtree 发表于 2012-9-19 08:54 static/image/common/back.gif
能给解释解释吗？太多缩写了
领域驱动，领域专家用领域专门的描述语言描述，然后大部分代码自动生成。以前也弄过类似的东西，只是知道点概念
雪候鸟 发表于 2012-9-18 22:32 static/image/common/back.gif
你要是看到我们这边的代码，人会疯掉的。举例，在传给一个batch程序的übergabe对象，怎么说应这个对象应该是一个纯粹的data object吧，里面竟然有GUI的reference, 而且这个reference竟然和其他几个字段组成key. 一个dynpro在头一次初始化的时候立即用level to program退出，为了只是需要初始化text editor作为临时变量，用来存储字符串，tmd这个字符串寸哪里不行啊，我看到这种程序都崩溃了。程序里到处的抓表，不用标准FM, 美其名曰我要面向对象编程，调用FM不容易县向对象。我现在就天天在这种程序里找错。。。
我理解你的想法，但是正如有洁癖的人看哪里都脏，有技术洁癖的人也看不得别人不尽合理的算法，但是这个世界绝大多数的任何地方和人都不会满足你的要求。你要是为了这个原因跳槽，到哪里都一样烦恼。
正相反，你应当庆幸，正因为有他们的存在，你的技术水平和价值才会凸现出来，否则，就像你想从中科院用发文章来熬出头就太累了。
另外，你所描述的除了“到处抓表”，如果指的是数据库表而不是内表，那可能是无解之外，其它都是很正常的。SAP自己也经常把GUI的reference传来传去。把Text Editor用来存储字符串很可能是他拷贝（或者模仿）了一段SAP程序，SAP源程序里面的字符串是Text Editor输入的，他如果不造一个Dummy的Texteditor，就要把拷贝来的SAP程序改很多地方，这个我完全可以理解。
我指的是这样的：
我接过一个国内的程序，原设计里面的数据库表格的Key只有一个字段，却是一个structure所有字段contatenate出来的。让我把这个表格的查询这个Key的子串查询优化，我立即对头儿说，这个数据库表格必须删除，相关程序必须修改，要想优化找别人去。
我还接过另一个国内程序，6000多行里面有Select了上百个SAP标准表格没有一个FM的，我告诉头儿，对不起，我没有这个人清楚这些表格的关系，我也绝不相信他的表格关系是完全正确的，我可以用10个FM把这些Select替掉，但是这个程序必须完全重写。
adgjl 发表于 2012-9-19 10:59 static/image/common/back.gif
我理解你的想法，但是正如有洁癖的人看哪里都脏，有技术洁癖的人也看不得别人不尽合理的算法，但是这个 ...
技术洁癖，我还真是这样。{:5_319:}
本帖最后由 sbtree 于 2012-9-19 12:25 编辑
雪候鸟 发表于 2012-9-19 09:51 static/image/common/back.gif
领域驱动，领域专家用领域专门的描述语言描述，然后大部分代码自动生成。以前也弄过类似的东西，只是知道 ...
这东西都在哪些地方应用？PPP又是什么东西？
adgjl 发表于 2012-9-19 10:59 static/image/common/back.gif
我理解你的想法，但是正如有洁癖的人看哪里都脏，有技术洁癖的人也看不得别人不尽合理的算法，但是这个 ...
sap 那么做肯定有他的原因，这要看看上下文关系。我们那个代码就是写程序的不明白数据和GUI应该是分离的。