2008-10-17 10:51:21 heweiyabeijing 阅读数 221

       我曾经管理和经历过使用所谓“敏捷开发”的两个相对比较大的项目。之所以是“所谓的敏捷开发”,掺杂了不少了自己的实现和理解,见笑了。

       第一个所谓的敏捷开发的项目是迫不得已的,因为项目前期投入大而且人事变卦(其它公司挖墙角),后期没有足够的时间来完成项目,所以我自告奋勇承接这个项目,CALL,其实就是为了年底能够领到更多的奖金。这个项目总价是100W,其中30多W是硬件,30多W是公关(灰色)费用,老板给我的成本价是15W,而且很认真的给我算出这个数。当时老板给我的条件是:公司资源随便支配,其中开发资源计在成本之内,三个月交付,这个时期内最少有三个重要的里程碑,每个里程碑必须完成工作的35%,包括质量检查。

        我的做事方法,一个能力跟我相当的程序员,一个能力一般且很仔细的程序员,一个测试工程师,另外还有一个是美工,还有客户方至少有一个到现场帮助测试或者业务讲解。然后在中关村某公寓封闭开发。

         我们挤在一个不大的会议室里,都在一张桌子上办公,开发程序有点像流水线,第一个是我,我写程序快,经验多,i当然BUG也多。因为是J2EE程序,我在前一周都是在写所有表的增删改查,其中MODEL和DAO这一层自动生成,controller这一块写了通用的增删改查,页面也是简单的增删改查。然后就是其它两个程序员帮助我修改一下错误和BUG。测试人员在写测试用例,美工在和客户方交流用户的操作体验。总之,我想要说的话是:敏捷开发当中,敏捷的生产过程非常非常重要

         。我们经常交流,且有一种努力创业的想法。

         。有能力的程序员,让他写一些通用的方法和JS。(随便是google或者baidu上去抄)

         。客户方帮助我们不少。每个人都了解业务,有的想去卖仪器(哈哈,客户是做仪器的)

         。我们没有单元测试,每个人做完既定的功能后就提交功能测试,我们每个人的BUG很多,但是后面就很少。

         。我们完成一个相对独立的模块后,就提交给实用户,到现场进行试用。

         当然也少不了零食,看板,使用xplaner做管理。

          结果:我们不到两个月完成项目的85%以上,如果不算BUG的话,应该是在90%以上,然后退回到公司过着朝九晚五的生活。年终我也领到了两个多月工资的奖金。一个字爽。客户如期上线。

         黑五总结:跟着我的几个哥们,很讨厌我,他们最希望加薪,我只给他们的福利是每天120元/所有人的消费标准,每天工作10个小时左右,工资每天加100元,星期六星期天加200元(可以选择过星期天)。经过这个事后,他们很疲惫,虽然他们的技术提高很快,但是对公司的不满也每天增加,终于不出半年走掉一个,不出半年,又走掉一个。

         个人感想:敏捷开发的方法是老板喜欢看到的,因为敏捷开发方法节约成本,快速交付。但是对于员工来说,这种管理让人感觉压力很大,有点变态的感觉。我想如果一个人长期处于这种敏捷的开发当中,而自己没有自由的空间时,员工的不满会与日俱增的。尤其我们IT程序员跟现在的小姐一样,青春就哪么几年还在变态中渡过,所以从员工角度来说敏捷开发不是很好。

          我同时又想到了“计件工资”,又扩大了思维想到了“联产责任承包制”,又想到了“事业部”。感觉敏捷开发应该和员工的利益直接关联。于是我又想到了长得漂亮“出台率”巨高,美妓李师师......

          可能,敏捷开发的路可能还很远,对企业的管理方式也会不断的变化。这家伙,搞的天天跟考试一样。

          至今,找到的新工作也在敏捷的氛围当中进行,看看我的BLOG的更新时间你就知道我有多忙,为了生存,奉献身体,奉献青春。

          个人想法,仅供参考,不要人身攻击。

           链接:敏捷生产

