标签：end 隐藏 习惯 恢复 编译器 builder 分析 项目经理 自己的
本人所在的工作性质，通俗的讲，叫“IT外包”，工作经历上即是所谓的“项目”。本人技术水平并不高，并且经历的项目目前也不多，但还是想把在包括实习期在内的的入职两年的时间里的一些经验分享给刚入场的技术新人们。如果在经验丰富的前辈们面前班门弄斧了还请见谅！
一. 电脑软件配置与基本技能
0. 这是最基础的，作为一个开发人员，请将电脑系统的隐藏文件后缀名关掉。
1. 所涉及语言的代码编辑器（编译器），并且熟悉其各种快捷键。像“撤销”、“查找”、“替换”这类快捷键，事实上无论是不是打代码的小伙伴，在使用相应的编辑器时，都是很基本的东西了，不熟练掌握都不好意思说自己是一个IT人。另外，像一些比较傲娇的开发工具，比如form builder这种既要编辑程序单元又要配置各种属性还得兼顾各种触发器代码的，如果不知道怎么查找代码，想知道某个功能是哪段代码实现的时候，是无助得想撞墙的。
2. 常用软件配置。
A. 远程命令工具 securitClient，Xshell等
B. 文件传输工具 fileZilla等
C. 文件搜索工具 everything等
D. 比较好用的通用编辑器 sublime，notepad等
C. 多款浏览器（WEB开发相关） 流氓IE就不说了，谷歌和火狐建议还是装上
3. 如果会接触到linux服务器，linux命令是必不可少的，如果像网上的linux教程、鸟哥的linux私房菜、Shell脚本学习指南这些懒得看的话，以下这些最最基础的linux命令请稍微记一下：
A. ls 显示当前目录的内容
B. cd [your directory] 进入你要进入的目录
C. pwd 显示当前目录
D. mkdir [your directory] 创建目录
E. touch [your directory] 创建文件
F. history 查看历史执行过的linux命令
G. mv [source file] [target file] 移动文件（也可用于重命名）
H. 像rm这种可能导致跑路事件的命令我就不多说了
I. 上述命令，如果你是个linux小白，使用之前请先跟谷歌或度娘打声招呼
4. 学会如何解决问题
这一点说的有些虚，毕竟并没有解决问题的万能方法。但是你需要有思路，基于能够更好地成长的原则，首先是自己先思考，如果实在想不出，求助谷歌和度娘，这个年代，如果不会使用搜索引擎去查找解决问题的方法，耐克的“just do IT”这句广告白费了。最终的最终，当真的无法找到答案或解决方法时，向有经验的人求助。
5. 学会问问题
二. 项目了解
1. 项目成员
A. 项目经理
B. 技术总监
C. 技术负责人
D. 其他顾问，包括你自己在内的业务顾问与技术顾问
E. 客户
2. 项目进展
项目什么时候开始什么时候结束，你进场项目时项目处于什么阶段，这些最好都了解，即使是新人，也是项目组的一份子，时刻了解项目的进展情况，对自己为项目更好地付出是有帮助的。
三. 注意事项
1. 码过留痕
无论何时何地，只要你动了代码，无论动的是什么年代的你自己的还是老前辈的还是其他新人的代码，一定一定留注释
此处的注释包括，一般包括两点：
A. 修改时的信息，包括修改者、修改时间
B. 修改时的目的
C. 此处再乱入第三点：如果你是修改或者删除一段代码，请不要删除掉原来的代码，正确的做法是：
注释掉原来的代码，如果是修改，就紧接着编写修改后的代码
举例如下：
目前有一个代码（假设语言是java）段如下：
x = 1
因为需求A，需要修改为x = 0，可以如此修改
// updated by XXX@yyyy-mm-dd begin
// 因需求A需要调整x的赋值
/*x = 1*/
x = 0
// updated by XXX@yyyy-mm-dd end
如果的的确确确确实实实实在在是时间很紧，至少标上修改者或者修改日期，至少自己或者其他后来者看的时候，能够知道这段代码曾经改过。
请相信我，相比于之后自己忘记或者其他同事找不到代码修改过的地方的代价，以及被打断后恢复思路所耽误的时间，打上个名字或者日期的时间真的微不足道。
2.邮件是甩锅的唯一标准
这里并不是指拿邮件来推卸责任，更不是说有了一封邮件你就可以不顾后果地按邮件说的做并且最后能够理直气壮地争辩。邮件的作用是：
A. 记录
比如，业务顾问请你帮忙部署代码，如果只是口头说一声，可能一个星期之后大家都忘了当时有没有部署了，有邮件的情况下，事情会变得很清晰
B. 明确责任范围，排除模棱两可的争议
一件事情，怎么做，由谁来做，最后要达到的结果是什么，事情的截止时间等等，如果没有邮件，在工作效率以及交付质量上都是很难把控的
3. 把生产环境当成刚出生的宝宝重点呵护和保护
A. 不要轻易动代码
B. 不要轻易动数据
C. 如果真要动代码或者动数据，请先回顾一下“甩锅的唯一标准”
4. 养成良好的代码规范习惯
5. 如果想说什么，就说出来，不要憋在心里。（向女生表白这种事情请自己把握）
在项目上，如果觉得方案设计有问题，或者某段代码会导致不可逆的风险时，一定一定提出来让别人听到，不要拖到悲剧发生。
如果真的是代码或者方案有问题，就能够及时避免不必要的损失。
如果是你自己想错了，没关系，大家一块讨论一块分析，确定方案或者代码没有问题就好了，不会多一块肉少一块肉。
如果没有说出来，最后真的悲剧发生了，后悔也来不及了。
时间有点晚了，今天写到这里，后续继续完善，希望目前的可以帮助到大家。
标签：end 隐藏 习惯 恢复 编译器 builder 分析 项目经理 自己的
原文地址：http://www.cnblogs.com/distanceN/p/7104834.html
