附加题作业

1.教材第3章3.1节
问题:初级软件工程师如何成长运用及javascript调用后台出现的问题
疑问:作为编程接触不到2年的我们,而且在这方面没有天赋的我们怎样积累更多的软件知识,有更好的软件设计思想以及提升自己的职能技能。在一个img 的前台onclick调用javascript方法,显示出来的是异常信息 "输入格式不正确".
回答:document.getElementById('txt2').value = ' <%=GetBig("' + a + '")%>';
改为document.getElementById('txt2').value = ' <%=GetBig(' + a + ')%>';结果试试还是不行,试试ajax调用后台貌似可以。

2.教材第4章4.4节
问题:代码完成未啥还要做复审呢
疑问:例如在一个代码运行结果无出错的情况下为什么还要再次审核
回答:大多人可能认为在代码运行结束后显示出结果就以为完事了其实不然,后面还要做很多的后台工作。从某种意义上讲,复审是在原先的基础发现的问题,很大程度上还是有我们自己完成。当然有些人认为这要在之前做的完美后续就不用再浪费复审者的时间了,其实你想想一个在怎么厉害或多或少都会犯一些错误甚至更低级的错误都会有,所以在我看来复审是非常必要的。

3.教材第5章5.2
问题:假设我要做一个很大的软件开发的项目,怎样选择自己的Team呢?
疑问:一个完美的团队决定着结果好坏吗
回答:搜了一下,项目角色包括:
.分析师
.策划师
.数据库管理员
.设计师
.操作/支持工程师
.程序员
.项目经理
.项目赞助者
.质量保证工程师
.需求分析师
.主题专家
.测试人员
看了之后在我看来,核心的应该是程序员,设计师了,默默的做着前台的工作。

4.教材第12章12.2
问题:好的人机交互设计 (UX) 有哪些主要评判标准?

疑问:好的设计需要哪些好的原则

回答:比如说:
1.优先级:做一个基本的假设:如同经济学里资源的稀缺性假设一样,用户的认知 源和系统的界面资源都是稀缺的。包括:a. 用户优先级 b. 功能优先级 c. 内容/信息优先级 d. 交互优先级 e. 视觉优先级

2. 一致性:一致性可以让界面更容易被预知,可以降低用户的学习成本等等。一致性几乎是设计中最普遍的一条原则,也是缺乏设计经验的团队最容易犯的错误。
通常需要注意一致性的地方包括:a. 交互逻辑的一致性 b. 元素的一致性 c. 语词的一致性 d. 信息架构的一致性 e. 视觉的一致性

3. 感觉:可用性工程的教科书里,往往会有“主观满意度”的内容(实际上这也是ISO9241的内容之一),但是却也往往语焉不详,因为主观的问题往往难以通过工程/经验的方法来解决。
例如以下几点:a. 快的感觉 b. 安全的感觉 c. 其他感觉

4. 临界点:临界点往往是多种因素综合的作用,和用户的主观心理(感觉)和客观因素(绩效)等有关系,姑且作为半个原则来看。

5.教材第15章15.1.3
问题:如何系统修复C#的Bug
疑问:具体来说Bug是由于什么原因而产生的
回答:查阅了一下,因大多数程序的bugs出现在程序员之间的接口:当一个程序员编写的代码被另一个程序员调用时。不知何故,调用者破坏了代码编写时做的假设。是谁的过错呢?这并不要紧,更重要的是你能多快修好它?下面这些技巧将帮你在程序投入使用前更快地发现并解决这些问题。最终,这些技巧会帮你诊断任何的确在使用中出现的问题。
1.验证完整性:
一个C# 程序中的大多数函数都是一个对象上的实例方法。对任何对象的有效状态都有暗示的假设。当一个公有的方法被调用时,你应该确保那些暗示的假设经过了测试。C# 的条件编译特征使这一点很容易实现。
   首先,写一个私用的函数来测试对象的完整性。你在这么做时,将该方法标为“conditional”: [Conditional ("DEBUG")]

2.运用debug 和Trace 输出:
打印诊断消息可以帮你确定你的程序是怎么出错的。你需要知道当触发Assert时,发生了什么情况;你也通常需要知道在这之前发生了什么。知道这些最好的方式就是运用你的代码,这样你就可以很容易地看到在出现bug前,调用了什么函数。
在生成调试输出时,.net Framework有一些新的功能可以用。System.Diagnostic.Debug类可以让你格式化调试输出,并能很容易地创建不同的类或级别的调试输出。下面是我喜欢用的一些指导方针。

你可能感兴趣的:(附加题作业)