对于生手来说，什么架构啊，谈架构等于玩死自己。
大家都没经验，自然也没有最佳实践可言，硬套 OOP，设计模式，活出不来还会给团队带来挫败感，最终严重拖慢进度。
自己也是这么过来的，记得自己真正意义上的第一个团队项目，是4个人，都是学生，1个美工，3个程序员，没有前端并且在程序刚开始做的时候，只有我略懂 HTML/CSS/JS。
很巧，这个项目也是个CSS，并且，因为某些原因，必须从头写起，不能用现成的代码改。项目期只有1个月，大家一周能聚在一起的时间，只有周末。一周下来，真正开发的时间，摊到每个程序员头上，最多10个小时。
美工很早就把设计图出来了，没人懂切图，于是纠结在切图究竟是美工学好呢，还是程序员学好呢。最终是我拉了一个“高手”，把图切了，按照切的图，我带着另一个程序员，硬着头皮把前端做完了。此时，逻辑代码数量为0。时间已经是第二周中了。
美工看没什么事情，就一个人去1000多公里外，见从来没见过的网友妹子了，据说，要去一周。
数据库的表，在项目开始之前，我就建好了，此时翻出来对着前端功能看，很多不能自圆其说。自己觉得应该讨论一下，于是第二周剩下的时间，就花在表结构上。事实证明，“更加完善”的表结构，引入了很多没有必要的“扩展性”。
第三周中，终于进入代码编写阶段。
项目用的ASP.NET，当时版本2.0，所谓的架构不过是一个微软MVP写的一套三层架构的系列文档，纯英文。后来回想，这个文档很有Magic Demo的感觉——告诉你，
ASP.NET+ADO.NET是个多么帅的框架，OOP，设计模式在双A框架里，是多么容易融合。
真做起来就完全不一样了，首先是怎么分工，3个程序员，我和A略强，B略弱，任务平均分给3个人自己回去写。到了第三周周末的时候合代码。
问题就来了。
虽然说事前约定好了代码规范，但是花括号到底是跟在签名后面呢还是重起一行没说过，a, b, c这种变量名虽然说了不要用，但是1个函数下来，到处都是ret strA, intB也不行啊。数据库的外键关系改了又改总发现还是不能随心所欲的删改数据，干脆就不要用外键了吧。又总觉得几个表功能差不多，是不是要继承一下？学习了什么叫做单表继承，多表继承。拿回来发现ADO.NET没法这么玩。Google了一圈，发现ADO.NET其实是可以这么玩的，只不过你要实现N个接口，M个抽象类，还得在程序初始化的时候做1，2，3，4，5件事情。三层架构，处在中间的业务逻辑层，似乎完全没用处。
所有的所有，折腾到交工的1个月的最后一天，手写代码虽有近3000行，网站可用性依然是0。
最惨的是，我自己发现，“标准” HTML/CSS/JS，套到ASP.NET上，几乎是没法用的，
因为奇葩的ASP.NET，居然会在运行时，动态改变前端元素的ID。如果要用微软推荐的套用设计的方案，又要新学一大堆东西。
在第六周快结束的时候，3个程序员都泄气了，没人觉得再给1个月的时间，这网站可以完工。美工同学见光死回来了1个多月没见人，我们也不好意思去找他。很多前端要改的图，就让程序不是很强的程序员C代劳了。我美其名曰研究架构，没有1秒钟不想把整个程序推翻了重新来一遍。B也迷茫了，虽然陆续完成了用户、权限、发文的功能，但是怎么都觉得不对味道。
然后就没有然后了，一共花了2个月时间的代码，最终烂在我电脑里一直到现在。项目最后用Wordpress交工，当时说坚决不能用现成代码的甲方，什么也没说。
--------------------------------------------------------------------------------------------------------------------------
直到今天，如果让我问自己怎么做程序架构设计，我想只有1个答案，在你完成了解自己要做什么，对要做的东西，至少每个部分实现过2次以上，再去谈架构，谈优化。未知项目，探索性要求高的项目，只谈实现。