binjuny的专栏

技术总监谈好的程序员如何写代码

杨德静 — Wed, 10 Feb 2010 10:16:00 +0800

这篇文章是我在书部落上看到的，也不知道转载了几下，所以具体的原始作者已经不知道是谁，做开发那么多年了，感觉其中许多方面自己还没有做到，故转载至此，多给自己点警醒。

ZZ python 类型转换

杨德静 — Sat, 10 Oct 2009 10:33:00 +0800

函数描述 int(x [,base ]) 将x转换为一个整数 long(x [,base ]) 将x转换为一个长整数 float(x ) 将x转换到一个浮点数 complex(real [,imag ]) 创建一个复数 str(x ) 将对象 x 转换为字符串 repr(x ) 将对象 x 转换为表达式字符串 eval(str ) 用来计算在字符串中的有效Python 表达式,并返回一个对象 tuple(s ) 将序列 s 转换为一个元组 list(s ) 将序列 s 转换为一个列表 chr(x ) 将一个整数转换为一个字符 unichr(x ) 将一个整数转换为Unicode字符 ord(x )

我的重构步骤

杨德静 — Sun, 16 Aug 2009 09:39:00 +0800

第一步：注释检查
   1：是否利于阅读
   2：检查注释是否充分
   3：是否存在多于的注释
   4：注释是否与代码一致
   5：是否有假设依赖条件需要特别说明
   6：是否需要对框架，调用关系进行说明
第二步：检查类、函数、变量命名
   1：检查命名是否表达了含义，是否还有更合适的名称。
   2：整个项目中，命名风格是否一致。
   3：不阅读注释，是否能从名称中读出需要的信息
   4：类成员的调用是否用了this，是否有m_前缀，静态成员是否有s前缀，全局成员是否有::。
第三步：检查方法的复杂度
   1：检查方法嵌套是否太深，是否可以修改嵌套
   2：检查局部变量的声明与使用之间，是否距离太远
   3：检查for循环中，是否存在重复的执行操作，例如数组的长度等
   4：检查函数的个数是否合适
   5：检查多个函数之间，变量位置是否一致
   6：函数参数是否可以更

关于 SetProcessWorkingSetSize 和内存释放

杨德静 — Mon, 10 Aug 2009 15:45:00 +0800

在应用程序中，往往为了释放内存等，使用一些函数，其实，对于内存操作函数要谨慎使用，比如大家常常想到的 SetProcessWorkingSetSize，其实对于windows来说，系统会自动在程序闲置时（如程序被最小化）释放内存的，自己用内存释放时，往往会造成一些莫名的内存错误，造成自己的应用程序及系统不稳定。

具体原理有人已经写得很清楚了，以下为转帖的几个帖子，供参考：
=============================================
1、将物理内存的占用挪到虚拟内存里-----揭密篇
将物理内存的占用挪到虚拟内存里-----揭密篇
参见 VB(或任意程序)将物理内存的占用挪到虚拟内存里

那么我的程序为什么能够将占用的内存移至虚拟内存呢？

其实，你也可以，试试看把一个程序最小化到任务栏，再看看任务管理器，看到没，你的程序占用的实际内存一下子减少了，看来并不是我有什么方法能够压缩内存，而是操作系统

IPHLPAPI 的其它函数(1)

杨德静 — Fri, 10 Jul 2009 09:27:00 +0800

IPHLPAPI 的其它函数
IPHLPAPI还有以下的函数，这里给出C语言的函数原型和参数说明，具体说明详见MSDN2003。
1、GetAdapterIndex：从名称获得一个适配器的序号
DWORD GetAdapterIndex( LPWSTR AdapterName, PULONG IfIndex);
AdapterName：[输入] 指定了适配器名称的Unicode字符串
IfIndex：[输出] 指向一个指向适配器序号的ULONG变量指针
返回值：成功，返回0；失败，返回错误代码。

2、GetAdaptersAddresses：返回和适配器关联的地址
DWORD WINAPI GetAdaptersAddresses( ULONG Family, DWORD Flags, PVOID Reserved, PIP_ADAPTER_ADDRESSES pAdapterAddresses, PULONG pOutBufLen);

设计构建一个软件程序的基本步骤探讨

杨德静 — Tue, 18 Nov 2008 15:31:00 +0800

