作者Jeff Standen,有着21+年经验的软件开发者。

首先开发spike解决方案——这是我早期敏捷/极限编程所养成的习惯之一。spike解决方案是一次性原型,可以帮助你在投入大量时间和精力之前验证你是否走对路。

区别就在于原型,因为你遵循这样一个规则,在你完成研究之后,你最终会扔掉“spike”代码。所以允许你偷工减料,迅速行动,因为它不会出现在产品或代码审查中。

此方法有助于迅速发现设计的哪些部位尚不明确,而不必过早地尝试架构或设计决策。

致力于小而连贯代码块的版本控制——通过类似CVS/Subversion,每次提交都直接发送到服务器。做部分文件的提交并不简单。

随着Git的出现,只提交较大文件的若干行代码变得很容易,并且可以在push到远程代码仓库之前先本地rebase/merge提交。

有一次,我在工作于更大功能的时候,采用了小型增量提交,我的工作效率直线上升。这样做能够清空我的大脑以便于面对更重要的事情。

经常写代码——最近,我正工作于:一个基于Web的企业协作和自动化平台(PHP
/ MySQL),一个基于云的实时指标聚合器和使用循环哈希(Node.js/
Redis)的API,一个面向iOS app商店(Swift/
SpriteKit)的棋盘游戏,专门的基于URL的cronjob可替代基于web的SaaS服务(JAVA),等等。

用过大量框架和语言有助于我的抽象和算法思维。

我从工具,如Eclipse
RCP、Tapestry和Hibernate中学到了很多伟大的经验教训,并用到我的PHP项目里。尤其是在2000年初,在有Java特征的企业生态系统用于PHP存在之前。我从Unity3d/C#学到了很多关于网络和面向消息的架构。

如果我只坚持单一平台和社区的话,就永远不会知道这些概念。

编写简单的代码——我以前习惯于写复杂的代码以作为对自己的挑战。而现在的挑战是要编写优雅且简单的代码——到一种每个人都觉得他们也能做到的地步(即使他们不能)。简单代码通常来自于若干次复杂代码的迭代。

引用Antoine de Saint
Exupéry的话就是:“不是没有什么可添加,而是没有什么可消减的时候,才算是达到了完美。”

这也使得我们在长时间休止之后返回项目,以及鼓励其他人参与进来变得容易多了。

最后优化——我们很容易掉入试图比用户或计算机更聪明,并且预优化各种边缘情况的陷阱。关注帕累托法则(80%的效果来自于20%的工作)。写代码,运行代码,当必要的时候专注于最大的瓶颈。这也支持保持代码库的简单。

说“不要首先优化代码”并不意味着“编写粗糙的代码”。代码总是应该精益和优雅,没有必要画蛇添足,不要将一整天的时间用在挤压剩下的10%,但其实已经能够工作良好的一些东西上。不但工作效率会下降,而且还会引进更多复杂性,解决方案变得不那么可归纳,等等。

着眼于“最重要的事情优先”——总是有一些项目领域比其他的更有趣或更具挑战性。工作于那些有趣的东西总是比工作于那些必要的东西更有诱惑。

在攻克重要部分时,将有趣部分作为一种调剂,也就是说,两者都做一点也是可以。

因此,光从这一点上说,将大的问题分解成小问题的理念是不言自明的。每个人都懂。所以,我会通过计分若干“quick
wins”来开启我的一天,这能让我更有冲劲和更专注(“quick
wins”可以是任何东西,包括有趣又小型的挑战),然后我会首先冲向“最重要的事情”。

了解全栈——当我刚开始干这一行的时候,没有什么比等别人做完他们那部分东西,然后我才能继续我那部分工作更糟糕的了(设计师,后端人员,前端人员,数据库人员,服务器人员,等等)。

于是,当我2000年创办自己的软件开发公司的时候,我做了一个明智的决定,那就是涉猎全栈。我知道我不可能擅长所有东西,也不可能是最后唯一对所有一切负责的人,但我想要做终端到终端的原型,因为我没有耐心看过程。

