废话

长期从事Delphi开发，虽不敢说精通，但说很熟悉还是相当有自信的。不过，只会一门语言，而且还是这么老的语言，更是在大天朝很小众的语言，总感觉自己离饿死街头没多远了，所以趁着还没老再学个潮点的吧。

先前考虑过Python，初步了解后觉得不太适合自己：

解释型语言：部署时得先搞个运行环境，发布的程序就是源码本身，再加上这个执行效率，怎么想都还是编译型语言更合适。
动态语言：无需声明，拿来就用，这已经很不合习惯了。想想一个变量，前一秒还是浮点数，下一秒就成字符串了，再一眨眼又成某个对象了……虽然一般不会有人这么写，但是挡不住手误啊，还是把这种小细节交给编译器更让人放心。

所以，对于有点强迫症和洁癖的自己，最后还是选了Go，比较符合已有的编程习惯，学习成本应该相对会低些吧。

至于Go嘛，想学是已经很久了，但由于种种原因却迟迟未开启，不过终究还是要迈出这一步的，所以就搞这么个系列来记录吧，一方面算是自我督促，另一方面也算是一种交流吧，当然，若一不留神帮上了谁，那自是开心极了。

言归正传

已经初步了解过了Go，说来和Delphi还是有不少相似之处呢，从Delphi转向Go应该会比较轻松吧。

工程结构

Delphi的工程算是比较自由的，源码的话，只要把单元路径引了或是直接包含进工程单元里就可以了，编译出的dcu和最终的exe指定下路径也就没问题了，通常我都使用下面这种结构：

Project/
  bin/
  src/
    dcu/
    mod1/
      *.dfm
      *.pas
    mod2/
      *.dfm
      *.pas
    *.dpr

不过，每一个工程都要设置，而且我习惯将Debug和Release设置完全一样，也还真是够烦的。

Go就没得选了，只有一种结构：

Project/
  bin/
  pkg/
  src/
    *.go
    mod1/
      *.go
      *_test.go
    mod2/
      *.go
      *_test.go

整体和我原有的习惯差不多，还是蛮容易接受的，不过倒是要把这Project的路径加入到GOPATH系统变量里让人有一点小不爽。

源码结构

Delphi典型的源码结构是这样：

unit Unit1;

interface
uses
  ...//单元引用
type
  ...//公开类型定义
const
  ...//公开常量
var
  ...//公开变量
procedure Proc1;//公开过程声明
function Func1: Integer;//公开函数声明

implementation
uses
  ...//私有单元引用
const
  ...//私有单元级常量
var
  ...//私有单元级变量
procedure Proc1;
var
  ...//模块级变量
begin
  ...//公开过程实现
end;

function Func1: Integer;
const
  ...//模块级常量
begin
  ...//公开函数实现
end;
procedure Proc2;//单元级私有过程实现
  function Func2: Integer;//模块级私有函数实现
  begin
    ...
  end;
begin
  ...
end;

initialization
  ...//单元初始化代码
finalization
  ...//单元反初始化代码
end.

Go的源码结构是这样：

package pkg1
import "fmt" //导入包
const C1 //公开常量
const c2 //私有常量
var V1 //公开变量
var v2 //私有变量
func Func1(){}//公开方法
func func2(){}//私有方法

整体上来看，Delphi语意更明确，Go则更简洁，Delphi更集中，Go则和所有类c语言一样比较单一、灵活，各有各的好。倒是Go这用首字母大小写来区分公开私有让我这喜欢pascal命名法的有点尴尬。

未完待续

业余码农

从Delphi到Go

废话

言归正传

工程结构

源码结构