随笔分类 -  管理相关

软件工程师两年的职场训练
摘要:德鲁克说:“组织的成员作为个体,发展得越好,组织也会取得更多的成就。这一点正是今天所有经理人培训和资深经理人教育课程重点和背后的真谛所在。当组织严谨的作风和道德精神不断发展、组织的目标和处事能力不断提升时,组织内个体成员的发展空间也愈加广阔。”借着写博客把关于软件开发中新人训练的想法总结一下,也希望抛砖引玉,得到大家的指正。综合来说,一个软件工程师的培养需要涉及以下四个方面: 1. 产品专业开发领域 指的是产品开发过程涉及的专业技术。如操作系统、数据据等。这里不讨论这一项。 2. 通用软件开发技能 指的是诸如代码撰写、Debug、单元测试、系统分析之类,也包括思维拓展等。 3. 产品应用领域  阅读全文

posted @ 2011-12-02 21:42 c语言源码 阅读(199) 评论(0) 推荐(0)

圈复杂度评价及工具
摘要:转载请注明出处:http://blog.csdn.net/horkychen圈复杂度用来评价代码复杂度,以函数为单位,数值越大表示代码的逻辑分支越多,理解起来也更复杂。圈复杂度可以成为编码及重构的重要参考指标,以指导撰写可读性高的代码。有关圈复杂度的定义,可以自行搜索。《代码大全》有如下的定义:计算子程序中决策点数量的技术(代码大全2,19章P458)1.由1计数,一直往下通过程序。2.一旦遇到以下关键字,或者其同类的词,就加1: if, while, repeat, for, and, or3. 给case(switch)语句中的每一种情况都加1.作者也给了处理复杂度度量结果的建议:0-5: 阅读全文

posted @ 2011-11-21 16:18 c语言源码 阅读(1423) 评论(0) 推荐(0)

[《人件》摘录]: 生产力:赢得战役和输掉战争
摘要:下次当你听某人谈到生产力时,仔细听一听说话的人是否用了“人员调整”一词,很大的可能性是他或她没有提到这个词。多年来从听到的关于生产力的讨论或看到的数以百计的关于这方面的文章中,我们从没有遇见一个专家谈到有关人员调整这个主题的任何事情。然而只谈论一个而不谈论另外一个有什么意义呢?下面评价一下公司在改进生产力方面要做的一些典型的事情:l强迫人们加班加点l产品开发过程的机械化l在产品质量上的妥协l生产过程的标准化 这些措施中的任何一个都会潜在地降低工作的趣味性和满意度。因此,改进生产力的过程是在冒险使人才流动幅度加剧。这不是说你不付出人才流动的代价你就不能改进生产力。这只是说无论何时开始达到更高的. 阅读全文

posted @ 2011-11-18 20:01 c语言源码 阅读(151) 评论(0) 推荐(0)

为何不大情愿去做一件事
摘要:人可能出于以下原因不大情愿去做一件事:1.太简单2.太繁琐3. 太难4. 认为没有价值或意义 (或对工作而言,或对个人而言)5. 时间上安排不了6. 其它方面带来情绪上的影响首先要尊重个人的价值判断,如果是5及6,就不要强求。如果4,则要分开看。倘若个人明确了未来目标,且与现在的目标冲突,在讲清可能的收益后,就顺其自然。倘若个人目标并不清晰,仅仅认为当前任务对个人没有意义,就要帮助其分析。如果1,2,3,都是要花点时间,从中间进行提練可以提升的部分。其实,别人不愿做事,才是要花心思去做的事。如果你能做好,那就是价值。如果做不好的话,那还是随大流吧! 阅读全文

posted @ 2011-09-02 10:35 c语言源码 阅读(180) 评论(0) 推荐(0)

较好的代码维护实践
摘要:在别人实现的基础上进行开发,基本是一种常态。特别是对原来的代码陌生的情况下,有没有什么好的实践方法呢?基本原则:类似重构一样,尽量减少对原有流程和结构的修改,最好能兼容原有结构。上来就按自己的相法来修改代是比较容易的,这样做很大程度是因为理解原有的代码需要较长的时间且有一定的难度,但这样会增加系统的复杂度,也会引入许多不必要的风险。除非得到项目负责人的同意,否则相当然的直接动手重写,绝非是什么好事!那么如何做呢?要花大量的时间从头阅读代码吗?你以为文档写得那么好吗?嗯,阅读代码和文档是免不了得,但需要有明确的目标和有序的安排。有效地控制各个阶段所关注的内容是成功的关键。过早的被许多的细节困扰会 阅读全文