每当我需要的东西触碰到我不懂的领域时,我会研究它。于是乎,我学会了服务器管理,数据库管理,设计,前端/后端开发,云架构等。

通过了解其他领域是做什么的,我才能写出包含它们需要的代码。

当然,其中的一些要点似乎并不是所谓的“小习惯”,但我向你保证,它们是小变化历经20年时间导致的结果。重要的行为变化并没有意义,更多的是关于我是如何频繁地练习这门技术(在过去10年时间中每年大概4000-5000个小时)。

所以,我的做法更像是去回答这个问题:“什么样的小习惯会导致更糟糕的软件和低效的生产力?”,然后反过来。

微软澳大利亚的解决方案架构师Tom Hollander,在TechEd
Australia大会上举行了一场题为“敏捷团队中的架构师角色”的演讲。在演讲中,他讨论了他作为领导敏捷团队的架构师所做的工作。

新手程序员必备十项技能

拉勾导读:初出茅庐的你带着仍残留墨香的毕业证书踏上工作岗位,马上就被书上没写的规则和各种繁杂的日常事务来了个下马
威。这样的故事实在是司空见惯,编程工作也不例外。没有几个学生能 100%
为自己的第一份真正的工作做好准备(开发人员求职神器:URL)。如果你不想成为其中之一,请学学以下这
10 项无需手把手指导就能学会的基本技能:

作者Ed Prentice,软件工程师

时间是宝贵的,所以要尽可能地节省时间。尽可能自动化。一旦时间成为一种商品,那么你可以实现下一个伟大的创新。

使用功能强大的IDE(如vim),并将其配置能为你做尽可能多的事情。力争单个命令Build/Test/Deploy/Run。

如果你发现自己常做某件事情,那么可以让它们在一个按键下发生,或者一次点击下发生。或者更好的是,让它们自动发生。

了解键盘快捷键和UNIX命令行。几乎所有的IDE都可以让你运行复杂的编译命令,甚至任意的终端命令——不但强大,并且可以为你节省大量的时间。

提问题,然后提更多的问题。如果有什么你不明白的事情发生了,那就问为什么。然后走开,研究替代方案,并提出来。一直问问题直到你可以详细地给下一个问为什么的开发人员解释。我时常感到奇怪为什么会有这么多开发人员不知道为什么,仅仅是因为觉得“它总是/曾是这样”。

通过提供更好的替代解决方案挑战现状——并且制定步骤实现。如果你的测试不完整,或每天/每周运行一次——那么成为本地的Continuous
Integration大师——目的是为了有利于你的团队,并实现它。一旦你使用它并且它可以帮助你更好工作的话,那么让你的团队也使用它。

不要只是挑战别人,挑战自己。从来没有写过web应用程序?那么写一个。从未用过Python?用Python劫持无人飞行器。

拥有一些东西。创造一些东西。没有必是非要做技术项目,可以是一个事件,例如聚会或编程马拉松,也可以是一个游戏,一个网站,一个博客。

教一些东西。Java,公开演讲,写作,下棋,vim,网球。

成为一个杰出的人。拿到一个垃圾类/组件?修复好它。编写代码的正确途径。不在代码中走捷径。做出明智的决策,向你周围的人说明为什么你要做这个决定的利弊。总是改善代码。制定不需要花费1小时的待办事项表?Just
Do It。

浏览你熟悉的Stack
Exchange的话题——例如你喜欢的语言。当你发现什么新的东西的时候,尽快末位淘汰相关知识。知道C语言?什么是分支预测?这篇文章会告诉你——你要做的就是学习。

浏览你不熟悉的Stack Exchange的话题——好好学习,天天向上。

澳门新葡萄京所有网站 ,学会沟通。书面文字,呈现展示,解决问题,小却激烈的小项目,大型团队,小型团队。

文档化你的所有过程。你可以回头查阅你为什么做这些事情,以及依赖原先的解决方案去解决碰到的相似问题。这还有助于捕捉你可能会忘记的思维过程和关键的信息片段。我经常通过日志来回顾前几天的工作。

