谈某些程序员顽固的思维方式

就像程序都有500个错误了，还改啥改啊，别改了，一样的道理，怎么能这么顽固？必须1个错误都不能有，才是正确的硬道理。

改变开发人员的思维很难、固执的多、自以为是的多、老顽固的多、听不进劝告的多，我们今天封建了吗？

最近给几个开发人员检查程序，进行技术沟通交流：



1：建议做软件先有设计，后有施工的思路，虽然软件都已经做好了，但是设计图纸还是有必要补充的，表结构等，应该整理出来，修改哪个模块就应该把哪个模块的表结构都整理好，方便今后的维护工作，人员之间的交流。

一个管理软件，若一个像样的数据库设计文档都没有？这不是成了软件作坊了？以后还怎么上层次、怎么提高呢？

曾经有个比较有水平的朋友跟我讲：“别人做的软件是否设计合理、功能是否正确，有经验的人看看数据库设计文档就能感觉到很多”。

再说了将来我们的软件行业也会走设计、施工分离的发展路线，做软件前总需要有设计图纸的吧？就是软件做好了，也应该把设计图纸补充好吧？

大家驳倒：工作量大、意义不大、现在有更紧急需要处理的事情，好几个人都这么认为，我不好意思暴力做决定必须要把数据库设计文档补充好。



2：现在都是2010年了，都VS2010 ADO.NET Entity 技术都出来了，老程序还是 拼接sql的， " + this.txtName.Value + "，面向对象都有10年了，总需要把老的程序改进为面向对象的吧？别都面向过程的，将来维护起来不上档次。

大家驳倒：程序现在用得好好的，这么修改了，客户用起来也没啥变化，而且可能会带来工作量，还可能会引起程序的不稳定，哇靠晕倒啊这不是明显拒绝提高吗？别人想给你提高一下努力往前拉动，你倒是想尽一切方法阻止进步啊？兄弟真够倔强啊，我服了。



3：程序里有一大堆没必要的方法、命名紊乱的方法、功能重叠的方法、写错位置的方法，这些很多没必要写或者根本不需要写那么多代码，调用一下基础类里的先有方法就可以了，修改到哪里，仔细修正一下不就可以了，按专业术语来讲就是需要不断重构完善的？

大家驳倒：程序现在很稳定，这么修改了，会引起程序的运行不稳定，我们冒不了这个风险，我服了、那干脆啥也别动了。



4：程序里层划分太多了，写代码写太多了，有接近7-8个层，什么设计模式、开闭原则、反射把时髦的技术都用上了，导致写一个方法，需要到处去修改，重命名一方法也要修改很多环节，搞那么多层干啥？有必要吗？何必跟自己过不去呢？等以后有需要时，再把这些层加上去也可以了，我说只需要3层就足够了，见效快、修改程序简单、维护起来也方便，搞那么多技术玩自己干啥呀？

领域模型层 + 商业逻辑层 + 页面层， 就这么3个层就足够了，搞那么多飞机干啥？

大家驳倒：若用Mysql数据库，每个客户端还要引用[b]Mysql的Dll，将来的维护量大？，我服了Mysql才272k，更何况公司的产品从来没用过[b]Mysql，我们有必要天天担心太阳会掉下来，有必要吗？[/b][/b]



5：建议大家用代码生成器，不要总是手写，太累又不规范，太小农了，生产量不够，现在都啥年代了，机械化批量生产了？

大家驳倒：[b][b]一个表才几个字段，手写一下也很快，没必要用代码生成器，哇靠牛B啊，居然手写比代码生成器还强？那么多人写的如何规范化？代码是否还要检查质量？若100个字段，那不是要写死人啊？人来人走的，为什么不接纳一下代码生成器？大家都比我年轻至少5岁以上，为什么还这么老顽固？是我太老顽固了吗？[/b][/b]



6: 建议大家空时看一看视频，绝对对工作会有些帮助的。

大家驳倒：[b][b]工作忙，没空看，等空了再看，NND平时设计数据库啥的，写代码啥的注意事项都不知道，设计出来的表系里啪啦的，看一下视频能死人啊？看一下再工作不是更好吗？至少少制造一些电子垃圾，少犯点儿错不是？[/b][/b]



就这样5个比较好的提议，都当是放屁了，都被大家驳倒枪毙了，想难道这5个建议就这么差劲了？大家为什么就听不进去呢？是谁固执呢？程序员朋友们固执呢？还是我没能把道理讲清楚？还是说话的语气不对？组织的方式不对？为什么就没能让大家接纳呢？



有时候想想，我们中国人为什么总是那么封建？就是因为我们大家封建，思想不开放，才导致我们大家封建，现在都啥年代了，这前5项估计都是做管理软件最最基本的技能了，大家才25岁左右，就这么顽固，那到30岁了，不是更顽固了？可能是我太人才啦，太另类了，哈哈



我们就不提老美的创新，接收新思想，还都这么艰难啊？不用总用自己的理解能力、自己的思维对待新鲜思想，新鲜做法，若你有那么高的智商，早就考入清华北大了，不会在这里天天写管理类软件了，多听听别人的，多听听比你经验更丰富的，能力更强的人的建议，你走过的路人家大多都做过来了，你还没做过的路，人家也都可能走过了，多听听别人的说法，多吸纳一下别人的优点，改进一下自己的缺点，别总自以为事，别人也不是猪，别总抢着说自己的，不成熟的思想说出来就是丢人，先听别人的，然后再结合自己的，若有必要再提出更好的思路，你就是不提出思想，别人也会把你当成是猪。



