分类目录归档:Programming

推荐:Thoughtworks 的程序员的读书雷达

reading-radar

前几天在 Startup News 上看到一篇文章,是 ThoughtWorks(中国)发布的《程序员读书雷达》,先摘抄一部分:

读书雷达将书籍分为四个维度:

Coding Practice(编程实践)
Architecture & Design(架构与设计)
Methodology(方法学)
Thought & Leadership(思想与领导力)

每个维度分为三个等级:初学、进阶和高级。每一位程序员都可以根据自身水平与能力,选择适合自己的书籍,甚至组成一份读书路线图,在获得知识完善与汲取的过程中,提高自己能力,达到各个维度的巅峰。

作者们之所以将方法学、思想与领导力放入到这个读书雷达中,是因为软件开发不仅仅是个人活动,也不仅仅是编码技巧和设计能力的体现。他们认为,开发技能其实是一个综合的系统工程。了解方法学,可以促进你对开发过程的理解;关于思想,则涉及大脑思维的修炼,可以提高程序员的抽象能力、学习能力;至于领导力,则有助于程序员在开发团队中发挥更大的作用,并能作为很好的团队成员,提升团队整体能力。

摘抄完毕。

我很认同。就说编程实践这一个维度,你不去读书补充知识,很快就会遇到瓶颈。我有个朋友,做了有两年多的 PHP,现在转 iOS 开发,有一次交流时,他说,PHP 做的也没什么追求了,现在虽然转了 iOS,但是仍然觉得自己被什么束缚着,感觉不是靠拼命写代码就能有突破的。我们分析了下,虽然有三年的编程经验,但经验的局限性太大了,虽然能总结出些东西,但比起阅读大师们的著作,来的有慢又少(除非你悟性奇高)。我推荐了《实现模式》,虽然薄薄一本,差不多能把编程中的小经验都固化下来了。

关于架构与设计。虽然设计模式有点教条化,那是因为你还没在实际应用场景中看到它们的精巧之处,因为它们就是在日常实践中总结出来的,是实践派而不是理论派。比起靠自己跌倒 n 次总结出来,前辈们已经为我们准备好各种固化下来的解决方案,我们只要花时间去认识和了解它们。

关于方法学、思想与领导力。曾经我稀里糊涂的加入一个拥有方法学的团队,除了架构师,我们都是一两年的 PHPer,但是在架构师的引导下,团队成员慢慢接受了面向对象编程(那时候对 OOP 还是相当排斥的),接受了重构,接受设计模式,接受极限编程。团队整体实力不可同日而语,而凝聚力也是我之后再也没遇到过的。这都归功于架构师在方法学、思想和领导力上的造诣,还有耐心。我了解过,一般拉回一头牛(比如让一个排斥 OOP 的程序员接受 OOP),需要 6 个月,有了第一次接受,之后就快了。所以说 “开发技能是一个综合的系统工程” 是没错的,特别是一个团队进行开发时。

关于方法学的概念,其实我也含糊,明天就聊聊这个。

题图也来自于引用的文章。

依赖注入在框架中的应用

di

现在的 PHP 应用包含了很多对象。有的对象能帮你发送电子邮件,另一个可以帮你把数据持久化到数据库中。在你的应用中,你可能会创建一个管理产品库存的对象,或者是一个处理第三方 API 数据的对象。这篇文章中,我们的关注这件事情:应用做了很多事情,它组织了很多对象来处理每一个任务。

在 PHP 的 Symfony 2 框架中,有一个特殊的对象,帮助你实例化、组织和获取应用中的那一系列的对象。它叫 Service Container(服务容器),可以让你标准化和集中化地创建应用中对象。容器让生活简化,它速度很快,包含的架构思想促进代码的重用和解耦。所有 Symfony 2 的核心的类都使用容器,容器为框架的速度和可扩展性做了最大的贡献。

先来了解下什么是 Service。