posted @ 2011-05-18 22:33 c语言源码 阅读(136) 评论(0) 推荐(0)

《Peer Reviews in Software: A Practical Guide》第2章 - (2)
摘要:Review的结果不可用于个人工作的评价依据,这样会严重影响组织的文化,人人开始回避Review。可以使用总的统计数据进行质量改善。滥用Review会导致一些不良态度的产生:1.开发者不愿进行Review2.Review人员不会在会上直接提出问题3.Review过程中会进行激辨4.内部Review时会趋向发现较少的问题5.开发者可能反复提供相同的代码进行Review,以减少可能发现的问题。作为一个Manager必须认真思考这个问题,帮助解决在Review上的抗拒心理。Review注意事项:1. 先排除自我保护的干扰2. Review的人员应当较少(3~7)3.只在Review中找问题,而不是马 阅读全文

posted @ 2011-05-03 21:07 c语言源码 阅读(146) 评论(0) 推荐(0)

《Peer Reviews in Software: A Practical Guide》第2章 - (1)
摘要:让别人指出工作中的错误是需要学习的,并不是天生就会的。我们都自豪于自己的工作,从不乐于承认错误。我们不知道犯了多少错,也不愿意其他人发现这些错误。如果你正着手于建立成功的Peer Review,这些自然的抵触情绪就必须克服。Peer Review是和技术训练类似的社交活动。在一个组织中,逐步灌输Review流程,一定要了解组织文化和成员们所持有的价值观。经理们应当相信花在Review的时间是一种投次,然后为团队安排Review,你要理解为什么某些人并不愿意将自己的工作拿给同事们做详细的审查,而且牢骚不断。你也要向团队和经理说明Peer Review流程,期待的行为,以及大家的帮助对于个人和团队 阅读全文

posted @ 2011-04-27 23:06 c语言源码 阅读(209) 评论(0) 推荐(0)

《人件》描述的是乌托邦!
摘要:读了一下<<人件>>,最大的感触的是软件行业的问题似乎在这二十年没有变化过,作者也提到过软件行业的革新的速度只不过比钢铁企业稍快一点而已,我想应该远不及街头小贩的革新速度。如果是这样,既然这本书被如此推崇,却得到多少实质性的改变呢? 说到底,这件事完全要看老板怎么看!即便程序员和项目经理再清楚这个行当所谓的真理,又能如何? 人人都能有个靠窗的位置,人人都不用常加班而平衡地生活,真不知道老美是不是已经享受到了。但看看我们周围,那只能是痴人说梦一般。醒醒吧!变化是一步步进行的,环境也是这样!想要做到如作者期望的那般,还有很长的路要走, 也有一些事情可以在自己能影响的范围内推 阅读全文

posted @ 2011-04-20 23:31 c语言源码 阅读(141) 评论(0) 推荐(0)

程序员要学会偷懒---正确运用自动化技术
摘要:马云语录: 世界是由懒人来支撑的! 懒不是傻懒,如果你想少干, 就要想出懒的方法。 要懒出风格,懒出境界。McConnell在他的<<Code Complete>>提到三种"懒":"实在的懒","开明的懒"以及"一劳永逸的懒"。并说明第三种"懒"才是最具产值的"懒",因为它需要运用工具或者代码来为自己完成任务:这就是工作中的自动化。<<The Pragmatic Programmer>>的作者也有专门章节提到"一切都要 阅读全文

posted @ 2011-04-15 00:41 c语言源码 阅读(184) 评论(0) 推荐(0)

研发人员的职业精神
摘要:除去基本的专业精神,以及一般的职业精神外,作为研发人员还有以下两项独特的职业精神:一、无中生有---创新精神 创新是研发人员的基本要求,而不是什么高深的目标。基于现有条件,创造出具有不同价值的事物就是研发人员的工作。目前没有,我们就去创造!运用新的思考方式,深入学习可以掌握条件,然后加以整合、提练,最终开发结果。这个过程,重复与模仿或许不可避免,但关键还是要打造自己的知识系统,为日后持续的创新打好基础。其实,很多创新的成果形成一段时间后,都会被认为那是“正常的、一般的”,它有一定的时效性,所以对研发人员而言,只有不断创新,工作才有价值。“等一切准备就绪”将会使研发人员失去创新的本质。没有条件, 阅读全文

posted @ 2011-01-03 23:40 c语言源码 阅读(389) 评论(0) 推荐(1)

导航