这篇文章很对程序员来说很适用,在这里分享给你!
这是一个很有趣的问题,如果遵循一些我认为的一些常识和规则,无论你的才能如何,我认为人人都能成为优秀程序员。
实际上这些规则并不止适用于程序员,而是适用于任何专业人士。
其实并不是所有的东西都是那么严肃认真的,有些东西只是我的看法,你可能在有的经历上与我不同,不是所有的程序员的个性都符合我遇到的人物情况。
1、学习如何提问
一些提出问题的程序员类型有如下几种:
1)完美主义者
这种类型的程序员在问一些关于一些开源工具的问题。他们大多数已经通过代码进行了测试,发现了问题的真正原因。即使不是这样,完美主义者也会写出问题介绍、重现的步骤,潜在的建议解决方法。
其实,完美主义并没有问题,只有答案。
2)话匣子
这种类型的人不会问问题。他们公开自己的想法,并偶尔在这里或那里提出一个修辞问 。什么似乎是一个问题,实际上只是描述自己的思想流。如果你想给答案,他们可能已经自己找到答案,或者在邮件中提出了真正的问题。
或许,或者,也许,如果我们这样尝试…你知道吗来,这个需求是完全错误的,我用其他技术解决了这个问题。哦,我其实完全改变了库。呵呵,别再问问题了。
3)懒鬼
“这是源码”。怎么了/p>
“请帮我”…
4)经理
对于这种类型的人,时间就是金钱。要求问题必须简短,答案尽快给出。这种方法存在一些问题,因为通过简短的问题,可能不完整,并不简明扼要。很多时候重要细节没有披露,后期丢失细节的需求。
之后,经理会感到失望,因为答案不对,或者又产生了一个新问题。他会不断的发送信息,要求更快的答案,反复几次后,可能得1-2周的时间才出来真正的答案。
5)抱怨者
这种人从来不提问题,只会抱怨,直到问题消失为止。也许,如果不是它更好…等等诸多抱怨。
到目前为止,我们应该清晰的是,一个准备充分的问题:简洁、重点突出,又有足够的细节,将会产生更好的答案。如果我们都学会了如何提问题,那么很快就能得到你想要的。
5、期待例外事件
程序员应该始终遵守墨菲定律。一切都可以打破。作为软件工程师,我们知道它会被打破。因为我们的世界是不确定性的。我们正在实施的需求也是不确定的。
但是我们的实施是确定性的,直到它不再可能变化。
从我们做软件开发开始,我们将不可避免的进入非确定性的现实世界,那里一定会出现错误。所以,请瞄定它。
我们要期待例外与变化,以此来训练和改变自己用内心的悲观主义来预见各种事物。
当然,如何以简洁的方式编写悲观的代码是一回事。
如何区分那些可能会失败但不需要处理的事物与将要会失败并不需要处理的事物,需要一些刻意练习。
6、永远不默守成规,教条
我们学过的每件事都可能是错误的。包括(或可能,特别是)真正流行时这么说。
这里有一句话:
我认为我的职业生涯中至少有50%在促成或展开一场灾难或另一场灾难。
我们的专业其实充满虚伪,我们喜欢把自己当作数学家、科学家,认为只有最纯粹正确的想法才会持续下去。
这其实是个错误。我们的专业建立在数学的基础上,但除非你进入类别理论或关系代数这种世界。即使这样,我也怀疑所有东西的“正确性”,我们都处在实际业务需求的世界中。坦率地说,这些都是那么不完美。
我们来看一些最流行的编程语言,比如C、Java、SQL等,你认为这些语言与数学相似吗果是,我们来看Java泛型或SQL三值逻辑的分段都是错误的。这些语言都是由实用主义者创建的平台。
他们都在建立之前有一些非常酷的理论背景,但最终他们不得不完成这项工作。
对于建立在语言之上的所有东西也是如此:库,框架,设计模式,甚至架构。没有什么是对或错,一切都是针对某种情况设计的工具。
我们要在其上下文中思考该工具,切勿将此工具视为独立存在的理由。不是为了艺术的缘故,我们不是在做艺术 。
所以,我们不要质疑:
XML
JSON
功能编程
面向对象的编程
设计模式
微服务
三层体系结构
DDD
TDD
等等…
所有这些都是在一定背景下的好工具,但它们在逻辑并不是总成立。
通过保持好奇心并开箱即用,你将成为更好的程序员,并知道何时使用这些工具中的哪一个。
7、去做
真的,此时才能产生超过大多数人的杰出人物。
但是大多数程序员只是“好”,或者他们有潜力成为“好”的人。你怎么能成为一名优秀的程序员/p>
我们通过以下方式。
伟大的软件并不是一天写成的,而明星也不是我们这个时代唯一的英雄。我遇到过很多并不知名的优秀程序员,他们过着私人的悠闲生活,解决着小公司的问题。
优秀的程序员都有一个共同点:他们不断做,不断练习。他们每天都能把工作做得更好,更加好。
想把SQL中做得更好吧!尝试写一个SQL语句,在其中添加一些新功能。使用事务,分组集合,递归,分区外连接,MODEL、MATCH_RECOGNIZE子句。它不必每次都能够在生产环境上使用,但这种做法是值得的。

8、长期关注一个主题
在这里可能只有极少的“优秀”全堆栈开发人员。相比之下,大多数完整的堆栈开发人员在很多方面表现平庸。
当然,一个小团队可能只需要其中的一小部分角色,涵盖很多业务逻辑来快速启动开发一个新软件。但是,一切都会相当草率,并且“有点奏效”。或许这对于最小可行产品阶段来说已经足够了,但从长远来看,将会有更复杂的问题出现,即整个堆栈开发人员没有时间来正确分析(或预见)。
关注一个主题并且非常擅长。只要该专家的利基存在,专家就会始终处于需求之中,许多专业领域将超越我们所有人(比如人工智能或大数据)。
所以,请将一个最擅长的做好,并且据此做很好的事情,而不是很多事情都好。
9、把玩技术
虽然你应该关注一个主题,但你不应该忘记其它主题。您可能永远不会真正擅长所有的SQL,一次性扩展,高级别的性能,CSS,面向对象,需求工程,架构等。这不可能的。
我们应该掌握每一个技术的本质。你应该明白什么时候选择SQL是正确的选择,当低级别的性能调整很重要时。CSS是如何工作的,推荐算法等的优点。
我们应该花一些时间玩耍,投入这些一些概念和新技术,以便更好地理解它为什么重要,知道何时应用它们,然后或许找到合适的专家来实际执行。
通过对新的范例和技术的把玩,你会打开完全不同的思维方式,而且以后有机会在日常工作中使用到它。
10、保持简单和愚笨
爱因斯坦说:“一切都应该尽可能简单,但并不简单。”
没有人能够处理巨大的复杂性。不在软件中,不在生活的任何其他方面。复杂性是优秀软件的杀手,因此简单性是推动者。
这话说起来容易,但很难实施。简单是需要花费大量时间和实践来识别和生产的。
有很多规则可以遵循:
有一些简单的规则,比如函数和方法只有很少参数。并且不需要阅读任何文档,每个人都会立即明白这是什么,该方法只做一件事和一件事,也没有复杂的上下文/设置/其他参数可以传递给方法,也没有特例。
同样,在库中生成简单性比在业务逻辑中执行简单得多。我们需要通过练习、通过重构来完成。 和所有伟大的产品一样,简单性不是一天建成的。
文章知识点与官方知识档案匹配,可进一步学习相关知识MySQL入门技能树数据库组成表31516 人正在系统学习中
声明:本站部分文章及图片源自用户投稿,如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢!