您所在的位置: 首页>行业资讯>山东三十年软件开发之路:老码农的自我修养!

山东三十年软件开发之路:老码农的自我修养!

发表于:2021-10-06 阅读:0 关键词: 软件开发 码农 程序员 网站SEO优化
免责声明:本文来自微信公众号CSDN(ID:CSDNnews),作者:Julio Biason,Hyun-woo Technology转载授权发行。 [CSDN编辑笔记]“成千上万的年轻人还年轻”,对于程序员而言,保留技术初衷和不断提高实力是巩固自己的唯一法则。 本文的作者,作为具有30多年开发经验的“老”程序员,在本文中详细总结了他多年来所走过的陷阱以及从实践中获得的真相,并谈到了软件开发, 团队合作工作,个人成长等方面。 我相信阅读本文将帮助您成为更好的程序员。 免责声明:本文已得到作者朱利奥·比亚森(Julio Biason)的授权翻译。 翻译器| 主编王彦妮| 郭睿以下是翻译:这是我30年来在软件开发过程中所学到的一些实践经验。 听起来有些愤世嫉俗,但这只是我个人的经验。 同样,有些内容确实很愤世嫉俗,有些是对不同工作的长期观察。 软件开发首先阐明问题,然后开始编写代码。 如果您不知道要解决的问题,那么您肯定不知道要编写什么代码。 在编写任何代码之前,请清楚写下应用程序的工作方式。 “如果不需要或不进行设计,编程就是向空的文本文件中添加bug的艺术。”-Louis Srygley有时,即使它只是一段“电梯演讲”(在结果中引用结果的内容) 短时间)-仅使用两个自然段来描述此应用程序的功能-足够。 有时我发呆地看代码,不知道下一步该怎么做。 实际上,这通常是因为尚未定义下一步。 这通常意味着是时候停下来与同事讨论或重新考虑解决方案了。 将步骤写为注释。 如果您不知道如何启动,请先以自然语言,英语或您的母语描述应用程序的流程,然后用代码填充注释之间的空白。 比这更好的方法是将每个注释视为一个函数,然后编写可以完全实现其功能的代码。 小黄瓜是为了帮助您了解期望(expectation)的好帮手Gherkin是一种测试描述格式,它指出“假设系统处于特定状态,则当发生某些情况时,这就是预期的结果”。 即使您不使用任何可以读取Gherkin的测试工具,它也可以使您对应用程序的预期效果有很好的了解。 单元测试很好,集成测试更好。 在我目前的工作中,我们仅测试模块和类(例如,我们仅针对视图层编写测试,然后仅针对控制器层编写测试,依此类推)。 它使我们能够知道某个部分是否有问题,但是由于缺乏对整体的观察,而集成测试则无法测试整个系统的行为,因此在这方面它会表现得更好。 测试可以使API更好。 我们在不同级别进行编码:有一个存储层可以使我们的数据永久存储; 有一个处理层应该对存储的数据执行一些转换; 有一个与数据有关的视图层如何显示信息...等等。正如我提到的那样,集成测试感觉更好,但是单独测试不同的层可以使您更好地了解其API。 然后,您可以更好地了解如何调用:API是否过于复杂? 您是否需要保留大量数据才能拨打电话? 做您知道如何在命令行上运行的测试并不意味着该命令行对于任何项目都是重要的。 但是,当您知道运行测试的命令时,就会知道如何自动执行测试,然后可以在持续集成工具中使用这些测试。 始终准备扔掉您的代码。 当许多人最初开始使用TDD(测试驱动开发)时,一旦被告知可能必须重写很多东西,他们就会非常生气。 TDD旨在“扔掉”代码:您越了解自己的问题,您越会理解,无论您写什么内容,从长远来看都将无法解决问题。 因此,您不必为此担心。 您的代码不是一堵墙:如果您必须永远放弃它,那不是浪费材料。 当然,这意味着您花费了编写代码的时间,但是现在您对这个问题有了更好的理解。 一门好的语言是经过全面测试而诞生的。 可以确定的是,如果一种语言在其标准库中附带了一个测试框架(即使它太小了),那么会将周围的语言与没有测试框架的语言进行比较。 生态系统仍将具有更好的测量无论该语言的外部测试框架多么出色,都应尝试。 未来的思维是垃圾思维。 当开发人员尝试解决问题时,他们有时会尝试找到一种方法来立即解决所有问题,包括将来可能出现的问题。 但是现实是这样的:未来的问题永远不会出现,最终您将不得不维护大量永远不会被完全使用的代码,或者您必须重写整个代码,因为其中有很多事情 不使用...。解决您现在遇到的问题,然后解决下一个问题,然后解决下一个问题。 直到一天,您将在这些解决方案中找到固定的模式,然后您才能真正“立即解决所有问题”。 文档是将来写给自己的一封情书。 我们都知道,为功能,类和模块编写该死的文档是一个痛苦的过程。 但是在将来,当您看到文档时,您可以回忆起编写函数时的想法,并且您将了解,文档可以在将来的关键时刻挽救您的生命。 功能文档是合同。 当您编写文档作为编程工作的起点时,实际上是在签定合同(可能与您将来的自己签订合同):我说过此功能可以做到这一点,那么它必须做到这一点。 如果以后发现代码与文档不匹配,则说明代码而不是文档有问题。 如果一个函数的描述包含“和”,那么一个函数应该并且应该只做一件事情是不对的。 当您编写功能文档并发现您写了“和”一词时,这意味着该功能不仅仅完成一件事。 然后,您需要将该函数分解为两个独立的函数,然后删除“ and”。 不要将布尔变量用作参数。 设计功能时,您可能想要添加一个标志-请勿这样做。 现在,让我给您个栗子:假设您有一个消息传递系统,并且有一个可以将所有消息返回给用户的函数getUserMessages。 但是在某些情况下,您需要返回摘要(例如,第一段)或每条消息的完整消息。 因此,您添加一个标志/布尔参数,名为retrieveFullMessage。 再次,不要这样做。 因为任何读取您的代码的人都将看到getUserMessage(userId,true)并想知道true在这里意味着什么。 您可以重命名功能