Showing posts with label Program. Show all posts
Showing posts with label Program. Show all posts

Friday, June 2, 2017

程序员如何学习新的技术?

要学会学习,尤其是程序员

学习就是在不断地提高自己,然后不断的完善自己,让自己变的更强大,更加的完美!


作为一个程序员如何学习呢?

1  一手资料:
源代码,文档

2  二手资料
博客:一般是笼统的讲述 或者  是针对具体的问题的解决方案,快餐!
书籍: 一般技术都比较的老旧,适合比较深入的学习,写书需要很长的时间,所以,最好看一下算法和设计模式什么的,学习新的
技术,书上面是没有,就算有的话,书的延迟太高了。
视频: 学习效率最低的一种,因为太浪费时间了。所以,建议初学者使用看视频的方式。如果,你是刚入门的学习一种语言的话,可以使用这种方式!


以为,二手资料是别人的理解和认知,有的时候,技术和能力也是参差不齐的,如果作者的能力很强,我觉的会好很多,但是,如果作者的理解存在偏差的时候,比如:毛哥之前看中文的Android文档,但是,翻译出现了一个错过,所以他的理解就错了。我给他纠正了,但是,似乎并不服气,然后就没有然后了呢!以后,我不会在跟被人争论哪门语言更好,对我而言,我觉的合适的语言最好,自己用起来最舒服的语言就是最好的,我觉的世界上没有最好的语言,只有最合适的语言!所以讨论语言的话题,我拒绝回答!

看二手的资料存在的问题,就是太依靠作者的能力。

个人建议,最好是学习一手的资料,一手的资料的问题,就是难度大,很多的事情,需要自己去琢磨,这个说实在的挺不容易的饿。

到目前为止,我还没有怎么完整的看过文档呢,我一般都是用到的时候再去查看文档,因为,看完一整套的文档是挺麻烦的,一般是没有那么多的时间,现在,一般是用到什么的时候去学习什么,有好有坏。坏处就是没有什么准备,一切都是从头学习比较的困难,所以,有一些东西,需要弄清楚原理,然后自己去思索,学会解决问题的能力!







Thursday, July 14, 2016

有的时候 重写比改更快

看之前写的代码就像吃屎一样难。

其实,看别人写的代码,跟吃屎差不多。

就连自己几个月之前的代码也是一样的呀。真是醉了, 有的时候,看了半天也不知道为什么的时候,干脆就别看了,直接干掉吧。改成自己的风格。真是醉了,修改以前的代码,还不如自己的直接重写来的更快呢!

不是针对你,我是说在做的各位全他妈的是垃圾!

Sunday, May 29, 2016

Error: More than one library with package name ""

问题描述:
我不喜欢用 Actionbar 所以自定义一个ChowTitleBar, 本来放在项目中没有任何的问题,但是现在公司要求,要做好几个项目(定制软件,也叫外包)所以,我就将ChowTitleBar 提取出来作为一个第三方的库,但是,不同的项目中的色值是不同的,我就用 Gradle 的productFaver 解决色值的问题。针对不同的项目创建不同的ChowTitleBar, 然后在项目中引用。





error:
code:
compile 'com.chow.ui:mlw:1.1.2-release'compile 'com.chow.ui:gjb:1.1.2-release'compile 'com.chow.ui:xjlh:1.1.2-release'

出现错误的原因,是因为每一个远程的依赖仓库里面,都有一个 com.chow.ui.chowtitlebar 导致了gradle 编译代码的时候的二义性。 编辑器根本不知道你要用哪个?

我想了一些实现的方法,根本没什么卵用:
1  我想讲 com.chow.ui.chowtitlebar 抽取核心出来,然后创建多个  子项目 去继承com.chow.ui.chowtitlebar, 然后 compile 子项目,但是 也会出现这种问题。

2  然后,我想在 公司项目里面去做 com.chow.ui.chowtitlebar 的继承,在不同的productFaver 中实现不同的子类,但是有一个问题,就是色值的问题,我无法改变 lib 库中的色值!

