探讨一个SAP Dynpro编程的问题: Dynpro切换时，貌似会做隐式数据库Commit，原因何在?

雪候鸟

adgjl 发表于 2012-9-17 11:07
也有这么一说。这也有两个层次，一个是由于使用了高级编程技术和设计模式使得别人出于技术水平原因无法接 ...

没错，咱们想到一起去了。 我昨天本来还想和sbtree说这两个都让人无法接手的办法，无奈儿子一哭就草草提交了。我想换公司的原因也是因为所有的项目基本都是头痛医头脚痛医脚的修修补补，天天在给人擦屁股。高级编程技术和设计模式的层次确实也只能高手接手，但是只要找到合理水平的高手，新的release中产品的扩展和错误的修复都在可控范围以内。头脚痛医脚的修修补补的层次产品一大就开始失控，基本每个release修改错误的aufwand都比添加新功能本身高出很多倍，弄得项目经理根本没法aufwand schätzen.

sbtree

雪候鸟 发表于 2012-9-17 11:42
没错，咱们想到一起去了。 我昨天本来还想和sbtree说这两个都让人无法接手的办法，无奈儿子一哭 ...

我的感觉是，你的代码在工作中没什么人关心，关心的都是软件的功能。没有大软件公司的经历，也不知道在德国是不是都这样。貌似很多公司提倡Agile，Extreme Programming，你们是不是也这样呢？
我们公司小，虽然也讲XP，可是实际上十分之一的原则也做不到啊，除了狂写代码，看不到什么设计啊，仅有的就是PowerPoint，主要还是针对用户的。在公司干了几年了，也没看见个设计文档什么的，就算是Prototype，还都是用代码写出来的。大家都这样，这几年也就这样跟着混下来了，感觉虚度青春啊！

雪候鸟

sbtree 发表于 2012-9-17 14:20
我的感觉是，你的代码在工作中没什么人关心，关心的都是软件的功能。没有大软件公司的经历，也不知道在德 ...

总说国内软件开发怎么个不规范，其实这边大多数公司也一样。

sbtree

雪候鸟 发表于 2012-9-17 14:46
总说国内软件开发怎么个不规范，其实这边大多数公司也一样。

我到觉得国内还好些，我曾经在的公司起码文档齐全，一个产品从需求分析到用户手册都有人做。

adgjl

我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性，要么过于具体（比如外包文档），以至于限制了程序员的发挥空间。而写文档的人通常不懂得设计模式，他写的越具体，你可能越难应用设计模式。所以我不觉得文档对于高水平的程序员有多重要。

而且，高水平的程序其实可读性是很强的，写得好的程序我一看就懂，写得滥的我看文档也一样看不懂。

低水平的程序一方面是技术因素，另一方面是很多程序员的确不懂得使用设计模式，你再给他时间也没用。再一个是时间因素，给你一个新需求，你可能也没时间学习这方面的设计模式，只要草草完成交差。所以年度谈话的时候要尽量和头儿争取一定的自学时间。

当你的头儿对你的水平有了信任之后，你就不必头疼了。需要你维护一个写得很烂的程序，你就告诉头儿，这个程序是永远改不好的，要么重写，要么找别的同事去改 :-)

sbtree

adgjl 发表于 2012-9-17 15:13
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...

我不敢自称你所谓的高水平程序员，但是文档对我很重要，尤其设计文档。直接看代码当然也看得懂，再滥的程序起码还可以单步调试去了解上下文中的变量内容，终究有办法搞懂。但是看这样的程序费时费力，项目一大，根本抓不住要点。设计文档是一个程序的中心思想的最简明的表达，对于程序员来讲，任何文档都可以缺，但设计文档不能缺。

sbtree

adgjl 发表于 2012-9-17 15:13
我倒是觉得，其实对于水平高的程序员来说，文档都是浮云，因为写文档的人要么写的过于简单，没有可执行性， ...

个人体会，设计模式不是用来生搬硬套使用的，他本是是人们的经验总结，就像是公理，你可以在实际中应用它，但你不能对一个实际问题那个公理来套它，因为在细节上，任何一个公理对于一个实际问题都是不适用的，所以公理只是一个最高的概括，从众多实例抽象出来的东西，当然不能在细节上一一用到。

adgjl

sbtree 发表于 2012-9-17 16:34
我不敢自称你所谓的高水平程序员，但是文档对我很重要，尤其设计文档。直接看代码当然也看得懂，再滥的程序起码还可以单步调试去了解上下文中的变量内容，终究有办法搞懂。但是看这样的程序费时费力，项目一大，根本抓不住要点。设计文档是一个程序的中心思想的最简明的表达，对于程序员来讲，任何文档都可以缺，但设计文档不能缺。

我同意你的说法，也收回我原来的看法。

通常我不是单纯的程序员角色，所以在初步设计和详细阶段就已经参与，所以写文档之前已经通过各种会议了解了文档里的需求部分，所以实施过程很少再看文档，至于文档里的实施部分反正我是不看的:-)，我会按照自己的想法去实现需求。

woo2333

DDD / DSL 才是正道， PPP是下一个方向。

sbtree

adgjl 发表于 2012-9-17 22:21
我同意你的说法，也收回我原来的看法。

通常我不是单纯的程序员角色，所以在初步设计和详细阶段就已 ...

作为团队的一员，无论是设计师，还是程序员，在项目的实施的每一步骤中，多少都会参与其中的，如果是一个人独揽项目，也无所谓怎样实施，最终能有一个漂亮的报告和程序运行的结果那就是工作成绩。即使在一个团队中也没人太关心你份内的一个具体函数的编写，所以自己怎样想就可以怎样写。如果你编写的是一个接口或者框架那你就要更多的考虑你团队内的其他成员的工作了