在我最早开始写代码的时候，通常是理解了需求之后，大概找到修改的地方就开始写。因为是新人，需求简单，这样子干也不会出现太多问题。最多也就是代码不够简练，函数过长，问题不大。
工作了两三年后，需求开始越做越复杂，涉及的类，模块也逐渐的变多。我也就慢慢的学会了先看代码，大致心里有个数后才开始动手。如果只做需求的话，基本上也能应付得了了。
到了上家公司的后期，因为工作安排，我开始写框架了。其实看过的书中我也了解到，写代码之前要画图，要想清楚之后再开始写。可是我感觉心里只有一个模糊的想法，画图也是越画越糊涂。后来我索性按照上面的办法，大致想了想，也没有画图，直接开始写了。可能是由于有经验的关系，倒是让我给写出来了，也没出什么大问题。但是却在我心里留下了一个疑问：在写代码之前，究竟要不要做一个比较详细的设计？
到了现公司，有个新的小项目需要我一个人来负责。因为要做架构评审，我仔细的去学习了UML图的画法，收获颇丰。只是在学到画类图的时候，我按照以前的经验，想着其实画不太出，不画也没问题。因为架构评审只评项目架构，不评代码结构，也就没发现什么问题。然后我按照之前的经验，大致想了想就直接开干了。结果一路写下来，吃了不小的亏。有那么几次写着写着发现心中的设计满足不了需求，就只能现改，有时候工作量还并不小。经过这一项目，我终于懂得了代码设计和画图的重要性。
确实，在项目初期，由于需求不明确或者思维有限，设计可能会比较粗糙。但此时，我们也应当把代码设计图给画出来，有些问题可能在心中想不明白，但在画图的过程中就想明白了。我感觉画图就跟写文章一样，不仅仅是把想法表达出来，也是一个总结提炼的过程。同时图对于代码结构的表现也非常强，能够一目了然。画完之后再将需求代入，看所设计的结构是否满足现有需求和将来有计划的需求，再进行完善修改。当然画图也要分步骤，我的想法是由粗到细，首先考虑整体的大致架构是否合适，再考虑拆分设计具体类（类也没必要详细到每一个成员变量和方法，只要详细到这个类提供什么功能即可）。等一个真正完整的图画完之后，写代码其实就是对图的翻译了。就算发现有遗漏，因为大方向是没有错的，所以不会有伤筋动骨、劳神费力的大修改了。
想法是很好的，但是实际上很多程序员会有一个毛病，就是只喜欢埋头写代码，不喜欢设计和表述。画图？还是一个完整的框架图，类图？这可真要了老命了。是的，按照上面所说的来，其实画图是非常累的，因为要不断的思考是否合理，是否满足了需求，是否有扩展性等。但是这一步是免不了的，直接写代码其实是将设计这一步混入到了写代码之间，给思想增加了负担。因为写的时候也是不能停止思考的，用什么特性，用什么写法，函数怎么划分，这些具体详细的设计都是在写代码的时候要思考的，这时如果再混入代码架构的相关问题，脑子会顾不过来的。
以上是针对写框架的一点体会，将之记录下来，既是总结，也是希望自己能够记住不要嫌麻烦，要先设计，再动手。