以上的方案都不行:

然后,我想能不能再 build.gradle 里面去 有选择的依赖库的信息呢?我只想依赖一部分的 代码,而不是全部,搜了一下资料。貌似不行!  但是可以排除一些代码,我忘记了,你可以搜一下:

解决方案:
mlwCompile 'com.chow.ui:mlw:1.1.2-release'xjlhCompile 'com.chow.ui:gjb:1.1.2-release'gjbCompile 'com.chow.ui:xjlh:1.1.2-release'


原理:
每创建一个ProductFlavor就会自动创建一个基于它名字的编译依赖配置<productFlavor>Compile








屌屌的,再次感谢作者:  zly394
http://www.jianshu.com/users/56b93d979576/latest_articles







感谢:

Gradle之多版本打包不同依赖配置

http://www.jianshu.com/p/9b50c4059d61






Wednesday, May 25, 2016

为什么当了十年的程序员还只是初级程序员?

昨天看到一篇文章,说一个干了十年的程序员还不如两年经验的程序员?

这是为什么呢?

一篇文章说到: 高级程序员 不是说看基本编程的书籍和写几万行代码就可以做到的!

高级程序员,不仅仅是靠天赋的,更重要的是后天的努力,没有人是天生就是天才的,那种人非常至少。大多数还都是普通人!


但是,什么人才能成为大神呢?

有钻研的精神的人?凡是都要问个为什么的人? 对什么事情都感到好奇的人。最重要的是有毅力的人。

为什么做了10年,还不如两年的呢?

因为十年的时间完全浪费了。时间的时间里面,他没有研究过真正底层的代码。很多东西: git  svn Mysql 仅仅是为了应付工作的需要,并不愿意花时间来研究,古人云只是虚长几岁而已, 闻道有先后,术业有专攻。 我是喜欢自己的钻研的人。很多的时候,我并不是很喜欢问别人,当然 浏览器除外。我是 非常喜欢使谷哥的孩子。 浏览器是一项伟大的发明。不亚于四大发明。

我用Git快半年的了,昨天,我才突然的顿悟。原来,我也仅仅只是会用而已。根本从来没有考虑过,他是怎么实现的,怎么进行数据存储和维护的,很多事情,我根本就没有深入的思考过的!

其实很多的时候,我们缺少的是耐心。我们更多的时间是本 Bug 和需求占用了,真的用来钻研技术的时间,我觉的是10经验的孩子,未必有那个2年经验的人花的时间多!

就是这样。


Stay  Foolish, Stay hungry!

Wednesday, May 11, 2016

代码重构的感悟

随着自己的能力的不断的增长,主要是自己的视野和格局在不断的增长。让自己,觉的现在的代码越来越垃圾了,急需重构代码。项目中的冗余代码越来越多,这是为什么呢?这是因为,之前开发规范的问题。没有一个很好的规范,导致了各种问题,当然也埋下了很多的坑!

这么说,一个六个人的团队,未必就会比一个人的做的好!因为,In China 很多的时候,我们往往只相信自己的能力,并不相信别人。总觉的被人是傻逼。一般的只要不是大公司,小公司也包括中型的公司,新人到了公司之后,缺少代码规范的训练。因为,似乎每个人都很忙,他们不知道,现在的很忙,导致了以后会更忙。新人,必须要代码规范。但是,很多初级的程序员,往往没有这种意识!需要我们来督促!

说说,今天! 今天上午发了包,下午有点自己的时间,可以让自己来重构自己的代码!说真的我很庆幸现在自己的状态,因为,我算是 天时  地利  人和。 我很是庆幸,比如我的哥们,小强,他作为一个新人刚到公司,看到公司垃圾的代码,但是,他不可以重构,因为,作为新人,到了公司没有什么话语权。这个社会就是这个样子的,新人要有新人的样子。就像PM 很多都是傻逼,娜姐除外。说白了,很多人根本就是看不起程序员,我们一般是比较理想化的人,活在自己的世界里面,感觉自己的世界里面,自己似乎可以做所有的事情!说白了,我就是自己的神。总之,我现在重构我的代码,没有意思的顾虑,就是只要自己有时间就好了!花点精力来做这件事情。我觉的代码就像自己的老婆一样,如果,你都不花心思来整理,还有谁会对你的代码上心呢?所以,代码可以变的更好,实现 可修改,可维护,可增量!

