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
帮定客户帮公司挣钱最重要，代码写的让别人无法接手。
也有这么一说。这也有两个层次，一个是由于使用了高级编程技术和设计模式使得别人出于技术水平原因无法接手，还有一个是程序结构混乱使得别人无法接手。区别在于，对于前者，其他高水平的程序员不但可以接手，而且很容易维护和扩展，并且保持程序的高效和扩展性。而后者，往往只有作者自己进行头痛医头脚痛医脚的修修补补。可惜，实践中的确后者才是大多数。