C#调用其它程序

狮子心 — Sat, 29 Sep 2007 07:31:00 GMT

//执行bat文件
                System.Diagnostics.Process myProc = new System.Diagnostics.Process();
                myProc.StartInfo.FileName = batPath;
                myProc.Start();
//调用cmd.exe
                System.Diagnostics.Process.Start("cmd.exe", ff);

using System;

class test
{
static void Main()
{

//声明一个程序信息类
System.Diagnostics.ProcessStartInfo Info = new System.Diagnostics.ProcessStartInfo();

//设置外部程序名
Info.FileName = "notepad.exe";

//设置外部程序的启动参数（命令行参数）为test.txt
Info.Arguments = "test.txt";

//设置外部程序工作目录为 C:\
Info.WorkingDirectory = "C:\\";

//声明一个程序类
System.Diagnostics.Process Proc ;

try
{
//
//启动外部程序
//
Proc = System.Diagnostics.Process.Start(Info);
}
catch(System.ComponentModel.Win32Exception e)
{
Console.WriteLine("系统找不到指定的程序文件。\r{0}", e);
return;
}

//打印出外部程序的开始执行时间
Console.WriteLine("外部程序的开始执行时间：{0}", Proc.StartTime);

//等待3秒钟
Proc.WaitForExit(3000);

//如果这个外部程序没有结束运行则对其强行终止
if(Proc.HasExited == false)
{
Console.WriteLine("由主程序强行终止外部程序的运行！");
Proc.Kill();
}
else
{
Console.WriteLine("由外部程序正常退出！");
}
Console.WriteLine("外部程序的结束运行时间：{0}", Proc.ExitTime);
Console.WriteLine("外部程序在结束运行时的返回值：{0}", Proc.ExitCode);
}
}

狮子心 2007-09-29 15:31 发表评论

《人件》读书笔记（1）

狮子心 — Sat, 10 Mar 2007 04:50:00 GMT

摘要: 阅读全文

狮子心 2007-03-10 12:50 发表评论

《人月神化》读书笔记（1）

狮子心 — Tue, 06 Feb 2007 02:09:00 GMT

一、焦油坑：
1．编程系统产品：
编写程序：即每个模块全部编写完成，写代码；
编程系统：即各个模块可以完美结合，形成一整套系统；
编写程序的工作量只是编程系统的三分之一。
编程产品：包括了通用化、测试、文档和维护；
编写程序的工作量只是编程产品的三分之一。
编程系统产品：是编程系统化和产品化的工作量，是编写程序的九分之一。
2．职业的乐趣：
首先是一种创建事物的纯粹快乐。
其次，快乐来自于开发对其他人有用的东西。
第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。
第四是学习的乐趣，来自于这项工作的非重复特性。
最后，乐趣还来自于工作在如此易于驾驭的介质上。
3．职业的苦恼
首先，必须追求完美。
其次，是由他人来设定目标，供给资源，提供信息。对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序，而往往这些程序设计得并不合理，实现拙劣，发布不完整（没有源代码或测试用例），或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情况下本应该是可靠完整的。
下一个烦恼——概念性设计是有趣的，但寻找琐碎的bug却只是一项重复性的活动。
另外，人们发现调试和查错往往是线性收敛的，或者更糟糕的是，具有二次方的复杂度。结果，测试一拖再拖，寻找最后一个错误比第一个错误将花费更多的时间。
最后一个苦恼，有时也是一种无奈——当投入了大量辛苦的劳动，产品在即将完成或者终于完成的时候，却已显得陈旧过时。
二、人月神化
对于软件任务的进度安排，以下是我使用了很多年的经验法则：
1/3计划
1/6编码
1/4构件测试和早期系统测试
1/4系统测试，所有的构件已完成

