[纯灌水]代码代表谁的心？

BluntBlade 2006-07-25 09:34:56

现在真正的体会到团队开发的难度了。
唉。
拼死拼活为了啥？写代码能赚回房子车子妻子儿子么……

BTW：深圳的姑娘太现实……

...全文

463 45 打赏收藏转发到动态举报

写回复

用AI写文章

45 条回复

切换为时间正序

请发表友善的回复…

发表回复

xiaocai0001 2006-07-31

打赏
举报

瞟一眼.

playmud 2006-07-31

打赏
举报

我的理解，一个PM需要了解的的事情，从重到轻：
公司战略的发展。
项目的性质和可延续性。
项目的需求，功能模块的细化。
风险的预测，分级和解决方法。
为项目进行所需要制定的规范。
对进度的把握。
对代码质量的控制。

代码没有放在一个很重要的位置上，所以写代码的人待遇不可能太高。

sjjf 2006-07-31

打赏
举报

to goodluckyxl(被人遗忘的狗) :
是的，没有静态的平衡。处于时空的东西都在变化中。
某一个哲学家说的什么某一时刻你既是自己又不是自己，
一个人不能两次踏入同一个河流等，
就是这个意思。(常常被俺拿去泡mm，嘿嘿。)

你说的1和2在实际上还要一个演化过程。
需求的产生基本都是由模糊到清晰的，模糊的时候是一个大块。
清晰后才能够形成细节。这需要一个过程，也需要手段，
我觉得只要紧扣需求点和演化规则，就应该能做好它吧，
教人做需求的应该都离不开这一点吧，如果不是的话，我觉得也没有看的必要。
温伯格又一本书好像叫《需求探索》偶早买了但是没有时间看。
设计在这点上面也和需求一样。
需求在整个软件周期都会有变化，过期无效，
时间才是项目管理最重要的制约因素，最大的压力。
一个合格的项目有一个起码的要求，就是要按时完成。

3是属于管理之道，理想状况下地解决模型无非是个线性规划+网络流。
但是实际上涉及到人际关系和复杂的人的心理的因素。
模型引入了比较多，也比较难以量化的变量，导致模型的效果和实际有很大的出入而不适用。
目前好像还没有太好的解决方法，只能靠企业文化和制度来调节。
看看郁闷的BluntBlade 状况就知道，类似情况我也经历过，而且不止一次，实力有时在权力面前没有什么优势。
总之，一言以蔽之，因势制宜。

4.不一定需要一个通晓整个系统的到细节的设计师及一个通晓自身模块细节的团队.
可以通过制度来完成。
比如，
由架构师确定或者几个设计师共同商定设计概要设计，选定框架。
项目内容通过文档通讯交流，如果不出于保密的目的话，每一个人都知道项目的进展和当前的个人的工作状况，
跨地域开发的公司这个方面做的比较好。
简单的团队评审机制--由各部分的设计者对自己的设计自圆其说，其他的人进行充当反方角色(但要把握度，对事不对人)。
很多人在潜意识中认为评审机制没必要，很耗时，效率低，
但是我认为换一种角度看设计评审也是一个项目成员了解设计的细节的过程，用众人力量去弥补个人力量的不足，
而且附赠自动纠错功能，提高团队凝聚力，这种买卖很合算的。

5.代码的质量除了靠规范外,还需要靠知识背景.
规范只能保证语法相似,但是不能保证思想相似.
反例如一个功能的实现选择很差劲的算法,虽然写的很规范,但是也很让人不舒服.
偶想起了帖子,说印度阿三写程序,很少去考虑算法,简单优先,比如开辟一个大数组来代替
链表之类的.我很不赞同这种说法.简单固然好,但这似乎过了头,一切自然为好,浪费不是一件好事.
对于持这种论调的人,我一般都是建议他最好建立一个公司的知识主题库.逐步的该善这种情况.
(他的公司肯定没有这样的东西，如果有的话，就不会用类似阿三的方法了)
有时候，为了应急用的代码，虽然看起来简单，但是破坏了实现的整体性。
比如在业务逻辑中一些问题的合适的做法是用多态来代替if，但是如果原来的代码已经充斥了一大堆的if。
使后来者迫于时间压力不敢重构，最后只能也跟着if了。到最后看到的代码洋洋洒洒一堆if。
编写代码除了语法规范外。还需要思想规范。而且一堆思想差不多遵循同一个规范的人交流也很方便。
比如一个人说单例，抽象工厂，另一个不会理解偏了，也不用去学习一番才能领悟，破坏了气氛和进程。

================================================================================================
这几天感冒了，白天吃药晕睡，晚上精神比较好 :(
昨天的代码之道还没有谈完。

代码之道，我认为是不多不少的表达某种意思。
它的"空间结构",我认为是外观和形体(偶创造的，可能词不达意)。
外观是指代码规范涉及的方面。
形体是指代码体现出来的逻辑，可以认为是广义的算法(一切皆算法，无论好坏)。
这两个东西制约着他们被修改的事件模式的重复。
如果外观或形体不符合检阅者的习惯就会给检阅者应力，(偶想起了脸蛋不漂亮，身材又不好的某种雌性动物)
不修改它这种应力将会持续，(最近反恐的人越来越多了.....)
会让人烦躁不安，工作情绪低下。。。。。
(此处可以发挥想象随意夸张，呵呵，the timeless way of building一书的作者就是这么忽悠我的)
这将导致被修改的事件模式产生就会重复，这时候代码就不能保持自我了。这种代码将是死的。
跟动物很相像，如果不能保持自己的有机体，那么就会处于死亡状态。
( :)如果有人叫你死鬼,那又是另外一回事)

外观就没得说了，每一个公司都有自己的代码规范，比较容易达到。
但是形体就比较难以衡量了。基本上我觉得代码逻辑越清晰，活的时间越长。
比如进行字符串的查找，如果你手工写的话，即使写得很漂亮，
但我也不觉得会比一句正则表达的逻辑清晰。
如果对于报文拆解组装的工作，你给我看一些.l .y或者.g的文件，
而不是一堆一堆代码的话。我会觉得逻辑更清晰，可以在第一时间内弄清楚要摆弄的东西以及它们之间的关系。
如果给我代码，可能需要的时间要乘于10.

sjjf 2006-07-30

打赏
举报

做设计和写代码在某种抽象层次应该是一样的。
最近在读<the timeless way of building>一书感悟颇深。
虽然改行了，但是还是愿意忽悠忽悠的。
代码是设计的更具体的一个层次，就像说人的手的细胞是人的手更具体的层次一样。
因此导致两者的面对的元素和规则不一样。比如你可以用恒星，行星来描述太阳系。
但是在更大的尺度层面上比如银河系，就需要旋转臂之类的概念。
层次不一样，不同的层次(忽略层次这句话也成立)系统是有自己的特征。
这些特征是由这些不断重复的事件模式赋以的，
空间结构又制约了事件模式比如决定了哪些模式能够得以重复。
模式的不断的重复可以看作是系统(确切地说是有活力的生气的系统)自我保持的能力。
说得通俗一点于设计层，这种自我保持能力可以是可扩展性--不需要修改或者尽可能小的修改。
如果想设计出来的系统有活力的话，关注的重点不是技术，而是需求，
因为需求是设计的"空间结构"。如BluntBlade所举的扣费系统，
客户的需求决定了那些这种系统的设计得以重复。
比如采用mvc模式会比都混在一起的那种好，特别客户需求中要求在web中也适用时。
这种需求制约那些事件模式能够得以重复，嘿嘿，和达尔文的适者生存意思差不多，
呵呵感觉有点倒因为果了吧？
对，the timeless way of building 一书就是要通过成功的案例(有生气的系统)去感悟成功之道的。
作者认为成功的案例(有生气的系统)里后面都有一个东西叫无名之质。
不过那个东西太抽象了，偶不知道怎么表达，只可意会。
回到题中。需求也有"空间结构"的制约,没有作过扣费系统但是猜测,
他们的这些空间结构可能是现实中的空间位置.公司的制度,人群特点(如健康程度文化程度)等.
这些因素制约了需求.举个例子,如果扣费系统的使用盲人的话,
那么可能产生供语言系统或其他的展现的代替品的需求。
换一种科学的方法(但也抽象)来说，需求也有拓扑结构，只要找到拓扑结构，就可以应付需求。
设计师只要针对拓扑结构进行设计就可以在需求改变但是其拓扑结构不被破坏的情况下仍能使设计适用。

对于代码，代码的存在是为了完成一个功能。功能在设计的时候已经确定了。在这里就没有改变的可能。
我们看看到底那些事件模式是在代码身上发生？
测试人员需要研读代码，做白盒测试。评审人员需要研读代码。维护人员需要修改bug之类的进行研读和修改。
作者重修改。
对于一份提交的代码基本上就这几种事件模式了。

正如一千个读者就会有一千个哈姆雷特一样，
一个功能的代码实现，一千个人有一千个实现，但是有人的人代码让人看起来赏心悦目，非常舒服，
有的人的代码让人看起来觉得非常难受，虽然功能实现了，但是还是想自己去重写。为什么？
前一种类型的代码是有生气的，有活力，它能够自我保持。即使被n多人传阅，也没有人想对它进行改动。
读起来都感觉都是那么的优雅，那么的自然。真的有这种代码，我曾读过一个11年前的设计的交易平台的c代码。
据说现在还在使用着的程序，除了设计非常优秀外，代码写得也相当漂亮。
整体居然让我感觉是一个人写的，但是它的规模告诉我绝不是一个人写的。
命名非常规范，写作方式简洁，几乎不能再简洁了，没有一个多余的变量，没有一句多余的语句。
注释简明扼要，三言两语，但是异常清晰。都让我无法挑出毛病,(我一向很挑剔的)。
只可惜我几年的程序生涯，只遇到过一个。
相反另外一些代码没有活力，不能保持自我。比如充满了魔术数，让人抓狂。泛滥的注释，
该注释的地方倒是很省，而且由于版本跟新是错误的。不该注释的地方连阿猫阿狗都标上了。
也不知道是穷还是怎么的，一个变量用作很多用途，从临时变量到计数器，几乎可以当万能保姆了，
而且名字含糊不清。不管什么样的循环一律用for，分不清if和switch何者在何时更合适。
一些全局变量如时空大侠一样到处乱串，不遵守交通规则。
困死了，睡了，下次再写了。

goodluckyxl 2006-07-30

打赏
举报

一个系统需求都将会是持续变化
好的设计都是针对于持续变化的客户需求而不是套用某个模式
1.做好一个系统对于整体需求首先要非常了解甚至要到一个很小的细节
2.设计不是一个人的产物系统设计师首先将需求罗列并整理出基本流程
期间需要团队成员参与讨论并最终敲定框架及细节及相关适应性调整的扩展处理
3.团队能力有强有弱,人月神话作者以IBM的都是精英的coder效率相差数十倍.
一定要对用人有所选择,人尽其用
4.构建最好的系统基础并不是最优秀的设计,最精练的代码.而是最贴近需求的设计.
一个通晓整个系统的到细节的设计师及一个通晓自身模块细节的团队.
"如果想设计出来的系统有活力的话，关注的重点不是技术，而是需求，"
sjjf(水晶剑锋)这句话我深有体会.
5.代码的质量实现是最容易的,可以靠规范去控制问题.

还有一个设计师千万不可过度设计,实用第一.
以前我的部门经理告诉我,我花了很长时间才理解