这个世界上的事情,需求是不断的改变的。假如 需求是死的,那么的你活着还有什么意思!
我们就生活在不断变化 的世界里面

下面说说我的重构代码的感悟:

1 命名规范
这个问题,真是很蛋疼呢?说白了,很多人写代码就是瞎鸡巴写,根本就不在谁来维护代码,只要代码实现了就好,什么有道词典,百度呀,google 翻译呀,瞎鸡巴乱搞,很快他们就实现了功能,老板很开心,因为,很快就看到了产品,在老板的心里面,产品的代码应该是整整齐齐的。但是,在程序猿的心里面代码是乱七八糟的,我说的是大多数的。作为,刚到公司的人急于表现自己的能力,想让自己的能力得到老板的肯定。然后,就瞎鸡巴揽活,拿到需求之后,看到产品原型图,就瞎鸡巴写,写了之后发现有问题,就开始瞎鸡巴改!真是蛋疼的狠!最后,发现 坑越来越多,自己的坑越来越多,这是一个量变促进质变的过程。到了最后,发现自己真的是改不动bug了!然后,递交了辞职信!   这尼玛就是坑货, 新来的人  又开始了死循环!

解决:
命名规范的问题,每种语言都有自己的特性,但是命名确实大同小异。你需要根据自己的习惯总结一套自己的命名规范。不是每个人都有这种意识,很庆幸,我有这种意识!这个东西,CTO 产品经理 可以制订一份文档,来规范用到的英文。没有在文档汇总的,程序员可以  google,添加到文档中!

命名的规范有很多,我就不介绍了,你们随便找找吧!

2  Utils
为什么要提取Utils
今天,我的项目中用到了ImageLoader.  DisPalyOptions 很多地方都初始化了,将近 100 多个地方都用自己重新定义了一下!这样的重复代码, 根本原因,我们开发的时候,很多的时候只会粘贴复制。粘贴复制到了 代码的重复!

我的原则:  重复的地方超过了3次以上,立马听一下工作开始重构代码,或者提取到工具类!

我这里建立 了一个ImageLoaderUtils, 来处理 不同的DisplayOptions,  displayImage(). 

但是,这么做有什么好处呢?

我有一个问题,加入有一天,我不想用ImageLoader了,我想换一种 图片加载工具,比如 Passco 实现图片的加载。但是,现在的代码修改起来,代价太大了。因为内部代码跟ImageLoader 的耦合度太大了,属于低内聚,高耦合。就是,所有用到ImageLoader的地方都要修改。这样很不好。

这个时候,我体会到了解释器设计模式的用处。

提取工具类是一个非常好的习惯。因为,可以消重。消除重复代码的原则:拆分和抽取。就是 大事化小,小事化了,了事化无。

用了ImageLoaderUtils 之后,我可以在这个累的基础之上去使用适配器模式,做不同的  图片加载工具的 adapter. 我只需要链接不同的 图片加载的特性。然后,抽取一个 BaseImageLodaerUtil 设置几个抽象的方法,然后,让子类实现以下,就可以了!具体的需要思考。


这就是我今天的收获!


















Friday, April 15, 2016

GeekHades 如何测试?

作为开发者,自己写的代码,Bug 一定是少不了的。我们在估算开发周期的时候,似乎只是估算了,写代码的时间,完全没有把,产品原型,设计和测试的时间,估算进来!

真的是醉了,开发完之后,等了好几天,马上就要发包的,这个时候,测试开始测试,一堆的问题,bug,待优化的问题,再过几个小时就发包了。这种模式,真的是折磨我的意志呀。蛋疼呀。自己的代码,要对自己的代码要负责。