在你写之前文档化你的代码。使用系统图,类层次结构,流程图表,以展示说明你的代码将如何工作。如果有人提出建议——是的,他们会提出来的——那么你可以进行修改,这比已经写好了代码再去修改要容易得多。这是另一个我很少看到有人会做但却有着最负面影响的事情。

特定化。为新的东西制作图表,向大家展示。收集尽可能多的细节。确保每个人同意这个图表。如果有人提出了建议,那就补充/添加更正到图表。保持图表更新。

知道潜意思的偏见和男性特权。了解你是哪种MBTI和人格类型,并且更重要的是,要知道如何与其他性格类型更好地互动。了解情商。每个人都是不一样的,你需要知道如何与他们进行最有效和最有建设性的交互。

定期为团队做一些事情。带饼干。教魔术。培育一点文化,并鼓励其他人也这样做。赞美其他人的贡献。一支有凝聚力的团队是很难被击败的。

学习如何与人合作。我个人非常喜欢《The Pragmatic Programmer》的“stone
snop”。

理解和使用别人的代码。如果你正在实现自己的XML解析器或或csv阅读器或git
hook,那么你就是在重新发明轮子。

一旦你写了代码,并且它是有效的,通过测试的,那么回过头去整理一下吧。重新运行测试。再整理。每个类都应该有单一的职责,每个函数都应该只做一件事情。在大多数情况下,函数应该小于20行代码的长度。使用自文档的函数名和变量名。花时间整理你的代码以后将会10倍地回报给你和你的团队。

参与其中。承担责任。如果事情有不对的地方,那就解决它。如果最后期限临近了又想出了一个解决方案,那让其他人尽快知道。任何人都可以做到这一点,即使是最初级的开发人员。这要求对项目的蓝图,方向和截止期限有着大局观的认识——参与进来。保存好每天的工作内容!

和团队分享学到的经验教训(在适当的时候)。指出Java中finally块内部抛出异常的时候发生了什么?和大家一起分享。


出处:码农网

英文原文:What little habits
made you a better software
engineer?

 

1、版本控制系统(VCS)

VCS
也许是计算机课程最大的疏漏。这些课程光记得教如何写代码,但却往往忘记教学生如何去管理代码。每一个程序员都应该懂得利用
Git 或 Subversion 有效地创建
repository(仓库),编辑与提交代码,进行分支与合并,了解项目工作流。

在谈到架构师的角色时,Hollander指的是“解决方案架构师”或者应用架构师。他不是指企业架构师或者其他的专业人士(专精于特定的领域,例如消息或基础设施)。

2、学会写作

身为程序员要写的不只有代码。你还要写项目的发布说明,给版本控制写提交消息,在系统里面写漏洞报告。这些和许多地方都需要清晰有效的文字交流—但这个技能计算机科学却很少强调。

 

3、正则表达式

正则表达式本身就是一门语言,每一个现代程序员都要擅长。每一门现代语言都支持正则表达式或者有相关标准库。如果代码需要校验某字符串是否含有
5 个字符、1 个破折号和 1 个数字,你应该马上就能写出 /^[A-Z]{5}-d$/。

Hollander的团队采纳了由4周迭代以及最后的稳定阶段(几天代码冻结的时间)组成的流程,实施了每日站立会议、每日构建与自动化测试的持续集成等实践,并采用了许多角色:

4、库的使用

现在已经是 2014 年,所以没人需要用正则表达式从 URL
析取主机名了。因为每一门现代编程语言都有执行常用功能的标准库。

程序员需要明白,那些经过开发、测试和调试的代码通常要比自己重新写的代码更好。更重要的是,无需编写的代码实现起来要快得多。

 

5、SQL

很多人的 SQL
都是在工作中学会的。数据库怎么会是选修课呢?有不用数据库的吗?

