[collect]学习编程的过程中的一些经验[bak]

本文最后更新于2014年10月15日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

之前在知乎上看到的一个讨论,对我来说启发很大,多希望能早点看到这种类型的文章(之前我都干嘛去了o(╯□╰)o),不过现在看到也不算晚,因为,想奋斗,什么时候都不晚。

学习编程的过程中可能会走哪些弯路,有哪些经验可以参考?

@Crossin
回头看学生时代,最大的弯路就是怕走弯路、想不走弯路。
纠结该学什么语言、该研究哪个方向、该做项目还是啃算法,生怕一失足成千古恨,踏上一条不归路。

很久之后才发现,与其纠结选择,不如找个点坚持下去。好比爬山,你在山脚下纠结该从哪条路上去,而实际上,每一条都能通往山顶,每一条都不会是笔直平坦的。你怕错过另一条路的风景踟蹰不前,却不知道只要登上山顶就可以一览众山小。

如果一定要说个经验教诲,那就是尽可能多地写代码、读源码、读文档。

有两个词,一个叫做功不唐捐,一个叫做殊途同归。


@Blueve
学习过程中的弯路是不得不走的,但是学习方法上的弯路还是可以绕的。

得到经验和浪费时间终归是两回事吗?

我是个完完全全自学入门的人,现在虽已经进入科班,但是我认为经验还是可以分享给想自学编程的大家

的。当然如果题主是想要为了信息学的竞赛学习,那我觉得这个答案就不适合你了,你应该选择更为系统,更为针对,强度也更大的训练方法。

1.
大多数人学习编程最早的懊恼就是不明所以的“烫烫烫烫烫烫烫烫”,虽然基本教育的节奏都是从伟
大的C语言开始,但是作为一个早早自学编程的人来看,C语言作为入门语言是很容易打击人的(教材本身的质量也是一个因素),所以如果是自学入门的话,不妨学一学的入门容易规则简单的语言培养语感和基本素养,例如PHP、VB这样的东西,可以很快做出一个可以看可以用的东西,是很有成就感的,有了自信就自然而然得会想深入的提升自己了。

2.
自己当年中学的时候做论坛,那时候流行的是Discuz!,为了做好玩的互动插件学的PHP。当时的感觉是,自学一门编程语言并不轻松,在会的人看来容易的概念其实不容易灌输给完全不会的人。最开始自己就是啃书本,上课都不记笔记的我把学习到的东西规规整整地记在本子上,直到把基础的语法和语言特性都了解了才停止。不一定像我这样,但是作为一个一清二白的菜鸟,一定要让自己有一个把基础的基础看下去的驱动力才可以。

3.
实践是检验真理的唯一标准。实践对于初学者而言非常重要,但是C语言课本上的实践大多是一些就事论事,针对知识的题目,面对一个控制台程序,其实做完了……过几天也不会觉得这个有什么意思,所以我认为一定要尽可能的尝试去做一个可以用的东西。学PHP做个登陆页面呀~学VB仿个Win计算器呀~学Java做个扫雷~总之做出能够对除你之外的人都能有一点点兴趣的东西,对自己是很鼓舞的。在这方面,C语言这种,对于初学者做图形界面比较不友好的语言……主要的问题就是不会让你产生那种真正解决问题的成就感。

4.
最开始的实践是一种拼凑,因为知识的不牢靠,但是需要解决的问题对自己又是如此的庞杂,所以那个时候的代码都是以能解决问题为主,而不是以好的方法解决问题为主。现在回过头来看当年写过的论坛家族,论坛宠物中心,从外观上讲确实是当时一流的,但是背后的代码着实惨不忍睹。不过对于初学的人而言,能够利用现有知识达成目标已经是竭尽全力了。那个时候的编程没有精雕细琢,就是为了实现而实现,也不管有多少if套着if,甚至变量名我都能起成$if。不过我必须承认的是,没有那段经历,我可能不会如此的喜欢编程。当有人使用了你的成果,不管是对他提出建议还是提出赞美,对于一个尚未破壳的菜鸟而言,都是很棒的感觉。说实话,作为初学者,敢写代码,就是个里程碑了。

5.
历史和人的感觉是很像的,当你的代码写得多了的时候,你自然就会觉得写得不好看。照现在的话讲,那些代码一点都不优雅。作为一个逼格满满的人,完成任务已经不再是一个追求,当Ctrl+C/V成了编程的必备步骤的时候,你自然而然的就会思考了:是不是可以不这样做?这是一个重要的过程,你会想要提升你代码的执行效率,你会想减少查询数据库的次数,你会想用轻便的代码实现想要的功能……当你步入这个阶段的时候,恭喜,菜鸟终于入门了。
这是三个大坑,算法优化、数据库查询优化、代码复用。
你得心甘情愿跳进去,再慢慢往外爬。

