工作效率有点低。。。
大部分时间都不是在编码，看书，都用在配置环境，编译程序上了。
尤其现在项目收尾阶段--> 发现bug，需求变更--> 源程序的改动并不大，
但重新打包程序，安装运行，跟踪测试，要大块时间。
中间零零碎碎的时间，没法系统学习，就只能找些小文章东看一点，西看一点，觉得太乱了，没什么效率。
大家碰到过这种情况吗？有什么好办法？
[解决办法]
在软件工程里，编码不是最重要的。
把需求做好，项目成功了一半。
设计和测试的时间都要比编码的时间多。
[解决办法]
自动化做得不好。
另外零零碎碎的时间就不能系统学习了？
[解决办法]
UP
[解决办法]
好的办法 .......
还能有什么好的办法，
赶工....
[解决办法]
前期的设计工作要做好。做细。 做准
[解决办法]
刚出来工作，主要的任务就应该是学习如何将想法转化成好的代码吧？
以前在学校编码太少了，我目前的计划也是在这方面多锻炼下
至于设计，测试
设计不太清楚，不过似乎文档花的时间也不少?
测试有些工作就是体力劳动，徒劳的等待结果
设计一个测试用例用了 10 分钟，但是测试要半个小时，1个小时。
但是在测试的时候，因为心悬在这，自己想趁空学点别的什么，太系统的东西没法看，太零散的东西学起来又觉得没效率，所以想问问大家，这些零碎时间都怎么利用的？
------------
虽然小弟编程时间并不长，但还是有所感触的。
其实优秀的程序或系统，它的需求就做的很好，设计更是没的说
编码，只是将需求用代码的形式表达出来而已
还有不要沉迷与代码的技巧上，好比练武功一样，能用普通招式解决的绝对不用降龙十八掌
因为用了那些所谓的高级功夫回降低一些体力或者说是内力。
在编程上，过多的使用花哨的技巧，最后只能以运行效率的低下做代价。
只要前期的设计很完美，中间的编码几乎不费太大的力气
最重要的阶段是测试
个人编程时代，往往自己一个人测试一下就行了，或者在自己机器上能运行就可以了。
但是这样很多问题是隐藏的，不追根究底是找不到它的，
现代的测试都是很严格并且用很长的时间来测试。
个人认为整个软件的生命周期里，
需求分析，设计，测试占很长的时间
[解决办法]
都是从一部分一部分慢慢扩展开来的
先把一部分做好
[解决办法]
哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
充满理想的孩子们
羡慕啊。。。。。。。
[解决办法]
编码就是最好的设计
[解决办法]
调试的时候，多积累经验，自己总结一下什么的程序风格有利于后期修改调试
