程序员一个月做出来的东西和三个月做出来的东西有什么区别？

一个程序员，同样的东西，一个月做出来和三个月做出来到底有什么不同呢？底层架构不同、可预见未来支持的扩展不同、优化不同，可以这么说，从某个角度上说，是完全两种东西。

开发时间的常用评估方式

首先，评估开发时间的问题，两个常见的方式，第一种，会从底层程序员往上报自己需要的时间，经过主管、经理再到总监每一层都会多报出一个百分比的时间，以备用来解决不可预知的问题或bug，其实不预估时间的项目往往是最快的，程序员尽力去完成，但在有一定规模的项目组中却不可取，没有哪个老板或投资人会对没有时间规划的项目开发组充满信心。企业也不会任由程序员来规定时间。而报到老板那的时间也会直接被砍一刀，三分之一的时间被砍掉都算是少的。

第二种方式，如果是合同定制的，开发需求非常明确的，一般都会有一个明确的开发周期和时间节点，开发任务会“以终为始”的方式来开展，举个例子，六个月的工期，那么第六个月的时候交付产品，需求、设计、开发、测试各自匹配出相应的时间，在这个时间段内完成任务。只要对方不改需求，时间给的合理，这样反而简单了，一般情况下都可以保证deadline来之前上线交付。

开发时间被压缩的要求，往往来自于不懂行或者没有开发背景的老板，一方面是项目进度、企业进度这类客观性的要求，另一方面是怕程序员偷懒，工作不饱和，自己白付工资这种主观性的考虑，在他们的视角中，开发一套系统，三个月的时间成本和一个月的时间成本是一个简单的数学关系，所谓的高层，从来不会关心你短时间内开发的系统所遗留的问题，那是程序员应该解决的事，而这些问题实际上会像滚雪球一样一直堆积，最终在某个时间段内集中爆发出来，后果就是重写，而我刚好就遇到这么一起事件，项目进行半年后，那边的负责人告知我，他们的系统的架构已经无法再加任何的功能了，只能重写。

我们假定这个程序员的水平在中等偏上，不存在技术水平以及任何情绪的问题，一切都是按照比较公平的方式去比较，现在企业要做一套系统，需求明确度60-80%，为了简化模型复杂度，我们只要一名程序员，这名程序员负责系统的所有的任务，程序员报三个月的开发时间，如果这个时间被无端压缩至一个月，那三个月开发出来的系统和一个月开发出来的系统到底区别在哪呢？

架构不同，决定了对未来可扩展的支持的不同

系统做的可大可小，关键看给的时间，时间不够，即便有能力也会把系统做成小的、扩展性差，为什么呢？程序员都会选择当前环境下的最优解，和时间赛跑的项目最优解就是，快点上线。底层架构？领导又不关心你操哪门子心。未来可扩展性？表示不关心，只知道项目完不成会更糟糕。反正先让你看到个东西，管他底层是啥样子呢。

举个例子，你的系统是做一个学校的客户关系管理CRM，实现客户的录入、分配、跟进、报名的功能。假如老板或甲方压缩时间，给的时间不够怎么办，那只能做做表象的东西，一个客户表，一个跟进表，两者一对多关联，再加一个用户表和报名表，用户表和客户表一对多关联，客户表和报名表一对多关联，完工。项目做完啦，其它不管了，也没时间管，谁让你给的时间少呢？那上面这套系统哪还有问题呢？程序员报三个月，被老板压缩到一个月，老板是不是赚到了？

同样的东西，压缩时间做出来，老板真的是赚到了吗？

上面那套系统，程序员未来可预见的业务扩展，但由于被压缩了时间，所以底层架构是按照最快最简单的方式来实现的，那架构在哪会出问题呢？问题可大了，比如：1、对方需求没说支不支持多校区，整个数据库设计被设计成了一个校区，想要多校区？不支持的，你们没说，没这个概念。2、班级的问题，你们没提，我们也没给你们加，一个学员可以进几个班，一个班级可以安排多少课，是分开计课时？还是一起计课时，不管你上不上都会划去一节课。3、补课？缴费？退费？补款？没说啊，没说可不没有么？为什么我们不写啊，我们只写你们提的需求里的功能，谢谢。4、操作权限问题和数据权限问题，一个客户的市场收集人、销售分配的人、登记客户的人是三个人？不支持，按需求合同来。5、你还要统计跟进次数？什么，还按部门统计，你们重新提需求文档吧，先把第一阶段的给钱给结了。6、访问速度太慢啦？把服务器的性能调一下，多加点钱就好了，服务器费用从每月3000增加到每月9000。