十年的职场之路坚持不易,分享下我的「IT 职场」经验。
时光飞逝,我事业中第一个十年已然结束了。在这十年里,让我收获了很多,跟大家分享一下我在 IT 职场方面的一些个人经验,不一定对每个人都实用,请大家仅作参考吧。
为什么开发Java Web都要用框架?
我个人觉得框架有以下几点作用:
现在做Java Web开发都用哪些框架呢?
常用的比如Spring MVC、Struts2 等,国内的 JFinal、Nutz 等也不错,当然Smart 也是一个很好的选择。
有一定Web前端开发经验的人,很多都会有这么个想法:那些写框架的人好厉害,什么时候我才能写一个自己的框架呢?有时候看看别人的框架代码,又觉得很复杂,对此我有一些建议以及新人学习需要什么基础?分享一些好的方法。
对于接触 Java 不太久的朋友,建议按照以下几个步骤来学习:
此外,在学习的过程当中,建议做学习笔记,最好能通过博客的方式来记录自己的收获。
使用 Python、Perl、PHP、Ruby 等脚本语言开发 Web 程序,跟使用 Java 开发 Web 程序相比有什么不同或者优劣?
前者属于动态语言,无需编译,可通过解释的方式来运行,而且 Java 需要首先通过编译,将源文件转为字节码,且载入 Java 虚拟机才能运行,相对来说,Java 对环境的要求较高,但 Java 具备更强的面向对象能力。此外,Java 还拥有较广的开源社区以及流行的开源中间件。因此,如果是做大型系统,建议使用 Java 来开发,而并非那些脚本语言。
针对 Web,Java、PHP、Python、.NET 之中未来发展前景最好的会是什么?
我认为 Java 在未来还会有一段很长的路,需要在语言本身上做到更加轻量级,用最少的代码来实现目标功能;PHP 相对来说会比较平稳,它的特点非常突出,上手快且易于开发 Web 项目;Python仍然不会有太大的用户群体;.NET 加入开源社区太晚,且较 Java 而言并没有太强的优势,可能会走下坡路。
在软件开发中有很多的设计模式,也有一些很高冷,谈谈我对软件设计的理解,以及让一些设计原则接地气。
了解设计模式的朋友们,想必都听说过“六大设计原则”吧。其实最经典的 23 种设计模式中或多或少地都在使用这些设计原则,也就是说,设计模式是站在设计原则的基础之上的。所以在学习设计模式之前,很有必要对这些设计原则先做一下了解。
GoF(四人帮),传说中的四位大神们,他们联手搞出了一套设计模式,堪称 OOD(面向对象设计)的经典之作!震惊了整个软件开发领域。但这四个老家伙非常怪异,总是喜欢显摆一些高深的理论,甚至有时候不说人话,十分让人费解。
除了最经典的六大设计原则以外,还有一些其他的设计原则也非常重要。我将尽可能地解释这些晦涩的理论,希望看完之后,会让您对这些设计原则稍微加深一些理解。若有不正确的地方,恳请大家指正!
先看一幅图吧:
这幅图清晰地表达了六大设计原则,但仅限于它们叫什么名字而已,它们具体是什么意思呢?下面我将从原文、译文、理解、应用,这四个方面分别进行阐述。
1. 单一职责原则(Single Responsibility Principle - SRP)
原文:There should never be more than one reason for a class to change. 译文:永远不应该有多于一个原因来改变某个类。 理解:对于一个类而言,应该仅有一个引起它变化的原因。说白了就是,不同的类具备不同的职责,各施其责。这就好比一个团队,大家分工协作,互不影响,各做各的事情。 应用:当我们做系统设计时,如果发现有一个类拥有了两种的职责,那就问自己一个问题:可以将这个类分成两个类吗?如果真的有必要,那就分吧。千万不要让一个类干的事情太多!
2. 开放封闭原则(Open Closed Principle - OCP)
原文:Software entities like classes, modules and functions should be open for extension but closed for modifications. 译文:软件实体,如:类、模块与函数,对于扩展应该是开放的,但对于修改应该是封闭的。 理解:简言之,对扩展开放,对修改封闭。换句话说,可以去扩展类,但不要去修改类。 应用:当需求有改动,要修改代码了,此时您要做的是,尽量用继承或组合的方式来扩展类的功能,而不是直接修改类的代码。当然,如果能够确保对整体架构不会产生任何影响,那么也没必要搞得那么复杂了,直接改这个类吧。
3. 里氏替换原则(Liskov Substitution Principle - LSP)
原文:Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. 译文:使用基类的指针或引用的函数,必须是在不知情的情况下,能够使用派生类的对象。 理解:父类能够替换子类,但子类不一定能替换父类。也就是说,在代码中可以将父类全部替换为子类,程序不会报错,也不会在运行时出现任何异常,但反过来却不一定成立。 应用:在继承类时,务必重写(Override)父类中所有的方法,尤其需要注意父类的 protected 方法(它们往往是让您重写的),子类尽量不要暴露自己的 public 方法供外界调用。
该原则由麻省理工学院的 Barbara Liskov 女士提出,她是美国第一位获取计算机博士学位的女性,曾经也获得过计算机图灵奖。
4. 最少知识原则(Least Knowledge Principle - LKP)
原文:Only talk to you immediate friends. 译文:只与你最直接的朋友交流。 理解:尽量减少对象之间的交互,从而减小类之间的耦合。简言之,一定要做到:低耦合,高内聚。 应用:在做系统设计时,不要让一个类依赖于太多的其他类,需尽量减小依赖关系,否则,您死都不知道自己怎么死的。
该原则也称为“迪米特法则(Law of Demeter)”,由 Ian Holland 提出。这个人不太愿意和陌生人说话,只和他走得最近的朋友们交流。
5. 接口隔离原则(Interface Segregation Principle - ISP)
原文:The dependency of one class to another one should depend on the smallest possible interface. 译文:一个类与另一个类之间的依赖性,应该依赖于尽可能小的接口。 理解:不要对外暴露没有实际意义的接口。也就是说,接口是给别人调用的,那就不要去为难别人了,尽可能保证接口的实用性吧。她好,我也好。 应用:当需要对外暴露接口时,需要再三斟酌,如果真的没有必要对外提供的,就删了吧。一旦您提供了,就意味着,您将来要多做一件事情,何苦要给自己找事做呢。
6. 依赖倒置原则(Dependence Inversion Principle - DIP)
原文:High level modules should not depends upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 译文:高层模块不应该依赖于低层模块,它们应该依赖于抽象。抽象不应该依赖于细节,细节应该依赖于抽象。 理解:应该面向接口编程,不应该面向实现类编程。面向实现类编程,相当于就是论事,那是正向依赖(正常人思维);面向接口编程,相当于通过事物表象来看本质,那是反向依赖,即依赖倒置(程序员思维)。 应用:并不是说,所有的类都要有一个对应的接口,而是说,如果有接口,那就尽量使用接口来编程吧。
将以上六大原则的英文首字母拼在一起就是 SOLID(稳定的),所以也称之为 SOLID 原则。
只有满足了这六大原则,才能设计出稳定的软件架构!但它们毕竟只是原则,只是四人帮给我们的建议,有些时候我们还是要学会灵活应变,千万不要生搬硬套,否则只会把简单问题复杂化,切记!
1. 组合/聚合复用原则(Composition/Aggregation Reuse Principle - CARP)
当要扩展类的功能时,优先考虑使用组合,而不是继承。这条原则在 23 种经典设计模式中频繁使用,如:代理模式、装饰模式、适配器模式等。可见江湖地位非常之高!
2. 无环依赖原则(Acyclic Dependencies Principle - ADP)
当 A 模块依赖于 B 模块,B 模块依赖于 C 模块,C 依赖于 A 模块,此时将出现循环依赖。在设计中应该避免这个问题,可通过引入“中介者模式”解决该问题。
3. 共同封装原则(Common Closure Principle - CCP)
应该将易变的类放在同一个包里,将变化隔离出来。该原则是“开放-封闭原则”的延生。
4. 共同重用原则(Common Reuse Principle - CRP)
如果重用了包中的一个类,那么也就相当于重用了包中的所有类,我们要尽可能减小包的大小。
5. 好莱坞原则(Hollywood Principle - HP)
好莱坞明星的经纪人一般都很忙,他们不想被打扰,往往会说:Don't call me, I'll call you. 翻译为:不要联系我,我会联系你。对应于软件设计而言,最著名的就是“控制反转”(或称为“依赖注入”),我们不需要在代码中主动的创建对象,而是由容器帮我们来创建并管理这些对象。
1. 不要重复你自己(Don't repeat yourself - DRY)
不要让重复的代码到处都是,要让它们足够的重用,所以要尽可能地封装。
2. 保持它简单与傻瓜(Keep it simple and stupid - KISS)
不要让系统变得复杂,界面简洁,功能实用,操作方便,要让它足够的简单,足够的傻瓜。
3. 高内聚与低耦合(High Cohesion and Low Coupling - HCLC)
模块内部需要做到内聚度高,模块之间需要做到耦合度低。
4. 惯例优于配置(Convention over Configuration - COC)
尽量让惯例来减少配置,这样才能提高开发效率,尽量做到“零配置”。很多开发框架都是这样做的。
5. 命令查询分离(Command Query Separation - CQS)
在定义接口时,要做到哪些是命令,哪些是查询,要将它们分离,而不要揉到一起。
6. 关注点分离(Separation of Concerns - SOC)
将一个复杂的问题分离为多个简单的问题,然后逐个解决这些简单的问题,那么这个复杂的问题就解决了。难就难在如何进行分离。
7. 契约式设计(Design by Contract - DBC)
模块或系统之间的交互,都是基于契约(接口或抽象)的,而不要依赖于具体实现。该原则建议我们要面向契约编程。
8. 你不需要它(You aren't gonna need it - YAGNI)
不要一开始就把系统设计得非常复杂,不要陷入“过度设计”的深渊。应该让系统足够的简单,而却又不失扩展性,这是其中的难点。
一个成功的项目,离不开每个人的努力,分享下我曾经的项目管理经验。
给大家提出以下 10 点建议及其目标:
此外,作为项目管理者,需要不断在团队中加强以下 5 点文化:
谈谈我对「开源」的看法,国内的开源的现在如何,对比国外呢?
我个人认为,真正的开源并非只是代码的开源,而是思想的开源。在做开源项目之前,建议能将自己的想法共享出来,而不是 埋头闭门造车。我不反对“重造轮子”,因为我们需要更好的轮子,轮子好了车子才能跑得快。凡是有利也有弊,我们也不能盲目地选择开源技术,因为并不是适合 别人的技术就适合自己,而是需要根据自身的需求,选择最适合的开源技术,搭建恰如其分的架构。
有大量的新技术,我首先会去关注它,了解它是做什么的,可以解决什么问题,但我一开始绝不会去深入研究它,更不会去看它的源码,因为一旦遇到这方面的需求场景,我就会从这个“知识库”中去寻找最好的解决方案,如果仍然寻找不到最合适的开源技术,我才会尝试自己去实现。
走技术这条路,归途是什么?是否转型又该如何抉择呢?
至少有好几条路线是可以走的,比如:深入技术、转型做产品、转型做管理等,需要根据自己的特长和性格来选择,做自己喜欢的事情。
从技术转管理,对自身的要求比较高,说具体点,需要看自己的情商,为人处世的经验,与人沟通的技巧,自己也需要有足够的胸怀,去包容一些事情,还需要自己有足够的人格魅力去吸引别人,让别人愿意跟着你一起做事。管理有些东西是很难从书本上学到的,但一些经典的管理理论是必须要去学的。
相比较而言,继续深入技术或者从技术转产品会容易一些了,因为很多时候都不太需要与人打交道。
原文:http://www.cnblogs.com/java1024/p/7727479.html