测试的时间,越延迟。后面的问题,就会越多,所以,写完之后,应该尽快的让测试,进行测试,因为,问题,发现的越早越好。

自己写完的代码,就像是++的女人。真的是懒得在看一眼。如果,不是有问题,我是不会回头看的。

代码的余量,代码简洁,每个人写代码的风格是不一样的。所以,代码的风格和代码洁癖,直接导致了,各种的问题!你想重写代码的冲动,但是,代价太大了!有点让人恐惧呀!

测试,以后写完一个功能,需要立马测试,但是,每个人的又都有自己的工作,导致了测试的问题,一直在延迟,一直拖延到最后。这里的问题,从产品到开发,都有问题。最烦的莫过于,照着微信开发,往往不会给你产品原型图。这个时候,作为程序员的我就要开发创造了,不仅仅要胜任,产品经理的角色,还要做一个设计者。还有开发。我真他妈的是天才。写完之后,还要测试,真的是FullStack. 牛逼呀,小伙子!

今天,就吐到这里吧,真的是醉了,以后的问题,还有很多呢。慢慢的解决吧,这也是自己慢慢成长的而一个过程。

给自己,留一个余量。 来思考自己的代码!

今天,又给自己完了一个坑!  妈的上来就写,没有仔细的思考,预览的需求,导致了,实现的方案有问题,现在只能,从新写了,2个小时的时间白费了!

建立自己的工具库!

自己的代码规范!

最好,别让别人碰自己的代码!

思考的时间!

Tuesday, September 8, 2015

作为程序员的我每天应该思考的十个问题?


1.此处有没有模式?

研究在哪些情况下行得通,哪些情况下行不通的设计模式,能够让我们发现潜在的规则,了解看似不相关的概念和行为。为了更深层次地了解工作,你需要时不时地问问自己,“此处有没有设计模式?”。

这句话适用的不只是你的代码。在根据业务要求而变的类型变化中有没有模式?技术发展有没有模式?你是否经常看到同样类型的bug连连弹出?

理解其实就是一种感知模式。——以赛亚·伯林


2.如何让它变得简单起来?

通常作为web开发人员,我们会想着拿出复杂又可扩展的解决方案。搞点复杂的会让你觉得自己非常的高大上。问题是,你永远无法预知你的产品和业务在未来将会发生怎样的改变。

架构和编码与其说像建造,还不如说更像园艺艺术。你必须得能够适应不断变化的环境。解决方案越复杂,它的适应力就越弱。

简单才是终极的复杂。——达芬奇



3.它为什么这么工作?

知道事物能工作,与知道它为什么这么工作是两个完全不同的事情。知道一些事物的行为原因,有助于你做出显然更好的决策。

伟大的程序员,和那些只是知道一门编程语言的人之间的区别是,两者处于的知识层深度不同,前者深刻地理解其工作原理。

这也适用于修复问题的时候。“只要重新启动服务即可。”“你重启了吗?”当弹出问题的时候,我们往往会说类似于这样的话。然而,如果你这样说了,那你就失去了一次学习的黄金机会。

知道为什么会出现问题,才能从根本上修复问题,才能避免再出现这样的问题。

4.之前有人做过吗?

当你自我感觉发明了一种复杂算法的时候,可能就意味着你正在错误的道路上了。最好的方法是搜索其他人是否已经解决了这个问题。
需要写算法,以便于添加标签到最接近用户鼠标的菜单项中?别急,已经有解救方法了。想为送货车找一条最短路径?也已经有解决方法了。想找类似于用户刚刚enter的标签,那么也不用自己绞尽脑汁写了。

上面这些只是几个例子,但是相信我,你碰到的问题,别人早就碰到过了。

我能看得更远,那是因为站在巨人的肩膀上。——牛顿


5.谁第一个提出来的?

你觉得自己知道REST?

那么,你读过Roy Fielding说明REST的原始文件吗,你了解它的期望目的吗?暂且不说那个在IDE V7中使用REST API生成向导比你更有经验的博主了。

