分页

之前写php的时候，感觉分页有点复杂，没有搞过，结果现在天天见。。。

结果很简单

其实想想分页有什么就知道需要什么了

• 当前多少条——每页页数——pageNum
• 总共多少页——可以说是总页数，也可以是总条数（一般是后者）——total
• 每页数据是哪些？——排序，以及起始位置，或者结束位置——left，start，ORDER BY

没了

从表层看过去就这么些

然后就是具体实现，代码不想写，其实就是控制入参。

算好页数，做好排序，算好每页的起点，然后对应的发起请求就行了

高端一点呢？sql怎么写

书 《高性能Mysql》6.7.5一节中，对LIMIT分页的优化有具体的描述，写的还是很令人信服的，尤其是对大分页还是有效果的

软件架构师需要什么

先说正确的废话：广度+深度

将废话翻译的亲娘都不认识：

• 广度：包括知识见识层面的广度，也就是优秀的英文能力，良好的表达能力，优秀的沟通能力，优秀的技术功底，对各种技术的了解，保持对技术的热情，甚至，对生活的热情；
• 深度：技术上的深度，对业务的了解深度，对团队的了解程度，对圈子环境的了解程度等；

难么，难，万里无一的难

想当么？想

再引用一些文章吧，知乎的回答些，谢谢了

一

Daniel Mohl是一名专业的软件工程师/架构师，他的兴趣包括理解各种复杂的编程语言、企业应用架构以及如何搭建业务与技术，他通晓F#、C#、CoffeeScript、JavaScript、Erlang、ASP.NET、MVC、WPF、WCF、Sliverlight、SQL Server等技术。有着多年的软件开发经验。

他经常会被一些有潜力和有前途的程序员问到：“我要怎么做才能成为一名架构师？”说实话，这已经是老生常谈的话题了，答案当然是视情况而定。不过他也根据自己的经验，给大家一些建议，并且提供一些资料，助你快速走上架构师这条道路。

下面是Daniel Mohl所提出的列表，供大家参考：

首先，你必须不断地寻求改善和提升自己。而提升自己的最好方法是阅读，下面有几本书，对我的软件架构技能的提升很大。推荐给大家：

软件架构师应该知道的97件事
企业应用架构模式
敏捷软件开发，原则，模式和实践
企业集成模式
JavaScript语言精髓
利用遗留代码有效地工作
领域驱动设计
企业架构策略
设计模式（四人帮）
The Goal
SOA设计模式
SOA Principles of Service Design
除了阅读，还有没有其他需要注意的、或者在平时需要关注的东西呢？

每隔一两年学习一门新语言，F#是个不错的选择。
选择一个重点领域，但是尽可能对许多技术有个高层次的理解
对你所关注的重点领域，开通一个博客并且继续拓展该领域的知识面，让自己渐渐成为一名专家。
与不同的技术、编程语言、设计模式和结构等（甚至是它并没有在日常中给予你直接的帮助）打交道。你永远都不知道这些知识是否会在未来派上用场，但是对你绝对是有益无害。
根据你的目标受众来谈论“语言”。作为一名架构师，你将会与各种各样等级的人打交道，并且他们对技术的理解也会有所不同。所以要学会调整你的讲解方式，做到因人制宜，让他们能够理解。
阅读博客、观看/参加Twitter或G+、听播客、读杂志、参加用户小组会议和技术会议，并且在这些会议上踊跃发言。这些都会给你带来无穷无尽的知识和乐趣，建立自己的“品牌”和提供交流机会。
纪律是关键。永远做你自己最喜欢的工作，即使它听起来不那么有趣。每天安排时间学习一些新的东西，即使是15分钟也可，千万不要被其他事情占用了这段时间。
开启博客之旅。我发现，与阅读比起来，把东西写下来会让你有更深入的理解。
利用好“闲暇时间”，这段时间可以拿本杂志读读，或者去听听播客等。
了解各种可用的开发工具，可以使架构师的工作更好、更有效
看许多不同项目里的架构
学习各个项目的管理方法
学习一些评估技术，对业务可以提供有价值的评估
上面是作者总结出来的列表，虽然看起来有点枯燥无味，但在整个软件开发过程中是乐趣无穷的。如果你还有更好的建议，欢迎与我们分享

二

1. 多看书1.1 设计模式，重构，这两本让我能从程序员的视野往外走一点1.2 企业应用架构模式，领域驱动设计，比设计模式深一点，解决的也是更实际的问题1.3 人件、人月神话、梦断代码，理解一下软件工程为啥会失败2. 多看文章2.1 QCon 的就不错，有很多架构相关的PPT，拿着一个 PPT，等对方讲完问题之后，自己想想，自己的解决方案是什么？2.2 多看看各个企业的架构变化史2.3 多看看基础组件的设计思路，比如 MySQL, Memcache, nginx, ...3. 多做3.1 做点算法题，不是为了练习算法，而是为了让你思考更细致，毕竟少考虑一个点，肯定就无法 AC3.2 对于不同组件，自己去测试，上压力，真实测量容量。压死为止，看瓶颈究竟在哪儿？3.3 到线上去，看一看你的系统，哪些响应慢，不稳定。哪些资源消耗狠，需要优化或者扩容。还有多找人聊天，说出你的想法，等别人反驳，从别人的反驳中吸取知识，再去做验证。

作者：李道兵
链接：https://www.zhihu.com/question/27607979/answer/37312934
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

三

作者：William Wu
链接：https://www.zhihu.com/question/36658435/answer/68798316
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1：码农分为真的能写代码的，以及自认为能写代码的。2：真的能写代码的码农又分为自认为写的不错的，以及真的还不错的。3：真的能写不错代码的码农又分为会钻研会不断优化的，以及安于现状的。4：会钻研的码农又分为喜欢广度了解新技术蜻蜓点水的，以及深入钻研用到知识的。 了解广度的码农又有少部分愿意深入某些技术，喜欢深入研究的又往往缺乏广度知识。5：极少深度广度都关注的码农又分为为技术而技术和为业务而技术的。 纯为技术而技术的码农在国内的软件行业需求太少，且需求的往往不是应用软件领域了。6：为业务而技术的深度广度都了解的码农，又需要有良好的沟通能力。7：而沟通好的，又有一部分当PM去了。8：然后剩下的，又有一部分慢慢脱离实际开发（不再做任何实现）或者开始依靠拿各种中间件搭积木来作为“架构”手段。9：除去这些，剩下对业务有一定了解，对技术广度上有多种涉猎，深度上对部分技术研究彻底，还有很重要的一点，考虑问题足够细致全面。10：细致全面善于沟通，技术上深度广度都没问题， 又喜欢这个工作，还会不时做底层实现，从业务和开发两个角度出发，搭出“架构”来是为了开发效率，为了运行效率，为了开发质量，为了业务灵活和运行稳定，为了维护方便等等这样的人，个人认为可以称为“架构师”。而真能满足这种需求的，别说题主的10%的比例，1%能不能达到我也持怀疑态度。其实现在的“架构师”大多数都停留在8这个层次，甚至很多在5这个层次就当上title上的架构师了。总之，成为架构师，不仅仅是工作上的简单积累，更需要主动接纳工作外的大量知识，同时，对性格上对于非技术能力上也有一定的要求，不仅如此连思维方式都很重要，外加职业发展中又有很多岔路，最后走到架构师这根树枝上的就寥寥可数了。