若不是为了维护公司的安定团结、同事之间的和睦相处，真有做决斗的念头都会产生，怎么这么固执啊？是我跟不上同事们的思路了？还是同事们跟不上我的步伐了？一下班全跑了，什么时间来不及？忙不过来，全当是放屁了，产品开发部只剩下3个人写继续写代码什么的，其中我一个在整理文章。



也有人说，你怎么老是这些重复的理念？观点已经重复很多次了？

我回答：一个人能把一个理念坚持到低，能彻底做好，就足够了，毕竟我们是十多亿人，若每个人能把一件事情一个理念做好了，我们很快可以超越美国了，哈哈。



以下几个视频供参考：



C# ASP.NET走火入魔通用权限管理_数据库设计注意思想指导

下载 http://www.jirigala.tk/JiRiGaLa_DbDesign.wmv

C# ASP.NET走火入魔通用权限管理_实体结构定义

下载 http://www.jirigala.tk/JiRiGaLa_Entities.wmv

C# ASP.NET走火入魔通用权限管理_为什要用代码生成器(必要性)

下载 http://www.jirigala.tk/JiRiGaLa_CodeBuilder01.wmv

C# ASP.NET走火入魔通用权限管理_代码生成器如何用(实战)

下载 http://www.jirigala.tk/JiRiGaLa_CodeBuilder02.wmv



将权限管理、工作流管理做到我能力的极致，一个人只能做好那么很少的几件事情。

posted on 2010-09-17 15:31 吉日嘎拉 不仅权通用权限 阅读(4568) 评论(108) 编辑 收藏

评论

1926275

评论共2页:

上一页 1 2

#9楼[楼主] 　回复　引用　查看　

@sunsy
嗯，你这个逻辑也很对，所以我拿出来与大家共同探讨一下。

2010-09-17 15:50 | 吉日嘎拉 不仅权限管理

#10楼 　回复　引用　查看　

吉日最近不花时间带孩子，还高产量发帖子发视频。
2010-09-17 15:53 | 失落的锋芒

#11楼 　回复　引用　查看　

怎么老是宣传你的视频啊？？
2010-09-17 15:55 | 紫砂壶

#12楼 　回复　引用　

开发软件是一个系统工程，就像修房子一样，有设计、监理、施工等角色，其实代码工人不是别人给程序员的称号，是部分程序员自己给的。我想这么说应该还是很清楚的。
2010-09-17 15:55 | hldsoft[未注册用户]

#13楼 　回复　引用　查看　

我起个名字 论”某些程序员顽固的思维方式“
2010-09-17 16:02 | liyf

#14楼 　回复　引用　查看　

老哥，
说句实在话，你的管理方法还是有问题，该制定流程的时候就制定流程。
这样吧，给你说个故事，能不能明白，就看你明悟吧：
有七个人曾经住在一起，每天分一大桶粥。要命的是，粥每天都是不够的。
一开始，他们抓阄决定谁来分粥，每天轮一个。于是乎每周下来，他们只有一天是饱的，就是自己分粥的那一天。
后来他们开始推选出一个道德高尚的人出来分粥。强权就会产生腐败，大家开始挖空心思去讨好他，贿赂他，搞得整个小团体乌烟障气。
然后大家开始组成三人的分粥委员会及四人的评选委员会，互相攻击扯皮下来，粥吃到嘴里全是凉的。
最后想出来一个方法：轮流分粥，但分粥的人要等其它人都挑完后拿剩下的最后一碗。为了不让自己吃到最少的，每人都尽量分得平均，就算不平，也只能认了。大家快快乐乐，和和气气，日子越过越好。
同样是七个人，不同的分配制度，就会有不同的风气。所以一个单位如果有不好的工作习气，一定是机制问题，一定是没有完全公平公正公开，没有严格的奖勤罚懒。如何制订这样一个制度，是每个领导需要考虑的问题。
2010-09-17 16:04 | BreezeWoo

#15楼 　回复　引用　查看　

都是偷懒的借口
2010-09-17 16:08 | kiler

#16楼[楼主] 　回复　引用　查看　

不宣传这个？宣传啥呀？
引用紫砂壶：怎么老是宣传你的视频啊？？

2010-09-17 16:08 | 吉日嘎拉 不仅权限管理

#17楼[楼主] 　回复　引用　查看　

@BreezeWoo
我需要好好体会你的这个故事。

2010-09-17 16:09 | 吉日嘎拉 不仅权限管理

#18楼[楼主] 　回复　引用　查看　

这个比较上档次，我修正了。
引用liyf：我起个名字 论”某些程序员顽固的思维方式“

2010-09-17 16:11 | 吉日嘎拉 不仅权限管理

#19楼[楼主] 　回复　引用　查看　

大哥，你不能这么讲，这么讲你就是得罪所有的同事了，我可没这么说啊。
引用kiler：都是偷懒的借口

2010-09-17 16:13 | 吉日嘎拉 不仅权限管理

#20楼 　回复　引用　查看　

大家说：吉日啊，你的风格得改改啊，和大环境不协调啊
吉日驳倒：走我自己的路，让你们说去吧
2010-09-17 16:14 | 蔷薇

#21楼[楼主] 　回复　引用　查看　

@蔷薇
我一直在改进自己的缺点，大家说没视频，我贴视频，大家说没代码，我贴代码。大家说标题写得不好，我采纳大家的意见。

我有错就改，马上改，马上修正自己错误的做法。

2010-09-17 16:19 | 吉日嘎拉 不仅权限管理

#22楼 　回复　引用　查看　

楼主的团队就是典型的作坊式软件团队.程序员就是万能的,啥都要会.
2010-09-17 16:19 | Galactica

#23楼 　回复　引用　查看　

该动的不动。 该改的不改。 晕。 一看就知道这鸟，没写过程序。 只会来吓程序员。 哇搞。
2010-09-17 16:20 | chulia

#24楼 　回复　引用　查看　

操你大爷的，你不要再发文章啦

2010-09-17 16:20 | ttlin2010yeah

#25楼[楼主] 　回复　引用　查看　

@ttlin2010yeah

谢谢你留言，欢迎继续留言。

2010-09-17 16:24 | 吉日嘎拉 不仅权限管理

#26楼[楼主] 　回复　引用　查看　

@ttlin2010yeah
学C#好还是学C++好啊 ？ 哈哈，笑死我了，刚出茅庐。

2010-09-17 16:25 | 吉日嘎拉 不仅权限管理

#27楼 　回复　引用　查看　

非常羡慕上班时间能写博客的人!
2010-09-17 16:25 | 冯小诺

#28楼 　回复　引用　查看　

现在都是2010年了，都VS2010 ADO.NET Entity 技术都出来了

这一点不同意之外，其他的都不同意。
因为我一直使用存储过程,ADO.NET Entity 性能上没有测试过，上次一测试linq to sql，竟然汗颜，所以我宁愿使用工具生成，也不会使用这些低性能的代码在客户机器上浪费资源
2010-09-17 16:25 | yi

#29楼[楼主] 　回复　引用　查看　

@冯小诺
更羡慕上班时间不用写博客，还可以阅读博客，自由留言的人。

2010-09-17 16:26 | 吉日嘎拉 不仅权限管理

#30楼 　回复　引用　查看　

@吉日嘎拉 不仅权限管理
只能说明你不容易!我看看,耽误不了多少时间.
2010-09-17 16:28 | 冯小诺

#31楼 　回复　引用　

看问题要站在不同的角度去考虑，如果你真的是在给别人增加工作量，并且别人不是真的很闲，而且软件很好的在运行着，我作为程序员我也不会同意你的建议，即使你有道理。
还有建议和命令是有差别的，如果你是他们上级，你给的“建议”（命令）他们是要执行的，但同时，如果真的引起程序不稳定，责任也是要大家承担的。自己写的东西还好，如果是多人在开发，甚至以前都不是自己做的，动一个稳定运行的程序真的不是啥好的建议。
2010-09-17 16:29 | .Jack[未注册用户]

#32楼 　回复　引用　

当然，从管理者，公司的角度，文档是必要的。
2010-09-17 16:31 | .Jack[未注册用户]

#33楼 　回复　引用　查看　

@吉日嘎拉 不仅权限管理
泥娃娃，还不停止写文章是的话，我叫我家的旺财咬你哈
2010-09-17 16:32 | ttlin2010yeah

#34楼[楼主] 　回复　引用　查看　

@.Jack
你这个回复也很好，所以我也没跟大家闹个你死我活，适当的强力建议。

2010-09-17 16:33 | 吉日嘎拉 不仅权限管理

#35楼 　回复　引用　查看　

程序员更好面子？
2010-09-17 16:33 | dangjian

#36楼 　回复　引用　查看　

“顽固的思维方式”，不如说是“固执的思维定式”！

每个程序员的成长经历不同，所以要想改变他们“固执的思维定式”，那是相当的难！

2010-09-17 16:34 | 卡通一下

#37楼 　回复　引用　查看　

学习ing……
2010-09-17 16:34 | ffffff

#38楼 　回复　引用　查看　

对于代码楼主说得对，对于软件项目管理这不一定对。
2010-09-17 16:46 | chenqin

#39楼 　回复　引用　查看　

这是管理的问题，楼主不能怪程序员啊

若是你给他们工作量减半，他们自然会写出更好的代码，若是他们能像楼主这样，每天还有空来写写博客，他们也能有更多的时间写出更好的代码

2010-09-17 16:48 | 小 雷

#40楼 　回复　引用　查看　

说点个人意见。
1。做软件先有设计，后有施工的思路。这个话我同意。
不过很多时候，你有设计，别人都做好了。当然再对后期的扩展和维护来说，有设计当然更优秀，但是，当你还在设计的时候，别人的程序客户都用上了，我想客户不会考虑说你的设计有多好，我不用他的，用你的。因为客户关系的是业务功能，不是代码。所以有时候很无奈。当然有充足时间，绝对建议先设计后施工。

2。还是跟上一个类似的问题。话是好话，但往往实际情况不会让你如愿，修改一个几年前的代码，还要重构到面向对象，这中间花费的时间和金钱，谁来负责，重构之后出现的新BUG谁能说服客户软件在提高而不是下降（别告诉我修改和重构后一定不会出现新BUG）？当这个代码还能使用的时候，我想老板是不愿意付出这个时间和金钱的，客户也不愿意用一个看不见的代码更完善，但有一些新BUG的版本。直接说，开发第二版 更能说服老板。

3.这个同意。

4.这个不同意。不是为了分层而分层，如果说“重命名一方法也要修改很多环节”,只能说分层的人，没用好分层，这不是 分层的错。

5.同意。
2010-09-17 16:54 | 红色壁虎

#41楼 　回复　引用　查看　

这篇文章我支持吉日。
很多东西不这么做不那么做，我感觉就是一个“懒”，不过表达的时候用“软件工程”作为理由了。
我在做项目的时候是强烈推动不断改进的，每个星期的任务里，产品人员推动看得见的产品进步，我推动看不见的产品进步。
2010-09-17 16:57 | Jeffrey Zhao

#42楼[楼主] 　回复　引用　查看　

@卡通一下
需要用艰难来形容的。

2010-09-17 17:00 | 吉日嘎拉 不仅权限管理

#43楼 　回复　引用　查看　

赞一个，推荐+1
2010-09-17 17:00 | 风也无奈

#44楼 　回复　引用　查看　

我不得不说两句了。

第二点：维护遗留下的系统，特别是经历了N手人的系统，那种语句还真没必要改。 你都说了是面向过程的，改一处动全身。小心进去了出不来。

第四点：
“什么设计模式、开闭原则、反射把时髦的技术都用上了,导致写一个方法，需要到处去修改” .
很明显，你误用了开闭原则。

2010-09-17 17:01 | MuyangBaba

#45楼[楼主] 　回复　引用　查看　

今天我估计要失眠了，居然能跟大师产生了共鸣了，一般程序若有错，我就是不睡觉通宵都会把程序修改好，有的好时候重构一下，可能会删除掉3000-4000行代码，也是1个小时就足够了，这就所谓的执行力度不一样吧。

引用Jeffrey Zhao：
这篇文章我支持吉日。
很多东西不这么做不那么做，我感觉就是一个“懒”，不过表达的时候用“软件工程”作为理由了。
我在做项目的时候是强烈推动不断改进的，每个星期的任务里，产品人员推动看得见的产品进步，我推动看不见的产品进步。

2010-09-17 17:01 | 吉日嘎拉 不仅权限管理

#46楼[楼主] 　回复　引用　查看　

@红色壁虎
你是思路严谨，表达能力强，有想法的人，鉴定完毕。

2010-09-17 17:15 | 吉日嘎拉 不仅权限管理

#47楼 　回复　引用　查看　

有点意思。
2010-09-17 17:23 | www.w2pf.com

#48楼 　回复　引用　查看　

第五点不敢苟同。对于有一定经验的人可以使用代码生成器，但是对于菜鸟来说，手写代码是必须经历的阶段，不然以后就会是个代码机器.....
2010-09-17 17:30 | Alexis

#49楼 　回复　引用　查看　

@紫砂壶
引用紫砂壶：怎么老是宣传你的视频啊？？
人家做个视频推广一下自己的系统不可以吗？本来就赚不了几个钱推广一下还得被说。搞什么嘛~~~。
2010-09-17 17:30 | 荣少

#50楼 　回复　引用　查看　

推荐+1
2010-09-17 17:30 | Alexis

#51楼 　回复　引用　查看　

有好多问题都遇到过，不过楼主的第２。３条：
对于没事的程序员，改代码啊，改老程序啊什么的做做，当然没问题。
对于付钱给你的人来说：明显你自己写说了理由了，还何必拿出来讨论呢。
１。程序好好的，花钱找你改？
２。程序好好的，花钱找你人改面向对象，还到处BUG？
楼主　第２。　３条应该是说给自由软件工作者或者和楼主一样的人听的吧？

如果程序不是楼主你写的，那你没用任何理由发表看不起人的话语（你心中应该有数），你可以教导，可以劝说，但除非你花钱，否则你再有想法，也请不要强加与别人。

当然接下来楼主接手这样的过时编码（回头看，不久前的代码就过时了），你可以大展身手，表现一下自己的编码水平，回头还可以把你的修改发到博客园让大家欣赏一下。
2010-09-17 17:34 | 凌晨的太阳

#52楼 　回复　引用　查看　

完了，现在不在首页看到吉日都感觉寂寞的不行...
2010-09-17 17:39 | 炭炭

#53楼[楼主] 　回复　引用　查看　

@炭炭
不会吧老大？
2010-09-17 17:48 | 吉日嘎拉 不仅权限管理

#54楼 　回复　引用　查看　

这篇文章写的不错，推荐，的确程序员的思想还是要转变，需要不断的接收新的思想才能有所突破
2010-09-17 17:49 | CallHot

#55楼 　回复　引用　查看　

1：建议做软件先有设计，后有施工的思路
这个我赞同，做MIS系统没有ER图怎么动手。

2：程序改进为面向对象的吧？
拼SQL和面向对象没有任何关系。

3：需要不断重构完善
没有单元测试，谈何重构？

4.里层划分太多了，写代码写太多了
过分设计不是“什么设计模式、开闭原则、反射把时髦的技术都用上了”导致的。如果合理使用设计原则，代码不会牵一发动全身。

5：建议大家用代码生成器
这个我赞同，但是不能全部都用生成器，否则说明做的事情太无聊了，太低水平了。

6: 建议大家空时看一线我的视频，绝对对工作会有些帮助的。
这个没看过，不评论。

