旁听机房收费系统验收

   前两天在会议室,第一次见到了传说中的师傅验收徒弟的场面,给我的感觉像是在做毕业论文答辩!一堆老师听着一个同学讲述自己的论文或者设计,然后指出其作品中存在的瑕疵或闪光点,然后给出评价,对各种细节要求的都挺严格的。还好,咱也是过来人了,这种场面不怕了,(*^__^*)

 

  看着他们做的挺高深的,讲的好多技术知识像什么包图啦、UMLB层和U层啦咱也听不懂,但说到的很多思想和设计方式对我们将来的学习还是大有裨益的。下面大概说说自己见识到的几点吧。


    1、项目开发时设计的重要性

    俗话说“磨刀不误砍柴工”,前期的构思看似需要很多时间,如果觉得不值得而草草设计、匆忙上马,到后来开发时就会出现各种各样的错误,甚至严重到需要重构的地步!我们不能只看见万丈高楼平地起,却忘记了地基要比高楼更深的道理!这就像战略与战术的关系,战略方向错了,即使战术再高深再精明,也难以逃脱失败的厄运。所以,规划设计真的很重要!


   2、各个时期文档书写的合理与完整

   一个完整软件或者系统的研发过程,不仅仅体现在开发的代码上,也体现在总体设计、各个阶段、各种情况记录的文档上。文档的合理书写可以让自己的合作开发者一眼就能明白,而不能让他们看完后如在云里雾里,抓不住重点,看不清方向。文档的整体布局与细节理解,做到表格、画图与文字的整洁、简明,避免凌乱、复杂。大到软件的总体架构,小到文档的命名与字字斟酌,这些都是需要认真去琢磨的。在我们的学习过程中,也许会有上一期或者本期学得比较不错的人写的文档模版,如果我们照着他们的文档稍微修改一下加上自己的一点东西去应付差事,空洞、千篇一律、没有自己的灵魂,这样最终受害的还会是自己。

 

   3、团队合作的工具与分工

   团队合作,顾名思义就是N多人合作开发同一个项目。分工真的很重要,不仅仅为了给每个人开发的机会,更是锻炼他们对所接受的分工进行细化,如应该UMLB层干的事情就决不放到U层。只有每个人做好自己的一部分,整个软件才能够健康完整的运行起来。期间用到的各种工具也需要尽量统一,否则,有可能出现不兼容等等意想不到的错误。

 

   4、系统维护的前瞻性

   每开发出一个新的软件,就难免有各种Bug,但如何让用户能够满心欢喜和使用你的软件呢?让消费者尽量少见到出错的机会!软件开发其实靠的是技术,更是做人的道理!我们应该本着全心全意为人民服务的态度来为消费者设计研发和维护。发现错误(当然是小的)后,不告诉用户,悄悄的发送给维护人员,进行改进、升级、维护,让人花钱了也高兴。跟孔雀开屏似得,要把自己优秀的一面展现给别人,毕竟,人无完人,任何软件都不是完美无缺的!在开发的时候,系统可以专门设计出一个错误收集系统和处理模块,将可规避的异常与意外错误都能够集中处理!当然,代码和注释的规范性、严谨性都是必须的!

  

   5、中国人对待软件的设计与消费习惯

   我们中国人对待软件的态度就是俩字:凑合!买东西与用东西都是便宜为先,凑合为主,只要性能差不多,能够正常运转就行。宁可一次花10万,再次花10. . . . . 最后花到100万了,也不舍得一次性花50万来买一个质量高、信誉好的软件。想的就是能凑合跑起来就行,能凑合维护就行,却想大大的盈利!然后开发者就会按照这样的用户来设计符合他们胃口的软件。慢慢的恶性循环,造就了咱们国家软件行业所普遍具有的特点:价格便宜(也就是薄利)、维护成本高、生命周期短。而很多西方发达国家设计的软件都是设计的比较严谨、价格超贵,但产品质量高、维护成本低。所以,世界上通用的大部分软件和操作系统都不是中国人设计开发出来的,可悲啊!

 

    6Getting things done

   尽量让脑子不记住任何东西,无压学习,快乐学习。利用各种工具,把提醒等放进去。只要到点了,就让工具提醒自己。如借给别人东西,不要记到脑子里,而是立即用笔或手机或者电脑记下来详细情况,需要的时候就可以直接查,等事情积累的差不多了,集中处理它们。否则,我们的大脑记得东西太多,就会劳累,影响情绪和学习效率。

 

   还有其他的知识如基础知识的掌握了,快捷键的使用了,实图、类图、包图、状态图、活动图的构画了,组件与控件的区别了等等,收获真的挺大的,将这些整理出来,跟大家一起分享、讨论!

你可能感兴趣的:(活动,文档,手机,工具,UML,产品)