2008-08-27 17:26:12 iteye_6036 阅读数 82
二弟的一篇介绍 敏捷的文章,希望有机会在 GBS 的系统实施中能够早日用上 敏捷


关于敏捷
2008-08-27 10:02 | (分类:默认分类)
今天写实习总结,描述了一下这几个月的收获。截取其中的一段关于敏捷的感想。

Scrum对于我这样的开发人员来说,让我可以直接参与到整个开发周期的各个阶段。在评估会议时,团队中的每个成员都有权对产品的需求项进行评估,确定需求的工作量大小。在Sprint 计划会议1中,由Product owner对该Sprint中的需求项进行需求描述,明确具体的需求。在Sprint计划会议2中,Scrum master组织团队对既定产品backlog的需求项进行任务划分,将每个任务细化到每天的工作中,确保在Sprint周期中,每个人的任务分工明确。

在Sprint每日的例会中,每个开发人员报告自己的工作进度,并明确下一天的任务,遇到障碍,可以及时找到相应的人员开会解决。在Sprint的评审会议中,对Sprint的完成的任务进行提交演示,并可以增加新的需求项。在Sprint的回顾会议中,确定这个Sprint的成功和失败的经验,及时总结。

我们开发人员在整个Sprint周期中,可以明确需求,并自主地安排工作进度,在技术增长的同时,也增加自己的工程管理的经验,有利于个人职业生涯的发展。Scrum相比于其他的过程模型,更加注重团队个人素质的提高,并且能够快速的应对变化。

TDD也是一种敏捷开发的方法。它的主要思想是通过建立一套可执行的测试用例,保证代码的实现与具体的需求的一致性,以测试用例作为中介,建立一个有序的工作方式:从需求用例中导出测试用例,从测试用例中导出代码的接口和实现。

在我平时的开发过程中,严格的遵守了TDD的指导。拿到一个具体的Use case时,先测试几组测试数据,然后用JUnit建立一个Test case与Use case对应,在Test case中采用Mock对象,先虚拟地对测试方法进行实现,等测试通过之后,再抽取出具体的接口,然后实现。

我觉得TDD的好处是在产品的开发过程中建立了一套可运行的Test case,让需求变得具体,可控。一旦需求发生了变化,可以从Test case 入手,然后再修改实现代码。使需求的变更在代码的级别变得可控。

我还学习了基于Java平台的动态语言Groovy。这是一种敏捷的开发语言,比Java语言具有更高的抽象性,用少量的代码表现更多的功能。

在IBM的收获是让我体验到了“敏捷”无处不在。从敏捷软件过程的Scrum方法,到测试驱动的开发方式,到敏捷的开发语言,整个软件工程的各个方面都有敏捷的出现。我考虑过这个问题,为什么这两年敏捷变得如此的流行。我觉得一个原因是让需求的变更变得可控。软件工程发展了10多年,积累的大量的原始资源,各种平台,中间件林立。客户对软件的需求从最初的简单发展到如今的非常复杂,业务变更非常频繁。过去那种僵硬的,按步就搬的开发方式和管理方式已经不再适应变化。比如采用瀑布模型,开发了几个月客户才看到最终产品,但是最初的需求已经改变地面目全非了。Scrum的好处是它把“变”与“不变”控制地很好,在Sprint进行中Sprint backlog是不应发生改变地,保证了工作的有序。在Sprint的开始和结束之后可以进行需求的变更。由于Sprint的周期长度较短,这种短暂的稳定,可以让团队在正确的道路上持续的前进,而不是全程的变化,找不到正确的道路。

敏捷是软件工程的发展方向,让我们拥抱变化,让生活变得更美好一点。
2015-11-18 19:49:00 weixin_30814329 阅读数 3

个人作业week7——前端开发感想总结


 

1. 反思

