作为四年的软件开发人员，五个重要经验教训

自从我获得CS学位并开始我作为软件开发人员的职业生涯以来已经差不多四年了。 在这篇文章中，我想分享我在此过程中学到的一些经验教训。
目录
-永远不要假设
-非技术问题是最困难的
-首先考虑，稍后编码
-你创建的内容比创建它的工具更重要
-每个角色都同样重要
-结论
永远不要假设
在开始我的第一份工作后，我的第一个项目是一个长期项目的短期任务。 该项目见过许多冲刺和许多开发人员。 代码库庞大，复杂，并且与外部服务有许多集成。
我的第一个任务是修复一些间歇性失败的单元测试。 正在测试的代码相对较旧，由高级开发人员编写。 由于功能从UI工作得很好并且经过QA彻底测试，我假设问题必须与测试本身一致。
我花了近三天时间试图修复未破坏的测试。 当我向我的团队负责人解释为什么修复工作花了这么长时间时，他教我第一堂课。 他告诉我永远不要认为别人的代码是正确的，因为它看起来像它。
这可能是我学到的最重要的一课，可以应用于很多情况，而不仅仅是涉及代码。 以下是一些：
1永远不要以为某人会因为你的要求而做某事。始终得到明确的协议。还没有收到你要求检查某人的回复？发送跟进。如果有重要的事情，重要的是跟进。
2永远不要假设有人理解你告诉他们的内容，即使他们说他们这样做了。这是我在职业生涯中取得的成就之后学到的，我帮助指导了更多的初级开发人员。我发现我会通过指令进行步枪攻击，并在第二天跟进，发现有问题的开发人员虽然说他们完全理解了所需要的内容但没有取得多大进展。相反，让这个人给你一个关于讨论内容的演练，这样你就可以确定他们理解了。这不仅适用于指导开发人员，例如向BA / QA等解释某些内容。
3永远不要认为对方是错的。我认为开发人员倾向于责怪其他人，因为他们的代码不起作用。你对你编写的代码保护起来，直到你确信它不会出错。如果QA告诉你他们遇到了问题，他们有理由这样做。给他们带来怀疑的好处不会花费太多，而且他们会比关闭更能体会到它。
非技术问题是最困难的
在大学里，所有的问题都是技术问题。 弄清楚如何使一段代码工作几乎总是手头的问题。 然而，在职业生涯中，我发现这种情况很少发生。
确保在跨多个时区的大型团队中进行沟通。 确保流程有效，并且清楚地记录在案。 弄清楚如何帮助船上或指导新的团队成员。 试图在开发过程中顺利引入新的东西。 当数字在当前推动他们的议程时，说服项目管理专注于长期代码健康。
这些只是一些示例，显示了你可以在项目中遇到的各种事情。 在我看来，它们比追踪那些困扰你的空指针要难得多。
首先考虑，稍后编码
你发现了一个可以改进的流程。 你立即决定自动化它。 你花费每个空闲时间开发一些会彻底改变团队工作方式的东西。
听起来很熟悉吧？ 包括我在内的开发人员喜欢自动化解决方案。
我学到了什么？ 不要马上去找代码。 停下来，思考问题，而不是解决方案。 与一系列人交谈，而不仅仅是开发人员。 首先确定问题是技术问题还是流程问题。 然后你可以找出解决方案。
当然，使用Docker和好编写的脚本提出一些复杂的解决方案会很酷，你可能会学到很多东西，但从长远来看，为非技术问题提出技术解决方案可能无助于团队。 它可能只是掩盖了更大的问题。
你创建的内容比创建它的工具更重要
当我毕业时，我喜欢编写代码，学习新的语言和框架，以及任何涉及技术元素的东西。
不要误会我的意思，我仍然这样做。 但是，我已经意识到，只要我们用作开发人员的工具使我们能够完成工作，那么这些工具是什么并不重要。 在前端开发中，每隔一天就有一个新的框架。 尽管作为开发人员保持活跃是最重要的，但最终用户（重要人物）并不关心某些事情是如何发挥作用的。
每个角色都同样重要
我已经提到了不自动假设每个不是开发人员的人都错了的重要性。 除此之外，我了解到组成团队的每个成员（BA，QA，项目经理，其他利益相关者等）与任何开发人员一样重要。
如果没有来自每个角色的表示，项目就不起作用，并且如果不在不同资源类型之间平均分配资源，则同样不起作用。
我了解到，即使是编写实际代码的开发人员，也没有没有利益相关者的代码，如果没有质量保证他们的立场，就没有利益相关者。
结论
我希望你能从这些课程中学到一些东西。 如果你有一些你已经学过的课程，你想分享，我很乐意在答复中听到它们。

分享文章：作为四年的软件开发人员，五个重要经验教训
网页路径：/news/114608.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有软件开发等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联