写一篇软文——现在程序猿的现状

在昨天下午公司组织一场关于设计的讲座，受益非凡，所以写一下感触与大家共同分享一下

首先是设计：

可能与世隔绝，个人认知的设计和讲师认知截然不同，不知道有多少同学和我一样，认为设计和程序员没有一点关系，所有的设计都是产品和UI的事情，为什么和程序员有关系呢？

这个想法是错误的！！！ 这个想法是错误的！ 这个想法是错误的！！！

开发软体的时候首先要准备：

1.资讯，兵马未动粮草先行，为什么这么说呢，首先开发之前要了解做什么，要详细清楚的了解清楚，等做到一半的时候才发现自己的所认知的东西是错误的，那么恭喜你，你在前面做的内容都是错误的，都是无用功，白费时间。在接别人代码的时候，尤为重要，你要了解别人做这个的背景，拿过来就做肯定是有问题的，如果改了半天了才发现自己做错了，那就更麻烦了。

2.逻辑，三军统帅，要想打胜仗，将军尤为重要，要想编程编的好，逻辑很重要，有的人认为不应该是框架吗？如果逻辑自己都不能将自己说服，如何编程，所以在编程之前要想好要做的逻辑，究竟是怎么样的逻辑。

3.框架，韩信点兵，为什么说韩信点兵呢，在现在的互联网中，各种框架，多不胜数，不能都用，也不能不用，毕竟可以节省开发时间的，所以你需要将你所中意的一部分框架下载下来进行对比，对比的要求首先要适合自己所做的需求，比如你要做一个视频的框架，结果选了一个音频的框架，就算这个音频的框架再好，对项目没有任何帮助。第二点，真的需要认真对比，有点人看到一个需求，立马去gitHub上搜索一个，立刻用到项目中，这个样对吗？也对，但是如果后期这个框架不支持或者可扩展性不是特别好或者这个框架适合你所做需求的一部分，另一部分不是很适应，那么你做到后期的时候，有两个选择一个是换一个框架，前面工作白费，要不就在加入一个框架。后一种选择会将项目不断变大，后期优化比较困难。

现在软体开发主要问题有以下几点：

1.工期短，压力大

2.看中眼下利益，低估长远利益

3.主管不了解程序员开发的进度以及真实的工期

以上三点会出现的问题有：

1.为了赶时间，也不做任何准备，做到哪里就是哪里，至于后期问题到后期再说

2.功能会出现很bug，在新功能进入排期之后，就不管这些bug了，做新的功能

3.后期代码越来越复杂，后期bug越来越多，debug越来越不稳定

4.主管不了解具体情况，总觉得速度挺快的，做的也挺好的。

5.浪费时间，成本提高，本来修改bug只用一个月或者更短的时间就可以做好了，产品上线，但是后期发现bug一个接一个，修好一个bug引发了三四个bug，最终导致产品未能及时上线

6.最终效果不如预期，预期效果很好，但是产品真是上线之后会有各种奇怪的bug等，导致产品非常不如意

其实解决上述问题有两个秘诀：

1.做好前期的准备，缩短开发周期的秘诀在于准备阶段，准备阶段准备越充足，后期开发效率就会越高。

2.正确的估计时间，主管一般想听到真实的开发情况，开发要做一个好的程序是需要时间，每个技术主管都有这方面的经验，你给主管说的时间很短，但是开发的代码很烂，会降低你在主管心目中的地位，比如以下两位，你觉得更适合哪个职位呢，我个人比较倾向于真正的产品公司，不太喜欢外包公司。如果时间太短，就将实情说给主管听，要不去不断的迭代更新加功能，要不就延期拖延工期，程序员要对自己开发的程序负责。

如何正确估计时间呢？

请不要过分乐观估计也请不要义和团式估计，这两种估计都是不正确的。

如何正确的估计时间呢？

有一个工作要40个小时，每天工作8小时，那么你得出的时间是5天，但是你实际上每天不可能工作八小时，这八个小时中包括了你休息，喝水，开会等，所以你最少要加入一天半的时间。

到底要怎么做才好呢？

1.设计出来的东西可以满足需求，过多过少都不好，越简单越好，不要复杂化

2.设计出来的东西一定会有漏洞，请别人帮你看或者将思路讲给别人，最少有三个人给你建议

3.思考自己设计出来的东西有没有比这个更好的。

4.一定要写文件，写为什么要这么设计，这样设计解决的了什么问题，优缺点，这个文件并不是越多越好，是明白越好

5.学会沟通，沟通是一个非常重要的交流手段，如果你不会沟通是一个非常麻烦的事情

6.完整度是一个非常重要的事情，不是每个模块都做一点是好的，认真完成一个模块才是最好的，在固定工期的情况下，你完不成自己的所有模块，主管会调节人力资源，新来的人需要在你代码上写好还是自己单独开发这个模块好。

7.并不是最新的技术就是最好，某个技术只有稳定后才要考虑融入自己的项目中，加入这个技术才出来一年，就着急的融入自己的系统中，第二年不在更新了，那么这技术在自己的项目中就是一个鸡肋，更或者是一个毒瘤。

完成一个优秀的软体：需要品质、稳定度。

所以在这希望所有的程序员在开发模块之前都可以进行设计，开发出最优秀的软体，称为优质的程序员