5.
看上去我好像在抬高PHP一样,其实不是这个意思。我只是觉得作为一个可以立竿见影的入门语言,它是很合适的。进入大学计算机专业后,我和同学一样,一起学习C语言,我没有接触过这门语言,但是我却比周围的初学者们更快更好地接受了它,即便是像内存、数据类型、指针等从没有接触过的概念,我也比别人更快的认识清楚。我觉得这一方面是因为编程所带来的学习能力的提升,另一方面也是因为我自认为我不是菜鸟所带给我的自信和动力。我当时做了很多出格的事情,当讲课、教科书都在用VC的时候,我执拗的使用VS2010,因为我觉得这个用户体验好。在课设说明书还在按照Turbo C说明图形界面的时候,我却找了个能在VS下使用的仿造的图形库EasyX。其实人都是追求美的,老师也不喜欢你开个DOSBOX滚动翔一样的Turbo C给他演示。擅用和检索现有的工具和资源,是这个时期我最大的收获。
当然,这里也挖了一个大坑,用户体验。
前几天知道,我的学弟学妹们都放弃Turbo C了。

6.
在学校的学习过程是这样的:C -> C++ -> Java。
C++和C截然不同,作为一个拥有面向对象特性的语言,它带给我们很多新鲜的概念。尽管初次见面的时候我们彼此都如此羞涩,谁都看不懂谁。在学习C++的时候,其实我并没有提起多大的劲头,只是觉得STL很好很方便,在OJ上刷题的时候能比C省事不少。不过之后看到一本国外的关于物理引擎的书,便又是提起了12分的兴趣看了看。那本书终归我是没有看完,不过只看一部分我便能感受到自己的肤浅——原来类是这么用的啊。
很久之后我才知道这是一个高级坑:设计模式。

7.
之后数据结构的课程设计,按照套路是要用Java做UI的,但是Java的IDE在我的电脑上一直表现不佳,加上调试时候的种种不顺畅,使得我我对Java做窗体程序好感不佳。于是我想起了初中的VB,随后又联想到了它的同门C#(求别问怎么联想的=。=),那种拖拽做界面的爽快感……经过我的推广,班里最后只有一人用Java做UI,还有另外一个人用的MFC。这个其实是想说,我这个人比较懒,所以喜欢找更好的解决方案,存在就有存在的价值,短短5天,所有人都可以用C#做出一个好看的界面,而Java搞得很麻烦又不好看。这不是在谈优劣或是投机取巧,而是在谈生产力、效率。我训练的人可以5天上岗,做得比你训练一个学期的人还要好,那这就是价值。

8.
其实一路走来,站的越高,自己就越容易被颠覆。
当PHP写代码觉得原始的时候,框架这样的东西就会跳在你眼前打脸。
当WinForm程序做起来感觉到代码混搭的怪异的时候,就发现其实还有个WPF。
当觉得Java臃肿性能堪忧的时候,高级的Web技术又会颠覆你对Java的偏见。
……

学习编程的人需要这样一个自我认知和自我提高的过程,老实说,我觉得这其实不算弯路,这可都是经验呀。这些所谓的弯路是你只要踏上这条路就必走不可的,就像是宜家的步道设计,人家设计好就是要你走遍全程。因为这是一个过程,学习过程上的弯路是宝贵的。
至于我之前所说的学习方法上的弯路,大多是指教材选择、训练方法上的弯路,这些弯路可以通过前辈的指导来避免,我觉得这种弯路走上了,就是浪费时间。现在时间这么宝贵,我们都要讲效率的。当大家都说谭老的书不好的时候,就不要选这本书了。当大家都说某些习题没有用的时候,就不要去做了。学会选择,学会甄别,学会找到适合自己的方法,这才是最重要的吗。


@vczh
尽管我觉得我从知识的掌握上是走了很多弯路,但是这些弯路都培养了我的debug能力和独立思考的能力,我觉得都是值得的。


@郭斯特
编程和任何其他事情都一样, 当你学会了Java/C/C++的顺序选择循环时,会觉得自己已经很牛X了,编程不过如此。后来你发现居然有那么多种没听过的语言,甚至既不是面向过程的,也不是面向对象的,看着各种诡异的语法,感觉自己其实还有些不知道的知识。再后来你发现数据结构和算法的水很深,各种不同的Map, List之间的差别迥异,不同的排序和搜索算法诡异漂亮,你觉得还真得好好学学。再后来你发现编程不只是累代码,还得学IDE的高级功能,写测试,学版本控制,编译系统,持续集成,UML, 数据库,云平台,Linux,web服务器等等一套环境,觉得自己以前有点傻X。再后来你发现面向对象编程要有好的设计,要用设计模式,实现可复用,可扩展,低耦合,高内聚的漂亮架构,这已经上升到艺术而不是科学的阶段了,这时候你诚惶诚恐,觉得自己过去十几年的书都白念了,出去都不好意思叫自己程序员。恭喜你,你已经踏入了程序员的门槛,可以称自己为入门级程序员了。

