Fork me on GitHub

程序员需要每天写代码吗?

程序员需要每天写代码吗?

我的回答是:是的!
作为一个程序员,我觉得每天写代码是必要的,但不是为了写代码而写代码。
每天写代码,是为了保持对代码的熟悉感,以及对一些逻辑、思维方式、设计模式等保持一种敏锐的感觉。一个再强大的程序员,四五年不写代码,照样什么都忘光了。就像一台电脑,如果一直用着反而不容易坏是一个道理。
程序员需要每天都写代码,但也不是行数越多越好。不能通过代码的行数来硬性定义一个程序员的对编程精通的程度,就像并不能单纯通过程序员编程的年数来定义一个程序员的优劣。

程序员每天要写哪种代码?

程序员可以写文档、博客或者其他文章,但必须要加进自己写的代码。其实,程序员每天做的是思考,将编码养成一种习惯。每天写自己的代码,可以让我们养成善于思考的能力,可以增强我们对设计模式的了解与使用。也更容易培养我们写好代码的习惯。
曾经有人说:“平均有20行有效代码每天,就是世界级水平了。绝大部分时间你都在反复改写、修订已有代码。”
其实在很多外行眼中,我们程序员做的最多的就是复制粘贴。可能大多数人也确实是这么做的。但是我觉得这些都不算是有效代码。

什么算有效代码?

个人理解,有效代码应该是你觉得能够学到东西,或者有所感悟的代码,每天有这么20行确实也够了。很多人,每天为了完成功能而拼命地写代码,都是以前有着类似功能的模块那里扒过来的,或者自己加的一些只是为了完成功能的代码,这之中没有任何地方值得学习。作为一个程序员,我觉得当我们借鉴别人的代码的时候,首先要看懂。然后在心里问问自己,能不能做得比他更好?我们需要学会的一点就是把自己经常使用到的代码块封装成方法或者jar包,以便日后使用。一个好的程序员是一个会偷懒的程序员。
优秀的程序员有自己的想法,知道如何去学习,知道如何去做才能更方便自己。他们除了写代码,更多的时间会花在读代码和思考上,以及浏览技术网站,补充新知识。聪明的程序员会使用50%–70%的时间来思考,尝试和权衡各种设计和实现,而用30%–50%的时间在忙碌着编码,调试和测试。而这20行有效代码就是他们在思考中诞生的。一个会思考的程序员才能更快地成长!

心得体会

1.利用最少的时间写好代码
我们要养成让自己写好代码的习惯,然后能够利用最少的时间写好代码
2.让写代码成为一种习惯
我觉得每天写代码是自己心甘情愿去做的事,而不是为了跟随别人的脚步或者是人云亦云。这与减肥和锻炼是一样的,只有自己在乎,才会取得成功。
3.懂得安排和利用时间
一个善于学习的人,能够很好地安排和利用时间,他们总能有时间去学习和思考,同时妥善地安排个人生活。
4.潜意识思考
每天写一点代码,会让我们经常在做别的事情的时候想到我们的代码,这可以说是一种小小的副作用吧,但是我觉得它是有用的。作为一个程序员,我们经常会思考我们问题的解决方案,这一点对于我们的进步有着非常巨大的帮助。
5.每天写代码不易忘
我觉得这一点是我们需要每天写代码的主要因素吧,就像两个老朋友之间,经常不交流也会生疏。而程序员如果没有经常敲代码,也会生疏。不仅仅是对代码的生疏,而且还是思考上的生疏、

好的程序员怎样写代码

曾经有个笑话:文艺程序员写代码追求让别人看懂,普通程序员追求让自己看懂,2B程序员则追求让编译器能看懂;半年后再看自己当初写的代码,文艺程序员不知道是自己写的但很容易看懂,普通程序员知道是自己写的但是不太容易看懂,2B程序员埋头看了半天后拍着桌子吼到:“这是哪个SB写的程序!”
好的程序员与差的程序员写出的代码,只要一眼就能够判断出来,好的程序员写的代码,规范而整洁,视觉上有一种行云流水的美感。空白错落有致,注释恰到好处,命名和排版遵循统一的规范;差的程序员写的代码时常出现过长的函数,前后不一致的命名方式和排版,嵌套式结构过深,表达式异常复杂,数字出现的杂乱无章……
好的程序员会统一代码的风格,甚至对每一行代码都精心雕琢,对于同一类动作,好的程序员不会偶尔用这个动词,偶尔用那个同义词,而差的程序员则很随意,前面用了add,后面就用insert。好的程序员会注意名称中形容词与名词的前后位置,而差的程序员则时常忽略这些,偶尔名词在前,偶尔形容词在前……
说到这里,我觉得每个人都应该追求好代码,每个人都要养成写好代码的习惯。写好代码利人利己!

怎样的代码算好代码?

好代码首先必须是“可用”的代码,“可用” 是指代码做了它应该做的事情,而且做得不错。 如果让你写求绝对值的代码,你就不能写成求平方根的;如果让你做一个文本编辑器,OK,你做出来了,它不是一个图片编辑器,它确确实实就是一个文本编辑器,但是用户输入一个字要一分钟,这也不能称之为“可用”,因为它没达到“不错”的标准,当然,如果这个文本编辑器是给“慢星人”用的,你有理由认为它是 “不错”的。那么,究竟怎样才叫“应该做”,怎样才叫“不错”呢?也许客户(用户)的反应(评价)是唯一的标准答案。

其次它需要整洁
整洁是一个相对的词,在我看来,它唯一的作用就是令维护简单。如果你写的代码不需维护(没有BUG、完成之 后永远不会做功能改动、没有任何其它代码基于这些代码编写等等,显然,如果满足了这些条件,没人“有必要”来阅读你的代码),比如用完即抛的很简单的一次 性用品,那么只要“可用”就行了,不需要“整洁”。值得注意的是, 这里隐含了一个假设的前提条件:不保持代码整洁的情况下,你能够写出“可用”的代码。

现实生活中相当一部分(也许我可以说大部分)代码是需要维护的,也就意味着它们如果想成为好代码,必须要整洁。

在继续探讨“整洁”话题之前,也许有必要先谈谈“复杂度”。
复杂度
包括时间复杂度空间复杂度
好的代码能够妥善协调它们之间的关系

整洁代码的特征:

1,有序,各得其所,模块的归模块,接口的归接口,实现的归实现。
处理对于人脑来说过于复杂的东西,自古以来有效的办法就是分解,将大的分解成小的,使人脑在某一时刻只需要思考小的部分。要做到这点,除了分 解,还需要保持模块和模块之间联系尽可能少,只有这样你才能专注思考眼前这一块,而不必过于担心它和其它模块的相互影响。同样,只有这样,当软件发生变动 的时候,你才不至于陷入焦油坑。

相关术语:结构化、分层、抽象、解耦、正交、降低依赖、大量原则(SRP、OCP、LSP…)

2,一目了然。

流畅,没有障碍,它应该就是这个样子,而不是别的样子。任何维护工作的第一件事是什么?读代码。

相关术语:可读、文字化编程(Kunth)、自解释。

3,只做必要的事,保持简单。

简洁的代码只需要完成它所对应的功能需求即可,不必画蛇添足。

相关术语:敏捷。

4,令人愉快。

成功永远令人愉快,美永远令人愉快。

也许你已经发现了,如果保持代码整洁,似乎就可以应对多种复杂度(但不是所有),这也是为什么好代码除了可用,还需要整洁。

「真诚赞赏,手留余香」