2010-09-17 17:51 | Jake Lin

#56楼 　回复　引用　查看　

从本文想表达的思想来看，我是支持的。任何一个管理者都必须有立场、有态度、高要求。大多数时候，这样的态度不仅对团队有益，对成员都有益。
但是标题还是有问题。通常遵循以下议论文的惯例来定义文体：
“论”：指论述。这个概念有点大，必须有论点、论据，涉及所述主题的方方面面，篇幅也会相应比较大。
“议”：比“论”小，不必有分明的论点和论据，但通常会有一个明确的中心命题，着重阐述作者对该命题的态度，而不是描述事实。
“小议”或“浅议”：比“议”更小一点，虽然也必须有一个明确的中心命题，但是相对这个命题的大小而言，文章所展开的广度更窄一些、深度更浅一些。
“谈”：和“议”的范围差不多，但中心命题不一定非常明确，与“议”不同，通常以“叙”事实为主，“议”观点为辅。
“小谈”或“浅谈”：和“小议”的范围差不多，比“小议”更随意。
此外，文章标题通常用中性词，也强调公正性，而不是直接给一个“顽固”定语的结论。例如：“谈某些程序员思维方式的顽固性”和“谈某些程序员顽固的思维方式”这是有天壤之别的，前者是公正的，后者是偏激的。因为“顽固性”是一个名词，中性词。而“顽固的思维方式”则是加了定语的。如果某个人不承认他的思维方式是顽固的，你的文章这一箭就射偏了。
2010-09-17 17:56 | 双鱼座

#57楼 　回复　引用　查看　

面向对象何止10年？！！！！！！哪来的数据？？？？？？？
2010-09-17 18:05 | 钧梓昊逑

#58楼[楼主] 　回复　引用　查看　

@双鱼座
小议 感觉很合理。

2010-09-17 18:09 | 吉日嘎拉 不仅权限管理

#59楼[楼主] 　回复　引用　查看　

@双鱼座
说得的确很有道理，让我提高了不少，是我恩师。
2010-09-17 18:17 | 吉日嘎拉 不仅权限管理

#60楼 　回复　引用　查看　

此贴性质 约等于 广告
2010-09-17 18:24 | 编程浪子_

#61楼 　回复　引用　查看　

这不叫顽固，这叫懒！懒得去学新知识，不求上进！反正我现在这点也够用！也可以做出项目！就这种心态！这种心态的还是不要做程序员算了！
PS：这个评论与第五条无关~
2010-09-17 18:28 | 李宏

#62楼 　回复　引用　查看　

引用双鱼座：
...
“论”：指论述。这个概念有点大，必须有论点、论据，涉及所述主题的方方面面，篇幅也会相应比较大。
“议”：比“论”小，不必有分明的论点和论据，但通常会有一个明确的中心命题，着重阐述作者对该命题的态度，而不是描述事实。
“小议”或“浅议”：比“议”更小一点，虽然也必须有一个明确的中心命题，但是相对这个命题的大小而言，文章所展开的广度更窄一些、深度更浅一些。
“谈”：和“议”的范围差不多，但中心命题不...
论：期望对方能接受自己的观点。

议：自己也不十分肯定。

谈：想听对方的看法。

扯：只是图个热闹。

2010-09-17 18:32 | 卡通一下

#63楼 　回复　引用　查看　

为什么大家都要争个你die我live呢？ 谈谈事情，聊聊天，心平气和不是挺好的吗？ 包容包容
2010-09-17 18:49 | 小棋

#64楼 　回复　引用　查看　

说的都不错！
换我现在这家公司，只要有人提议去重构一下现在的系统，估计怨声四起。罢了，咱们都是凡人，做好自己的事，想改变别人还是算了吧。
2010-09-17 19:06 | 熊猫发光

#65楼 　回复　引用　查看　

支持下吧，说的很有道理的，上次我跟我上级搞翻也大概就是这么些原因了！

让那种听不进别人话，不敢革新，不敢创新，不愿意尝试的老顽固都闪一边吧

有些领导为了表面好看非要下面的人敷衍了是 忽悠客户，只要不弹BUG就是最好的，只要数据库里的时间是1秒一条记录就是完美的，去TMDB

当然作为摞代码的民工我们有时敢怒了 言了 却要被批评打击，

总之~ 做人对得起公司对得起别人的时候 千万也别对不起自己，

干完合同期就走人，不要在一个猪一样的领导手下做事
2010-09-17 19:20 | %admin

#66楼 　回复　引用　

1.程序员确实有问题
2.从你的语气，你应该是团队的管理者，即便不是，也可以看出你不够格做一个团队的管理者，你的目的是想改进，看的出团队成员对你个人很是不服，谈改进估计只能是痴人说梦，哪怕你有再好的想法，执行不了那只能说你的修炼还不够，看起你真的不像是一个在职场混了这么多年的人，倒很像一个刚毕业的小愤青。
2010-09-17 19:52 | 路人甲11[未注册用户]

#67楼 　回复　引用　查看　

支持,其实说白了就是懒.程序员本身就是需要不断吸收新知识,不断进步的一群人.固步自封只会被新人超越丢了饭碗.
2010-09-17 21:09 | xigua

#68楼 　回复　引用　查看　