我承认以上说的其实都是我自己的经历和体会,但作为IT民工中的普通一员,我相信很多人和我又类似的学习轨迹。知识像个圆圈,圈内是你已经知道的知识,圈外是未知。当你知道的越多,就越会发现自己其实知道的很少。所以作为初学者, 多看看书,拓展一下知识面,把圆圈撑大是很有好处的,起码你要知道这个圈子里经常用到的技术有哪些,哪怕不清楚细节,也要知道它大概是做什么的。之后在工作中需要用到这个技术时,再去仔细钻研。但预先学习一下基础的知识,总是有好处的。


@hoterran
花很多时间比较语言的优劣。

有这些时间两门语言都入门啦。

怕吃亏是学习的一个大忌。

工业语言和新型现代语言都值得学习。


@林建入

写一个小程序都要考虑半天可扩展性;起个变量名都要想半天如何才能优雅;没有设计清楚不敢动手写;喜欢用各种“新兴技术”;满嘴技术名词装作高大上;凡事从轮子造起;钻研太多的技术细节却越来越脱离实际……幸好后来我听我女朋友的按时吃药,现在终于快要痊愈了。


@储晓颖
“走弯路也是累积经验的过程” —— 不能赞同更多。

但是从题主问这个问题来看,应该是抱有快速学习和成长的愿望,这个时候就不仅仅要考虑长远的成长和经验积累了,我相信题主更在乎的是性价比——我付出的学习成本是否能较快的看到回报。这个时候,确实是应该正视学习方法,避免少走弯路。

举个例子,我们团队是偏底层JAVA中间件,但免不了也要做一些web页面、前端程序,来展示数据、做后台管控。团队里都是算法好手、分布式精英,然而面对javascript、css时却步履维艰,margin、padding调的一头雾水,稍微难一点的交互、拖动功能就捉襟见肘。

此时可以很明显的看到团队里的同学有两种人,一种会各种google、百度,搜到demo,照葫芦画瓢,写出丑陋的代码完成任务交差;另一种会去买一本《Javascript权威指南》猛啃几个月,成为一代js大师。

这两种人,哪种走了弯路?长期来看,一代js大师肯定功德圆满,简历上可以自信的加上精通js一栏;而应付交差的同学则无甚亮点。但是短期来看,应付交差的同学快速完成了前端任务,把时间和精力都投入到中间件最精髓的分布式、高并发、性能优化上,对自身、对团队都提供了巨大的价值;而一代js大师这段啃书时间则耽误了他在项目上的贡献。

我大学的时候Spring正火的无法无天,按耐不住买了一本《J2EE without EJB》砖头宝典,啃的不亦乐乎,但现在已经记不起书里的任何内容。最终让我真正理解IOC、DI精髓的,还是在后来的一次J2ME小项目,当我new出几十个角色对象、把它们在各自的构造函数里传来传去、自己都理不清对象之间的依赖关系时,我才发现我需要的是Spring的理念。这段小经历,对后来各种工作都受益匪浅。

我抽象能力有限,没法总结出一套少走弯路的方法论,但我可以举出几个“走捷径”的例子,以供参考:

大二的时候做公交车线路查询软件,我有限的程序思维在遇到会出现环路的公交线路算法时完全崩塌,再也没有信心能凭着自己的能力做出这个软件。直到后来一门让人厌恶的离散数学课上,我无意翻到了图论的那一章……结果就是我不仅完成了半年前的这个软件,而且还得到了大学四年唯一的一门90分。

大三的时候做手机客户端,解决少数民族的文字输入法,当用户提出手写识别的需求时,一直在堆砌代码的我束手无策,直到在图书馆无意翻到一本神经网络的书的第九章——有监督的hebb学习……迄今为止,没有读研的我,依然还能拿神经网络的知识去面试刚毕业的硕士同学。

在IBM实习的时候,SOA火遍全世界,想学都不知道这是个啥玩意儿,打开几份IBM的SOA教学文档,把人看的三观尽毁、自我否认的情绪弥漫良久。直到进入支付宝,在测试环境想要测一个中游系统的功能时,各种在上游系统找入口、在下游系统找输出,才真正理解SOA是个什么玩意儿。

类似的事例很多很多,如果说学习真的有捷径,那我能想到的就是目标性很强的——实践出真知。
最近在学习erlang,我的学习方法很简单
1 找到一个对自己项目可能有益的应用场景(比如快速文件传输)
2 按网上教程手把手搭建环境
3 抄一段client-server交互的代码、一段文件I/O有关的代码
4 修改+尝试+google
这么浮躁的年代,确实没有心思去啃砖头书了。各位原谅我的急功近利……