所以,告诉自己试着去阅读概念和理论的原始来源。然后通过各种方法去了解行业思想领袖给出的最新开发成果。如果你不知道是从哪里开始的,那么你怎么理解目前的发展进程呢?

6.我真的热爱我目前的工作吗?

首先让我们面对一个事实:编程很难。

即使很难,编程也在不断发展。如果用现在的标准来看,2年前的框架简直笨拙地就像一头恐龙。要想留在这一行,那么你需要终生致力于学习和研究。

如果你确实不喜欢编程,那么要想跟上那些热爱的人的步伐,希望并不大。找找你为什么对她没有兴致的原因。不要因为与市场存在差距或因为待遇还不错,就决定成为一名安全专家,不要只是因为最近的文章上面评论说,UX是高科技领域中最热门的职位,就立志成为一个UX专家。

重要的事情说三遍:做自己热爱的事情。做自己热爱的事情。做自己热爱的事情。

做自己热爱的事情,你所需要的资源也会随之而来。——彼得·麦克威廉斯



7.还可以用在哪里?

我发现web开发人员最大的局限之一就是失败的想象力。

我们在特定的情况下学习的东西,或看到某种用于解决特定问题的技术,我们往往会认为这就是它们的唯一用途。但是,这个想法基本上都是错的。每次你学到新的东西的时候,都应该问自己:“还可以用在哪里?”。

学到了一种超棒的新的定位方法来定位图形节点,那么它是不是也可以运用到在有2个维度的数据集中查找某一个数据点?发现一个越过WebSockets从客户端发送数据到服务器的很棒方法?那么它该如何应用于制定一个可扩展系列的后端服务?有时候此路不通,有时候却是可行的。

逻辑能力能让你从A到Z,但是想象力却能让你去往任何地方。—— 爱因斯坦



8.我败在哪里?

最简单的革新方法就是降低失败的成本。

游戏开发公司Valve和它的一些同行就将此当作金科玉律。这同样适用于web开发人员,如果你害怕失败,那么你将永远不会有大的突破。

勇敢地去尝试,从失败中学习,然后再试一次。

不要害怕犯错。认识失败。然后从头来过。——本杰明·富兰克林



9.如何实现这个目标?

我们生活的世界中只有很少一部分事情是真的完全不可能的。

要抱着自己想做的任何事情都是可能的这样一种想法去做事。可能你会发现你想做的事不符合当前实际,但随着世界的不断进步,它也许比你想象地更快成为了现实。

事情未成功之前,它永远是看似不可能的。——曼德拉(前南非总统)



10.我可以向谁学习?

不要在你是最聪明的地方工作。

选择那些拥有能够激励你,挑战你,让你做得更好的同事的工作和企业。不必与代码相关,在文本编辑器和命令行之外还有一个世界。学习其他领域的事情,然后应用于你的工作中。

不管如何,仅仅胜任工作是不够的。

Sunday, September 6, 2015

Why my mac Android studio ButterKnife doesn't work , Genarate --> have no butterknife chose?

Now I know I am newser to Android!

Today I reslove the problem! Why  my mac Android studio  ButterKnife  doesn't work ,    Genarate -->  have no butterknife chose? I spend a long time!  Because I don' know the question occer where?

But now I know, The deep because is that:  I forget set Android studio Plugins. I din't know before. beacuse the last time is my brother to set Plugins for me. Not I do it myself! 

Folling this way:
Step one:
     Click the Setting Coin or keymap


Step Two
   You just shoud inpur ButterKnife Zelezny . You can see the Browse. just click it.


  Strp 3: 
   The esayest method: just install plugin!

  Let me see:




Thinking the question:

I should know my IDE very much . So now  I am loser to Android . So I have a long way to go!



Saturday, September 5, 2015

Error:failed to find Build Tools revision 23.0.0 rc2 Install Build Tools 23.0.0 rc2 and sync project

How to resolve this problem ?