大师啊，看来你应该了解一下教育，你说得在好，也改就不了什么的嘛，做项目经理的，老是要程序员按他们的意思做，但是程序员也有想法撒。想问楼主一下，怎么保持一直做程序哟（可能有点糼稚），我初学，快坐不下去了啊！！！
2010-09-17 21:40 | xin_ny

#69楼 　回复　引用　

吉日平时不写代码吗?做管理了吗?人家在写代码你在整理文章哦!
顶你
2010-09-17 22:17 | dingjiri[未注册用户]

#70楼 　回复　引用　查看　

关于第5条我觉得没什么，手写是很好的方式啊，如果一个程序员经常用鼠标要比键盘多，哪一定不是好程序员
2010-09-17 22:28 | 新志

#71楼 　回复　引用　查看　

唉 , 你们这些上班时还能上网真是太幸福了.
我可没这待遇
2010-09-17 23:12 | 坚持破译

#72楼 　回复　引用　查看　

支持吉日，我看过你的数据库设计的视频，确实不错，赞一个。
至于你说的情况，我感觉咱俩的处境类似，性格也差不多，看到那么多垃圾代码恨不得拍桌子骂娘，别说让我们去维护了。但有时候历史遗留问题不是一天两天，一个人两个人能解决的。我现在的做法是：原来的项目维护工作，尽量保持原来的风格；新做的自己负责项目，按规范走。至于你说的那几种程序员我们单位也有，有时候强迫也没用的，像你是技术总监还好，咱普通程序员也没权力要求别人。所以只能靠自己的风格，自己的技术一点点影响他们，现在情况已经好一些了。

再有一个建议就是沟通要讲技巧，尤其对中国人，中国的程序员，你上来就说“你这块写的不对，这样写有问题，这样不规范”，是不会有人接受的，因为他会觉得你不尊重他，有了这个前提，你说什么都是白说。你可以和他说“你的程序写的不错，哪块哪块值得向你学习；但是就某处来说，如果这样这样写实不是更好？”，想来更容易让人接受吧？
2010-09-17 23:17 | John Liu

#73楼 　回复　引用　查看　

时间呢？给你做产品的时间肯定可以不断的重构。
2010-09-17 23:18 | 陈房贵

#74楼 　回复　引用　查看　

建议本身都很好，感觉大家担心的是怎么实施，多交流会好的。
2010-09-17 23:19 | 我是打酱油的

#75楼 　回复　引用　查看　

深有同感，我有时候也有这样的气愤情绪，遇到的情况和你差不多。
对于你所说的这些顽固的程序员，我个人认为是两个原因导致：
1.视野不宽，以为掌握了工作中用到的技术就行了，习惯成自然，不会主动接触新知识学习新东西，也不了解其它的解决方法和流程。
2.缺少精益求精的品质，对于一个稍显稳定的系统，就很害怕修改会带来不稳定，而不会去想如何提升品质和稳定性，对重构这个概念比较陌生，更没有习惯。

曾经问过同事，让他们推荐几个专业的技术论坛，他们只告诉我一个CSDN，我当时差点儿气晕了。
2010-09-17 23:21 | 无待

#76楼 　回复　引用　

小鸡，你要努力学好带团队啊，程序员最不喜欢的就是话多不干活的人啊，注意了，可能你们的团队人员不认可你的技术。
2010-09-17 23:21 | 我也是路人甲[未注册用户]

#77楼 　回复　引用　查看　

我认为效益问题才是最重要的，人生苦短，想一辈做写程序吗？其实那样想是没前途的。

你的程序合不合规范，架构好不好，不是你一个人说了算，架构好的系统从来都不是一人搞的开发。国外如此多开源系统，人家就算用最简单的PHP，都可以写出比中国大多数.NET程序员更接近OOP规范的应用出来。

如果真的有那份热心，咱们搞个社区版开源系统，一同架构更好的系统，并且令使用者知道系统架构完善的好处，这才是正道。

微软和GOOGLE都有开源社区，我们有什么？
2010-09-17 23:23 | 猫之良品

#78楼[楼主] 　回复　引用　查看　

@猫之良品

我们有金蝶、用友，哈哈，做得还不错的。

2010-09-18 01:20 | 吉日嘎拉 不仅权限管理

#79楼 　回复　引用　查看　

顶一个~~~~真的很朴实很有用！
2010-09-18 08:41 | Jack Fan

#80楼 　回复　引用　

支持吉日的说法，
不过现在是领导的问题，不懂B/S，拿着C/S的想法来指挥开发。
喜欢用所谓的一般技术，sql+DataTable,怕以后没有人能维护。成本不想支出过多。 而以前开发PB的，以前用过C#1.1的同事，也很喜欢。

拼SQL和面向对象的确是没有任何关系。
不过现在的情况是，拼SQL的人，特别怕数据库变化，非常怕业务变化。

2010-09-18 09:57 | forevery[未注册用户]

#81楼 　回复　引用　查看　

吉日嘎拉, 你说的太好了! 我完全同意你的观点.

但是并不是所有人都这么想, 这也就是为什么在中国做软件还是有很多机会的.

2010-09-18 10:07 | glshader

#82楼 　回复　引用　查看　