@付强
以为这问题可以跳过,其实你根本跳不过。以为百度很厉害,其实google才最给力。以为英语根本没用,其实英语才是编程基础。以为自己很牛屄,其实渣渣都不如。以为编程需要强大的数学能力,其实根本没那么邪乎。

编程就像写作,画画,一开始都是阅读和临摹。

先设计再实现,有轮子就用,不怕bug,不怕别人的bug。

读懂别人的代码比自己会写要nb。

不用妄自菲薄,越厉害的大牛越找不到对象。


@刘炜
别纠结于选择,重要的是坚持。


@叶泽韬
走的弯路太多了,因为走这些弯路,浪费了我太多宝贵的时间和精力,我这里总结在下面,希望后人引以为戒吧!

1.讨论哪种语言好是完全没有意义的。某种语言之所以产生,是因为当前该领域没有很好的解决方案,人们需要更合适的语言来解决特定的需求。没有最好的语言,只有合适于解决某个需求的语言。

2.多看书,多看代码。有的人说关键点是多写代码,我倒觉得是多看书和开源代码。烂代码写一万遍还是烂代码,你的水平不会有提高,但是读了书和开源代码,你会发现对于某个问题的解决上,书里的和开源代码里面告诉你的解决方案比你自己的解决方案要优秀多了,下次你就可以写出高质量的代码出来。同时,书会系统的较完整地告诉你知识,看完一本书,你的能力会有显著的提高。

3.少看些没营养的科技/IT新闻。科技圈很热闹,从来不会有安静下来的时候,每天都有各种各样的新闻出现,但是事实上,大部分的新闻过几天大家都会慢慢的忘记掉,也不再关注,媒体的注意力又集中在新的东西上了。有时间刷这些无聊的科技新闻,不如好好的看一本编程书,提高一下自己的水平。

4.多和比你优秀的人同行。榜样的力量是强大的,从他们身上学到的东西和习惯,将使你受益匪浅。

5.多出去走走,多和亲人朋友联络。看看真实的世界,你会发现其实真实的世界要远比计算机的世界更丰富,更多彩,也更重要。


@齐鹏
大忌就是不肯学新东西。时刻记住“选择最适合任务的语言,而非最熟悉的语言”这句话,往往能事半功倍。


@RefuseBT
一开始不要为学哪种语言发愁,干到最后你会发现,所有流行的基本都得看一圈。很少有用一个东西用到头的。c、面向对象、脚本语言以及数据库都要了解一种,一上来太多可以不精,了解适用范围,使用特点。数据结构其实很重要,常用几种的特性一定要知道。设计模式什么的不用那么较真,重构多了,基本模式什么的都是打散了用的,以适应项目为主。设计模式只是告诉对于一些问题已经有比较好的解决方法。


@Gnix Feng
我学习编程最大的弯路就是入门用了潭浩强的书!

学好一门编程语言,首先就要学好基础,然后再循序渐进的深入学习。我上大学前对计算机一直只停留在开关机、打开浏览器、登录QQ的水平,大一学习C语言入门用的是潭浩强的,当我千辛万苦看完每一章节,做完里面的练习(包括混论坛提问)。上手写完里面的所有代码,自己又写了个千行代码的小程序后,以为可以,就想可以做点什么了,就在网上找做项目的书。但当我买了本《C++primer》看后,我发现我还差得远呢,而且深深的感受到,为什么入门时用的是潭浩强的那本入门书!!!
——————-以上只是吐嘈下—————
我觉得如何学好一门编程语言的方法,也许可以拿下面的代码来讲述:

大概就是这样吧!


@追逐pursuit
我的弯路就是不够努力。。。
其实都不难,只要努力,用心,都能学会成为高手


@ched
总而言之,「折腾」。

虽说在这条路上总得折腾几下,但是上瘾了就不好了,就我而言:
1. 折腾编辑器 vim, emacs 之类
2. 折腾各种工具的选择
3. 折腾 Linux 配置,美化之类
现在觉得把大把的时间花在这些上面真是太愚蠢了。自己和别人一样都把大把的时间投入进去,但是最终水平却远不如人,所以我觉得尽管折腾有积极意义,但是真的不值得去做。

建议把时间花在有计划的学习和有针对性的实践练习上,不要想做什么就做什么

参考这篇文章:The Most Valuable Lesson I Learned from Playing the Violin

====
想得太多,书看得太少

光熟语法,没认真学标准库及各种编程环境
太晚知道正则表达式
太晚知道版本控制软件,尤其是git
======
对某种技术(语言,平台)怀有宗教般的热情是有害的。