apply plugin: 'com.android.application'
android {
    compileSdkVersion 21    buildToolsVersion "23.0.0 rc2"
    defaultConfig {
        applicationId "com.love.hades.hades"        minSdkVersion 19        targetSdkVersion 21        versionCode 1        versionName "1.0"    }
    buildTypes {
        release {
            minifyEnabled false            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:22.2.0'
    compile 'com.jakewharton:butterknife:5.1.2'//inject}

why?

Because  the buildToolversion you set is "23.0.0.r2"  but your Mac SDK din't have the version. I check my version the lastest version is 22. So the gradle to complie will occer the error.

Folling this way:
you just change the buildToolVersion like this(you have install version! OK )

android {
    compileSdkVersion 21    buildToolsVersion "22.0.0"


Sunday, August 30, 2015

Android studio 如何关联Subversion?

之前一直被一个问题困扰: 我的Android studio 打开 SVN CheckOut 的项目 一开始的时候是没有问题的!

 But  when i close the svn project, to open the other Project.  A day later I reopen the last project.but I can't see subverion  update and  commit!  How to reslove the porplem?

fowlling this way;
1  you can choose "Enable Version Control Integration"


2  you just  choose the subverion!  that is all right!




thinking in problem?

Why is occer?  I think maybe is you use Android studio , But Android studio subverion Manager  didn't control the file, When you quit the android studio or quit cmputer but not person do it !



Saturday, August 29, 2015

优秀程序员是如何处理糟糕代码的

可能你一行不好的代码也从来没有写过。这是有可能的,但在现实中又不太可能。
现实情况是,和这个星球上的其他所有程序员一样,你会产出安全漏洞、UI元素偏移,等等等等的代码。这并不能说明你是一个不好的开发人员。只是因为你是人类而已——一种不可避免会犯错的生物。
正是这种每个开发人员都有的“人性”缺陷,驱使那些优秀的开发人员敢于承担代码和底层基础架构的不足,有准备有计划地行动。下面是他们将做的事情。

假设

几年前,Netflix开源了Chaos Monkey和Simian Army的其他部分(Simian Army是一套工具,用来管理基于云的软件)。从本质上说,Chaos Monkey的范围贯穿亚马逊Web服务的基础设施,能够随意终止实例。从根本上说,它是一种通过创建最坏的可能方案来做最坏打算的方法。
正如Netflix的Cory Bennett和Ariel Tseitlin于发行之时在博客上这样写道,“代码会失败,并且你越不希望失败或一点也没有准备的时候,反而更加不可避免会出现故障。如果你的应用程序不能容忍实例故障,那么你是愿意凌晨3点被召唤呢还是在办公室里通宵?”
使用不可预测的方式来模拟故障,Netflix强迫注重基础设施的弹性。与其假设最佳的情形,还不如做一个最坏的打算。这样我们就能愉快地进入下一个进程了。

测试

上面我们说了一个提高基础设施的伟大方法,那么代码呢?
Jeff Atwood,一个程序员的答案是:“你需要折腾你的代码。”他写道:
我相信,每个专业程序员职业生涯的一个关键转折点,就在当你意识到你才是自己最大的敌人,以及减轻这种威胁的唯一办法就是接受它的时候。将自己当作最大的敌人。打破你的用户界面。打破你的代码。折腾你的软件。
在实践中,这意味着“程序员至少需要对常见错误有一定的了解,然而,很多程序员往往不会这么去做,甚至是反着来。”这意味着你作为“编程之神”的责任也包括成为“测试之神”,通过“折腾”代码积极地来消除里面的错误。
Andre Medeiros补充认为我们应该对调试“精益求精”,因为开发人员需要对他们的代码做更多的事情。
“为了防止bug,你写出来的代码得让任何程序员都觉得简单。为了修复bug,你得理解你的代码。为了精密地了解代码,你需要列举和验证你的假设,如果有必要,你还需要构建调试工具。”

贫民窟上的摩天大楼

当然,对于我们的代码,其最大的问题之一是,它继承了如此多其他的代码。特别是在已建立的企业中,我们常常构建在旧代码上,从而导致了各种后续延伸问题。
以下是Zeynep Tufekci的精彩描述:
将它比喻成造房子的话——也就说你将要在已经造好的底层基础上造二楼。但房子一开始造的时候并没有造好,没有打好地基,你也不知道哪面是承重墙。你只能尽可能地去猜,然后造好了一个楼层——用你的手指。然后你接着这样做。很多旧但控制着基础设施关键部分的软件系统就是这样运行的。在某一段时间内它也的确是可以工作,但每一个新楼层的建造意味着增加了更多的漏洞。我们正在代码中建设贫民窟上的摩天大楼——而且,还在地震区。
很显然,我们对于改善这种情况束手无策,除非我们能够致力于去除技术债务。
但也许,只是也许,在心甘情愿折腾代码的过程中,你会发现消除技术债务是如此之重要。

Thursday, August 27, 2015

程序员真的是吃青春饭的吗? 你愿意作甚呢?

在国内,很多人说程序员是吃青春饭的,一开始说过了30岁就得转行,后来又有人35岁是一道坎……看起来好像程序员真的和风尘女子一样,注定有朝一日会年老色衰不再受人青睐。
No!我要说,不是这样的!
所有的道路都通向天堂
只是要度过路上的痛苦时光
那一天我正走在路上
两边的荒草,比人还高
——海子,《月全食》
真的程序员,敢于直面惨淡的人生和淋漓的鲜血,一定能够在荒草满布的岁月荒原里踏出一条自己的路来。
其实别人说的话,听一听就算了,决定还得自己来做。面对别人的怀疑、否定、讥讽,我们只需要坚定地前行,做给他看。行动是最好的证明,多坚持一秒,未来就会不同。
现在就实打实的来看看程序员的价值之路在何方。

应用技术

相当大一部分的程序员都在做应用层面的开发,所做的软件用来解决特定场景的问题,给用户的工作和生活带来方便。
开发一个应用,经常会用到高级语言和框架,比如 C# 和 .NET ,比如 C++ 和 Qt ,比如 J2EE ,比如 Ruby on Rails ,比如 Python 和 Django ,比如 Java 和 Android ,比如 Objective-C 和 Cocoa Touch ,比如 JavaScript, PHP……太多了,数不胜数。
应用层面的开发技术,很多人觉得门槛低,小年轻和富有经验的老资格差别不大,后浪会把前浪拍死在沙滩上,所以当新一茬韭菜长成时,老一茬就得玩完了。
其实不是的,即便从纯技术的角度来讲,你对一个语言和框架的理解与把握程度,也会严重的影响开发效率和产品质量。
什么样的人会被轻易替代?不求甚解,似懂非懂,干了多少年还看不透所用技术的本质,遇到问题仍然懵懂不解茫然无措,这样的程序员,注定很快被一大波正在赶来的小鲜肉挤下工作岗位。
假如你对一门语言的各种特性都体察入微了悟于心,假如你对一个框架的机理和各种应用场景都有独特的理解和丰富的实践经验,那你几乎是不可替代的,你已经成了这个语言和框架方面的专家,价值不可估量。你的一句话就可能为一个项目节省几个月的时间,别人一筹莫展的问题到了你这里分分钟就搞定。
所以,不要理会“能 Run 就行”、“完成任务就可以了”、“用不到学那么深干什么”之类的话,在你用完一项技术解决了一个实际问题满足了某个需求之后,继续钻进去吧,多学一点,深入一点,日积月累,你必然会与众不同。上班时没时间,那就下班了继续投入。记住,你的学习和研究都是为了自己,不是为了老板,不是为了项目,你唯一的产品就是你自己,而这个产品值得一辈子打磨。

高难技术

有一些技术,门槛是相对较高的,比如汇编语言,比如操作系统内核,比如驱动……正因为门槛高,回报也高。比如你熟悉 Windows 内核或 Android 内核,能够熟练撰写各种驱动,那找个月薪五六十K的工作不成问题,百八十K都不在话下。惟其稀缺,所以保值。

算法

大部分程序员其实不懂算法,都是用框架里的模块拼积木。如果你妙悟算法真谛,那你就超越了90%的程序员了,你的重要性和价值将不可估量。
比如你精通图像处理算法,比如你精通视频编解码算法,比如你精通搜索推荐相关的算法,比如你在模式识别领域有建树……试看谁能挡得住你前进的脚步!

业务

在一个行业内持续积累,对业务的理解到位,积累深厚,你的价值是巨大的。不信你去浏览招聘网站上的岗位需求,99%都要求相关行业背景。所以,选择一个靠谱的、前景好的行业非常重要,只要这个行业能够不断发展、前进,你的积累就是有价值的,你自己就是不断增值的。
特定领域的业务有一定门槛,比如金融,比如电力,比如电商,比如彩票,比如考古,比如医疗……在这些行业里,你是个业务门儿清的程序员,即便技术不是特别优秀,那也是价值无限的。

产品意识与思维

究竟什么是产品意识呢?我认为产品意识一般包含商业意识、用户意识、创新意识和团队意识。
——《人人都是产品经理》
互联网时代,产品为王。有产品意识,懂产品思维的程序员,是最受欢迎的人群,也是最能做出好产品的程序员。
商业意识通俗地讲,就是要思考这个产品能不能卖出去,好不好卖。这个一定是要有的,程序员虽然很少直接接触市场,但是一个产品成功与否,多数时候就是看市场表现,如果你能关注市场,从市场的角度来看待技术实现,接纳“技术为市场服务”的理念,那你更容易把产品做好。
用户意识是最容易理解的,它是说我们要从用户的角度来思考这个产品该如何设计,因为产品好不好用最终由用户说了算。如果你在实现产品时也能站在用户的角度来思考,斤斤计较一个功能是否符合应用场景、是否与用户的行为特点吻合、是否贴合用户的使用习惯,那恭喜你,你超越了90%的程序员——大部分程序员是按产品经理和UI设计师的要求来实现产品。
创新是人类发展的源泉,是社会进步的动力,同样也是产品的核心竞争力。但这里所说的创新不一定是那种颠覆性的创新,也许是把众多不被重视的细节做到更好,也许只是把另外一种理念引入到这个产品中去,也许是像海底捞的员工一样给用户不一样的感受,这些都是创新。创新意识是产品经理必须有的,否则,他永远不会有进步,产品永远也做不好。创新意识也是优秀的程序员必须要有的,否则他就不能把一个产品实现得很好,不能把产品的核心竞争力演绎到极致。
当下已不再是孤胆英雄单兵作战的年代,我们要想做好一个产品,多数时候都需要一个团队。团队意识是必不可少的,你是和一帮程序员在一起,你还和产品经理、UI设计师、业务分析师、项目经理等等在一起,如果你能融入团队,并且能影响、促进其他人为共同的目标做出有效的努力,那么,你这样的程序员,是无敌的,是国之瑰宝!
说了这么多,究竟你适合在哪个方向下功夫,还需要你自己来做决断。你可能一看便知自己适合做什么,那无需赘言。也可能你有些茫然,不要担心,我们都还有大把的时间,你可以去试着去做,发现不合适了换个方向再来,直到踏上适合你的路。

Sunday, July 19, 2015

码农 之道 --- 精简你的代码 责任单一制

自己写的代码,很多时候都不喜欢在去看了。因为写的代码重构性太差了!这个就像图片一样的

长得不好看,是没有人愿意去看的。嘿嘿。

单一性原则:
自己的代码,类具体的实现某一单一的功能,减少耦合度,尽量所有的代码,都在一个类职工实现。

抽取原则:
很多时候,我们的代码都是重复的,就像网络的访问,数据库的操作,每一的不同的就是不同的表和连接。所以,我们可以把这些重用度非常高的地方抽取出来,这样,减少代码量。可以调高自己代码质量。