周年回顾，小程序员的自我修养。
<入职>
完成了达内毕业项目设计后毕业，毕业后工作并没有那么好找，遭遇很多次团面，四处碰壁，因牙套，笔试和学历就被刷下来。
一家公司很魄力的问我现在有个三十多万的工程让我另外一个人一起开发，问我有没有能力接下这个工程，我一下子懵了，“该死我在犹豫些什么”，
我说可能需要学习，大工程可能做不好，沉默了一会之后他对我说你先回去，我打电话叫你。（没希望的预感）内心无比忐忑。我感觉自己好差劲。
有一家公司面谈问我如果界面显示飞机票只剩一张，有2个用户同时购买，该怎么办？我回答：锁定一个机票，给先购买的用户飞机票，
给后购买的用户提示购买无效的信息。他们摇摇头说这不是很好的用户体验，解决方案在我后面的黑板上。
我没有看后面的黑板，沉默的思考了一下他们让我离开，我很后悔自己当时没有扭头看黑板，我到现在也不明白解决方案。
当时我还萌生过希望那些没有招聘我入职的企业后悔的中二病想法。现在回想起来，自己还真是可爱。
刚入职的时候，公司给了上一个项目让我维护。一个50多个类几万行的代码，连一个文档也没有，
这个项目公司打算让前任几天后即将离职的前辈来培训我。前辈只对我说:“从Main函数入口开始看。”
我以为我自己是个苦命的人，当我在自己的群里抱怨的时候，不少同学反应遭遇过同样的事情。
所以在公司碰到一个肯愿意带人的前辈分享经验是一件很幸福的事。
基本上在公司大部分的事情得自己解决:但如果自己解决不了。
-1：一些简单的调错，跑不通，:不要请教别人了，那样只会加重别人的工作，增加反感而已。
0：必备开发手册和官方文档。
1：用搜索引擎找自己不能解决的问题，你遇到的问题，别人基本都遇到了（感谢那些博主分享自己经验）
学习他的思路和所用的api和扩大自己知识，当看到代码很精巧的地方，忍不住赞叹写的很棒。
2:找同行求助，他们给你的意见都有参考价值。不妨请几个同行一起吃饭，抱怨几个问题，也许会有意外收获。
有一次任务是解决条形扫描枪扫描时过于灵敏的问题，我希望能从软件方面解决问题。
但是我完全不知道有任何方案解决，我去问好几个同事，有没有知道扫描枪api的
直到去问做net开发的同事，他告诉我很重要的信息；扫描枪在windown下是有开发标准的。
扫描枪在不管任何语言开发的图形化界面遇到文本框会以键盘形式输出号码回车符结尾。
3：有丰富的代码来源，有关注的博客，有关注的开发社区，官方提供的sdk，有已证明的开源工程解决方案
4：解决不了的问题或者没有开发过，要早点把问题上报上级。避免资源浪费。
5：学会阅读审阅源代码，不要拿别人的代码就用，这不仅仅是职业道德的问题。
有些时候文档并不完备，有时甚至是错误的，而源代码从不说谎。对于一个有经验的开发者，
阅读源代码的速度通常会更快……特别是当你已经对包的结构很熟悉 时
在我的机器上运行，就是我的软件，我会对它负责，我必须弄懂它；从源代码创建是规则而不是例外；我必须控制我的环境，我必须控制我的依赖。
在毕业前让我接手维护一个工程，我都表态想要拒绝，TM不如把思路和需求告诉我，我重写一份代码。
这表示我对阅读代码。特别是别人的代码有多么厌恶了。现在已经很平淡了。
但我们需要查看源代码。我们必须阅读他人的代码，因为要完成工作，我们必须先弄懂它。
如果我没有阅读公司的第一个产品，我现在很大一部分对细节和框架仍然很模糊。
阅读源码的好处是可以让你设计一个完整的产品并掌控它。
6：积累 模仿 与交流。
平时多积累 ,模仿，交流,才是正道。基本功扎实才是正道。
成长源于模仿，所以想要快速做项目，不如模仿一些已经完善的成品。
积累：
看一些教学视频，源代码，API，编程书籍都可以。
将知识融为已用，封装类，或写成博客。你得知识写成博客你不会忘记。但是你没有写过总结你一定会忘记。
把好的经过验证的框架提取成引擎以便服用,把好的算法保存起来。以后你遇到相同的项目，
只需要半天的时间完成，剩下的时候可以悠闲的喝下午茶。
交流:没有交流视野会太狭隘。不妨问问同行最近在做什么。
< 定位自己团队角色--升华>
毕业前也曾雄心壮志：我设计的程序不会有BUG。但事实上任何程序都会有BUG。只是还没有被发现。
那是从进公司开发第一个产品，失败以后，产品中遍布小BUG，与其说产品不如说像学校里的作品。。
我非常沮丧，因为我非常努力，却越维护越累，怀疑过自己的编程能力，我像检查自己的程序BUG一样，
思考是什么环节出现了问题，我怎么会变成这样子。
回想老师跟我们说过刚进公司不要想着给企业创造利益是有道理的。
我阅读开发文档能力太初级，编写文档基本太弱了，没有开发计划，软件测试知识零。商业模式和产品体验设计从未考虑。
我去学习软件工程管理学，和阅读了软件测试艺术。大大开放我的视野。
找到了问题的原因：由于没有大型项目开发经验，我用迭代增量的方式编写软件。所以当项目完工的时候，BUG全面爆发，身心俱疲。
软件工程管理学，让我大彻大悟，我明白了很多道理，这是编程以外收获。尽管是纯理论。
我已经历经了失败的时间，但是理论与实践相结合。我懂得如何用理论规避损失了。
<主见-学会拒绝>
我开始学会拒绝，正视曾经只要有需求就开发的自己，
拒绝一些没有价值意义，没有商业模式的产品设计。
那不仅不会带来收益，而且将来产品下架也是一件很麻烦的事，
在提出需求的时候，尽早提出疑问。
要知道一个看似简单的需求，背后是一个程序员夜以继日的工作。
产品的收益不仅仅是软件功能，界面，按钮体验都是软件成功的一部分，作为团队的一份子
像菜单键出现在左边，对于这种不合理的设计你完全有理由说"这不对"；
<别给自己订太高的要求>
比如一个小功能需要1天能做完，你千万别说你一天能做完。
因为在做这个小功能评估的一天是你能力最巅峰时的评估。如果你中间因某事拖延了时间，或者编写代码出现了BUG，几个小时才搞定。你得承诺就很难实现。
程序是需要测试的，余下一天先自测试一下程序，把程序提交给专职的的软件测试员。
事情还没有结束,你会祈祷软件不会有任何的BUG，
软件测试员会几次叫你过来给你看检测到的BUG，这个阶段是相信大部分程序员最痛苦的阶段。
经过严格测试，程序才成为商业级的产品。
所以遇到需求，设定产品的开发周期=自己预计无阻碍一般开发速度*（2~3)
< 软件测试的思想包装自己-缜密>
为什么我要提软件测试呢？软件测试不在于工具，而在于思想。但你学会了软件测试思想，无论让你测试一个软件工程还是一个微波炉，甚至一架飞机。唯一的不同是测试工具的变化
从软件测试的角度来看需求文档你会发现很多，很多不合理的地方。
需求工程过程中,即使不起眼的缺陷,若未察觉并加以纠正和修复,
都将会随着开发活动的进行而形成滚雪球似的扩大蔓延,轻则造成纠正错误的代价急剧上升而损失巨大,
缺陷越早发现,修改缺陷所导致的错误所需的开销越小。
比如软件在内存不够或者在网络很差的情况，这些情况需要考虑好。
但是文档没有提出内存不足或者网络很差的情况如何应对。
如果你中途加入针对内存不足或者网络很差的机制，很可能会给应用加入一些新BUG。
代码变得臃肿，框架也得调整修改，为此加班。
所以你必须考虑那些不安定因素，向部门提出完善这个需求。甚至可以为软件测试员代笔写出测试范围和用例。
<编写小Demo测试封装>
尽量把功能的耦合性降低，写一些小的Demo并且测验后粘贴到工程中。复制的流程，把日志也完善打印，我曾经无意识的把thread.start()写成thread.run()。
如C：
虽然代码运行正常结果也正常，但是我发现处理结果总是顺序执行这和多线程相反。
如果这段代码我没有经过流程的测试而直接粘贴到到项目中，将来的错误就会匪夷所思。
C:
new Thread(){
@Override
public void run() {
for(int i=0;i<4;i++)
{
new MyThread(i).run();
//new MyThread(i).start();
}
}
}.start();
<整理并封装已经使用过的代码>
我注释掉代码写了些新代码来测试一个功能。后来很混沌，哪些是有用的代码我写过的垃圾代码呢？
为什么我要遗留这些没用的代码，我删除注释的代码。保证整洁和观赏性。
好多工程因为长时间没有整理，已经理解不能了。
我开始整合，有意义的可重用的代码部分写成工具类来开发，
为某一种经常用的应用写框架。
以便自己能够快速套用框架来开发。
新需求：套用框架，功能套用工具类，完成。
我曾经写完代码后补文档，但现在我明白学会写文档，画图
如何利用文档的设计快速开发稳定健壮的代码。比如我先把程序的思路全部以文字的思想写下来，形成伪代码。
然后把它们分类成类，然后设计成那些接口哪些监听，可以用哪些设计模式？
然后设置那些类里面应该有哪些方法，回调什么样的参数，
我不写每个类的方法的具体实现，我给每个方法都写上了注释。
每个参数写上注释。这样可以团队完成。即时思路断了，也能用填空题的方式完成。
现在BOSS问我项目还需要多久完成。
我只需要回答我已完成项目的 完成类/全部类实现*100% 就可以了。
/**
*
* @param userId -用户id
* @param ssid -条形码id
* @param mac -设备编号
* @param wifiLevel -wifi强度
* @param bTypeId -协议13
* @param activityId -默认值0"
* @return Vector<QiandaoInformation> -返回签到信息数组
* @throws IOException
* @throws Exception
* @功能：获取签到信息数组
*/
public static Vector<QiandaoInformation> andleMobile(int userId,
String ssid, String mac, String wifiLevel, String bTypeId, String activityId) throws IOException,
Exception {
}
<成为好程序员的追求：代码是给人看的 >
在学校里我一直喜欢写功能，每当我完成一个功能，我就非常兴奋，但是我回头再看过去的自己。
过去我总是专注于实现，回去看自己的代码，天哪，为什么我看不懂了，我压根就没有考虑自己看自己的代码。
这样对吗？我在阅读其他人的源码时，我看到了很多规范工整的代码，很多代码通过封装和多态，最终形成很多子类。
许多类中将方法都用switch来归类，代码非常简洁工整，我需要的功能，一眼就能从代码里找不出来了。
我希望自己的代码也能这样，
这种想法开始指导我的工作，代码写出来是给人看的。
把代码上传到网络分享到社区，我渐渐感到自豪感，不再感到寂寞
<包容--不要抱怨>
我曾经非常抱怨自己的团队，为什么需求一直再变，为什么没有人我给我做测试。抱怨为什么团队不完美。
为什么没人监督项目进度，为什么我一直在等别人。
我曾经向美工一页一页的图片，美工误解她已经给我图片了，她很生气的说:"我都已经给过你了。"
这样的事情已经发生很多次了，我怨气已经上升到到极点。
为了避免这种情况，最后我觉得自己方式不对，先道歉了，重新要了图片。
以后我就用替代图片，然后每次告诉她，你什么时候把图片都做完了给我，然后给我就可以了。
同事总是写出BUG程序，我们也明白写程序一定会有BUG，关键不只是程序员的能力问题。
我们加强了团队管理，强化了测试。追求敏捷开发。
我们的需求总是再变，我们开始反驳那些无意义的需求。
出现BUG，也能追踪BUG找到问题。包容磨合团队，用自己的力量改变团队。