在学校非开源的东西瞧都不瞧,那时候觉得在 Windows 上用 IDE 学习编程太 LOW 了,非得在 Linux 下用 Vim , Emacs 才能称得上真正的程序员;Windows 这种操作系统根本就是给小白用户准备的,怎么能配得上我们高贵的程序员呢,程序员电脑上都应该跑自己 DIY 的 Linux。

工作一两年之后为自己当初的狭隘感到羞愧。Windows + IDE 确实有着很高的生产力;语言和平台也没有我以为的那么水火不容,掌握 C# 会对掌握Java 有极大帮助,熟练运用 SQL Server 别的 SQL 数据库也不是难事 … …

这段经历告诫自己做实事,多思考,不要停留在表面。
————
大神们已经说的非常深刻了,那么我跟楼主分享一下我大学这几年学编程的经历吧,当成自己的总结,也希望能给题主一点借鉴的作用。 1、我的大学环境及高中以前的教育背景。 大学之前我接触电脑的场景只是在网吧打dota,高三没怎么努力,考进了一个二流大学(但我还是爱这所大学,她给了我成长环境);进入大学之后调到了计算机专业。 2、大一,从井口中仰望世界。 现在想起大一的时候的一些想法啊,好可笑的,那个时候觉得上课老师好水,于是每次上课花十多分钟看完这节课的内容,然后就干自己的事情了,我真是无知啊!(题主上课千万要认真,别像我~~)自己的思维更多的是围绕自己的,而不能考虑更多的东西,这段时间是比较幼稚的。在编程方面,我在军训的时候用中午的时间看了大半本C语言教材(学校自编的教材你敢信!还有就是那个时候居然可以中午不睡觉,现在完全做不到了啊),这直接导致了我后来参加校ACM选拔考试的时候简直无压力了,当然,我的数学还是凑活的。大一一期基本在弄ACM了,各种算法,各种练习,到了二期,我对ACM的兴趣下降了,觉得ACM没意思,就放弃了(这不知道算不算个错误的决定)。大一就是这样了,一直投入ACM,弄各种算法,各种数据结构。所以这段时间基本还是不明白自己要干什么,学什么。 3、大二,受学长影响! 我有位很好的学长兼朋友他是学java的,所以我就学了java,看了《think in java》 《java 核心技术1》两遍,然后就开始啃jdk7 API (API是我读过的最无聊的东西),其实api现在很多也不记得,但是这个过程中培养了学习能力和阅读外国文档的能力(我认为这两个能力是核心竞争)。在第一个寒假我还把c++ primer plus 扫了一边,主要是考虑到有c++的课。大二的第二期,又学了java web的各种东西,具体的什么servlet啊,mysql数据库啊,http协议啊,MVC,REST。基本能写个小网站小论坛啥的,但是没有学习什么框架,因为基础不牢,框架用的太多会局限思维。这个阶段看过的资料有,mysql document ,网上的javaweb教学视频,tomcat源码(一部分吧,要读完就真NB),java核心技术2。这段时间做的不好的就是没把刷ACM题的习惯保持,导致现在都没能再次养成了。 4、大三,越学越弱的感觉 到了大三,差不多就是最后的一年大学生活了,大四都是各种找工作找实习了,要么考研。大三上学期呢,就是去年,偶然的机会知道了cuda和opencl,然后就去学了这个东东帮老师优化他的粒子群算法什么的,还好以前c和c++还是蛮认真,要不然真搞不定。这段经历让我接触到了高性能并行计算的知识。这个时候也开始用ubuntu了,开始很不适应,后来就彻底放弃windows了。用了ubuntu之后,开始了解开源,了解github。也开始接一些小的项目,一般1w一下的,四五个人搞,这里提个建议,大学里面项目其实不宜过多,有经历就好。这个时候我的编码能力和代码视野已经比周围的人强了(但是毕竟是个二流大学咩,外面大神多得是呢)。大三二学期呢,就是这一期了,打算学习一些框架了,就是java的ssh了,毕竟我也要找个实习了。开学到现在也在同步学习linux内核的源码。感觉比较有兴趣,操作系统真是很伟大的软件。随着学的多了,代码视野大了之后觉得自己真是很弱很弱。 5、总结一下吧 a、 大学一直还是有在玩游戏,我个人觉得这个不好的习惯。 b、 社交能力没有好好的培养,这是我最头痛的地方,望题主要多多注意这方面。 c、 没谈妹纸,估计大四也不会有了~~~唉。题主高富帅自然木有问题了。 d、 感觉自己比较属于有知识,没文化的那种,望楼主大学要多看书。 e、 苦B的大三党还不知道自己的这些个东西能找个啥工作。 6、最后的建议 大学真的不能浪费时间,我自己还是浪费好多时间,呜呜,学会时间管理很重要啊。别怕走弯路,多学,代码视野会大些。在生活中多思考思考,有什么好的想法就code出来,自己写的各种小工具能方便自己的学习和生活,还有就是相信付出才有回报的。 7、最最重要的 a、没有比coding更重要的了,代码写的多才能体会一些深层次的东西。 b、自学能力! 鄙人大学三年就是这么呼噜过了~~~~~~希望能给题主一些借鉴,另外感谢忍受我粗烂的文字一直读完了的人。