软件的主要任务
软件的核心任务不外乎是收集和整理数据，然后以用户需要的形式表现给他们而已，此外还有数据的存储，数据的传输等外围任务。
数据的收集，整理，表现，存储和传输就是软件的主要任务，它们也是程序员的主要工作内容，也是程序员编写代码的最终目的。
那么该如何编写代码让软件完成它的主要任务呢？编写代码的过程是否有规律可循？编写代码需要注意那些方面的问题？本人想就这些问题罗列自己一些粗浅的看法，并大家进行一些探讨。
一.软件构建从需求开始
需求即用户对软件功能的描述，用户通过需求告诉程序员他需要收集什么数据，这些数据该怎么处理，最后他希望看到什么结果。需求中描述的场景和内容是软件处理的核心领域，程序员需要通过代码把它表现出来。
即使用户是和你一样的程序员，需求也不可能完善到直接指导编码的地步，而且软件的构建是一个“邪恶（Wicked）”的过程，也就是说某些问题在设计阶段并不显山露水，只有在构建过程中它们才会逐渐暴露出来。这就要求程序员深入问题的领域，了解领域的相关知识，对领域做出合理的抽象，并在软件构建过程中不断完善它，直到完全

OOAD培训心得

杨德静 — Wed, 22 Oct 2008 08:38:00 +0800

周末参加了公司组织的“面向对象设计与分析基础”的培训，感觉获益良多。
有些比较好的东西摘出来，标记！

【用户需求观】
        这个名称说起来容易，一切从用户出发，用户的需求决定我们的产品，从用户的角度去考虑问题。但是实践时，我总会考虑这个需求如何对应，那个需求如何实现。这样做不是很好，容易考虑的太多，注意力偏离了正轨，用个大家常说的词就是“不上道”。
        需求分析阶段，应该把系统当成一个黑盒，这时，我们需要做的就是规定他与外界交互，让他拥有最基本的完成用户需要的功能。

【功能的划分】
        这个问题说多了，可以用整个一篇文章，这里我们只考虑需求阶段，在这个阶段，还是那句话，不要过多的考虑实现。
        在我的第一个项目里，因为是新手，所以我很小心的考虑了很多，比如这个功能可以和哪些功能联系在一起，比如这个功能可能用到的技术。从而造成了这样一个问题，当考虑第一个问题的时候，ok，一切都是空白，然后把他的基本功能列出来，把他可能用到的技术列出来，然后继续，随着

用例分析技术：确定系统边界

杨德静 — Wed, 22 Oct 2008 07:47:00 +0800

用例分析技术：确定系统边界
确定系统边界非常重要，是使用用例技术的基础，小记下！
1、找出系统有什么；系统外有什么；确定项目规模，定义要创建系统那些部分。
2、通过确定执行者和用例来确定系统边界。
3、确定执行者：谁使用这个系统，谁安装这个系统,谁启动这个系统，谁维护这个系统，谁关闭这个系统，那些系统使用这个系统，谁从这个系统获取信息，系统为谁提供信息，是否有事情在预计时间自动发生？.....提问的方式最好针对参与者的目标。因为用例建模的观点就是寻找特定参与者及其目标。
4、确定执行者使用的用例：
5、用例是一种系统执行的一系列活动，执行者执行它产生一种可估量（量化）的结果。什么样子才是可量化？一般指用例执行后的结果是具有持久性，稳定性的数据。
6、确定用例：执行者希望系统提供什么样功能？系统存储，创建，更新或删除什么信息？系统是否需要把自身的状态变化通知给执行者？系统必须知道哪些外部的事件？执行者怎样通知系统这些事件？
7、言简意骇的描述执行者和用例。
8、发现新需求问一些问题：
这些

需求——对系统边界的描述

杨德静 — Tue, 21 Oct 2008 17:59:00 +0800

需求表达

定量描述需求

杨德静 — Tue, 21 Oct 2008 17:52:00 +0800

定量描述需求      goldway 发表于 2006-8-13 11:01:00

   特别是对于非功能需求，更应该尽可能地用定量的数据来描述，定量描述可以避免需求的二义性，同时也提供了可测试的依据。
  为定量地描述系统需求，首先必须定义表达这些属性的合适的度量，然后为这些属性决定一个合适的值。在某些情况下，这可能是很难的，需要从业务人员和系统相关人员处获取更多的信息，同时还需要了解业界目前的常用标准。
系统特性可以使用的度量的例子如下：
系统特性
可以使用的度量  可靠性出错时间可靠性错误发生率有效性请求后出错的可能性性能每秒处理的交易数性能对用户输入的相应时间存储系统需要的最大内存空间大小（KB）可用性学习75%的用户功能所需要的时间可用性在给定时间内，由用户引起的错误的平均值健壮性系统出错后重新启动的时间完整性系统出错时，允许的数据丢失的最大限度。  系统性能往往要求体现在系统的高峰期，即当系统承受最高负载时系统的性能情况。该项性能可以由压力测试工具进行检验。