简单的说,一个 Service 就是任何的可以完成某类“全局”任务的 PHP 对象。一个 Service 是一个 PHP 对象的通用性的术语,这个对象能执行特定的任务,通常被“全局”地使用,比如一个数据库连接的对象,或者一个能发送电子邮件的对象。如果拥有很多松耦合的 Service,我们就说这个应用遵循了 SOA(面向服务的架构)。创建一个 Service 很简单,你只要为那份能完成特定任务的代码写个类,就 OK 了。

一般来说,PHP 对象如果要成为 Service,必须要在应用中被全局的使用。比如一个 Mailer Service 被全局的用于发送电子邮件,但是由 Mailer 发送的邮件内容对象(每次的内容都不同)就不是 Service。

既然 Service 这么容易创建,那有啥了不起的呢?如果你开始考虑将应用中的每个功能都分离开来,你就能开始感受 Service 的好处了。因为每个 Service 只做一个工作,你在任何地方都可以轻松地获得并使用它们的功能。每个 Service 也能更容易的被测试和配置,因为在应用中它们是互相分离的。将你的应用组织成一系列独立的 Service 的类,也是面向对象编程的最佳实践之一。这种技能在任何开发语言中都是好程序员的标志。

什么是 Service Container。

Service Container 也叫 Dependency Injection Container(依赖注入容器),就是一个简单的 PHP 对象,管理着 Service 们的实例化。

假设你有个发送电子邮件的 PHP 类。如果不用 Service Container,在你需要它时,都必须手工地创建对象。这也算简单。但是,如果你不想重复地去配置它,就可以把它作为 Service。

当你需要创建一个 Service,它依赖了 Service Container 中一个或几个其他的 Service 们时,你才会意识到容器的强大。假设你的一个新的 Service,依赖了发送电子邮件的 Service。只要在新的 Service 配置中将发送电子邮件的 Service 设为参数即可,如果你的这个 Service 后来做了改动,需要再依赖一个 Service,只需要改下配置,增加参数即可。

对应到依赖注入模式,其实 Service Container 就是注入器;Service A 依赖 Service B,前者是依赖者,后者是被依赖者;被依赖者的接口一般就是依赖的定义。这次设计模式解决的是整个框架的架构问题,解决了:功能间的松耦合、框架的扩展性,运行效率也高。

其实还是蛮羡慕学 Java 的同学,很早就接触一些好的设计和应用,比如:Spring 框架。当然现在 PHP 的新的框架层出不穷,也借鉴各种好的思想。面包和牛奶已经有了,可以吃了。

 

翻译自:Symfony Service Container

封面图片来自网络。

了解下依赖注入

dependencyInjection
昨天想翻译的那篇文章有点深奥,我们需要先了解依赖注入这个设计模式。下面内容是对部分 Wiki 的翻译。

依赖注入(Dependency Injection)是一个软件设计模式,它可以帮你去除硬编码依赖。比如,你要动态加载一些插件;或者,你想要在测试环境下使用模拟的对象,在真实环境下使用真实的对象。在知道调用者的需求后,这个模式会自动把被调用者(对象、值 等等)注入到调用者中。

依赖注入涉及到至少 3 个元素:

调用者(依赖者);
一份依赖的声明,以接口方式定义;
一个注入器(有时也叫:提供者、容器),它能创建实现了接口(定义依赖的接口)的类的实例。

调用者会描述它需要哪些被调用者才能正常工作。再由注入器来决定哪些具体的实现能满足调用者的需求,并提供给调用者。

在传统的软件开发中,调用者是自己来决定使用哪些被调用者的实现的。但是在依赖注入模式中,这个决定权授权给了注入器,注入器能在软件运行的时候选择替换不同的实现,而不是在编译时。这也是依赖注入的关键优势。

依赖注入模式除了在复杂软件的测试时特别有用,还经常用于定位组件,或者定位、初始化软件中的服务。

支持依赖注入的框架,在 Wiki 上也列了很多。比如 Java 的 Spring,PHP 的 Zend Framework 2、Symfony 2,等。

明天我们看它在 Symfony 2 框架中的具体实现和应用。

 

封面图片来自网络。很切题,能留个深刻印象不?