@Van Bruce
各种大神们说的都不错了,不才补充几句,权当来狗尾续貂罢。

走过最大的弯路,是对于“基础”的看轻,导致我工作三年后仍然在回头补课。

程序算是我自学的吧。当时自学的时候,把重点放在了“如何实现功能”,而非去摸透更深层的实现机制。那些被计算机系的学生睡过去的课,我没有意识到重要性。当然,再怎么不在乎基础,也还是把数据结构当回事看的,但我也仅仅做了这些而已。

我现在在补什么呢?

离散数学、编译原理、JVM、计算机结构……等等很多本该大学本科就该牢记的基础,现在成为了我自身提高的瓶颈

不要急躁于看到编译结果,做好基础知识的吸收和理解,否则,你将为此付出更多的代价去补课。

世上本没有弯路可言,有的只是宝贵的经验。

 

 

原文讨论地址:

学习编程的过程中可能会走哪些弯路,有哪些经验可以参考?

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/1481.html

《[collect]学习编程的过程中的一些经验[bak]》上有22条评论

  1. 增进编程技能的万全之计
    http://www.infoq.com/cn/articles/one-sure-fire-way-to-improve-your-coding

    增进编程能力最明显的方式就是尽可能编写更多代码,除此之外,我们还可以通过另一种方式增进你的编程能力——阅读别人写的(好)代码。

    选择可供阅读的代码:
      阅读你所依赖的代码(首先可以读一读你目前正在使用的任何插件或库的代码)
      阅读让你印象深刻的代码(最近有什么东西让你印象深刻吗?是否是开源的?如果是,那么也许很值得一读,因为代码本身可能会像应用程序一样让你留下深刻的印象。)
      阅读你所敬重的人写的代码
      阅读你可以完全领会的代码

    最佳阅读“姿势”:
    从大局着眼
      在宏观层面了解自己要阅读的代码所实现的功能,全局了解整个项目的结构,注意文件结构。
    记录你的发现和结论
      代码的阅读不应该是一种被动行为。建议你能在阅读的同时添加自己的备注,随着对程序流程的理解逐渐深入,记录你的猜测和结论。随着理解的深入,也许可以陆续删除一开始留下的浅显的备注,并开始写一些更有意义、更权威,甚至能对整个项目产生真正回报的备注。
    如果可以,一定要测试
      阅读其他人写的代码时,测试是一种很好的起点,因为其中记录了不同代码本应实现的功能。
    执行,修改,执行
      谁说读代码就只是“读”代码?如果能将一切拆解又重新组装起来,才能获得真正的理解。

    周而复始的重复
      读完一个代码基后,挑选一个新的再次开始这一串过程吧。读的代码越多,阅读的收获就越多,获得这些收获所需付出的时间则会越少。我认为你会发现自己在时间方面的投资回报会飞速增加,并且整个学习过程会编程更愉悦的体验。

  2. 无我编程的十条戒律
    http://www.infoq.com/cn/news/2017/06/10-Commandments-without-program
    https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/

    1.接受自己会犯错的事实。关键是要在错误进入到生产环境之前把它们找出来。
    2.不要使用代码来针对个人。要记住,代码评审的目的是为了找出问题,而且总归会找到问题。
    3.不管你知道多少“秘籍”,总有人比你知道得更多。
    4.不要不经讨论地重写代码。
    5.尊重非技术人员,并对他们抱以耐心。
    6.这个世界唯一不变的就是变化。敞开胸怀,面带微笑地去拥抱变化。
    7.真正的权威来自于知识,而不是职位。知识造就了权威,而权威会迎来尊重。如果你想要在一个无我的环境里得到尊重,那么充实你的知识吧。
    8.坚定你的立场,优雅地接受挑战。
    9.不要成为“小黑屋里的人”。
    10.批评代码,而不是人。对人好一点,而不是代码。

  3. 10年老兵给程序员的10条建议!
    https://www.jianshu.com/p/80bde6eb5e03

    1. 想清楚,再动手写代码
    刚入行的新手,为了展示自己的能力,拿到需求迫不及待地就开始上手写代码,大忌!

    2. 不交流,就会头破血流
    不爱说话和沟通,需求都理解错误了,最后做出来才发现,只能加班返工。

    3. 文档没人看,但还是要写
    文档的作用大部分时候不是用来沟通的,是用来做记录的,大部分需求还是通过口头沟通,但是不写文档做记录,后续就容易扯皮。

    4. 一定要写注释
    时间久了,你会连自己的代码都看不懂。

    5. 别指望需求会稳定
    产品需求是根据商业需求不断调整的,改需求是再正常不过的事,别抱怨。

    6. 业务高于技术
    如果技术不为公司商业做服务,那将毫无价值,公司赚钱才是硬道理。

    7. 不要心存侥幸
    你隐约感觉会出bug的地方,就一定会出bug。

    8. 自己先测几遍
    不要写完就扔给测试人员去测,经自己手的东西,要保证质量。

    9. 尽可能自己解决问题
    遇到不懂的问题,要先尽力解决,别动不动就截个图扔在别人求帮忙,上司和同事不是来给你擦屁股的,但是真的搞砸了就要尽快求助。

    10. 慎用新技术
    新技术是好东西,但没有百分百把握,自作主张用了,多半是作死。

  4. 闲话高并发的那些神话,看京东架构师如何把它拉下神坛
    https://mp.weixin.qq.com/s/FLpdT9wZFT0sJBmNTCIObw

    0x00 一切源自网卡
    0x01 一头雾水
    0x02 没有连接,就没用等待
    0x03 感谢操作系统
    0x04 核心矛盾
    0x05 中断与缓存
    0x06 高效利用网卡
    0x07 阻塞式IO
    0x08 非阻塞式IO
    0x09 多路复用IO
    0x0A select和epoll的区别
    0x0B Reactor多线程模型
    0x0C Nginx多进程模型
    0x0D 突破木桶理论
    0x0E 并行与并发
    0x0F 多线程设计模式
    0x10 消息传递模型
    0x11 Actor模型
    0x12 CSP模型
    0x13 多样世界

  5. 程序出现bug是必然出现的情况还是程序猿水平有限导致的?
    https://www.zhihu.com/question/288732719

    程序出现bug,既是必然情况,也和程序本身的难度、规模,程序员的水平、责任心乃至公司正规程度息息相关。

    低级bug:100%是程序猿的锅,不仔细看需求文档和设计文档导致实现结果偏离需求,写的时候不认真各种说出来丢人的拼写错误,写新代码不知道考虑对已有代码的影响上手就胡来,写完代码自己都不自测一下就提QA。这都是没有职业修养的表现,QA测出bug你不背锅谁背锅!

    业务逻辑bug:通常源自需求沟通出现问题,这往往是所有人同时出问题,而不是某一个地方出现问题。第一环节是需求方自己说不清楚,第二环节是需求分析师没理解需求,第三环节是设计师没有动脑子还没做设计评审,第四环节是不跟需求方做需求设计确认。

    深度逻辑bug:不能把锅推给任何一个人,设计、开发、QA全都有责任,但这种bugQA通常根本测不出来,一般要上线稳定运行好久才被发现,而且会相当难解决。

    性能缺陷bug:逐层背锅吧。开发能力不足,原子功能执行效率低下;设计不合理,高性能原子功能组合成模块性能低下;架构不合理,高性能模块联合成整个系统死活是玩不转。

  6. 我的程序方法论
    http://ftomcode.cn/2019/01/18/%E6%88%91%E7%9A%84%E7%A8%8B%E5%BA%8F%E6%96%B9%E6%B3%95%E8%AE%BA/

    程序开发要沉淀自己的方法论。说到方法论大家会觉得比较虚。是一个抽象的东西。我认为的方法论是做开发,做业务过程中 采用的能够提高效率,减少出问题概率的一些做事方式和思维习惯。

    需求分析
    what【这个需求是什么,在什么场景下使用,谁来用】
    why 【为什么要做这个需求?能给用户带来什么价值?】
    how 【怎么做,是否可以不做,是否可以换其他方式来达到同样的目的?异常情况有哪些,针对异常情况如何处理?有哪些潜在的体验问题或者性能问题?】
    when 【这个需求完成时间结点是什么时候?跟哪个版本?什么时候转测?是否是重点特性?】

    方案设计,接口设计,协议设计

    日常工作
    善用自动化提高效率

    系统压测和优化
    系统压测需要先量化,然后才能展开针对性的优化。

    切入新项目

    系统架构设计
    架构设计的目的是为了降低软件复杂度,减少维护和扩展的成本。 架构设计需要根据业务特性,有选择性的在【高并发,高可用,扩展性,安全性, 可维护性】 几个特性之中做出选择,同时 要兼顾开发进度和部门团队的实际人力情况,支撑部门的支撑力度。

  7. 无我编程的10条诫律
    https://mp.weixin.qq.com/s/1ccYgHixRX1-7vOCGun2DA
    https://blog.codinghorror.com/the-ten-commandments-of-egoless-programming/
    https://blog.codinghorror.com/egoless-programming-you-are-not-your-job/
    http://blog.stephenwyattbush.com/2012/04/07/dad-and-the-ten-commandments-of-egoless-programming/

    无我编程的10条诫律最早出现在 1971 年 Gerald Weinberg 出版的《程序开发心理学》中。后由Stack Overflow网站的联合创始人 Jeff Atwood 在其2006年5月9日的博文《无我编程的10条诫律》中再次列出。

    Understand and accept that you will make mistakes.
    理解和接受自己会犯错误。

    You are not your code.
    不要使用代码来针对个人(你不是你的代码)。

    No matter how much "karate" you know, someone else will always know more.
    不管你知道多少“秘籍”,总有人比你知道得更多。

    Don't rewrite code without consultation.
    不要在没有讨论的情况下重写代码。

    Treat people who know less than you with respect, deference, and patience.
    尊重比你懂得少的人,并对他们抱以耐心。

    The only constant in the world is change.
    这个世界唯一不变的就是变化。

    The only true authority stems from knowledge, not from position.
    真正的权威来自知识,而不是职位。

    Fight for what you believe, but gracefully accept defeat.
    坚定你的立场,优雅地接受挑战。

    Don't be "the guy in the room“.
    不要成为“角落里的程序员”。

    Critique code instead of people – be kind to the coder, not to the code.
    批评代码,而不是人。

  8. 程序员应该怎样提高自己
    https://blog.codingnow.com/2019/07/top_programmer.html

    引我爱上编程,并乐此不疲的学习,是“我能写出更高效的代码”这种乐趣。如果一个人在学习编程开始,不努力让自己的代码变得更高效,发现不了优化的乐趣,我想他很难爱上编程。Don Knuth 说,Premature optimization is the root of all evil ,这句话背后的道理,不必一开始就强行接受。evil 最能蛊惑人心,但是我们需要它引入门。

    朝着优化这条路走下去,你会有自发的动力去了解计算机的本质架构,理解操作系统,理解内存模型,理解新的软硬件技术(它们大多数都是为了让程序跑的更快而发明出来)。否则,现在去学习这些东西,并不会体会到现实的意义。软件开发在今天,大部分的工作都在很高的层次了,大部分人的日常都在完成一些琐碎的业务,用不到这些。但实际上,你在融汇贯通后,可以在很高的层面凭经验就能从蛛丝马迹判断出底层发生的问题;可以从一些代码片段,判断出整个模块的设计意义。这些是无法作为单独的技能学会的。

    精通一门语言是最基本的要求。所谓精通,就是要了解这门语言的各种阴暗角落。用每一样语言特性的背后的代价。知道在面临各种问题时用这门语言解决该问题的惯用法。大部分通用语言都会有设计缺陷,表现在具体方面就是面对某些问题,写起来直接了当,而另一类问题时却要绕很多弯弯,这些绕弯弯的部分就需要用某种模式去弥补。我认为,所谓编程的设计模式,并不是跨语言而独立存在的,它们是强烈依附于编程语言的。《设计模式》这本书,我读过的版本是基于 C++ 的,设计模式被谈论的更多的是在 Java 社区。这类模式都有很深的语言烙印。我们学习设计模式其实学的就是一门语言的惯用法。

    初次学习设计模式时,肯定会有豁然开朗的感觉。但不应把自己陷入其中。为了提高一次层次,就必须精通至少第二门的语言。我的第一语言是 C ,第二语言是 Lua 。但对于许多人,肯定会有很多更好的选择。多看看不同的语言下解决问题的不同方式,有助于提高编程技能。

    在我谈论程序员的编程技能的时候,我指的通常是两类能力:一是运用熟悉的编程语言,用在该语言下最高效的方法解决需求的能力;二是领域知识,尽量多的了解工作所处领域前人的积累,已存在的软件层次的接口,接口背后的代价。这两者缺一不可。不要用自己学习能力强为借口,认为随时可以进入一个新语言,一个新领域,而不会比别人差。不管是一门语言的使用,还是对一个领域的了解,都是需要长期的实践刻意积累的。

    以上,都是我认为一个程序员对自己最基本的要求。这些东西多么精进都不为过。但还有一些更高层面的东西。

    那就是分解问题,保持简洁的能力。也可以说是规划和构架的能力。这是超出编程语言,具体问题领域的,不过绝不能绕开它们。如果一个程序员编码很粗糙,或是对所在领域一知半解,我绝对不会信任他做的设计。

  9. 程序员的进阶之路
    https://github.com/wx-chevalier/Awesome-RoadMaps

    三个问题:
    应该学习什么?这是怎样的一个技术世界?存在着怎样的高峰与路径?
    如何克服遗忘带来的无效学习?
    如何不再碎片化地学习?

    产品经理
    前端
    安全与渗透
    技术之外
    服务端架构
    测试与运维
    算法与大数据

发表评论

电子邮件地址不会被公开。 必填项已用*标注