把 数据存进平面文件的时代已经结束了。一切东西都要进出数据库,而 SQL
则是存取数据的语言。这是一门说明性语言,不是程序语言,所以用它来解决问题时需要新的思考方式。每一个程序员都应该了解数据库标准化基础,能够执行
SELECT(及 INNER、OUTER JOIN)、INSERT、UPDATE 和 DELETE。

  • PjM——项目经理,类似于Scrum Master,确保团队遵循了流程
  • PdM——产品经理,也被称为客户或Product
    Owner,决定产品应该是什么样子
  • 架构师——解决方案/应用架构师
  • 开发人员——开发团队
  • 测试人员——测试团队
  • 用户体验设计人员UX)——用户体验团队
  • 发布人员——承担构建和发布的职责,负责维护构建的流程

6、会用IDE、编辑器及CLI工具

只懂用锯子的木匠永远也无法出师,所以计算机专业毕业的人只懂 Notepad 或
pico
令人惊诧。编程工具帮助操纵代码及其他数据,令程序员生活变得容易。所以每一个程序员都应该知道命令行、shell
脚本、find、grep 及 sed 的使用。

 

7、调试

每一个程序员都应该知道利用交互式调试器或在代码中点缀一些输出语句来调试程序。通过逐步求精来跟踪问题的能力实在是太重要了。

Hollander针对解决方案架构师如何在敏捷团队中取得成功,提出了最重要的十件事情:

8、防错性编程

错误总是难免的,哪怕是明星程序员也不例外。失控是世界的常态,出错毫不奇怪。防错性编程正是理解了这个事实。如果东西不会不出错,我们就不会检查文件打开成功与否,不会检查客户
ID 是否合法数字,不用测试代码是否允许正确。

程序员需要知道,编译器告警是有用的工具,可让我们生活得更舒适,而不是要避而远之的麻烦事。每一个程序员都应该知道为什么每一个
PHP 程序都要这样开头:

1set_error_reporting(E_ALL)

每一个 Perl 程序都要写上这些语句:

1use strict; use warnings;

 

9、团队协作