简单、武断地重复一下Brooks法则：
向进度落后的项目中增加人手，只会使进度更加落后。（Adding manpower to a late software project makes it later）
三、外科手术队伍（The Surgical Team）
      软件经理很早就认识到优秀程序员和较差的程序员之间生产率的差异，但实际测量出的差异还是令我们所有的人吃惊。在他们的一个研究中，Sackman、Erikson和Grand曾对一组具有经验的程序人员进行测量。在该小组中，最好的和最差的表现在生产率上平均为10:1；在运行速度和空间上具有5:1的惊人差异！简言之，$20,000/年的程序员的生产率可能是$10,000/年程序员的10倍。数据显示经验和实际的表现没有相互联系（我怀疑这种现象是否普遍成立。）
      Mills的建议
      外科医生。Mills称之为首席程序员。他亲自定义功能和性能技术说明书，设计程序，编制源代码，测试以及书写技术文档。。首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的大量系统和应用知识。
      副手。他是外科医生的后备，能完成任何一部分工作，但是相对具有较少的经验。他的主要作用是作为设计的思考者、讨论者和评估人员。外科医生试图和他沟通设计，但不受到他建议的限制。副手经常在与其他团队的功能和接口讨论中代表自己的小组。他需要详细了解所有的代码，研究设计策略的备选方案。显然，他充当外科医生的保险机制。他甚至可能编制代码，但针对代码的任何部分，不承担具体的开发职责。
      管理员。外科医生是老板，他必须在人员、加薪等方面具有决定权，但他决不能在这些事务上浪费任何时间。因而，他需要一个控制财务、人员、工作地点安排和机器的专业管理人员，该管理员充当与组织中其他管理机构的接口。Baker建议仅在项目具有法律、合同、报表和财务方面的需求时，管理员才具有全职责任。否则，一个管理员可以为两个团队服务。
      编辑。外科医生负责产生文档——出于最大清晰度的考虑，他必须书写文档。对内部描述和外部描述都是如此。而编辑根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息和书目，对多个版本进行维护以及监督文档生成的机制。
      两个秘书。管理员和编辑每个人需要一个秘书。管理员的秘书负责项目的协作一致和非产品文件。
      程序职员。他负责维护编程产品库中所有团队的技术记录。该职员接受秘书性质的培训，承担机器码文件和可读文件的相关管理责任。所有的计算机输入汇集到这个职员处。如果需要，他会对它们进行记录或者标识。输出列表会提交给程序职员，由他进行归档和编制索引。另外，他负责将任何模型的最新运行情况记录在状态日志中，而所有以前的结果则按时间顺序进行归档保存。
      Mills概念的真正关键是“从个人艺术到公共实践”的编程观念转换。它向所有的团队成员展现了所有计算机的运作和产物，并将所有的程序和数据看作是团队的所有物，而非私人财产。
      程序职员的专业化分工，使程序员从书记的杂事中解放出来，同时还可以对那些杂事进行系统整理，确保了它们的质量，并强化了团队最有价值的财富——工作产品。上述概念显然考虑的是批处理程序。当使用交互式终端，特别是在没有纸张输出的情况下，程序职员的职责并未消失，只是有所更改。他会记录小组程序和私有工作拷贝之间的更新，依然控制所有程序的运行，并使用自己的交互式工具来控制产品逐步增长的完整性和有效性。
      工具维护人员。现在已经有很多文件编辑、文本编辑和交互式调试等工具，因此团队很少再需要自己的机器和机器操作人员。但是这些工具使用起来必须毫无疑问地令人满意，而且需要具备较高的可靠性。外科医生则是这些工具、服务可用性的唯一评判人员。他需要一个工具维护人员，保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特别是交互式计算机服务）的构建、维护和升级责任。即使已经拥有非常卓越的、可靠的集中式服务，每个团队仍然要有自己的工具人员。因为他的工作是检查他的外科医生所需要的工具。工具维护人员常常要开发一些实用程序、编制具有目录的过程库以及宏库。
      测试人员。外科医生需要大量合适的测试用例，用来对他所编写的工作片段，以及对整个工作进行测试。因此，测试人员既是为他的各个功能设计系统测试用例的对头，同时也是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台。
      语言专家。随着Algol语言的出现，人们开始认识到大多数计算机项目中，总有一两个乐于掌握复杂编程语言的人。这些专家非常有帮助，很快大家会向他咨询。这些天才不同于外科医生，外科医生主要是系统设计者以及考虑系统的整体表现。而语言专家则寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。他通常需要对技术进行一些研究（两到三天）。通常一个语言专家可以为两个到三个外科医生服务。
      如何运作

      十个人，其中七个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。
      团队的扩建
      扩建过程的成功依赖于这样一个事实，即每个部分的概念完整性得到了彻底的提高——决定设计的人员是原来的七分之一或更少。所以，可以让200人去解决问题，而仅仅需要协调20个人，即那些“外科医生”的思路。

狮子心 2007-02-06 10:09 发表评论

BlogJava-可爱的java-随笔分类-读书笔记

C#调用其它程序

《人件》读书笔记（1）

《人月神化》读书笔记（1）