引用BreezeWoo：
老哥，
说句实在话，你的管理方法还是有问题，该制定流程的时候就制定流程。
这样吧，给你说个故事，能不能明白，就看你明悟吧：
有七个人曾经住在一起，每天分一大桶粥。要命的是，粥每天都是不够的。
一开始，他们抓阄决定谁来分粥，每天轮一个。于是乎每周下来，他们只有一天是饱的，就是自己分粥的那一天。
后来他们开始推选出一个道德高尚的人出来分粥。强权就会产生腐败，大家开始挖空心思去讨好他，贿赂他，搞得整个小团体乌烟障气。
然后大家开始组成三人的分粥委员会及四人的评选委员会，互相攻击扯皮下来，粥吃到嘴里全是凉的。
最后想出来一个方法：轮流分粥，但分粥的人要等其它人都挑完后拿剩下的最后一碗。为了不让自己吃到最少的，每人都尽量分得平均，就算不平，也只能认了。大家快快乐乐，和和气气，日子越过越好。
同样是七个人，不同的分配制度，就会有不同的风气。所以一个单位如果有不好的工作习气，一定是机制问题，一定是没有完全公平公正公开，没有严格的奖勤罚懒。如何制订这样一个制度，是每个领导需要考虑的问题。
好经典的小故事。可以用来比拟国家、社团、公司---- 任何一个组织。
这个故事说明了一个问题。团队出问题，就是领导有问题。老百姓不过是当政者手下的棋子。
再谈谈楼主的想法。太自我了，完全是占在自身所处位置讲出来的东西。“医之好治不病以为医”。
首先应该肯定的说楼主所举的一些东西都是好东西。但是好东西我们就要拿过来用吗？ 有句很经典的话：“把飞机的引擎按装在拖拉机上一定行”。事实上只有适合的才是最好的。
我写个小应用程序半天多时间就搞定了？你要我写设计，要我用7 8层框架？！ 存有毛病。
我也发现很多搞程序的有个误区。总觉得自己的代码多，结构复杂，就牛B了。这叫做蠢。把简单问题搞复杂了。框架的开发出忠就是把复杂的东西简单化明了化。但用的前题是 你的项目复杂度一定要高于框架本身。当然楼主的心情我也能理解。总觉得自己占这个位置不搞点啥明堂，对不住自己心理需求，显不出自己价值。这个不光是在程序领域，在很多领域人都犯这个毛病，这是中国人的通病
2010-09-18 10:51 | 泥冰

#83楼 　回复　引用　

我很少回帖子，但自认为开发也不差，现在大家都喜欢用实体类的方式，其实我觉得实体类应用到数据库上，特别是建立那些字段对应的属性类，是程序员的病态应用，就好比说div比table好，就到处都用一个道理.
如果你想应用这种实体类,我建议你用linq，最起码一拉就一个实体类，还有很多功能，汇总统计等等也比较容易.
数据库我只会抽出一个接口去做，我希望项目越搞越简单，真要是维护出了问题，谁也不可能临时动代码，效率就不说，我追求使用sql语句，而且尽量写到存储过程中，最起码改变起来，我只要去数据库改一下sql，系统缓存，机制都不会丢
2010-09-18 11:51 | 吉日嘎拉-最顽固[未注册用户]

#84楼 　回复　引用　查看　

确实说到心坎去了，可惜很多时候有些东西还得有经理或多数人的支持才行，否则你一个干劲满满，其它人都不搭理，还会吃力不讨好!
2010-09-18 11:58 | 潇湘隐者

#85楼 　回复　引用　查看　

博主其實也提出自己的觀點，認為其他程序員應該仿傚，不知道博主對自己這些觀點是否也很"頑固"呢?

其實「擇善而固執」並非壞事。

很多工程上的問題和選擇，並無銀彈。每個都可從正反雙方辯論，博主的論點被人所駁並不一定是"頑固"使然。在下認為，工程上的問題，為某項目某情況找到適合的方法便可。
2010-09-18 12:58 | Milo Yip

#86楼 　回复　引用　查看　

6: 建议大家空时看一线我的视频，
写错一个字，哈哈
不听老程序员的话 还是很不好滴
2010-09-18 13:17 | 李传涛

#87楼 　回复　引用　查看　

说的有道理。
2010-09-18 13:30 | 一张纸

#88楼[楼主] 　回复　引用　查看　

@李传涛
谢谢您的指证，已马上修正，再次感谢。

2010-09-18 13:46 | 吉日嘎拉 不仅权限管理

#89楼 　回复　引用　查看　

开发一个东西肯定是要先有设计，但至于设计是否在开发之前用文档表示要根据项目的紧迫程度来决定吧，开发完成后确实有必要补充一个文档（重点在于关键的算法，结构之类的），目的在于今后的维护。
另外好的公司，开发都会有自己的流程，比如使用什么技术，什么代码并发控制软件，什么自定义自动化编译环境，甚至测试环境。
2010-09-18 13:46 | 大料

#90楼 　回复　引用　查看　

你要求别人像“要求自己”一样严格，显然是不现实的。
即使你的想法是好的，什么样的表达方式更能让别人信服还是很有技巧的。
还是别让自己太累吧。。

2010-09-18 14:16 | 小Sun

#91楼 　回复　引用　查看　

@吉日嘎拉 不仅权限管理
是的，大企业做好的软件、好的产品。不过那不是因为用了什么新技术，软件好就是好，代码写得好不好，这个没人知道。所以程序还是以效益最重要，用什么手段没关系。
2010-09-18 14:31 | 猫之良品

#92楼 　回复　引用　查看　

