这个技能看起来似乎没有必要强调,毕竟程序员不懂一种编程语言也说不过去啊。我之所以再次强调是怕你“贪心”,以为技多不压身就拼了命的学很多种编程语言。
有个大二的学生就曾经问我:“你好呀,老哥,有个问题想咨询一下您,我专业学的是 C#,但听说以后不太好就业,所以就自学了一段时间 Python,但感觉越来越混乱了,您有什么好的建议吗?”
我只能说不混乱才怪。编程语言虽然有相似的语法,但毕竟是不同的编程语言啊,之间还是有很多差异的。对于初级程序员来说,切勿贪多,先把一门编程语言吃透再说,等你有了融会贯通的本领,再去学新的编程语言也不迟。
我刚刚查了一下(见下图),C# 还是挺热门的编程语言,没到不太好就业的地步,别随便听信别人的话,要学会自己去判断。Python 是门不错的编程语言,增长势头很猛,但远没到那种独霸天下的地步。
学校有不尽人意的地方,但不至于蠢到让学生学一门已经被市场淘汰的编程语言。在这一点上,我宁愿站在支持学校的立场上,否则就太糟糕了。
我承认,学霸学什么都快,不仅学的快,还比平常人学得好,学得多,因为他有一套自己的学习方法,但大部分学生并不具备这种条件。如果你对自己没有这种认知的话,很可能会陷入泥潭。
因此,我给出的建议是,深入并且专注于一种编程语言,当你对使用这种编程语言充满信心时,再去学其他的编程语言也不迟。
当你学会一门编程语言之后,接下来要考虑的事情就是让你编写的代码变得更整洁,更易于理解,更富有艺术。关于艺术,我想到了一段话,王小波在他的杂文《用一生来学习艺术》说的:
我念过文科,也念过理科。在课堂上听老师提到艺术这个词,还是理科的老师次数更多:化学老师说,做实验有实验艺术;计算机老师说,编程序有编程艺术。老师们说,怎么做对是科学,怎么做好则是艺术;前者有判断真伪的法则,后者则没有;艺术的真谛就是要叫人感到好,甚至是完美无缺;传授科学知识就是告诉你这些法则,而艺术的修养是无法传授的,只能够潜移默化。
不得不说,偶像就偶像,把艺术的真谛阐述得很清楚。我见过不少臃肿的代码,它们让我想起“裹脚布”这三个字;我也见过不少整洁的代码,它们让我想起“艺术”这个词,我想创造出它们的程序员一定富有工匠精神。
Elliot Chance 曾表达过这样一个观点,他说:“要分辨两个程序员的优劣,就是给他们一样的时间,越好的程序员写出来的代码越少(当然是可以运行的)。”
我同意他的观点。越多的代码并不一定代表着认真,有可能代表的是懒惰,懒得去思考,才会写出臃肿的代码。如果我们程序员没有这种(写更少代码的)追求的话,那我们的编程技艺就只会原地踏步,长此以往的后果就是各种避免重复造轮子的第三方类库就不会出现。
说起来惭愧,在很长的一段时间里,我对算法和数据结构存在着很大的偏见,认为它们就好像悬挂在夜空中的月亮,虽然很美,但却很遥远。
因为这种偏见,在敲代码的过程中吃了不少的闷亏,经常遇到一些实际的问题,由于无法充分利用数据结构将数据之间的关系通过合适的算法策略进行有效地存储转换,就导致程序的性能很低。
作为一个吃过亏的男人,我必须要负责任地提醒你,趁有大把的时间和精力,多投入一点到数据结构和算法上面去。基础知识就像是一座大楼的地基,它决定了我们的技术高度。数据结构和算法就是最重要的基础知识,学习它们的过程就像是在打地基。
举个例子来说,假如你要在一个列表中对元素进行排序,那么可采用的算法就有下图中的这 10 种,每种算法所花费的时间,所占用的内存都不尽相同。换句话说,如果你不能够熟练地掌握算法和数据结构,就很难找出一个优雅的解决方案。
长期来看,大脑思考能力是一个人最重要的核心竞争力,而算法是为数不多的能够有效训练大脑思考能力的途径之一。有了这项能力,很多别的程序员解决起来很困难的编程问题在你这里就会迎刃而解。
虽然软件开发人员更应该专注于程序设计而非编写和优化 SQL(应该交给专业的数据库管理员负责),但在我们国内,只有顶尖的企业才会有数据库专家。扎心了。如果你想要在软件开发这条道路上走得更高更远,懂一些基本的数据库知识是必须的,比如说:
如果再懂一些数据库分库分表的中间价,那你可能就会成为团队的宝贝了,毕竟所有的应用程序都要与数据库交互,另外,数据库是系统最先出现性能瓶颈的地方——总有你大展身手的时候。
除了要吃透一门编程语言,我强烈建议你再学习一个技术框架。如果你像我一样是个 JAVA 后端开发人员的话,Spring 的系列框架(Spring MVC、Spring Boot、Spring Cloud)就不得不学了;如果你是一个 C# 开发人员,.NET Framework 就不得不学了。
技术框架是一组通用类库的集合,它帮助我们让编程任务变得更简单,毕竟轮子替我们造好了。假如说没有技术框架的话,我们就好像坐着马车前行,而不是飞机、高铁和汽车,开发效率就要大大降低了。
记得我刚参加工作那会,用的源代码管理工具叫做 CVS(Concurrent Versions System),估计有不少读者没听说过,非常非常难用。后来迁移到 SVN(Subversion)后,情况总算是有了很大的改善,它不仅支持 Eclipse,还有专属的客户端,除了管理源代码,还可以管理许许多多的文档。
每天上班的时候先从服务器获取最新的代码,然后开始一天的工作,下班走之前切记要提交一次代码,否则就很容易耽搁团队其他成员的开发进度。
现在呢,有了 Git,它是一套开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。它与 SVN 最大的不同之处,在于每个开发者的电脑上都会有一个本地仓库(Local Repository),即便是没有网络也一样可以提交版本,查看版本,以及比较版本;等到网络连接上之后,再提交到服务器端。
源代码管理工具最大的好处就在于它可以帮助我们保留不同文件更改的历史记录,并且允许多个开发人员对同一文件的代码进行合并。举个例子来讲,小王完成了一项任务,然后提交了代码;但他觉得有待改进,于是他重新修改了代码并提交到了版本库,谁知道,程序上线后出了 bug,这时候源代码管理工具可以帮助他快速回滚到之前正常的版本。否则的话,小王只能被祭天了。
测试真的是太重要了!但并不是所有的开发者都这样认为,这种感觉在我回到洛阳后尤其强烈。竟然有团队成员不经测试就把代码提交到代码库,并且是会报错的那种,我天呐,遇到这种队友我也是醉了。
在我回来之前,是在一家日企工作,测试是一项非常重要的工作,占用的时间比代码编写的时间多多了。从单元测试到集成测试,所有的测试结果都要整理成册,所有的边界条件都要测试到,哪怕你觉得完全没有必要。但正是这种一丝不苟的态度,成就了日企软件高质量的美誉。
一个优秀的开发人员绝不允许他的代码在交给别人之前不经测试,我想这是不容置疑的。
说句实在话,在我做程序员的这 10 年里,调试代码的时间比编写代码的时间要多得多。因为解决 bug 的难度要比创造 bug 难得多,首先你要先复现问题的场景(真的是难啊),要复现问题就需要你拥有出神入化的调试技巧,否则只能锤爆鼠标,然后大喊“为什么,为什么,为什么我的代码无法正常运行呢?”
入门级的调试很简单,你只需要在发生问题的代码处打个断点,然后再跑一跑,就能从堆栈信息和代码的上下文中发现问题。难度再上升点的话,就需要你创造代码执行的条件;再难的话,你甚至需要内网穿透,比如说微信公众号开发;再再难的话,就不是一句半句能说得清楚了。
总之呢,调试就是为了让你弄清楚代码不能正常运行的真正原因,如果你的调试技巧不过关的话,甚至有可能会被表象蒙骗,从错误的角度去修改 bug,从而引发更多、更大的问题。
由于我是 Java 技术栈的,顺便推荐几本 Java 的书籍,从左到右的顺序看到