给大学刚毕业的程序员们的一封信

蒋さんへ
お返事遅れになっておりまして、本当に申し訳ございませんです。
第1：工作的重心在于沟通，软件开发的本质是沟通的技术。作为刚开始开发的新员工，一定要记得，有问题就问，而且要知道问问题的ルール、首先应该问身边的老员工，然后再问担当，最后向领导汇报，有效的将问题提出和解决，能够提高自己的工作效率和成果
第2：式样设计不是万能的，式样设计必然会有错误，在coding中间，要学会用质疑的眼光发现式样的问题，然后做好证据，去找式样确认，千万不要贪图自己一时爽快，把问题掩盖下去，等最后测试时发现问题的时候，问题就会变得不可收拾，当初只要花一个小时解决的，现在可能要花1天，1周
第3：coding的时候，要注意自己的式样里面是不是有共同的机能，这点，式样不会说明，但是自己要认识到，如果有共同的机能，就要抽出来写成共同函数，抽成共同函数能减低程序的耦合性，提高程序的结构，以后的再开发和改修都会有好处
第4：写程序的时候，请一定写注释，一个没有注释的程序就不是好程序，不要指望自己能永远记住自己的程序的含义，如果以后有其他人帮你对应bug的时候，你的注释就是他的引路灯，但是如果你没有注释，你的程序就是别人的恶梦
第5：所有的变量申明要在程序开始的地方写出来，变量的定义要符合规约，函数名也要，我在日本遇到过一个日本人写的帐票程序，因为没有式样书，所以我只能阅读程序，但是程序里面的函数名字是xxxx1,xxxxx2,xxxxx3这种样子的，导致的结果就是，一个4000行的程序，我看了整整3天，最后只能报告日本人，重写程序。如果是你遇到这种该死的source,你也一定会很不爽，所以，规约对自己和别人都有好处
第6:程序中经常出现bug的一个问题就是，数据的边界值，这也是测试中重点测试的问题。打个比方，前面一个程序，传一个[3，3]的数组给你，结果你在自己的程序里面，循环取每一个元素，取到了[3，4]这自然是会出错的，尤其在循环的条件判定上面，如果你是用到计算出来的判定值，那就更要小心计算的正确性
第7：程序中间经常出现bug的一个问题就是，数据类型的转换，比如在vb.net下面，有这么一段程序
dim x as integer = CINt(a) (其中a是前面传过来的string)
大家觉得这段程序怎么样？
其实有很大的问题，因为在a是空的情况下，这种条件转换就会抛出exception
所以正确的做法是
if (a = string.empty) then
x = 0 '具体赋什么值要看具体的式样
else then
x = Cint(a)
end
第8:checkin 和 checkout的时候，一定要小心，小心，再小心。一般不推荐，全体下新版本，很多时候服务器上面的版本不是稳定的，如果你下来之后，就会冲掉自己的环境。checkin的时候，如果发生冲突，千万，千万不要把人家的东西删掉，加上自己的东西，再上传。这是一种非常不负责的行为。
第9:做什么事情都最好在机器做个list，比如今天自己今天改了那几个配置文件，再source上面修改了几个case,这样如果以后有问题，可以按图索引，汇报进度的时候也好说清楚
第10：有时候工作的时候，会遇到老员工心情不好的时候，发脾气的时候，这个时候还是多体谅一下老员工吧。大家都是一个team，团结才能做好软件
以上です。よろしくお願いいたします。