架构漫谈读后感

　　对于一开始的软件人员，如我们这些大学生，严格意义上还算不上什么软件人员，接触到更深层次的东西时都是会有一个认知进步的过程的，比如架构这样的问题，我们对此真的是没什么主观意义上的理解。对于我们而已，最多的也就是跟着老师做做项目罢了，真正的项目对于自己来说还是别人让你怎么做你就怎么做，还处于最底层的软件人员的阶层，码农大概就是这么一种吧，别人告诉自己该怎么做或者别人也这么做，我们就这么着吧。这种真的是没有什么提升的，你能做的就局限在你当下所做的东西，真正涉及深层的东西你什么都不了解的话，那你和咸鱼又有什么区别？

　　软件架构大概就是处于更高层次的一些东西了，起码系统给了你，你知道该怎么去分解吧，当然这也仅仅是一点东西罢了。架构总是会和建筑一起拿出来比较，对于结构的划分可以说软件和建筑确实有很多相似的地方，比如哪个部分负责什么不正是像各个房间爱有各个的作用，厨房的话，说出来就会知道他是干什么的，而一个软件那也是应该有明确的结构才是，否则非常不适合进一步的扩展和迭代，因为很乱的东西是很不适合一个团队去合作完成。就像是缠在一起的乱线团一样，交给一堆人去解开的话那真是糟透了，你一下我一下能解开才怪了。但是结构清晰时也就更好的能让人理解，让人明白分工的话就知道需要做的是哪个部分了。感觉读了别人的一些言论真的是不可能能怎么样，这只能让你知道更多的概念，但是你不一定能有什么实际意义上的理解，我感觉也就是照搬呗，别人说的大概是正确的吧。软件架构就是在了解用户需求的基础上来挖掘需求，最后生成软件的详细设计说明书，然后不只是文档，还要告诉团队里的人员他该怎么做才是最终要做的事。Kevin说软件是对现实生活的模拟，这么说也确实挺相似得，做软件的考虑的东西可真不只是你要做成什么样，应该有什么样的功能那么简单，你所做的还有各种的潜在的东西，比如说对于用户的习惯进行的设计，那恰恰就是一种模拟的体现，你所做的东西，只有顺了用户的意愿了，并且超出了那样才会惊艳了他们，让他们接受我们的产品，这不就是软件行业所追求的东西了。

　　当然，也不是说读些东西时不行的，只是实际要做的东西还有很多的，架构师对于语言啊软件啊，没什么更加严格的要求，懂得的话，能更快地找到是谁的问题，听起来确实是很简单的东西，但是，有一点还是不可否认的，基础永远是不可或缺的。框架已经很容易理解了，就是为了规划一个软件呗，让原本的一堆源代码变成一块一块的，可以切分开的。一直以来我都以为什么主流的框架什么的，就是别人都这么用呢。现在了解到，尽管房子大多都是意识中的样子，但是也分无数中的样式，这大概就是和软件的架构类似，框架只是为了划分简单吧，所以没什么框架是可以学了就可以一劳永逸的。这么说和语言就有点不一样了，尽管有很多的高级语言但是主流那几种，学好了的话，你都可以有不错的出路，架构的话，真正的出师的话，大概是到自己能架起来属于自己的架构吧，这和建筑师第一次完全自主去设计似的，听起来还是很不错的。软件这一行业好似出路很多，但是总的来说也就那么些东西，你所能做的并不多，在自己不牛之前，那就虚下心来好好地听别人的，学别人的，然后到最后有了你自己的，那也是算能出师的了，对于此我只想说，能做的还是有很多的，就看你有没有这个决心和耐心了。