原帖由 山中无老虎 于 2007-9-27 14:06 发表
实际上软件工程所鼓吹的是培养一大批的软件工人，以最低的投入换取最高的回报，根本没有从个人的发展上着想过，也没有为任何一个软件工人想过其职业规划的事
原帖由 山中无老虎 于 2007-9-27 14:06 发表
实际上软件工程所鼓吹的是培养一大批的软件工人，以最低的投入换取最高的回报，根本没有从个人的发展上着想过，也没有为任何一个软件工人想过其职业规划的事
原帖由 knighter 于 2007-9-27 14:19 发表
这个没理解，或者说不至于吧
不过现在有些公司确实是，大项目分工很细，以致于很难从整体把握。类似于一个流水线工，能完成一个工序，但对整个产品无能为力。
原帖由 山中无老虎 于 2007-9-27 14:37 发表
工业上是可行的，因为是一种体力或机械的劳动。而管理理论的由来就是为了提高生产效率，换句话说就是能得取更高的利益。
软件工程也有按这个方向发展的趋势，把所有的东西完全细化，每个人只知道自己的一部分，那么些人出去后可以说只是一个编程的好手，但根本没有自己的系统思路，那么这是什么？这就是一个软件工人，如果只有少数的这种人，工资当然会高，但如果培养了很多的这种人，工资水平会如何？所以我说软件工程实际上也是为了利益而提出的，可能有些偏激。
至于说没为个人着想，你想，一个项目中，你只了解自己的一部分，对别人的一部分根本不清楚，那你这部分的思维能拿的出去吗？拿不出去的话，你想跳槽会有多大的成功率呢，待遇提高的可能性又有多大呢？对于软件工人，培养的只是开发能力，而不是处理事情的能力，这时候想掌握一些东西只能靠自己，能说他为个人的职业规划着想了吗？
原帖由 knighter 于 2007-9-27 14:47 发表
确实只能靠自己了
现在一个项目里，能从大局考虑的估计也就项目经理等少数人。要想自身发展，真的要在工作中主动多学习。当然有领导提拔就更好了
机会可遇不可求，修为在自身。
但是我认为，软件工程是有助于培养一个人在软件项目中的大局观的
原帖由 山中无老虎 于 2007-9-27 14:06 发表
此题无解。
软件工程是一个理论的东西，如果完全按理论进行，必须得满足绝对的条件或大部分的条件，但有这种条件的企业有多少？日本这方面做的不错，但他们是在利用廉价的中国劳动力做为其条件的补充，印度好象 ...
原帖由 jaffaz 于 2007-9-27 16:01 发表
企业毕竟是个盈利机构，没有义务为员工的职业生涯做规划。反过来也差不多，想想又有几个员工会在企业的长远发展上花心思了？
企业与员工之间的关系，本来就是相互利用。企业接来的单需要人去干活；员工依附企业也是为了生存需要。
原帖由 knighter 于 2007-9-27 16:16 发表
这是国内企业的现状，外企一般都会注重员工的职业规划的。
而老虎也是那种为手下兄弟作规划的领导
员工对公司的忠诚很重要，问题是现在企业给的待遇不好，不为员工着想，员工哪来的忠诚可言？
原帖由 jaffaz 于 2007-9-27 16:22 发表
老虎的百层大楼我也看过，只能说他手下那位兄弟太走运了
原帖由 knighter 于 2007-9-27 16:25 发表
现在开始拍老虎屁股吧
有人指点过我的发展方向，我感激他，但是他的为人，我鄙视他……
原帖由 knighter 于 2007-9-27 16:25 发表
现在开始拍老虎屁股吧
有人指点过我的发展方向，我感激他，但是他的为人，我鄙视他……
原帖由 jaffaz 于 2007-9-27 16:38 发表
？为人
原帖由 山中无老虎 于 2007-9-27 16:44 发表
吓我一跳，幸好我是CU最聪明的人。
他不是说我。
原帖由 jaffaz 于 2007-9-27 16:38 发表
？为人
原帖由 山中无老虎 于 2007-9-27 16:44 发表
吓我一跳，幸好我是CU最聪明的人。
他不是说我。
原帖由 jaffaz 于 2007-9-27 16:45 发表
你的大楼盖到一百层了，有空继续
原帖由 knighter 于 2007-9-27 16:47 发表
咔咔，不好意思
差点让老虎和耗子误会了
原帖由 knighter 于 2007-9-27 16:46 发表
做人比较恶心啊，胡乱造谣
之前是我的直属领导，汗～后来我到另一组了
现在他手下的人对他怨言不少啊，做个领导要有咋样的手腕呢？～～～
原帖由 山中无老虎 于 2007-9-27 16:53 发表
原帖由 jaffaz 于 2007-9-27 16:56 发表
其实有时候也是因为相互间缺少了解引起的
原帖由 ssafa 于 2007-9-28 12:13 发表
软件工程的发展方向感觉就如同大规模的工业生产，通过重复某种简单的劳动来建立流水线模块，然后通过改变模块位置或者添加新的模块或者删除旧的模块来得到符合需要的产品。
原帖由 shaver 于 2007-9-28 13:12 发表
一个人写程序，也存在这个问题吧
规模大了，就需要划分成小块；而块与块之间，需要信息的流通。。。。。。
但是，有什么办法？
我们不能把所有的代码塞到一个函数里面；同样，一个上点规模的软件，也不能指望 ...
原帖由 liuty2006 于 2007-9-28 14:39 发表
组件化编程是个好的解决办法。
可以通过定义接口来区隔不同组件的开发。
基本可以实现多人同时开发。
但对设计接口的人员要求比较高！
原帖由 柳拂风 于 2007-9-28 17:35 发表
大规模集成电路是怎么设计的？
是每人设计一小块再拼起来吗？
原帖由 liuty2006 于 2007-9-28 22:14 发表
MS几千人参与的系统设计开发，怎么协调？
COM组件开发起了很重要的作用。
也就是各模块之间只暴露接口。这样，当内部实现发生改变时不会影响其他部分的运行。
可以说，WINDOWS操作系统其实就是一个组件库。
COM组件被MS应用的炉火纯青！
程序开发经历了三个阶段：
面向过程－－》面向对象－－》面向接口（组件开发）
现在正在兴起面向服务。
感觉：面向接口开发可以使系统开发并行，各个组件只对接口负责。
解决了多人开发协调的问题。
原帖由 liuty2006 于 2007-9-28 23:23 发表
面向服务知道一些，但没有实践。
但对面向接口编程，感触很多。
好不夸张地说，对编程观念是个很大的改变，甚至可以说是革命。
觉得任何一个程序员都要了解这个技术。
面向接口后，感觉面向对象很“丑陋” ...
原帖由 liuty2006 于 2007-9-28 22:14 发表
MS几千人参与的系统设计开发，怎么协调？
COM组件开发起了很重要的作用。
也就是各模块之间只暴露接口。这样，当内部实现发生改变时不会影响其他部分的运行。
可以说，WINDOWS操作系统其实就是一个组件库。
COM组件被MS应用的炉火纯青！
程序开发经历了三个阶段：
面向过程－－》面向对象－－》面向接口（组件开发）
现在正在兴起面向服务。
感觉：面向接口开发可以使系统开发并行，各个组件只对接口负责。
解决了多人开发协调的问题。
原帖由 liuty2006 于 2007-9-28 23:23 发表
面向服务知道一些，但没有实践。
但对面向接口编程，感触很多。
好不夸张地说，对编程观念是个很大的改变，甚至可以说是革命。
觉得任何一个程序员都要了解这个技术。
面向接口后，感觉面向对象很“丑陋” ...
原帖由 aha111 于 2007-9-29 09:46 发表
无论在什么样的公司，人员的流动性是不可避免的，无论是主动的还是被动的，对公司来说，考虑如何让人员不流动是毫无意义的。软件工程的提出确实是为了流水线操作，这样做的目的呢，既是为了提高开发效率，不只是只有几个高手才可以参与项目，这样也可以减少人力资本。同时，也是为了减少员工的流动对项目造成的影响，公司就是想让任何一个人都是一颗螺丝，拔掉一颗螺丝还能运转。从企业管理或项目管理的角度来说，这种想法不是很应该的吗？
原帖由 liuty2006 于 2007-9-29 10:11 发表
面向接口是对面向对象的升华。
将面向对象中的纯虚类以接口的方式固定下来。
从“最好使用”改变为“必须使用”接口方式编程。
以物理的方式强迫你面向接口进行思考。
原帖由 山中无老虎 于 2007-9-29 10:24 发表
那只是编程方法，但不是编程的思想。
原帖由 knighter 于 2007-9-29 10:33 发表
昨晚我仔细想了想，觉得好像面向接口只是面向对象的一种衍生
但是现在没有找资料，没有发言权
引用自：http://www.e-midas.cn/Article_Show.asp?ArticleID=107
在一个面向对象的系统中，系统的各种功能是由许许多多的不同对象协作完成的。在这种情况下，各个对象内部是如何实现自己的对系统设计人员来讲就不那么重要了；而各个对象之间的协作关系则成为系统设计的关键。小到不同类之间的通信，大到各模块之间的交互，在系统设计之初都是要着重考虑的，这也是系统设计的主要工作内容。面向接口编程我想就是指按照这种思想来编程吧！实际上，在日常工作中，你已经按照接口编程了，只不过如果你没有这方面的意识，那么你只是在被动的实现这一思想；表现在频繁的抱怨别人改的代码影响了你（接口没有设计到），表现在某个模块的改动引起其他模块的大规模调整（模块接口没有很好的设计）等等。
Booch先生那天谈到Interaction Designer，它就是指做这类设计的人，只不过层次更高一些。我想目前我们的软件设计队伍中，这类人是最缺乏的人才之一。
非接口编程？是不是就是面向过程的编程思想？
1.关于接口的理解。
接口从更深层次的理解，应是定义（规范，约束）与实现（名实分离的原则）的分离。
我们在一般实现一个系统的时候，通常是将定义与实现合为一体，不加分离的，我认为最为理解的系统设计规范应是所有的定义与实现分离，尽管这可能对系统中的某些情况有点繁烦。
接口的本身反映了系统设计人员对系统的抽象理解。
接口应有两类：第一类是对一个体的抽象，它可对应为一个抽象体(abstract class)；
第二类是对一个体某一方面的抽象，即形成一个抽象面（interface）；
一个体有可能有多个抽象面。
抽象体与抽象面是有区别的。
2.设计接口的另一个不可忽视的因素是接口所处的环境(context,environment)，系统论的观点：环境是系统要素所处的空间与外部影响因素的总和。任何接口都是在一定的环境中产生的。因此环境的定义及环境的变化对接口的影响是不容忽视的，脱离原先的环境，所有的接口将失去原有的意义。
3.按照组件的开发模型（3C），它们三者相辅相成，各司一面，浑然一体，缺一不可。
面向对象是指，我们考虑问题时，以对象为单位，考虑它的属性及方法
面向过程是指，我们考虑问题时，以一个具体的流程（事务过程）为单位，考虑它的实现
接口设计与非接口设计是针对复用技术而言的，与面向对象（过程）不是一个问题
我认为：UML里面所说的interface是协议的另一种说法。并不是指com的interface，CORBA的interface，Java的interface，Delphi的interface，人机界面的interface或NIC的interface。
在具体实现中，是可以把UML的interface实现为语言的interface，分布式对象环境的interface或其它什么interface，但就理解UML的interface而言，指的是系统每部分的实现和实现之间，通过interface所确定的协议来共同工作。
所以我认为，面向interface编程，原意是指面向抽象协议编程，实现者在实现时要严格按协议来办。也就是Bill Joy同志说的，一边翻rfc，一边写代码的意思。面向对象编程是指面向抽象和具象。抽象和具象是矛盾的统一体，不可能只有抽象没有具象。一般懂得抽象的人都明白这个道理。 但有的人只知具象却不知抽象为何物。
所以只有interface没有实现，或只有实现而没有interface者是没有用的，反OO的。
所以还是老老实实面向对象编程，面向协议编程，或者什么都不面向，老老实实编程。
但是我很讨厌讨论这样的术语，不如我们谈谈什么叫面向领导的编程？面向用户的编程？领导和用户有时都很BT，我们就面向BT编程？
http://www.e-midas.cn/Article_Show.asp?ArticleID=107
原帖由 山中无老虎 于 2007-9-29 10:35 发表
看了2006的发言后，找的一篇文章。
原帖由 aha111 于 2007-9-29 10:57 发表
错了，软件工程的分工做法恰恰有利于挽留对公司有重要作用的人员，因为这样分工，他们可以专注于全局，而不必事事亲历亲为。
你想啊，在一个公司中，是人人都是轴承好呢，还是只有那么几个轴承好呢？要是人人都是轴承，你要花费力气去挽留任何一个人啊，要不，只要有一个人离开了，他负责的项目就完蛋了，因为从头到尾，只有他自己知道，文档也没留下。而只有几个轴承呢，公司要做的是集中精力去挽留这么几个人而已。
为了减少轴承掉了后的影响，目标就是要让轴承的工作有可替代性，坏了可以马上换一个，插上直接就可以用。这就要强调标准、规范、流程。甚至让总经理、董事长之类的离开了，他所定下的远程目标依然能够运转。当然，人的因素之所以最重要，也在于人的脑力劳动是不可复制的。所以，对于这个目标，也只能是减量去靠近。
当然理论永远是理论，而且理论的作用更多的是告诉人们要去做什么，而无法告诉人们怎么去做。怎么去做要跟实际结合，找到符合自己实际情况的有效办法。
原帖由 knighter 于 2007-9-29 11:13 发表
师姐原来也是高人啊！
不过和老虎说的不矛盾，在一个项目里都有那么一个或多个关键轴承，比如项目经理。
这便于项目的执行管理，减少了项目失败的风险。也就为企业的管理设定了指导思想。
而对于个人 ...
原帖由 knighter 于 2007-9-29 11:13 发表
师姐原来也是高人啊！
不过和老虎说的不矛盾，在一个项目里都有那么一个或多个关键轴承，比如项目经理。
这便于项目的执行管理，减少了项目失败的风险。也就为企业的管理设定了指导思想。
而对于个人 ...
原帖由 aha111 于 2007-9-29 11:26 发表
我不是高人
原帖由 山中无老虎 于 2007-9-29 11:24 发表
我跟你的理解正好相反。
我的理解是：所有人都参与，但有分工。而不是软件工程先分工，然后各干各的（当然也要沟通），这样关键人只是公司指定的，而并不一定真的是关键人物，因为大家都对全局有一定的了解，每 ...
原帖由 山中无老虎 于 2007-9-29 11:24 发表
我跟你的理解正好相反。
我的理解是：所有人都参与，但有分工。而不是软件工程先分工，然后各干各的（当然也要沟通），这样关键人只是公司指定的，而并不一定真的是关键人物，因为大家都对全局有一定的了解，每一个人都有可能是轴承，这样我就不用为了挽留某一个人而费心，也就是平时所说的：没了谁地球都一样转。而软件工程，我觉得他忽略的正是人的重要性，特别是关键人的重要性，把关键人变成不一定是关键人是关键。
替代性我一直是这么做的，我不喜欢让别人威胁我，所以在项目中虽然有一个绝对的核心，但他也一定有备份存在，而且不止一个，因为大家都了解这些东西，只不过了解程度不同，做备份的档次也不同。
至于文档方面，是必须通过公司的制度来执行的，但软件技术文档不同于管理制度文档，因为即使有文档，你所能了解的也只是文档的内容，但实际开发中情况千变万化，如果有一个也对项目有一定的了解的人来接手这部分工作，会比一个外来人强的多。
我主要是强调人的重要性，在软件工程方面，任何的制度、方法只能起到辅助的作用，永远代替不了人（前提是公司资源有限的情况）。
原帖由 山中无老虎 于 2007-9-29 11:28 发表
软件工程方面的书看的不是很多，到目前为止系统看过的就两本：人月和人件。我是一个纯粹的实践派
原帖由 aha111 于 2007-9-29 11:44 发表
没错，大致是这样。这也是这篇文章有提的，也是我前面所说的这篇文章唯一的意义，但却不能因此就全盘否定软件工程中的分工啊
我觉得软件工程只是一个系统的方法论，给你一个大体的导向，并不是要你就一定要完全照搬啊。比如，它有说要有系统分析员，系统架构师，程序员。在一个小项目，这个分工也是有意义，在这里，系统分析员、架构师、程序员完全可以是一个人，但如果这个人具有软件工程的理论，他应该明白，他承担了这三个方面的工作，每个方面的工作和步骤，他自己可以有一个清楚的认识和理解，而不是说，他想怎么就怎么样，只要最后能出得来可交付的成果就可以了。
至于分工嘛，我还是比较赞同先分工，也赞同参与项目的人都要对项目从头到尾有个认识，先分工，可以提高效率，也可以提高每个人对自己的工作的关注度，在一起了解项目的过程度，每个人会侧重自己更应该关注的方面。
原帖由 aha111 于 2007-9-29 11:53 发表
老实说，我看的也不多。而且我曾经在干了一段时间后，离开了这个软件行业很多年，不久前才回归。
实践更重要呢，如果没有实践，就成纸上谈兵了，当你觉得自己的理论无懈可击的时候，殊不知，实际中却不是这 ...
原帖由 knighter 于 2007-9-29 11:53 发表
分工是肯定的了。有能力的人始终会与众不同，是金子就会发光
但是一个项目里，必须有一个有大局观、沟通协调能力强的人，这是很关键的，此人未必技术很牛。同样技术大牛也未必就是最关键的人物。
软 ...
原帖由 山中无老虎 于 2007-9-29 11:24 发表
我跟你的理解正好相反。
我的理解是：所有人都参与，但有分工。而不是软件工程先分工，然后各干各的（当然也要沟通），这样关键人只是公司指定的，而并不一定真的是关键人物，因为大家都对全局有一定的了解，每 ...
原帖由 山中无老虎 于 2007-9-29 12:02 发表
我就是对理论了解的太少了，对理论经常有一种瞧不起的态度，这样不好。
刚才我在清茶感谢你师弟，让我又开始重新学习了，我觉得经常讨论一下这东西就是各取所需。
欢迎以knighter为核心，常来讨论 ...
原帖由 山中无老虎 于 2007-9-29 12:04 发表
名校出来的人跟普通学校出来的人就是不一样。
PS：不是瞧不起谁，也不是PMP，是真心话。
原帖由 jaffaz 于 2007-9-29 12:05 发表
很赞成所有人都参与，然后分工。
若先分工，以后的沟通成本将会更高，且开发人员误解设计的可能也会更大。
原帖由 knighter 于 2007-9-29 12:12 发表
Ono，我非常的惭愧……
技术没有，理论也正在学，怎么可能成为核心呢
愧对学校啊，我太惭愧。不过我觉得名也只是学校的——惭愧，这是去年人家教训我的
...
原帖由 jaffaz 于 2007-9-29 12:05 发表
很赞成所有人都参与，然后分工。
若先分工，以后的沟通成本将会更高，且开发人员误解设计的可能也会更大。
原帖由 knighter 于 2007-9-29 12:18 发表
耗子就是被我拉过来参与讨论D
耗子这里所说的，就我公司而言，我的部门经理就是希望在需求分析阶段一起参与讨论，让每位成员都参与到项目中。
只是现在… ...
原帖由 jaffaz 于 2007-9-29 12:20 发表
我是写程序的，只是从程序员的角度来看，有很大局限性的
原帖由 jaffaz 于 2007-9-29 12:20 发表
我是写程序的，只是从程序员的角度来看，有很大局限性的
原帖由 knighter 于 2007-9-29 12:27 发表
倒，你这么说，那我做测试的
每个人都有认识的局限性
原帖由 jaffaz 于 2007-9-29 12:36 发表
呵呵，别那么认为。
我的意思是说我之前对于工程管理这部分很少关注，所以你跟老虎讨论这这些问题对我来说都算比较陌生的。
原帖由 山中无老虎 于 2007-9-29 11:59 发表
嗯，我否定软件工程实际上是从对人培养是否有利的方向出发的。
分工上我还是喜欢后分工，因为先参与能够最大限度的了解软件人员技术的优势，这样可以根据不同的人安排不同的方向，能最大限度的发挥其优势。实 ...
原帖由 aha111 于 2007-9-29 12:56 发表
软件工程考虑的是怎么样更好的完成一个项目，包括项目的后期维护和跟进。而不是从人的培养来说的。但是我觉得即使从对个人的发展来说，我也会赞同软件工程的分工方式的。对一个新手来说，如果一下子就让他从头到尾都要一个人去完成一个项目，只怕他是苦不堪言啊。但是如果分工的方式，他最初做的也许就是一个很机械的编程工作，就是要求你要完完全全的把别人的设计文档实现，他要考虑的只是怎么更好的熟悉和运用好编程语言和工具，这对他来说会容易多了。而随着这样的工作多了，任何一个有思想的人，都会慢慢去思考，为什么设计人员会这样设计，而且会结合自己实际用编程工具实现的过程中的实际情况，思考这样的设计好在哪，不好又在哪，如果由自己来设计，又会怎样做。这样一步步的，他的成长会更加明晰。而做为领导，如果你想创造一个有利于手下成长的环境，你要做的是，给这些有想法有兴趣的去参与其他不同工作的员工一个机会。同时，你也可以鼓励手下在做好自己的那份分工之余，多思考别的分工和别人的做法的优劣。
后分工的做法，对一个具体的项目来说，会降低效率。了解软件人员技术的优劣，是在平时工作和做项目的过程中，慢慢了解的，你不可能要做一个项目了，然后才去了解每个人，然后才分工。
原帖由 山中无老虎 于 2007-9-29 13:20 发表
软件工程的理论特别是流水线方式剥夺了一部分人提高自己的机会，一个公司用一个人，应该是即让这个人工作，也给这个人接触其他事物且学习提高的机会，只用人，不培养人，只靠员工自身学习来提高自己我认为是不 ...
原帖由 aha111 于 2007-9-29 13:51 发表
造成这个问题不是软件工程，而是公司的用人制度。
原帖由 aha111 于 2007-9-29 12:56 发表
软件工程考虑的是怎么样更好的完成一个项目，包括项目的后期维护和跟进。而不是从人的培养来说的。但是我觉得即使从对个人的发展来说，我也会赞同软件工程的分工方式的。对一个新手来说，如果一下子就让他从 ...
原帖由 jaffaz 于 2007-9-29 12:32 发表
之前发现跟你同城，就有兴趣搜了下你的帖子，发现你除了在清茶灌水外就基本只是在这里混了。
来了只会看了些老虎的帖子，觉得写得不错，就久不久来这里看看了
原帖由 knighter 于 2007-9-29 16:51 发表
我来CU的目的，本来是学习Linux的，发的第一帖好像就是在Linux那边
没想到的就是现在主要混清茶了
因为工作相关，溜进来“软件工程”版，发现老虎大作，被深深吸引，于是更坚定了 ...
来了只会看了...
原帖由 山中无老虎 于 2007-9-29 17:51 发表
每人收100000000块钱的学费。
原帖由 jaffaz 于 2007-9-29 17:57 发表
冥币
原帖由 山中无老虎 于 2007-9-29 17:58 发表
小样，猜你就会这么说。
原帖由 山中无老虎 于 2007-9-29 17:51 发表
每人收100000000块钱的学费。
原帖由 knighter 于 2007-9-29 18:19 发表
能买多少只老虎？
原帖由 knighter 于 2007-9-29 18:19 发表
能买多少只老虎？
原帖由 jaffaz 于 2007-9-29 18:28 发表
假如你买两只狮子的话，送你一只老虎
原帖由 powerpolly 于 2007-9-29 22:37 发表
说的确实有些道理。。。
| 欢迎光临 Chinaunix (http://bbs.chinaunix.net/) | Powered by Discuz! X3.2 |