很少编程工作会让你自己一个人完成,如果你经常这么做,智力会受损,表现会变弱。你的代码必须与别人的交互或者混合。再有才的程序员,如果无法与别人协作,都会给项目造成负面影响,并迅速成为组织的负担。

  1. “正好足够”的预先设计——除了非常简单的项目,一定时间的预先设计(例如,1到2周)是绝对必要的,其时间长短会取决于应用的类型——网络应用程序、智能客户端(smart
    client)、移动或批处理,基本的功能需求是什么,是长期的解决方案抑或是折衷的、暂时的方案,都要弄清楚。预先设计的目的是要决定:使用什么技术——例如,ASP.NET或MVC,应用程序是什么类型——2层、3层抑或是面向服务的应用,如何访问数据库——存储过程、实体框架、LINQ、依赖注入(DI)。一篇简短的文档就可以包含所有这些信息以供大家参考。
  2. 从垂直分片开始——是指从一小块功能开始(例如登录页面),尽可能地在垂直方向把它切分为很多层,从而把前一阶段所决定的所有技术结合在一起。这将验证设计决策的正确性,而且所有的技术可以一起工作,并且将向开发者展示在开发新代码时可以遵循的模式。如果发现最初的设计决策不当,此时是一个合适的修改时间。
  3. 在每次迭代中的Just-in-time设计——在每个4周迭代的中段,项目经理、产品经理和架构师应该聚在一起讨论在下一个迭代中要完成的需求,确保他们每一位都同意这些需求,重要性更高的事情放在了前面处理,而且每个人对一切事情都非常清楚。这些讨论在当前迭代中会以不太明显的方式延续一个星期。接下来的一周,也即当前迭代的最后一周,架构师复审下一次迭代的需求,作出必要的设计决策,以便团队可以在下一个星期基于这些决策开展工作。如果需求与以往相当不同,那么,架构师会开发一些原型,编写一些代码来证明概念,绘制一些图表,然后把所有这些东西集编为5页的文件以供参考。这不是为了制定出有利于开发人员的详细设计方案,而是要确保新的需求满足全局的要求。
  4. 信任你的团队…但要跟他们在一起——这关乎架构师与开发人员的关系。架构师需要确保他没有逾越自己的角色,没有独占所有“做决定”的乐趣,使得开发人员的工作变得无聊。与此同时,架构师需要给团队提供指导,解决那些可能会导致开发人员停顿的困难问题。架构师每天都应该与每位开发人员接触,获悉他们在做什么,并且在他们遇上编程问题的时候给予帮助。特别是当开发人员不喜欢寻求帮助,试图花上整整一个礼拜的时间来自行解决问题的时候,这种帮助尤为需要。这种关系也适用于PjM和测试/构建/发布团队。
  5. 编写代码!——架构师应该知道代码的质量如何,这样才会对他做出的决定所产生的影响有更好的理解。他也可以整明白何时重构是必须的。
    编写代码的架构师在开发团队中有更好的声誉。也就是说,Hollander并不认同(设计和开发)职责的泾渭分明。他还认为,架构师仍然是架构师,他不一定要像普通的开发人员一样擅长于编写代码。
  6. 参与一切——架构师参与所有与项目有关的会议:设计、开发、代码评审、需求规划等,这是有好处的,因为他能够以更广阔、更清晰的视角看待正在发生的事情,而且他能够通过告知产品经理其决定的潜在后果,从而帮助他/她避免在早期阶段做出错误的决定。
  7. 推动质量文化——一个成功的团队,一个人人都想成为其中一分子的团队,是建立在质量文化之上的:没有人偷工减料;没有人提交拙劣代码;如果设计中有一个重大的缺陷,它绝不会不知不觉地混过关;所有人都是诚实和开放的,寻求整个团队达到最佳的结果。Hollander承认,建立这样一个团队很难,但并非不可能。首先,架构师应该在一开始就创建一些规则,这些规则不会因为开发人员不喜欢就随着时间而改变。比如决定编写单元测试,再比如在每次提交以前都要进行代码评审,包括由架构师提交的代码。如果评审人员(可以是团队中的任意一位)不认可代码,代码就不能提交。
  8. 知道何时需要改变——架构师应该非常灵活,随时准备好在设计需要改变的时候去改变设计。早期的解决方案也许不再适合,抑或是新的需求需要不同的方法。
  9. 屏蔽来自外部的随机请求——虽然这通常是项目经理/Scrum
    master的职责,但架构师可以保护团队不受外部请求的影响,这些影响往往会分散团队的精力和浪费真正工作的时间。举个例子:业务团队可能想要以某种特定的方式完成某些特定的事情,而他们的请求并不全然合理,也并不是必须实现。 
  10. 撰写文档…但只有当有人需要阅读它们的时候——Hollander并不提倡记录一切,也不提倡根本不撰写任何文档。他认为有必要取得一个平衡——只编写一定数目真正有帮助的、有人会去阅读的文档。文档在记录详细设计的决定(比如数据模型)方面是很好的载体。迭代的设计决定,虽然它们由整个团队在迭代开始之初讨论得出,但我们仍然建议将它们记录在5页的文档之中,以备开发人员日后不记得架构师言论的时候进行查阅。而当最开始的开发人员和架构师离开项目、加入其他项目之后,新加入项目工作的人也能借助于这些文档理解某些决定的来龙去脉。 

10、利用现有代码

在学校的时候,每一次作业都是一个新项目。但现实世界不是这样的。对于刚工作的人来说,所接到的第一项任务往往是修改代码漏洞。然后,再在现有代码库的基础上为现有系统增加一个小功能。设计新代码那是几个月后的事情,如果幸运的话。

 

做程序员,仅仅成为码农是远远不够的。下面是云和数据整理出的CTO、高层执行人员和HR共同认为程序员必备的13项技能和软技能。

综上所述,Hollander指出,架构师应该确保他从理论上和实践上都是团队的一分子。架构师不应该编写所有的代码,而只是其中一小部分,他不去测试或部署这些代码,但他要确保整个流程的顺利进行。

