频道直达 - 专题 - 新闻 - 技巧 - 组网 - 开发 - 安全 - web编程 - 图像 - 操作系统 - 数据库 - 教育 - 旅游 - 健康 - 时尚 - 驱动 - 软件 - 游戏 - 多媒体 - ERP - 讨论组

java开发人员经验总结

来源: 作者:佚名 出处:巧巧读书 2008-04-18 进入讨论组

·立项
    一、需求的收集,UC的编写虽然不是开发人员的工作,但最终需要开发人员在产品中实现。所以开发不合理的设计至少浪费了你的时间,开发技术无法实现的设计带来最大的痛苦:失败。所以,开发人员要重视需求以及UC的评审,提出自己能够想到的所有异议。


    二、一栋楼很难估算重量,但是一块砖头可以精确估算重量。一个项目的时间很难准确的估计,但把项目开发划分为不能再进行分割的模块功能点,对每个点的估计是可以更精准的估时的,由此由上至下,由下至上,得出近乎准确的编码时间。
    三、机会总是倾向有准备的人,成功也是。编码工作保质保量的按时完成需要多方的准备工作,技术难点需要进行充分的技术预言,不熟悉的依赖平台或类库要进行熟悉。

    ·设计
    一、一图胜万言,模块结构以及流程等很难用用文字描述,即使用文字描述出来也很难看懂,所以在设计中,要善用用图。
    二、痛苦是为了快乐,详细设计过程中有思考的痛苦,繁琐的痛苦,但是绕过这些痛苦,编码期间将会面临更大的痛苦。

    ·编码
    一、 磨刀不误砍柴工。对于一个实现可以有很多解决方案,花些时间精力选取你认为最好的解决方案可以总体上提高工作成效,往往还可以得到用户更好的体验效果。
    二、 细致认真严谨的工作即是对工作负责,更是对自己负责,让这些成为习惯。任何一次,任何时候所进行的编码工作,在逻辑、风格、简单有效等方面拿出你的最好,既能更好为公司实现价值,同时更有利自己在技能,岗位的进步。
    三、 简单是美,在有效的前提下,越是简单的处理方法越是珍贵的,代码编写也是,简单的代码便于理解维护,同时不容易产生错误。
    四、 慎做改动,当然不是说不做改动或不鼓励改动,而是不做仓促、草率的代码改动。没有洞察全局,考虑全面,而仓促进行的改动往往没有达到改动的目的却带来了其他问题。

    ·测试
    一、事出有因,任何bug都是由于代码的疏漏造成的,修复bug的痛苦过程中切莫怀疑是神在耍弄你,勇往直前的利用排除法或跟踪调试代码等方法找到疏漏所在。
    二、遇到自身模块相关问题首先检查自己,相互推诿只会浪费时间以及减弱在其他同事对你的信任。
    三、站的高看得远,不同的视角有不同的风景。遇到比较难解决的问题而苦苦没有思路时,转换思路或把问题的考虑范围放的更广一点,往往可以找到解决方案。
    四、功能提交测试前或bug修复提交验证前,开发人员都要自己详细的测试一下,验证无误再提交,这样才是一个优秀的开发人员。

    ·全局
    一、善于以及及时的沟通。在项目的整个流程过程中,遇到他人的问题或自己解决不了的问题,切忌堆在自己心里,要及时找问题解决方进行沟通,通过寻求解决方案。
    二、三人行必有我师,发现并学习别人的长处。作为开发人员,我们在追求接近完美的同时,也需要学会欣赏别人的长处,发现别人的优点,并学习别人的优点,转化为自己的潜质,这样,我们才可以进步的更快,更全面。
    三、利人利己,善于帮助他人解决问题以及进行知识经验的分享,更有利于自己的提高,同时还可以获得他人的尊重。
    四、模块的性能不是减少一行或几行执行代码所能提高的,性能的优化首先是从算法上考虑,降低时间复杂度,然后从执行逻辑入手,减少循环执行代码的执行次数。
        以上是笔者几年做开发测试的经验积累,但是并不全面,欢迎大家拍砖补充。

更多文章 更多内容请看Java环境安装配置Java编程开发手册Wlan组网----家庭专题专题,或进入讨论组讨论。
收藏此文】【 】【打印】【关闭
相关图文阅读
频道图文推荐
健 康 咨 询
时 尚 咨 询
巧巧读书宗旨
相关专题
讨论组问题推荐
站内各频道最新更新文档
站内最新制作专题
热门关键字导读
Photoshop教 程照片处理 照片制作 PS快捷键 抠图
计 算 机 故 障XP系统修复
艺 术 与 设 计设计 流媒体 设计欣赏 边框
计 算 机 安 全ARP
站内频道文章精选
巧巧电脑频道编辑信箱  告诉我们您想看的专题或文章