首先要谈谈在这次团队项目的工作中,我这边出现过的较为严重的一个问题:
我和HoerWing (后端担当)合作时,最初因为我没有使用github(始终连不上,最后才确认是宿舍有线网的问题,没错就我那一个位置这样= =),所以导致我和后端这块对于代码进展的情况严重不同步,因为我们要同时写一个网页,同时又因为是敏捷的工作模式,所以经常会需要做一些小的修饰,而在这个时候就会冲掉对方先前写的一些逻辑。整个项目中前后端对接是比较后期的一件事儿,所以这个问题最后才暴露出来,不过好在后端这边封装得很好,因此没有拖延整个工作流程太久,用无线连上github并和后端使用了一个共同的分支之后这个问题基本已经解决。


 

2. 网页开发中的‘大泥球’

我最初理解的是对于前端应该不需要过多考虑这方面的问题,但后来整个页面的绘制加前端逻辑写下来也是上千行的东西,结构和功能逻辑都会比较复杂,比如不同的操作时页面元素的改变,用户保存实验数据,发送XML格式化的数据,后端处理完毕后返回正确结果或异常时按钮的响应情况是不同的,相应的也会伴随着一些页面元件的样式变化,因此后端要做代码复审工作就会变成一件非常捉急的事情,这个在前后端对接的初期成为了一个类似于‘Big Ball of Mud’的东西,不过好在我跟后端沟通后结果了这个问题,那就是我来复审后端添加的逻辑代码,并将纯前端的内容分离拷贝出来以便本地查看实际效果,相比较前端的内容,后端添加的逻辑很精简也很易读,毕竟我这边没有配置过后端框架的环境(事实上也不好去在linux系统下做这些设计的事情,至于虚拟机,我可能会在年底考虑换硬盘的事儿,但是现在没有钱),所以没有办法做到所见即所得,只能采取这么个这种的方案,不过好在对于一个小项目,这一点的影响不算很大。


 

3. 交易频繁的集市

对于集市和大教堂,我觉得整个软件的项目可以从整体上视为一个大教堂,但是同一个部门(比如网页交互,计算核心开发)内部采取的是集市的模式,那么就会不免常常有两个人修改同一部分,结果出现各种代码上的冲突。对于学生时代的我们而言,将这些冲突通过PM合理分配工作来化解实在是太难了,尽管PM很负责,但是我也能看到,更多时候他是通过自己重写有问题的部分来解决这些问题,相比较归咎于经验不足,我觉得这可能是软件工程中的普遍现象?因此我提倡如果要求敏捷,则对于一个独立出来的负责部门而言,或由一人负责,或由有良好交流的两个人结对编程来完成。这样对于敏捷开发过程中的频繁更新情况,在做代码修正时的内部沟通成本也可以有效降低。


 

4. 代码优化与软件工程

