网址关键词查询网站,本周热点新闻事件,南宁市网页设计,四网一体网站建设方案概述
工作即将满8年#xff0c;如果算上2年实习的话#xff0c;满打满算我已经走过将近10年的程序员编码生涯。关于Spring Boot知识点#xff0c;关于微服务理论#xff0c;也已经看过好几本书籍#xff0c;看过十几篇技术Blog#xff0c;甚至自己也写过相关技术Blog。 …概述
工作即将满8年如果算上2年实习的话满打满算我已经走过将近10年的程序员编码生涯。关于Spring Boot知识点关于微服务理论也已经看过好几本书籍看过十几篇技术Blog甚至自己也写过相关技术Blog。
无论是Spring Boot还是微服务这些我们都可以称之为编程职业硬技能。这些硬技能一般来说都是固定的有规律可循的。对大多数人而言都是可以快速习得的至少是掌握其使用方法的。
但是职业不是说仅仅有这些硬技能就可以应付的我们还需要很多软技能包括融入团队、人际交往、压力应对、成果交付、冲突解决、沟通、带领团队、合作互惠等等。
我们需要阅读这本书
这本书就能给你一些警醒和帮助。阅读过程中相信你也会会心一笑又或者苦涩一笑。
很后悔没有早几年读到这本书。当然这并不是说这是一本度过一遍就可以放下的书籍事实上这是一本常读常新的书。
注下文以引用的方式摘抄原文附带一些个人体会、私货与碎碎念。
专业主义 什么样的代码是有缺陷的呢那些你没把握的代码都是 要用这些自动化单元测试去测多少代码呢还要说吗全部全部都要测 我是在建议进行百分百测试覆盖吗不我不是在建议我是在要求你写的每一行代码都要测试。完毕 说“不”
说“是”
编码
测试驱动开发
TDDTest Driven Development测试代码先于业务代码的编码。 TDD三项法则 1.在编好失败单元测试之前不要编写任何产品代码。 2.只要有一个单元测试失败了就不要再写测试代码无法通过编译也是一种失败情况。 3.产品代码恰好能够让当前失败的单元测试成功通过即可不要多写。 测试代码的一个问题是必须隔离出待测试的代码。如果一个函数调用了其他函数单独测试它通常会比较困难。为了编写测试你必须找出将这个函数和其他函数解耦的办法。换言之测试先行的需要会迫使你去考虑什么是好的设计。 事后写的测试只是一种防守。而先行编写的测试则是进攻事后编写测试的作者已经受制于已有代码他已经知道问题是如何解决的。与采用测试先行的方式编写的测试代码比起来后写的测试在深度和捕获错误的灵敏度方面要逊色很多。 练习
只有通过不断的反复练习才能提高自己的职业技能。作者提到的练习方式包括学习其他语言为开源项目做贡献参加编程柔道场编程马拉松
一万小时理论。
展开来说除了作者说的练习外我们还可以解决同事疑问学习GitHub开源代码参加技术峰会看技术书籍浏览stackoverflow网站回答技术问题写技术blog写技术书籍。
验收测试 在工作中有一种现象叫观察者效应或者不确定原则。每次你向业务方展示一项功能他们就获得了比之前更多的信息这些新信息反过来又会影响他们对整个系统的看法。 首先即便拥有全面准确的信息评估也通常会存在巨大的变数。其次因为不确定原则的存在不可能通过反复推敲实现早期的精确性。需求是一定会变化的所以追求那种精确性是徒劳的。 测试策略 QA在团队中要扮演的便是需求规约定义者specifier和特性描述者characterizer 自动化测试金字塔。
时间管理
回头看我过往8年的职业生涯参加过无穷无尽的用户需求评审会议测试用例评审会议Code Review会议生产事故复盘会议 关于会议有两条真理 1会议是必需的 2会议浪费大量的时间。 如果会议让人厌烦就离席。 凡是不能在5分钟内解决的争论都不能靠辩论解决。—— Kent Beck 有人会表现得非常被动。他们同意结束争论之后却消极对待结果拒绝为解决问题出一份力。 要小心这类会议它们的目的是发泄情绪或者让大家站队。如果会议上只有一面之词就要避免参加。 死胡同和泥潭 所有软件开发者都要遇到死胡同。比如你做了决定选择了走不通的技术道路。你对这个决定越是坚持浪费的时间就越多。如果你认为这关系到自己的专业信誉就永远也走不出来。 慎重的态度和积累的经验可以帮你避免某些死胡同但是没法完全避免所有的。所以你真正需要的是在走入死胡同时可以迅速意识到并有足够的勇气走回头路。这就是所谓的坑法则The Rule of Holes如果你掉进了坑里别挖。 比死胡同更糟的是泥潭。泥潭会减慢你的速度但不会让你彻底停下来。泥潭会阻碍你前进但如果使尽全力你仍然可以取得进展。之所以说泥潭比死胡同更麻烦是因为在泥潭中你仍然可以看到前进的道路而且看起来总是比走回头路要短虽然实际不是这样。 我曾经看到过产品因为陷入泥潭而报废公司因为陷入泥潭而破产。我也看到过原本小步快跑的团队在几个月内被泥潭搞到步履蹒跚。除了泥潭没有其他东西能够对开发团队的效率产生如此深远且长期的负面影响绝没有。 真正的问题在于泥潭和死胡同一样是无可避免的。慎重的态度和积累的经验有助于避开泥潭但无法彻底避开每一处泥潭。 预估
需求估时项目排期
PERT计划评审技术Program Evaluation and Review Technique。
压力
谈到压力就不得不提到当下非常流行的一个词PUA。
在我之前的工作经历中被人PUA过。
换一份工作换一个岗位。在我做技术经理时我可能也在不知不觉中PUA过其他同事当然在我自己看来这哪里能算得上PUA呢
需要谨记的是随着我们的工作年限的提升工作能力的提高自然而然工资也在增长的过程中要时刻管理好压力。我们可能会作为一个小领导手下带着几个人。在我们上面也有话语权更大的领导们。当上面领导在施加压力的时候压力往下传递的方式和方法是一门很大的学问。
协作 专业程序员的首要职责是满足雇主的需求。这意味着要和你的经理们、业务分析师们、测试工程师们和其他团队成员很好地协作深刻理解业务目标。这并不是说你必须要成为业务方面的老学究而是说你需要理解手上正在编写的代码的业务价值是什么了解雇你的企业将如何从你的工作中获得回报。 专业程序员最糟糕的表现是两耳不闻窗外事只顾一头将自己埋在技术堆里甚至连公司业务火烧眉毛行将崩溃了也不闻不问。你的工作职责就是要让业务免于陷入困顿让公司可以长久发展下去。 团队与项目
组建一个强有力的团队远远比做成一个艰难的项目更有意义。绝大多数人98%仅仅只是平庸人。世间少有的是一个旷世奇才能够仅仅凭借一个人完成一件伟大的产品。哪怕是乔布斯那样的偏执狂般的天才人物也需要一直队伍协作起来才能创造出iPad、iPhone等划时代的产品。 有凝聚力的团队通常有大约12名成员。最多的可以有20人最少可以只有3个人但是12个人是最好的。这个团队应该配有程序员、测试人员和分析师同时还要有一名项目经理。 关于团队建设的重要性不言而喻组建一个战斗力超强的团队更并非易事。君不见多少创业团队失败就是因为团队成员出现各种各样的隔阂、利益出现冲突、想不到一起去等等。
所以项目应该跟着团队走而不是团队因为某项目而临时组建。临时组建的团队要经历多久的磨合期什么时候才能有多少比较高效的产出这些都是不确定性。而不确定性就意味着失败。 专业的开发组织会把项目分配给已形成凝聚力的团队而不会围绕着项目来组建团队。一个有凝聚力的团队能够同时承接多个项目根据成员各自的意愿、技能和能力来分配工作会顺利完成项目。 辅导、学徒期与技艺
鄙人本科专业是自动化所谓的又一个【万金油】专业。【隐隐约约】记得本科即将毕业时有去找过实习找过工作但是一来自己啥也不会啥也不懂没有找到满意高薪的工作二来也不想太早面对现实社会能多逃避几年是几年所以选择读研。专业是模式识别与智能系统。
嗯非计算机科班出身。
本科和研究生实习时甚至都没有怎么写过Java代码只写过C、MATLAB、C#、Python、Shell。误打误撞第一份工作去了一家外企使用Java语言。工作前两年疯狂恶补Java基础与Spring等框架。这几年一直也在持续看书学习在弥补所谓的非科班出身的基础薄弱。
我想表达的意思是程序员尤其、特别、非常值得一提的是Java程序员并不是没有门槛。
虽然在达内嗯有没有会心一笑的朋友们培训机构学习一两个月就可以找到一份Java开发职业
事实上编码还是有门槛的哪怕是Java编码。
事实上还有相当多的人确实也承认编码是有门槛的但是测试能有什么门槛呢不就是点点点吗不就是发现Bug吗不就是根据产品出具的需求文档来验收功能发现其中不想符合的地方吗
所以我无数次听到或看到哎呀行业不景气经济在下滑要不要考虑转行做测试呢
这口气说得好像测试没有任何转行的门槛一样。
事实上在我不算长的职业生涯里看到过好几例表现极其差的测试QA同事。表现是逻辑思维混乱理不清业务模块间的关系不具备自我学习的能力等等。 画家不会这么做管道工不会这么做电工也不会这么做。天哪我甚至认为快餐厨师也不会这么做在我看来这些雇用计算机科班毕业生的公司在新员工培训上的投资起码应该比麦当劳在服务生身上的投资要多些才对吧。 我们不要自欺欺人地说这无关紧要。这很要紧。我们的文明运行在软件之上。是软件在传送和操纵我们日常生活中无处不在的信息是软件在控制我们的汽车引擎、变速箱和刹车是软件在维护我们的银行账户、发送账单和接收付款是软件在帮我们洗衣服是软件在告诉我们时间是软件在电视上显示图片是软件在发送短消息和拨通电话是软件在我们疲劳时为我们带来娱乐。软件无处不在。 我不是在反对转行只是在提醒自己需要持续学习。公司不能也没有任何规定必须要如此给你提供培训的资源时你需要自己主动积极去学习。
工具
git是必备技能
