大型软件开发 心得(精选多篇)

-精选财经经济类资料- -最新财经经济资料-感谢阅读- 1 大型软件开发心得(精选多篇) 最近做的一个项目从需求分析到上 线绵延了四个月之久，这也是目前接手 过功能点最繁复，产品线对接最多的一 个项目。从中得到的一些关于设计较大 型产品的心得，拿出来跟大家分享。 立项前 1、统一元素设计需考虑周全 也许是初创团队的缘故，我不得 不感叹团队对产品经理要求之严格之缜 密，项目全程只有一个人负责，所以大 到产品线对接，小到一句提示的位置和 展示形式都需要一一推敲。 哪些元素应该做到统一？ a、提示方面：统一的操作成功/ 失败提示；统一的弹窗形式；提示语言 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 2 采用较统一的句型；为空情况的友好提 醒；溢出情况的友好提醒；表单实时验 证的提醒形式等。 b、文字方面：是否有统一的段 落前“”号；统一的链接状态；统一的字 体、间距、行高等。 c、图片方面：调取图片的统一 尺寸；如果是上传图片类的操作，需要 考虑周全全站的调取情况，以及考虑是 否统一预览图的尺寸等。 d、细节交互：未激活功能的按 钮做“灰色”处理；按钮点击的状态统一； 特殊控件的统一等。 也许会有朋友说，上面有些是交 互设计师需要做的事，但我一直认为作 为一个产品经理考虑周全一些，没坏处。 这些“统一”同样可以用在验收阶段，要 知道，即使一个像素也可以改变整个产 品的感觉。 2、原有功能的去留 我一直觉得升级已有产品比开发 新产品难一些。这就像栽培植物一样， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 3 新种下一棵果树无非需要选对了土地， 然后刨个坑种下去，然而成长期的去病 枝、打顶等各种修剪所消耗的精力往往 更多。 改进已有产品常常需要面对一个 最棘手的问题：原有功能是去是留？ 原功能去掉的话是不是会影响部 分用户使用？是否需要通过公告、站内 信、界面引导等方式友好地告知用户？ 怎样把对用户的伤害降至最低？ 原功能留下的话是不是可以优化 完善？听到了什么用户群怎样的声音？ 是否要在这次升级中做调整？ 这些问题当接到项目的时候，产 品经理就应该考虑周全了。特别需要注 意的是，如果这个产品之前不是自己设 计的，那么最好找到 prd 说明文档细细 研究一遍，对把握不准的功能点找到原 负责人确认，毕竟树苗是 ta 摘的，别把 将来最能结果的枝干给砍了。 3、产品线上下游的对接 昨天有跟朋友聊起淘宝强势之处， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 4 就是产品与产品紧密捏合，线上线下、 跨平台跨行业形成了一个盘根错节、根 深蒂固的根基，无可撼动。 所以把握产品线上下游和产品周 边很重要，即使一个看似简单的新闻展 示页面修改也会牵扯到编辑后台、广告 位管理、帮助中心，甚至是访问统计、 数据需求的变更。 这要求在产品设计开始前，需要 把该产品“连根拔起 ”，仔细梳理相关脉 络，如果产品线够长，一个清晰的产品 线结构图很有必要。 项目中 1、项目期间来自相关产品线调 整的影响 项目期间相关产品线的调整是我 最不愿意遇到的情况，这就像你在通往 目的地的道路上高速行驶，就快要到达 终点了，突然一个人告诉你：你走错路 了。 项目里有一个通用模块，产品设 计到一半，这个通用模块改了；项目里 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 5 有一个流程，产品做到一半，这个流程 废弃了；最要命的是已经立项开发了， 你不得不硬着头皮跟程序员说：“因为 一些不可抗拒原因，这个需求咱不做了。 ” 对于一个耗时较长的项目来说， 这种情况难以避免，事出原因私自总结 有三： a、严重体验性问题：例如某个 流程遭到大量用户的不满，为防止用户 流失，不得不做临时调整，而倒霉的是， 你也在用这个流程。 b、相关项目的影响：包括并行 项目和新项目。例如你的同事在设计另 一个产品，你们的产品相互牵扯较多， 所以需求分析时做过很多沟通，但有一 天，同事告诉你，ta 的一个需求做临时 调整了会影响到你，怎么办？ c、老板的突然决定：不举例。 最终的解决方法不外乎三种：立 即调整、延期调整、不调整。个人的处 理原则一般是对 a 种情况进行立即调整， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 6 对 b、c 情况讨论并选择性延期。 为什么这么做呢？a 情况是必须 要改的，时间早晚问题，长痛不如短痛， b、c 两种情况必须坐下来细细讨论。需 了解这个需求为什么要改？是长期对策 还是临时决定？能否延期，记录需求等 下一版本再开发？如果 b、c 情况提出 来的需求没过两天又有改变，那与你配 合的前端和程序员也太没有安全感了。 这个时代能耐心阅读完 xx 枚汉 字的人越来越少，较大型项目的产品工 作心得未完待续，欢迎交流 2、需求变更 承上，需求变更是每个程序员、 产品经理、设计师等都会遇到的情况。 产品经理不是神，项目组也不可能是开 了无敌状态抵挡任何外界的影响。 当遇到不得不变更需求的时候， 产品经理应该怎样处理呢？下面是个人 的四条建议： a、积极处理。往往，当一个设 计愈是趋于完成，人们愈是倾向于局部 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 7 调整，而不是做重新设计。当一个需求 因为众所周知的原因不得不调整的时候， 作为产品经理需要做的第一件事便是积 极面对问题，积极处理。 项目开发往往是一个紧张的过程， 每半天甚至每几个小时就有若干个功能 点开发完成，当一个需求变更传达出现 “延迟”，这个变更对项目的正常进程的 “破坏力”就会更大一些。 b、保持沟通。 “说话容易，沟通 很难。很多事除非对方自己想明白，劝 是没有用的。所以，很多时候，沟通是 个自己挣扎的过程” 这话没错。需求变 更直接会影响到下一道工序，产品经理 需要将需求变更的细节和原因传达给相 关人员，包括视觉、前端、程序、测试 等。 这是很多产品经理表示非常痛苦 的过程，因为可能会遭到数落和冷眼， 日本有一个礼仪原则是“ 不要给别人添 麻烦”，但是在项目中，这不可避免。 个人认为所有沟通的障碍都源于 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 8 思想的不统一，如果让大家觉得这个需 求修改是在浪费时间，那么沟通上的不 畅快在所难免。项目不是这样算的，需 求既然更改一定有所目的，产品经理需 要将这个原因讲明白，不做修改或节约 沟通时间导致的返工，后果往往更严重。 受某文化公司委托，开发一款用 于视频和图像处理的软件，开发难度高， 高到从未搞过，开发周期长，长到是我 以前项目监控最长开发周期的两倍，开 发成本之底，让我觉得程序员成了高级 打字员。首先是需求分析书、产品规格 说明书、设计说明书、代码规范说明书、 测试计划，光文稿就不知道熬了多久才 做完。 紧接着，遇到一系列问题，首先 是语言选择，vc+ 和 c#都是可以保证开 发完成的选择，但是 vc+内存容易报 错，界面很难修改，而客户要求的界面 质量甚至比程序的功能更严格，没办法， 客户就是上帝，上帝做事一定有他的道 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 9 理。c#语言易于开发，而且图形界面绘 制也易于修改，可以做出客户体验很好 的界面，但是在资源的消耗上，让我很 吃惊。做到第二个月，大概的界面已经 完成时，出现界面刷新的问题，刷新时 开始卡，界面不流畅。没办法，改。 开会，总结，技术骨干找问题， 拿出解决方案，力争第一次做软件把它 做好： 重新做软件开发进度计划和软件 测试计划，并且让独立功能 demo 制作 和测试先行； 用 direct draw、direct 3d 或者 opengl 中的一个替代 c#本身的 gdi 绘图， 将在接下来的开发任务中加入进去。 事无巨细，当我满意的看着界面 流畅，功能也已实现时，发现软件在低 分辨率或者小本上根本乱到没法看，甚 至是界面功能按钮错位，重叠等等。没 办法，改。毕竟软件的多分辨率兼容和 操作系统兼容是必须要做的。 接下来一大堆的麻烦找了上来， -精选财经经济类资料- -最新财经经济资料-感谢阅读- 10 软件出现各种各样想都想不到的问题， 总算是按时将第一个版本发布出去，并 且开始接下来的升级开发任务。 最后，给刚刚接手软件开发项目 的朋友一些忠告： 一、相关的文档不是给别人看的， 而是给自己看的，相关文档一定要齐备， 而且让所有涉及开发的人员都清楚的知 道你文档里所要表达的意思； 二、一定要注意多做 demo，多 做实验，一个 demo 程序员几个钟头就 可以完成，甚至更少，但是不做 demo，核心程序没有做实验，其他的东 西都围绕核心程序做了上去，到时候耽 误的可不是几个钟头 三、程序设计要注重用户体验， 当初客户对我要开发软件提出近乎苛刻 的要求时我不在意，但是当我自己反复 使用软件时有了很多体会，流畅美观的 界面带给人心理的快感的确能替代一些 尚未开发完整的功能带给用户的遗憾。 四、测试计划多次进行，分批进 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 11 行，不要全部开发完成再对软件做测试。 还要坚持三个月，软件马上发布， 希望大家的支持，谢谢！ 软件开发心得体会： 作为，有时需要招聘软件开 发人员。这几年也一直在想，如何能在 短短的 30 分钟或 1 小时内，快速识别 出，坐在你对面的应聘人员，是否适合 你的 team。这几年也一直在观察和反思， 经历过的 team 和现在 team 中的软件开 发人员。有几点小的心得。 1. 倾向于招什么样的软件开发人 员 - 经历过历练的人 吃过苦的，比如以前工作，经常 被外派出差，又如曾在业内都知道以加 班多而著称的公司呆过，还有些，留过 学，但都是自己边打工边读书的，等等。 这些人员，入职后，通常都是能 干活，能作为骨干。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 12 - 思路清晰，思想活跃的人 让谈谈自己现在的产品，如果能 清晰表述，有条理，会发散，但又能适 当控制住，并收回到原话题。谈到技术 问题和解决过的难题时，眼中有光芒： ） 这些人员，今后工作中，学习能 力强，对解决难题有帮助，能作为中坚。 - 坦诚、坚定、平和的人 面试中，坦诚，目光坚定。有时 坦诚到甚至于显得有点木讷：） 我曾经遇到一个，面试下来，我 最后介绍我们产品中用到的技术，他对 这些技术知之不多，最后他说， “我可能 不是非常适合，我知道一个朋友，他可 能更适合。 ”我综合评估后，最后还是选 了他，事实证明，他后来做的很不错。 坦诚坚定的人，会有恒心去学习， 去解决问题。这些人员会作为 team 的 基石。 - 有缺陷的人才 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 13 这是一个朋友的想法，我认为还 是有道理的。 大公司，会看重综合素质，而如 果是小公司，可以考虑选择一些有缺陷 的人才。所谓有缺陷，是指，比如他英 语很差，或沟通不清晰，但他能用程序 员该有的思维去思考问题。这样的人员， 通常进不了大公司，故会相对踏实地呆 在一家公司，做好自己的工作。 2. 谨慎考虑这样的开发人员 - 太活泼，太易兴奋 太易兴奋，说到投机处， “是是是 是，对对对对。 。 。 ”，又蹦又跳，还时不 时来点， “oh yeah, you are right“，然后还 摆个 v 手型。讨论问题，不易固守在 技术问题本身，时常跑到“我们产品中 用到的技术很强，我挺他们，不可能有 问题”，又或者 “我们对客户要强势，我 们要坚持我们的产品没问题”。 软件开发工作本身，显得比较沉 闷，优秀的技术人员，都略显有些内向， 因为解决问题，很多时候需要耐得住寂 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 14 寞，时刻保持相对冷静。 太活泼的人，会在遇到问题之初， 表现出很强的冲劲，但当长时间不能解 决时，会表现出没有耐心，会经常抱怨， 非常情绪化。有些女程序员还会吵，会 哭，这时项目经理只能放下手中的活， 下去给她买点零食来哄哄， “莫哭，这里 有你最爱吃的猫哆哩。 ”一边擦着鼻涕、 眼泪，一边嘴里塞满东西，鼓鼓啷啷 “这是酸角口味的，那个西番莲口味的 才叫好吃.” 这些通常不太容易在面试时表现 出来，在试用期时，要观察。 有感于网盘开发过程 有感于网盘开发过程 1 一、软件开发个人体会： 2 二、做软件开发我觉得要明白： 2 三、在开发中遇到问题应该怎么 去解决？ 2 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 15 四、怎么样才能提高自身的能力？ . 2 五、怎么样才能做好软件开发？ 2 六、文档的重要性 . 3 七、我的收获 3 八、网盘项目开发的最大体会 . 4 九、软件测试 4 常熟理工学院 sig 小组 3/28/2014 一、软件开发个人体会： 1. 软件领域中的知识在于积累。 2. 做软件开发，就类似算数学题 和世界杯足球赛一样：重在结果，而不 在乎过程。 3. 软件服务于人类，软件是在解 决一些生活中的问题和错误，问题决定 解决方案。 二、做软件开发我觉得要明白： 1. 职业的乐趣： 用自己的智慧去创建新事物的 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 16 快乐 开发对别人有用的东西 不断学习来充实自己 2. 职业的苦恼: 总是追求完美 所有要实现的功能由他人而定 概念设计计是有趣的，但找 bug 总是很苦恼的 三、在开发中遇到问题应该怎么 去解决？ 1. 2. 3. 4. 不明白就多问，不要自已一直 去琢磨。 一个问题如果 30 分钟还没有 解决就应该考虑是不是问问别人。 一 个问题在没有用过 3 种以上的方法解决 过就不要去问别人。 解决问题思路是 关键： 相信问题总归有解决的办法，就 算连技术上都没法实现的问题，相信通 过良好的沟通终究也会有解决的方法。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 17 5. 解决问题的前提是：理解别人 的意思，理解别人的需求，多沟通，及 时给客户反馈信息。 四、怎么样才能提高自身的能力？ 1. 程序员怎么样进步最快？ 理论结合实践 2. 不要怕出错，不怕遇到错误， 有错误就有挑战，这样才可以进步，但 不要让同一个石头 把你绊倒 2 次。 五、怎么样才能做好软件开发？ 1. 首先要明白解决的问题是什么， 理解问题，其次再决定怎么解决这个问 题 2. 碰到很复杂的问题，我们就简 单想，把问题简单化，细化到能够实现 为止 3. 出了问题，我们要先分析问题， 然后知道引起问题的原因，最后并想出 问题的解决办法 4. 我们应该从 2 个方面去把握一 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 18 个项目：从业务角度和项目的关键问题 上去把握一个项目 从不同的系统场景 从不同的用户角色 从不同的系统使用角度 5. 其实我觉得开发人员说实在应 该要比使用系统的人更了解系统需求， 只有真正彻底的了 解了项目的业务需求，我们才能 做真的做好这个项目 六、文档的重要性 记得我当初刚开发项目的时候都 是写个大致的需求说明书，做一个 e-r 图，画几个大致的数据流程图，然后建 立数据字典和表结构关系。 再接着搭 建一个开发环境，配置几台服务器，划 分一下模块，分工，我们就可以 coding 了，一直到项目结束了，也没有完整的 设计文档，更没有完整的测试文档，虽 然这样的确是很快的完成了 coding 工作， 感觉上好像节省了好多成本和开发时间， 但后期的维护和 bug 就是经常出现的事。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 19 小项目没有文档关系不大，但如 果遇到一个大项目的时候，那这样的开 发方式就很有问题很危险的。 大项目没有文档： 首先维护就 很麻烦，也很乱，写的代码，过几天都 不知道它是完成什么功能的了，其次系 统的稳定性和可靠性也让人怀疑，扩展 性就不用说了。 七、我的收获 a.程序员大多都不喜欢写文档,我 们以前也是特讨厌,记得以前都是系统开 发完了，为了应付项目验收，就匆匆忙 忙的一组人在那里补文档。在我们的思 想里,所谓的文档就是一些废话,一句话 硬是用十句话来代替的无聊透顶。 b.代码风格要规范 以前做项目，我们都是不怎么去 注意代码风格和写代码的规范，都是稍 微想一下就直接开始写代码了。注释也 很少用，总感觉我们自己写的代码，我 们怎么会不知道它做了些什么事呢 ？ -精选财经经济类资料- -最新财经经济资料-感谢阅读- 20 总觉得我们自己写的代码我们怎么会不 知道它是用来做什么的呢。一直都不相 信这是个事实，但事实上，项目验收后， 系统刚开始使用的人少，也就不会出现 潜在的错误，随着时间的增加，久而久 之，当大量用户并发访问的时候，系统 的 bug 就暴漏出来了，那时你再用熟悉 的 eclipse 打开整个项目的源码时，再去 看自己写的代码的时候，真的发现，我 们定义的这个变量名是什么意思啊 ？ 我们的这个 flag 是用来判断什么的啊 ？我们的 if 中条件不知道是判断什么？ function 也忘记是什么功能了？ 想想 好可怕啊。 难道真的都忘记了吗 ？回 答是肯定的： 真的忘了。 c.心得体会 : 通过做该网盘项目，在这 2 年的 锻炼中，我们才真的体会到，良好的文 档是正规研发流程中非常重要的环节,一 个好的程序是先写好设计文档再进行编 程的，在设计文档的指导下，才能写出 安全的代码。如果你不写文档，一开始 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 21 就写程序，这样你就不会按已设计好的 路线走，而是想到哪写到哪。小功能还 好说，要是大功能，就容易混乱. 刚开始我们还很不习惯这一系列 的编程风格，很多的规范，尤其是命名， 方法和注释，都有这着很多限制，让我 们觉得真罗唆，写个程序完成功能不就 可以了吗，明明 1 小时做完的事情非得 让人用 3、4 个小时去做，我们现在真 的明白这样做的好处了，我们已经习惯 这样的编程风格了，这也养成了我们的 一个编程习惯了，深有体会啊。 最忙的时候就是我们成长和收获 最多的时候。 八、网盘项目开发的最大体会 我们觉得项目开发的开始时候， 应该由项目负责人很好的对项目是什么 项目，具体大概做什么事情，是谁提出 来的，目的是解决什么问题，以及里面 用到的很多专有名词做个细致的说明， 而不是从一开始就分几本式样书，给个 静态 html 的 demo 看看，然后搭建好 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 22 开发环境就按照式样设计书来开发。 九、软件测试 我们首先认为，编写程序的时候 不要想出了问题再解决，而是要想如何 不会出现问题，要根据经验来预测可能 出现的问题，然后避免出现。 测试，说的直接点就是给软件找 错误。 很多人认为发现错误是软件测试 的唯一目的,查找不出错误的测试就是没 有价值的测试,实际上我们不这么认为。 我们觉得对开发人员来说，我们 要把测试出来的 bug 都应该做个分析， 知道错的原因之后，我们就应该在下个 项目中防止类似的错误发生，而真正来 提高我们开发的效率。 软件开发实习心得 一直以来期望从事自己喜欢的事 业的我，对软件开发有者及大的兴趣， 可由说种种原因使我从事工作以来走了 好几年弯路，心中的梦想迟迟不能得以 实现，可程序员的梦想从来没有从我的 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 23 心中抹去，但这扇大门好像并没有向我 敞开，今天，贵公司给了我敲开这扇大 门的机会，让我真实体验了程序员的诞 生过程。早就听说，程序员的前几个月 是最苦的，可从来没有感受到，海马实 习基地让我提前感受到了刚刚进入软件 行业的压力和困惑，再也没有在自己家 里随便写段小程序后的那种“自豪” 感了。 要面对每天必须面对的问题，再也不可 能以“逃避”而了之了。也让我感觉到做 为一个程序员所应该具备的基本素质在 这不到一个月的实习过程中也让我深深 体会到了作为一个合格的程序员应该具 备的基本素质。 团队精神和协作能力是程序员应 该具备的基本素质，最近的工作中让我 深深休会到了这一点，由于小组成员配 合不好，使本来很方便的 cvs 给自己的 工作带来的及大的麻烦，一不小心自己 写的的东西就会被小组别的成员在上传 文件的时候给覆盖掉，一整天的工作可 能就这样被反工，我们小组这次就是因 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 24 为协作不好，导致各模块之间不法连接， 给工作带来了及大的麻烦，消耗了大量 的劳动力还没有提高工作效率。这使我 深深的体会到：一个成功商业性软件的 开发必须有一个有强大凝聚力的团队， 个人的力量是有限的，团队精神和良好 的协作会使我们做出优秀的软件。 良好的文档是正规研发流程中非 常重要的环节，作为代码程序员，30 的工作时间写技术文档是很正常的，缺 乏文档，一个软件系统就缺乏生命力， 在未来的查错，升级以及模块的复用时 就都会遇到极大的麻烦。这次的这个小 小的项目，就因为文档上的一点点理解 错误让我们花了很大的工夫去改代码， 改页面。很庆幸的是，这是一个小项目， 要是大项目，这种问题可能就会导致大 量的代码修改，可见文档在一个项目中 起者巨大的做用。 此外，良好的代码编写习惯，不 但有助于代码的移植和纠错，也有助于 不同技术人员之间的协作。作为一个程 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 25 序员，对需求的理解能力也是很重要的， 只有真正理解了一个模块的作用，才会 写出高效率的代码，才能使整个软件项 目作出来更加优秀，具备更好的安全性 和稳定性，我在写代码的过程中就遇到 了需求理解上的问题，使得写出来的代 码功能不全，幸好不是给客户发现在， 要不，这个软件的商业价值可能就会打 折扣了。单元测试对于一个程序员来说 是不可不做的一项工作，不做好测试就 会给后期的集成工作带来麻烦，往往为 了一个小问题会让我们查找好多模块， 给后期工作带来很大麻烦。 这一段时间的工作也让我明白了 一点：一个优秀的程序员必须不断的学 习，随时总结，找到自己的不足，这样 逐步提高，才能让自己很快的成长起来。 建站侠客 发表于 2014-4-28 10:19 对软件开发的一点心得体会 一、前期规划： 我理解的前期规划是：在市场人 员们汇总一个需求提交给产品专家带领 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 26 的产品经理团队，然后经过这个团队根 据公司具体情况再次分析和规划出一个 最终需求文档。 这个需求文档应当首先提交给技 术研发部门的负责人以及核心开发人员。 由开发团队对其进行技术和风险分析。 如果对此需求统一有异议的地方，需要 返回给产品团队，重新修正需求。反复 如此，直至需求完善准确，细致，清晰。 前期规划就像高楼的地基，如果 马马虎虎，就算是一块砖块没摆好都可 能导致整个高楼建设的失败。在规划中 我认为，交流永远是需要双方积极主动， 能认真听取每个人的建议。前期工作思 维不慎重，不细致，不认真，不够完善， 将产生连锁效应直接导致整个工程和项 目的失败。 这种失败可能表现为：第一种， 软件按需求实现但是功能根本不能满足 用户需要。第二种，功能都有了，软件 没有达到可用性、易用性。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 27 对于第一种，当然是因为前期规 划疏漏了某些细小功能，没能把需求文 档做完善。应该是规划工作做的还不够 认真和细致。 对于第二种情况，我认为更多是 在产品设计规划方面经验还不够成熟。 这种问题应该是很难避免的。因为每种 新产品对产品团队来说都很陌生。即使 以前做过类似的东西，也难免面面俱到。 这只能通过不断努力和认真的态度来弥 补。 前期规划的交流涉及了市场、产 品和技术研发等多个团队之间。需要的 不仅是团队内部的交流，更多需要协调 好团队之间的交流。可能有时候需要公 司高层和中层参与协调。 目前，很多开发人员深感项目的 需求文档写的都很单薄。大家可以想一 想，如果没有好的开始，怎么会有好的 结束呢？需求文档单薄，不够细致，由 谁来继续完善呢？难道让程序员们自己 去完善。我想程序员也可能没有这种能 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 28 力。对于程序员能把代码写的很健壮很 稳定就已经是很不容易的事情了。 二、概要设计： 我理解的概要设计步骤： 1项目经理仔细阅读项目需求 文档。 2项目经理召集项目开发成员， 开项目启动会议。具体商议项目的开发 任务和责任分配。 3核心开发人员开发确定，以 及各模块开发人员确定。 4由系统分析员和核心开发人 员仔细阅读需求文档，对系统整个架构 分析和做技术规划。 5系统分析员整理和书写最终 的系统架构和概要设计文档。 6系统分析员在文档提交日， 提交给项目经理。项目经理确认文档并 审批。 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 29 7项目经理召集项目开发成员， 开一个概要设计以及系统架构确定的会 议。向每个成员分发文档，并讨论确定 最终概要设计文档。 8开始详细设计文档的工作 三、详细设计： 1项目经理组织成立各个模块 的开发小组，并确定开发小组组长。 2各开发组长书写各自模块的 详细设计文档，开发成员需要协助，配 合。 3在指定提交日，开发组长提 交文档给系统分析员。由系统分析员审 批。 4系统分析员组织召开一个详 细设计文档确认的会议。 5然后开发组长分发各自模块 的详细设计文档给程序员，程序员在指 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 30 定时间内完成。 6程序员做内部测试。开发组 长协调并配合。 7确认无 bug 提交给开发组组 长。 8所有模块整合工作，由整个 开发组成员参与完成。由所有开发组长 和系统分析员负责主要部分工作。程序 员协助和配合。 9对整合后工程做详细测试。 10确认测试通过后，开发组长 根据开发成员表现以及提交成果填写绩 效考核表。然后提交给项目经理。 11项目经理会召开项目总结会， 同时向优秀成员颁奖。同时鼓励所有成 员继续努力。对不能按时完成导致项目 能按时提交，以及对导致失败的 关键人员给与惩罚处理。 当然，以上只是一个简单的开发 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 31 流程，一定是有很多不足的地方。希望 能起到抛砖引玉的作用。大家都明白， 流程和制度是死的，但人是活的，所以 如何按流程做得好，关键还是在人本身 了。没有一个流程和制度，一个团队也 必将是一盘散沙。正所谓“无规矩无以 成方圆”。这句话说得很有道理。 四、具体编码： 开发几个项目之后，对编写程序 有了更进一步的了解。 好的程序应该具有: 易读性，易 扩展性，容错性。 易读性: 所有变量和函数以及类 名用简单易懂易记忆的命名方式。所有 类和函数甚至变量都有关键的注释说明。 这点很重要，也是最基础的。如果代码 书写不够美观和易懂，我想自己以后也 不想再看。就更别谈功能的扩展和新版 本开发了。 易扩展性: 整体系统架构逻辑简 单清晰。模块与模块之间尽量做到互不 影响，也就是尽可能的独立。这部分工 -精选财经经济类资料- -最新财经经济资料-感谢阅读- 32 作主要体现在前期设计工作中，需要掌 握好的设计经验和方法才能够做得比较 好。 容错性: 对数据流和指针以及数 组都做数据有效性检查；对第三方接口 的调用失败的容错性。对所有代码都做 调用失败后的错误处理。以及在大