每个软件在开发的过程中,都会不停地去考虑代码优化,或者说代码可扩展性以及兼容性的问题,因此这就增加了每次代码调整的成本(这要求我们必须重新审视之前所有优化过的地方,但是更常见的场景是你有可能不知道别人所做的那一部分优化),比如为了避免冗余我常常会采用jquery绑定的方式来为一组DOM对象绑定事件函数,但对于单一DOM对象的事件则回归JS的写法;对于中文字体的显示,考虑到网速问题,就放弃用下载来的中文字体去渲染而是通过建立合适的font-family顺序,针对不同的用户调用其系统内置的优化字体去显示(将mac的冬青黑列在win的雅黑之前等等);为了更好的兼容各种浏览器而放弃一些H5的新特性之类;于是当我需要改动的时候我自己都常常会忘记有哪些地方需要重构(在没有用户反馈的前提下),所以我发现果然最好的解决办法还是回归PS(笑


 

5. Agile 敏捷

考虑到敏捷的要求,我们使用了一些框架,并且参考了一些模板(如se7en)中一些css的写法,并提取出来放到网页的样式表中,此外也在codepen社区上摘了一些HTML+CSS的动态样式(LOADING动画),不过由于bootstrap定义了大量的类名使得做这种事儿命名冲突会比较难于处理,所以能自己写的样式部分我就全都自己写了,对于一些批量使用的样式(比如实验数据表格模态框),就集成到自己定义的样式表里,我觉得这也是一个很好的前端初学者工作模式,用框架去保证兼容性和响应式布局的问题(虽然实际上还是自己写了一些响应式的东西去应付较为特殊的情况),然后不去动框架,手写自己的自定义样式,并在它们反复出现的时候去做集成的工作,对于JS这边我想也是如此,即使引入jquery,一些简单的逻辑,或者较为基础的一些(如AJAX)还是自己用JS原生的方式全部过一遍比较好,一方面有助于深入理解前端开发,另一方面在跟后端对接时也会比较有帮助。

开发时参考过的博客:
网页开发中的中文字体:http://www.ruanyifeng.com/blog/2014/07/chinese_fonts.html
JS中的面向对象:http://www.ruanyifeng.com/blog/2010/05/object-oriented_javascript_encapsulation.html

转载于:https://www.cnblogs.com/kibbon/p/4975685.html

2009-03-23 17:38:53 cjwxd126715 阅读数 280

需求
 你能给出一些非功能性(或者质量)需求的例子吗?
 如果客户需要高性能、使用极其方便而又高度安全,你会给他什么建议?
 你能给出一些用来描述需求的不同技术吗?它们各自适用于什么场景?
 需求跟踪是什么意思?什么是向前追溯,什么是向后追溯?
 你喜欢用什么工具跟踪需求?
 你怎么看待需求变化?它是好是坏?给出你的理由。
 你怎样研究需求,发现需求?有哪些资源可以用到?
 你怎么给需求制定优先级?有哪些技术?
 在需求过程中,用户、客户、开发人员各自的职责是什么?
 你怎么对待不完整或是令人费解的需求?
功能设计
 在功能设计中有哪些隐喻?t出几个成功的例子。
 如果有些功能的执行时间很长,怎么能让用户感觉不到太长的等待?
 如果用户必须要在一个很小的区域内,从一个常常的列表中选择多个条目,你会用什么控件?
 有哪些方法可以保证数据项的完整?
 建立系统原型有哪些技术?
 应用程序怎样建立对用户行为的预期?给出一些例子。
 如何入手设计一组数量庞大而又复杂的特性,你能举出一些设计思路吗?
 有一个列表,其中有10个元素,每个元素都有20个字段可以编辑,你怎样设计这种情况?如果是1000个元素,每个元素有3个字段呢?
 用不同的颜色对一段文本中的文字标记高亮,这种做法有什么问题?
 Web环境和Windows环境各有些什么限制?
技术设计
 什么是低耦合和高聚合?封装原则又是什么意思?
 在Web应用中,你怎样避免几个人编辑同一段数据所造成的冲突?
 你知道设计模式吗?你用过哪些设计模式?在什么场合下用的?
 是否了解什么是无状态的业务层?长事务如何与之相适应?
 在搭建一个架构,或是技术设计时,你用过几种图?
 在N层架构中都有哪些层?它们各自的职责是什么?
 有哪些方法可以确保架构中数据的正确和健壮?
 面向对象设计和面向组件设计有哪些不同之处?
 怎样在数据库中对用户授权、用户配置、权限管理这几项功能建模?
 怎样按照等级制度给动物王国(包括各种物种和各自的行为)建模?
程序设计
 你怎样保证你的代码可以处理各种错误事件?
 解释一下什么是测试驱动开发,举出极限编程中的一些原则。
 看别人代码的时候,你最关心什么地方?
 什么时候使用抽象类,什么时候使用接口?
 除了IDE以外,你还喜欢哪些必不可少的工具?
 你怎么保证代码执行速度快,而又不出问题?
 什么时候用多态,什么时候用委派?
 什么时候使用带有静态成员的类,什么时候使用单例?
 你在代码里面怎么提前处理需求的变化?给一些例子。
 描述一下实现一段代码的过程,从需求到最终交付。
算法
 怎样知道一个数字是不是2的乘方?怎样判断一个数是不是奇数?
 怎样找出链表中间的元素?
 怎样改变10000个静态HTML页面中所有电话号码的格式?
 举出一个你所用过的递归的例子。
 在散列表和排序后的列表中找一个元素,哪个查找速度最快?
 不管是书、杂志还是网络,你从中所学到的最后一点算法知识是什么?
 怎样把字符串反转?你能不用临时的字符串么?
 你愿意用什么类型的语言来编写复杂的算法?
 有一个数组,里面是从1到1,000,000的整数,其中有一个数字出现了两次,你怎么找出那个重复的数字?
 你知道“旅行商问题(Traveling Salesman Problem)”么?
数据结构
 怎样在内存中实现伦敦地铁的结构?
 怎样以最有效的方式在数据库中存储颜色值?
 队列和堆栈区别是什么?
 用堆或者栈存储数据的区别是什么?
 怎样在数据库中存储N维向量?
 你倾向于用哪种类型的语言编写复杂的数据结构?
 21的二进制值是什么?十六制值呢?
 不管是书、杂志还是网络,你从中所学到的最后一点数据结构的知识是什么?
 怎样在XML文档中存储足球比赛结果(包括队伍和比分)?
 有哪些文本格式可以保存Unicode字符?
测试
 什么是回归测试?怎样知道新引入的变化没有给现有的功能造成破坏?
 如果业务层和数据层之间有依赖关系,你该怎么写单元测试?
 你用哪些工具测试代码质量?
 在产品部署之后,你最常碰到的是什么类型的问题?
 什么是代码覆盖率?有多少种代码覆盖率?
 功能测试和探索性测试的区别是什么?你怎么对网站进行测试?
 测试套件、测试用例、测试计划,这三者之间的区别是什么?你怎么组织测试?
 要对电子商务网站做冒烟测试,你会做哪些类型的测试?
 客户在验收测试中会发现不满意的东西,怎样减少这种情况的发生?
 你去年在测试和质量保证方面学到了哪些东西?
 
维护
 你用哪些工具在维护阶段对产品进行监控?
 要想对一个正在产品环境中被使用的产品进行升级,该注意哪些重要事项?
 如果在一个庞大的文件中有错误,而代码又无法逐步跟踪,你怎么找出错误?
 你怎样保证代码中的变化不会影响产品的其他部分?
 你怎样为产品编写技术文档?
 你用过哪些方式保证软件产品容易维护?
 怎样在产品运行的环境中进行系统调试?
 什么是负载均衡?负载均衡的方式有哪些种?
 为什么在应用程序的生命周期中,软件维护费用所占的份额最高?
 再造工程(re-engineering)和逆向工程(reverse engineering)的区别是什么?
 
配置管理
 你知道配置管理中基线的含义么?怎样把项目中某个重要的时刻冻结?
 你一般会把哪些东西纳入版本控制?
 怎样可以保证团队中每个人都知道谁改变了哪些东西?
 Tag和Branch的区别是什么?在什么情况下该使用tag,什么时候用branch?
 怎样管理技术文档——如产品架构文档——的变化?
 你用什么统计管理项目中所有数字信息的状态?你最喜欢哪种工具?
 如果客户想要对一款已经发布的产品做出变动,你怎么处理?
 版本管理和发布管理有什么差异?
 对文本文件的变化和二进制文件的变化进行管理,这二者有什么不同?
 同时处理多个变更请求,或是同时进行增量开发和维护,这种事情你怎么看待?
项目管理
 范围、时间、成本,这三项中哪些是可以由客户控制的?
 谁该对项目中所要付出的一切做出估算?谁有权设置最后期限?
 减少交付的次数,或是减少每个交付中的工作量,你喜欢哪种做法?
 你喜欢用哪种图来跟踪项目进度?
 迭代和增量的区别在哪里?
 试着解释一下风险管理中用到的实践。风险该如何管理?
 你喜欢任务分解还是滚动式计划?
 你需要哪些东西帮助你判断项目是否符合时间要求,在预算范围内运作?
 DSDM、Prince2、Scrum,这三者之间有哪些区别?
 如果客户想要的东西太多,你在范围和时间上怎样跟他达成一致呢?
作者简介:
Jurgen Apello:荷兰ISM eCompany首席信息官,该公司不久前被评为荷兰成长最快的技术公司。
Jurgen的兴趣在于软件工程、质量改进和复杂性理论,曾在DDJ等多本技术杂志上发表文章。
译者简介:
李剑是InfoQ中文站(www.infoq.com/cn)敏捷社区的首席编辑,Ethos(宇思信德)资深工程师。
他的译作包括《深入浅出Struts2》和《硝烟中的Scrum和XP》,二者均为InfoQ中文站迷你书。
(本文来自《程序员》杂志0903期)


在这个世界上,有数百万的人热衷于软件开发,他们有很多名字,如:软件工程师(Software Engineer),
程序员(Programmer),编码人(Coder),开发人员(Developer)。
经过一段时间后,这些人能够成为一个优秀的编码人员,他们非常熟悉如何用计算机语言来完成自己的工作。
但是,如果你要成为一个优秀的程序员,你还可以需要有几件事你需要注意,
如果你能让下面十个条目成为你的习惯,那么你才能真正算得上是优秀程序员。

1. 学无止境。就算是你有了10年以上的程序员经历,你也得要使劲地学习,因为你在计算机这个充满一创造力的领域,
每天都会有很多很多的新事物出现。你需要跟上时代的步伐。你需要去了解新的程序语言,以及了解正在发展中的程序语言,
以及一些编程框架。还需要去阅读一些业内的新闻,并到一些热门的社区去参与在线的讨论,这样你才能明白和了解整个软件开发的趋势。
在国内,一些著名的社区例如:CSDN,ITPUB,CHINAUINX等等,在国外,建议你经常上一上digg.com去看看各种BLOG的聚合。

 

2. 掌握多种语言。程序语言总是有其最适合的领域。
当你面对需要解决的问题时,你需要找到一个最适合的语言来解决这些问题。
比如,如果你需要性能,可能C/C++是首选,如果你需要跨平台,可能Java是首选,如果你要写一个Web上的开发程序,
那么PHP,ASP,Ajax,JSP可能会是你的选择,如果你要处理一些文本并和别的应用交互,可能Perl, Python会是最好的。
所以,花一些时间去探索一下其它你并熟悉的程序语言,能让你的眼界变宽,因为你被武装得更好,你思考问题也就更为全面,
这对于自己和项目都会有好的帮助。

3. 理性面对不同的操作系统或技术。程序员们总是有自己心目中无可比拟的技术和操作系统,有的人喜欢Ubuntu,
有的人喜欢Debian,还有的人喜欢Windows,以及FreeBSD,MacOSX或Solaris等等。
看看我的BLOG(http://blog.csdn.net/haoel)中的那篇《其实Unix很简单》后的回复你就知道程序员们在维护起自己的忠爱时的那份执着了。
只有一部分优秀的程序员明白不同操作系统的优势和长处和短处,这样,在系统选型的时候,才能做到真正的客观和公正,
而不会让情绪影响到自己。同样,语言也是一样,有太多的程序员总是喜欢纠缠于语言的对比,如:Java和Perl。
哪个刚刚出道的程序员没有争论去类似的话题呢?比如VC++和Delphi等等。争论这些东西只能表明自己的肤浅和浮燥。
优秀的程序并不会执着于这些,而是能够理性的分析和理心地面对,从而才能客观地做出正确的选择。

4. 别把自己框在单一的开发环境中。 再一次,正如上面所述,每个程序员都有自己忠爱的工具和技术,
有的喜欢老的(比如我就喜欢Vi编辑程序),而有的喜欢新的比如gedit或是Emacs等。有的喜欢使用像VC++一样的调试器,
而我更喜欢GDB命令行方面的调式器。等等等等。程序员在使用什么样的工具上的争论还少吗?到处都是啊。
使用什么样的工具本来无所谓,只要你能更好更快地达到你的目的。但是有一点是优秀程序员都应该了解的——那就是应该去尝试一下别的工作环境。
没有比较,你永远不知道谁好谁不好,你也永远不知道你所不知道的。

5. 使用版本管理工具管理你的代码。千万不要告诉我你不知道源码的版本管理,
如果你的团队开发的源代码并没有版本管理系统,那么我要告诉你,你的软件开发还处于石器时代。
赶快使用一个版式本管理工具吧。CVS 是一个看上去平淡无奇的版本工具,但它是被使用最广的版本管理系统,
Subversion 是CVS的一个升级版,其正在开始接管CVS的领地。Git 又是一个不同的版本管理工具。还有Visual SourceSafe等。
使用什么样的版本管理工具依赖于你的团队的大小和地理分布,你也许正在使用最有效率或最没有效率的工具来管理你的源代码。
但一个优秀的程序员总是会使用一款源码版本管理工具来管理自己的代码。如果你要我推荐一个,我推荐你使用开源的Subversion。

6. 是一个优秀的团队成员。 除非你喜欢独奏,除非你是孤胆英雄。但我想告诉你,今天,可能没有一个成熟的软件是你一个人能做的到的,
你可能是你团队中最牛的大拿,但这并不意味着你就是好的团队成员。你的能力只有放到一个团队中才能施展开来。
你在和你的团队成员交流中有礼貌吗?你是否经常和他们沟通,并且大家都喜欢和你在一起讨论问题?
想一想一个足球队吧,你是这个队中好的成员吗?当别人看到你在场上的跑动,当别人看到你的传球和接球和抢断,能受到鼓舞吗?

7. 把你的工作变成文档。 这一条目当然包括了在代码中写注释,但那还仅仅不够,你还需要做得更多。
有良好的注释风格的代码是一个文档的基础,他能够让你和你的团队容易的明白你的意图和想法。
写下文档,并不仅仅是怕我们忘了当时的想法,而且还是一种团队的离线交流的方法,更是一种知识传递的方法。
记录下你所知道的一切会是一个好的习惯。因为,我相信你不希望别人总是在你最忙的时候来打断你问问题,
或是你在休假的时候接到公司的电话来询问你问题。而你自己如果老是守着自己的东西,
其结果只可能是让你自己长时间地深陷在这块东西内,而你就更本不可以去做更多的事情。
包括向上的晋升。你可能以为“教会徒弟能饿死师父”,但我告诉你,你的保守会让你失去更多更好的东西,
请你相信我,我绝不是在这里耸人听闻。

8. 注意备份和安全。 可能你觉得这是一个“废话”,你已明白了备份的重要性。但是,我还是要在这里提出,
丢失东西是我们人生中的一部份,你总是会丢东西,这点你永远无法避免。比如:你的笔记本电脑被人偷了,你的硬盘损坏了,
你的电脑中病毒了,你的系统被人入侵了,甚至整个大楼被烧了,等等,等等。
所以,做好备份工作是非常非常重要的事情,硬盘是不可信的,所以定期的刻录光盘或是磁带可能会是一个好的方法,
网络也是不可信的,所以小心病毒和黑客,不但使用软件方面的安全策略,你更需要一个健全的管理制度。
此外,尽量的让你的数据放在不同的地方,并做好定期(每日,每周,每月)的备份策略。

9. 设计要足够灵活。 可能你的需求只会要求你实现一个死的东西,但是,你作为一个优秀的程序,
你应该随时在思考这个死的东西是否可以有灵活的一面,比如把一些参数变成可以配置的,
把一些公用的东西形成你的函数库以便以后重用,是否提供插件方面的功能?
你的模块是否要以像积木一样随意组合?如果要有修改的话,你的设计是否能够马上应付?
当然,灵活的设计可能并不是要你去重新发明轮子,你应该尽可能是使用标准化的东西。
所谓灵话的设计就是要让让考虑更多需求之外的东西,把需求中这一类的问题都考虑到,
而不是只处理需求中所说的那一特定的东西。比如说,需要需要的屏幕分辨率是800×600,
那么你的设计能否灵活于其他的分辨率?程序设计总是需要我们去处理不同的环境,以及未来的趋势。
我们需要用动态的眼光去思考问题,而不是刻舟求剑。也许有一天,你今天写的程序就要移植到别的环境中去,
那个时候你就能真正明白什么是灵活的设计了。

10. 不要搬起石头砸自己的脚。程序员总是有一种不好的习惯,
那就是总是想赶快地完成自己手上的工作。但情况却往往事已愿违。越是想做得快,就越是容易出问题,越是想做得快,
就越是容易遗漏问题,最终,程序改过来改过去,按下葫芦起了瓢,最后花费的时间和精力反而更多。
欲速而不达。优秀程序员的习惯是前面多花一些时间多作一些调查,试验一下不网的解决方案,如果时间允许,一个好的习惯是,
每4个小时的编程,需要一个小时的休息,然后又是4个小时的编码。当然,这因人而异,但其目的就是让你时常回头看看,
让你想一想这样三个问题:1)是否这么做是对的?2)是否这么做考虑到了所有的情况?3)是否有更好的方法?
想好了再说,时常回头看看走过的路,时常总结一下过去事,会对你有很大的帮助。