嗯 有点道理 下了视频 待会看
2010-09-18 14:39 | 月夜 思量

#93楼 　回复　引用　查看　

一个字：懒。
2010-09-18 19:45 | undefined

#94楼 　回复　引用　查看　

一个顽固的人写出的文章还是真够顽固的，虽然某些方面讲得有道理，但总体上都感觉很幼稚
2010-09-18 21:38 | 轻轻听

#95楼 　回复　引用　查看　

曾经有个比较有水平的朋友跟我讲：“别人做的软件是否设计合理、功能是否正确，有经验的人看看数据库设计文档就能感觉到很多”。
-------------------------------------------------------
我认为这句话不够正确。

原因是：上层业务和数据库之间还有一个数据访问层，数据模型设计的好坏主要影响到的是数据访问层的复杂度和效率，对业务逻辑层没有影响。
2010-09-18 21:51 | 潇湘雨歇

#96楼 　回复　引用　查看　

正解。因为他们不是主管，因为他们拿的钱比你少得多；所以，他们的立场是如何快速完成任务，更多的时间用来QQ等等
引用Milo Yip：
博主其實也提出自己的觀點，認為其他程序員應該仿傚，不知道博主對自己這些觀點是否也很"頑固"呢?

其實「擇善而固執」並非壞事。

很多工程上的問題和選擇，並無銀彈。每個都可從正反雙方辯論，博主的論點被人所駁並不一定是"頑固"使然。在下認為，工程上的問題，為某項目某情況找到適合的方法便可。

2010-09-18 22:57 | 个人知识管理

#97楼 　回复　引用　查看　

思维僵化的人，不应该做程序员
2010-09-19 08:58 | Rioyang

#98楼 　回复　引用　查看　

引用ttlin2010yeah：操你大爷的，你不要再发文章啦

注意素质，是不是大便吃多了，出来咬人。
2010-09-19 10:31 | 老马的家

#99楼 　回复　引用　查看　

吉日兄，你的文章很好，支持一下。
2010-09-19 10:33 | 老马的家

#100楼 　回复　引用　查看　

这篇很好，但是你的方案解决不了任何问题。

问题源于日常的管理没跟上，这个是个长时间的问题，不是一次重构能解决的。

这种问题 就是项目小，什么都没有。 几个技术比较好的做了个原型出来，一切都好，后来有人走了，新人来了，什么资源都没有，那就修修改改吧，年复一年积累的。 一个如果已经开发了3-4年的mis 系统。里面全是sql 拼接，+手工建议的。
要改就首先要你的设计文档，能和现在版本符合的设计文档。 你让程序员直接改掉代码，出现bug谁负责，特别在中国企业里，做好是应该的，出了bug要程序员负责的制度。必然导致大家多一事不如少一事的心态。

所以要从源头改起， 你先把设计文档， 详细设计文档，代码编写规范都补齐了，再开始补er 图， 再解决sql问题，再解决校验问题。 而不是这样想一剂猛药解决问题。
2010-09-19 13:59 | msnweb

#101楼 　回复　引用　查看　

文章很好，支持一下。
2010-09-20 00:49 | 小平C#

#102楼 　回复　引用　查看　

深有感触，一针见血的指出了程序员通有的毛病，俺个人是这么认为的。。。。支持一下。。
2010-09-20 13:34 | 无澍

#103楼 　回复　引用　查看　

楼主是中国软件的有心人，以软件为事业，可决大部分人只是以此混口饭吃，楼主也很无耐呀，故做有此文，不知道我理解的对不对,呵呵
2010-09-20 13:42 | №竹竹_

#104楼 　回复　引用　查看　

引用ttlin2010yeah：操你大爷的，你不要再发文章啦

看到这个我确实笑了

2010-09-20 16:09 | starwar3

#105楼 　回复　引用　查看　

红配蓝，招人烦。
2010-09-20 16:47 | Highflyer

#106楼 　回复　引用　查看　

代码生成器，一开始我用，现在早就不用了，也不推荐大家用。
2010-09-27 09:28 | mytudousi

#107楼 　回复　引用　查看　

如果你的表里面有100个字段，说明你的表设计的有问题。
即使你的表里面有100个字段，就需要一个类中的100个属性和其对应吗？肯定有相关的一些信息组织到另外的小类中去。代码生成器这些都干不了。只能硬生生的生成代码。
2010-09-27 09:32 | mytudousi

#108楼 　回复　引用　查看　

引用双鱼座：
从本文想表达的思想来看，我是支持的。任何一个管理者都必须有立场、有态度、高要求。大多数时候，这样的态度不仅对团队有益，对成员都有益。
但是标题还是有问题。通常遵循以下议论文的惯例来定义文体：
“论”：指论述。这个概念有点大，必须有论点、论据，涉及所述主题的方方面面，篇幅也会相应比较大。
“议”：比“论”小，不必有分明的论点和论据，但通常会有一个明确的中心命题，着重阐述作者对该命题的态度，而不是描述事实。
“小议”或“浅议”：比“议”更小一点，虽然也必须有一个明确的中心命题，但是相对这个命题的大小而言，文章所展开的广度更窄一些、深度更浅一些。
“谈”：和“议”的范围差不多，但中心命题不...

汉语语言功底深厚！本对吉日大哥的观点已是心悦诚服，然此评论又是给了我一记叹为观止的喜悦。