1****、Java**

2016年,开发人员掌握Java绝对不会错。Java能力是目前为止被高层执行人员和HR誉为最频繁的追捧技能。Java已被证明是当今市场中高度可移植和宝贵的技能。

 

2****、大数据**

大数据相较于去年继续扩大,而且在这几年里也没有任何放缓的迹象。开发人员必须有全面的商业智能和分析产品,机器学习工具和其他可以转移、存储和汇总大量数据解决方案的知识。只有这样,他们才能帮助公司存储,交互和分析大数据,以便于做出更好的业务决策。

3****、掌握全栈**

现在许多顶级公司都在寻求可轻松应对各种技术和平台的全栈开发人员。

4****、涉及开发运营**

炽热的就业前景并不是考虑在简历中添加开发运营经验的唯一原因:开发运营实践会让你成为一个更优秀的开发人员和一个更有价值的合作者。
  开发运营实践还可以提高团队凝聚力和业务敏捷性,这是一种能让企业加速领先一步的边缘技能。

5****、多样化**

相比前几年,现在的企业希望寻找更丰富的技能。Java和C#仍然占据市场部分份额,但是当你去看那些在上次经济衰退之后成立的公司,那么你将看到各种类型的语言需求:Ruby
on Rails,Python /
Django,Node.js,以及在出现的函数式编程语言中,Scala是最普遍的。

6****、使用源**

特别是自由职业者,指向GitHub上的代码,能够表明你的工作完成得很好,并通过了同行审查。
  如果公司本身正在探索GitHub以便于添加技术到他们的堆栈,那么你不上谁上?

7****、敏捷**

敏捷开发应该成为2016年程序员的必备技能。熟悉敏捷和精益方法——将大项目分解成小故事,确定优先排序,适应变化,并提供最大价值。

8****、安全性**

根据研究报告,去年深受安全漏洞之害的公司知道2016年什么技术对他们而言是最有用的。
  随着云计算使用的增长,安全性和合规性越来越为组织所担忧,这导致了对安全,合规,治理和数据管理专家的需求热潮。

9****、移动开发**

移动开发者备受追捧,尤其是那些可以广泛发布自己作品的开发人员。要成为一个成功的移动开发者不是通过特定的技术技能来实现的,而是通过商务头脑实现的。
  编写代码仅仅是项目的第一阶段。知道如何推广移动app,如何吸引和留住客户,才是成功的推动力。

10****、云计算**

当涉及到云计算中的职业机会时,它并不全部意味着工具。TEKsystems说,企业希望招聘到有业务能力,包括项目管理和与供应商谈判能力的开发人员,并且这将成为一种持久的趋势之一。
  此外,我们需要更多“推动业务”类型的技能,但不太需要战术工作,因为云供应商现在越来越对此负责。

11****、物联网**

现在的物联网不但作为了一种雇佣需求,也是一种天才工程师想探索的技巧。
  而且这不再只针对嵌入式系统工程师,你即使是一个Java开发人员,也可以做这个。协议如Wi-Fi
Halo,以及可穿戴和IoT设备开放轻量级SDK的出现,为开发人员不再局限于显示器和构建针对周围事物和环境的东西打开了很多机会。我们还可以看到由于这些工具的问世,很多硬件/软件开始协同设计。

12****、有说服力**

客户管理技能是很重要的,特别是巧妙但令人信服的推延能力,这在发布的替代品更有价值的时候很有用。也需要能够教育客户关于软件性质的口才,引导他们选择可更好满足他们长远目标的做法。

13****、变通**

如果你是团队中有着10x生产力又全栈的开发人员,那么对你的服务要求比供给更多。但是,如果你还是新手或正在转行,那么正确的态度可以让你的面试—留用—录用过程大不相同。
  作为一个优秀的团队成员,应该成为解决方案的一部分,而不是问题的一部分,愿意伸手帮助团队成员,有一种志愿服务理念,并努力提高对团队有价值的产品或文化。