以上是十条优秀程序员的习惯或行为规范,希望其可以对你有所帮助。

2011-03-06 14:12:00 dyx1024 阅读数 811

 从过年收假到昨天,每天都在公司待着,今天,终于可以休息下了,从未有过的疲惫感,一下子席卷而来。

   这段时间一直在加班,特别是本周,连续三个通宵工作,而且均是从早上九点到第二天下午下班才回家,不通宵时也是凌晨一二点才回家,现在终于告一段落了。忙碌的工作让人无暇思考,今天静静地思考了下,为什么会这样呢?总结了下,应该有以下原因:

 1. 不合理的工作量估计和开发计划

      本次中移动KPI需求估计工作量为3.5K,实际编码仅C程序为5K+,还不考虑sql等其他强相关工作;计划两周完成并交付补丁版本,从实际开发情况来看,我用去2周时间编写完5K代码并调通,完成UT,但这仅仅全部工作的1/2,剩下1/2中补丁制作原本估计2人天,实际用时7人天,复杂程度是估计的N倍,还有网管版本的联调工作,问题单修改及其他测试问题支持不算其中,原计划投入人力2人,实际投入5人。进度延迟一周。

2. 试图找到“银弹”

     开发中途发现风险,并增加人力,安排通宵加班,试图找到软件工程中的“银弹”,但结果让人失望;

3. 前期的技术债务导致困难重重;

    早期的设计缺陷,导致在后期测试中,发现有些场景在设计时并没有考虑全面,客户是否能接受,并没有进行有效的沟通,给交付带来了很大的风险;

4. 通宵加班导致的恶性循环

   长时间的工作,思考能力降低,心情很差,势必导致代码质量降低,导致恶性循环。

5. 个人原因

   没有在质量和进度中做好权衡,在解决小bug方面花费时间较多,导致进度延迟。从敏捷开发角度来讲,应该交付一个刚刚好的系统,不要做大而全。

 如果思考范围放大一倍来看,最根本的原因是这是一个破坏现有软件架构的需求,根本就不应该开发,客户导向并不一定是所有客户的需求都接受,当然这只是自己的理解,在其位谋其职,该做的还是要做,不该自己考虑的,可以考虑但要保留意见。

工作一年多的感想

阅读数 594

半年总结

阅读数 52

工作一周年总结

阅读数 963

没有更多推荐了,返回首页