|
项目管理者联盟 | 中国工程管理网 | 中国研发管理网 | |
会员中心 | |
资料库 | |
论坛 | |
博客 |
 |
|
 |
||||
|
|
||||||||||||||||||||||||||||||||
|
标题：开发人员最难于打理的九项工作
楼主
|
|
 wcabt PMB：21982 省份：天津市 行业：工程设计安装 注册：2006/12/14 |
软件开发人员经常需要啃下任务当中的硬骨头——而其中大部分都跟编写代码毫无关系 大多数非程序员朋友都会认为软件开发工作难度很高——虽然实际情况确实如此，但与普通群众的印象仍然存在出入。最近Quora网站发起了一份调查，统计了开发人员在工作当中遇到的最令人头痛的艰巨任务。通过对此次调查的反馈及评分结果进行汇总，再加上Ubuntu论坛曾经整理出的相关意见，我们统计出这份程序员眼中最难于打理的九项工作清单。正如各位所见，事实证明编写代码并不是编程工作中最大的难关。如果大家本身正是软件开发专业人员，那么这份清单上的许多任务肯定会勾起您不少“美好”回忆。 1. 命名难题 任务:为变量、程序、函数、类、对象以及数据库组件等起名字。 挑战:即使是在一个小型程序或者应用当中，我们也必须要想出很多个相关名称。选择名称的目的是为了表达某种事物的内容或者作用，这项工作贯穿于应用程序始终且必须足够简洁。 群众观点：“想出有意义的变量名称。” “为数据和函数起一大堆有意义的名称。” “在计算机科学领域只有两个大难题：缓存失效与事物命名。” “……如果你在去除重复和改正糟糕名称方面表现突出，我可以负责任地讲——你已经是一位面向对象设计的高手了。” 2. 解释我是做什么的(或者不做什么) 任务:向非程序员(包括家庭成员、朋友、非技术同事等)解释自己的岗位职责是做什么的以及不能做什么。 挑战:某些全身心爱着我们的人确实弄不明白我们到底靠什么谋生。再有，有些家伙不断要求我们帮着解决任何与计算机有关的问题。 群众观点： “尝试向任何人做出解释——我不知道怎样修复他们的计算机。” “向我的家人解释我是干什么的。” “我已经无数次向外行们解释，程序员并不代表没日没夜地编程!!” “我需要向人们解释，我不是电子城里那些每天给人装盗版操作系统和其它盗版软件的家伙。” 3. 估算任务的预计完成时间 任务:在项目起步阶段估算出完成全部工作所需要的时间。 挑战:在尚未着手之前猜测某件可能发生的事情将耗时多久，根据含糊的要求做出估算并为这些说不清楚的问题分配处理时间。 群众观点：“我发现在真正进入实践阶段之前，要对编程工作中可能出现的意外状况做出预判真的很难……” “我发现估算是最难的工作，因为大部分人都把估算当成承诺。” “……任务的实际执行时间根本不可能被准确预测……” 4. 和其他人打交道 任务:收集来自客户的需求信息、向管理层提交状态报告、与测试人员们共事以及向其他工程师交代项目内容等。 挑战:向非技术人员解释技术内容，工作主动权落在他人手中，与品质保证人员或者其他开发人员发生分歧。 群众观点： “与某些人比起来，我更喜欢跟处理器交流——这样更方便。” “来自非技术人员的阻碍……还有那些来自其他技术人员的代码编写指导……” “……对于技术行业一无所知的家伙实在很难沟通。” “其他团队的成员进度滞后，而我们只能坐着干等……” 5. 处理别人的代码 任务:不得不为由其他开发人员编写的应用程序或者代码片段进行维护、调试或者强化。 挑战:尝试理解某些遗留代码片段的工作方式并揣测原始开发者的真实意图本身已经很不容易，如果无法跟那家伙取得联系或者其人的编程水平、注释说明或者历史记录特别糟糕，这项工作就会变得更难。 群众观点：“尝试处理那些语焉不详的代码。” “有些人根本没资格编写代码，可有时候我却得处理他们抛出来的东西……” “尝试破译成千上万行未加注释的代码。” 6.被迫实现那些自己无法认同的功能 任务:有时候我们认为某些特性或者功能根本不应包含在应用当中，但客户或者某些职级更高的家伙却坚持要这么干。 挑战:抛开我们的个人感受或者意见，花费时间和精力来实现(并支持)那些尚存疑问的功能。 群众观点：“……我们只有两种选择——要么忍气吞声、要么趁早滚蛋。” 7. 撰写文档 任务:创建一份文档来解释自己的代码有何作用或者应用程序如何工作。这项工作当中可能包含创建多个独立文档以及代码注释。任务的目标受众范围非常广泛，从终端用户到其他开发人员都可能涉入。 挑战:这很可能是一项费时费力的任务，甚至有些浪费青春——毕竟愿意认真阅读说明文档的用户实在没多少。程序员通常更乐于通过编写代码来直接生成说明文档。 群众观点：“撰写这种根本没人会看或者会用的垃圾文档，只是因为这是‘流程’的一部分。” “不能处理代码，反而需要撰写一份能清晰解释当前工作的文档。” “撰写文档时，需要同时满足良好、解释清晰以及简洁三大要求!” 8. 编写测试 任务:编写单元测试，也就是把对小型代码单元进行宏观测试以确保它能正常工作。这些测试能帮助我们在开发流程早期发现并剔除bug，同时在代码被修改或者更新之后进行回归测试。某些开发方法鼓励我们在着手开放代码之前制定测试规划，但其它一些则倾向于在拥有代码成果后再考虑测试事宜。 挑战:选择测试机制并着手编写相当繁琐、因而令人十分头痛，开发人员会明显感受到这是一种额外任务、与应用开发本身严重脱节。 群众观点：“编写测试(这倒并不难，但我很讨厌做这类工作)。” 9. 设计解决方案 任务:根据一系列要求设计出技术解决方案并为其选择合适架构。这项工作当中可能包含设计数据及代码结构、功能算法以及能够囊括业务逻辑及理想用例的应用程序流。 挑战:确保我们所设计的解决方案能够满足客户需要，即起到预期作用又能在规定的时间框架内完成。 群众观点:“考虑如何从A开始、到Z结束，这是工作中最困难的部分。” “如果项目设计太臃肿，最终就会被自身的庞大规模所压垮;如果项目设计太单薄，又会缺乏实用性。” “在真正着手工作之前，很难准确预计事情的实际走向……”
|
| 回复 | 引用 发表时间：2014/2/24 21:55:42 | |
| ！ 您尚未登录，不能回复主题。 现在 登录 注册 |
|
