最佳实践

  这周小组内的学习是探讨Java异常处理的最佳实践，今天周末，外面太闷，宅在家里对Java的异常处理做一个总结，如有不对的地方欢迎指正~ 一. 谈谈个人对Java异常处理的看法   维基百科对于异常处理的定义是： 异常处理，是编程语言或计算机硬件里的一种机制，用于处理软件或信息系统中出现的异常状况（即超出程序正常执行流程的某些特殊条件）。   Java语言从设计之初就提供了对异常处理的支持，并且不同于其它语言，Java对于异常采取了强校验机制，即对于编译期异常需要API调用方显式地对异常进行处理，这种强校验机制被一部分人所钟爱，也有一部分人狂吐槽它。持支持观点的人认为这种机制可以极大的提升系统的稳定性，当存在潜在异常的时候强制开发人员去处理异常，而反对的人则认为强制异常处理降低了代码的可读性，一串串的 try-catch 让代码看起来不够简洁，并且不正确的使用不仅达不到提升系统稳定性的目的，反而成为了bug的良好栖息之地。   Java的异常处理是一把双刃剑，这是我一向持有的观点。个人认为我们不能对Java的异常处理片面的下一个好或者不好的定义，黑格尔说“存在即合理”，既然Java的设计者强制要求我们去处理Java的异常，那么与其在那里吐槽，还不如去学习如何用好Java的异常处理，让其为提升程序的稳定性所服务。不过从笔者的亲身感受来看，用好Java的异常处理门槛并不低！ 二.

Django 开发中的最佳实践之一 本文关注 Django 开发中调试的部分。 出自 Flask 项目 旗下的 Werkzeug debugger Werkzeug 这个词在德语里 好像 是工具的意思， 这里 有简要的介绍。和 Django runserver 提供的 50x 页面相比，最大的好处是在堆栈的每一层都可以打开 Python console。 选择下面列出的两种方法之一即可在你的 Django 项目中享受 werkzeug 带来的好处： https://github.com/philippbosch/django-werkzeug-debugger-runserver https://github.com/django-extensions/django-extensions/ 其实第一个方法就是从第二个大杂烩般的 Django Extensions 中单独摘取 werkzeug 出来。 如何设断点进行单步调试呢 通常调试命令行界面的 Python 程序，用 pdb 或者 ipdb 即可。如何在 Django 项目中使用呢？ Django PDB 项目提供这样的集成。在 URL 的参数中加上一个 pdb（比如 http://localhost:8000/test?pdb）就会在对应的 view 的入口点设置断点。当代码执行到此断点时，在你运行 runserver

Sections 应用领域（Application Domain） 应用层（Application Layers） 控制器 Beans Service Beans Repository Beans 数据传输 Beans Conversion Beans Further Reading Social Me 应用领域 Application Domains 我们的应用程序组件分解为两个基本类别：系统和问题领域。 系统领域（System Domain） – 基础设施架构，这个是Spring的强项！ 问题领域（Problem Domain） – 业务组件，通常这个是用例驱动的，这种方式是大多数开发者的使用的解决方案。 应用层（Application Layers） 应用程序的组件（beans）应该被分为不同的层次和类别。 Bean Layers Controllers (MVC, 系统领域 ) Services ( 问题领域 ) Repository ( 系统领域 ) Other Bean Categories 数据传输对象（问题领域） 系统函数（系统领域） 控制器（Controller Beans） 更多的关于 企业级Spring MVC最佳实践的博文即将发表 - 待定。 业务（Service Beans） Service Beans 是问题领域组件. 在应用程序中是最重要的部分，同时

生产环境最佳实践 1.linux 系统： 1】关闭文件系统/分区的atime 选项 Vi /etc/fstab 在对应的分区项后面添加noatime ,nodiratime LABEL=/1 / ext3 defaults 1 1 LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2 2】设置文件句柄4k+，目前该配置已经集成到启动脚本中。 Vi /etc/security/limit.conf * soft nproc 65536 * hard nproc 65536 * soft nofile 65536 * hard nofile 65536 3】不要使用large vm page （不要使用大内存页选项） Linux 大内存页参考：http://linuxgazette.net/155/krishnakumar.html 4】用dmesg 查看主机的信息。 2.linux 文件系统的选择： Mongodb 采用预分配的大文件来存储数据,我们推荐 1】ext4 2】xfs 3.内核版本： 网络上对2.6.33-31 以及2.6.32 的表现持怀疑度， 而强力推荐2.6.36 4.线程堆栈的尺寸 默认的线程堆栈尺寸为10m ，调整为1m ，已经集成在启动脚本中。 项目过程中的总结与建议 1.大小写问题 mongodb

@郑昀 汇总 创建日期：2012/9 Application Design： 1） 如果发现query没使用你预期的索引，请用hint强制使用指定索引 主站商品中心所使用的文档字段很多，各种索引建得也不少。在沙创排查慢查询时，曾百思不得其解，为什么明明建的有联合索引，查询起来还是非常慢呢，直到显式指定使用该联合索引。 hint的例子： db.collection.find({"age" : 18, "username" : /.*/}).hint({"username" : 1, "age" : 1}) 2） Design documents to be self-sufficient， 设计 自给自足的文档 MongoDB 应该是一个大的、无声的数据存储（big, dumb data store）。它几乎不需做任何处理，只是负责存储和读取数据。你应该坚持这个目的，避免强迫 MongoDB 做一些客户端可以进行的计算工作。 如果真的想算一些文档里没有显式存储的数据，你有两个选择： ——招致严重的性能惩罚（让 MongoDB 用JavaScript 做运算）； ——在文档中显式存储这些数据。 Implementation： 3） Override _id when you have your own simple, unique id 如果你的文档自己有明确的唯一键值，不需要