当编程书出错时

2022-02-21 09:37:10

这更像是一个指南,可以帮助你阅读哪些编程书籍以及阅读顺序。

读一本你感兴趣的书并没有错,即使它是在你还没读到的部分。

我是初学者,这就是我一直在寻找的。

在开始之前,我建议您已经经历了一年多的专业代码库,并且精通一种编程语言。

本网站上所有指向亚马逊的链接都是附属链接。我感谢所有选择使用它们来支持这个网站的人。

与自己和他人打交道应该是你首先关心的问题。作为一名软件开发人员,拥有一份长期而健康的职业不仅仅是编写代码。

在你的工作生活中,你会面临许多不同类型的问题。你不是第一个,也不是最后一个与他们斗争的人。这本编程书定义了一个几乎全面的列表,列出了如何充分利用你的职业生涯。

这本编程书将给我提供不可或缺的建议,我希望我刚开始时就知道这些建议。

我不是为了思考和学习而获得报酬的;我靠写代码赚钱。

你总是需要学习新的东西。如果你想保持相关性,这永远不会停止。

这些编程书籍将对软件工艺有一个基本的了解。熟练的软件工匠需要了解许多工具和技术,以适应各种各样的问题。

这不是一本Java最佳实践手册吗。我编写Ruby、Javascript和Haskell代码。

不要因为示例代码是用Java编写的而拒绝。概念和原则仍然适用于所有编程语言。

编码习惯有好有坏。这本编程书记录了许多内容,并给出了它们的上下文。理解代码难以阅读和更改的原因将有助于保持代码库的可维护性。

它不是重写代码,而是通过小步改进代码。

由于我们很少在第一次就做对了一些事情,我们的代码也需要更改(它被称为软件是有原因的),随着新需求的到来,重构是我们需要做的事情,总是和所有的时间。

善于重构,并且知道如何以及何时进行重构,对于代码的质量来说,这可能是成功的,也可能是失败的。

这本书介绍了一个关于代码气味和重构的词汇表,它将帮助您的团队讨论代码以及如何修改代码。

前100页是关于重构如何、何时以及为什么重要的,剩下的是重构的目录。

大多数尝试TDD(测试驱动开发)的人都没有读过这本编程书,或者过早地放弃了TDD。学习TDD很难,需要时间,这本书是一个很好的开始。

TDD是人们能学到的最有价值的技术之一,但它需要时间。

David Heinemeier Hansson发表了一篇题为“TDD已死”的博客文章。长期测试声称TDD会对生产代码的质量产生负面影响。

这引发了辩论和讨论,结论是TDD并没有死,但也不是一颗银弹(它从来没有声称自己是银弹)

要了解更多信息,请阅读大卫的帖子,聆听与马丁·福勒和肯特·贝克的闲逛讨论,并阅读博布斯叔叔的想法。

我相信在你的职业生涯结束之前,你会多次听到有人引用这本书。

我非常务实,我不写测试,我一直在复制/粘贴。

这本书会教你很多东西。本书给出的建议包括如何编写代码,以及如何作为专业程序员行事。

如何编写枯燥(不要重复自己)的代码,如何与他人交流软件熵,以及为什么不应该找借口。

这些都是很棒的编程书籍,但对于拥有计算机科学硕士或博士学位的人来说,它们可能是最基本的。

拥有大学的计算机科学学位并不要求是一名工匠大师。对计算机科学有一定的了解是非常重要的。

我不是把计算机科学的分支提炼成几本编程书;这样做是荒谬和不公正的。

这些编程书籍并不能取代经典的计算机科学书籍,比如《计算机程序的结构与解释》和《算法导论》。一旦你准备好学习更多的计算机科学,我也可以推荐你阅读它们。

这本编程书解释了计算机是如何工作的。它从第一个原理开始,讲述了如何构建一个,以及如何使用布尔代数进行计算。

不要让封面或苏格拉底式的写作风格让你以为这是一本简单的书。这是一本关于递归和计算的编程书。这本书既不长也不复杂,但它可能会让人费解。

丹尼尔·P·弗里德曼(Daniel P.Friedman)以这种风格写了更多的编程书籍,它们都很有趣。

读完这本编程书后,你应该看看经验丰富的阴谋家。此后,选择任何一个合理的计划者,小打字机,小校准器,或你选择的小MLer。

代码需要设计为可测试性、可读性、可扩展性和重用性。这很难实现,而且需要多次重构才能实现。

我是实干家,不是思想家。我不能专注于编写代码,让其他人来处理系统的设计吗?

编写代码与设计有关,这些编程书籍将为您提供一个工具箱,用于创建易于测试、理解和使用的API。

别让书中的插图蒙蔽了你,这是一本了不起的书。

它需要时间来引入新概念,并引导您了解最常见的设计模式的来龙去脉。

你别骗我,设计模式是Java的东西,好的编程语言不需要它们。

设计模式描述问题和一般解决方案。它适用于任何语言。在某些语言中,在其他语言中实现可能并不重要。EMPALE是Java语言,但它们只是实现的示例。

如今,函数式编程比以往任何时候都更为常见。不可变数据和高级函数是适用于所有编程语言的强大概念。有些语言使采用比其他语言更自然,但这些想法仍然很有价值。

要擅长测试驱动的开发和重构,必须擅长编写测试。编写可维护的测试需要练习和时间。

代码示例是C语言的,但是,关于如何构造测试代码的课程是通用的。

事实并非如此。这些名字来自于采取良好做法并将其发挥到极致。复习很好,为什么不通过结对编程不断复习呢?这本书很可能会让你质疑它的想法和你目前的做法。

我相信,在某种程度上,通过采用所有极端编程实践,可以在很大程度上帮助您的团队,但不要同时尝试太多,在给它一个适当的机会之前放弃。例如,结对编程是一项与其他任何技能一样的技能,需要时间来适应,而且它也是分层的。

你没有,但你有关于系统复杂性及其局限性的信息。

编写用户故事是比看起来更难的事情之一。在大多数情况下,试图用一句话来捕捉软件中的功能并非易事,因为它们既需要传达业务价值,也需要作为帮助开发人员找到要构建的内容的必要条件。

永远不会有一种语言、框架或平台来统领它们。写一次到处跑是一个神话。

如果你觉得学习一种新的框架或编程语言令人望而生畏,那么你被淘汰只是时间问题。

理解新工具的范例和模式可以减少学习它们所需的时间。

例如,一旦人们了解了函数式编程的范例和模式,以及静态类型是如何工作的,学习Haskell就只是语法和库熟悉程度的问题。

Head First设计模式仅涵盖本书中的一些模式。这本书的关键部分是23个经典设计模式。它也从一个伟大的讨论和案例研究开始。

它包含一个图表,需要花费时间才能习惯,并且例子是C++。阅读C++会有帮助,但是因为你最近读了头设计模式,这本书不应该是一个消费问题。

一个常见的抱怨是,TDD只适用于较小的问题,而不适用于实际应用,这是一个荒谬的想法!

本书将带你踏上一段TDD之旅,构建一个超越玩具示例的应用程序。

这本书介绍了七种不同的编程语言。它们可能与你的工作无关。这些语言中的许多思想和概念影响了当今许多现代语言。哈斯凯尔影响了斯威夫特、科特林、斯卡拉和埃尔姆等语言。

没人指望你能流利地掌握这些语言。它是关于尝试新想法和理解新概念。

将自己局限于一种编程语言无疑是一条失败之路。大师级工匠必须适应不断变化的行业。接触新语言是为了拓宽一个人解决问题的视角

熟悉命令行界面是你能学到的最跨平台的技能。从小到大的任务,它总是有帮助的。

有时在不需要数据库时使用数据库。一旦决定引入数据库,就应该知道如何设计好它,以避免数据重复。

数据库不仅仅是查询,还需要设计数据库。速度和效率是很难做到的。

这本书将遗留代码定义为没有单元测试的代码,并描述了如何围绕代码进行测试的技术(带有示例)。

如果足够大的话,遗留代码会出现在所有项目中,这有很多很好的理由。

使用遗留代码很累人,而且新功能的开发周期很长。它也可能是退化的温床。

代码示例在爪哇、C++、C、C中,但这些概念也适用于函数编程。

所有决策都会增加系统的架构。了解一些模式并制定策略将有助于控制系统。

这本编程书列出了设置代码边界的好策略。它很好地概述了应该努力争取什么和避免什么。

“干净的代码”讲述了如何保持实际代码整洁,清晰的边界非常有用。

DI是一个简单的概念,但会引起很多问题。如果所有依赖项都被创建了,那么我们在哪里?

这本书从以前的书中学习了许多概念,并给你一个完整的画面。它向您展示了如何避免对依赖项使用单例,实现跨领域关注点功能,如日志记录、验证等。

作为最初的设计模式手册,它定义了问题和解决方案的词汇表。了解了很多,你就可以灵活地在更高的抽象层次上探索和讨论解决方案。

如果你在编写软件时得到报酬,你可能正在开发一个企业应用程序。要把数据库、网络和用户界面代码等所有部分都做好是很困难的。这本书将帮助你为正确的理由做出正确的权衡。

设计模式和重构的耦合并不总是显而易见的。设计模式可以解决问题,所以如果没有,就不应该应用它们。

这本编程书展示了我们如何从其他书中学习并应用它来简化代码。

这本书很长,如果扔掉时被击中,你可能会被送进医院。也是它的完整性使它变得伟大。

测试代码和生产代码一样需要设计。关于干净代码的规则和原则仍然适用于测试。

如果不维护,测试代码可能会有问题。识别测试气味并知道使用什么模式对测试套件的健康至关重要。

编程是成为软件大师的重要组成部分,但与人沟通也是一项同样重要的技能。如果沟通中断,一切都会变得更加困难。

永远不要忘记,项目和公司只是人。试图为用户提供价值的人。

掌握的道路永远不会结束。就像武术中的黑带一样,这是开始,而不是结束。

每个人都有命名问题。拥有一种共同的语言将帮助你找到新的抽象,并为代码的读者提供更多的上下文。

软件很难构建。我们今天在软件项目中面临的问题与软件工程一样古老。这本书非常清楚地说明了这一点。这本书写于1975年,讲述的是60年代IBM的一个软件项目,它给人的感觉与当时一样重要。

了解和理解常见的软件项目问题有助于我们缓解这些问题,或者至少知道会发生什么。

“为一个后期的软件项目增加人力会使它变得更晚”——布鲁克斯定律。

有时我们把人当成机器。在某些职业中,这是可行的。在软件项目中,它会产生难以修复的问题。

你是什么意思,如果你使用的是最新的Javascript框架,成功不是基于什么?

人是软件项目成败的关键。很少有技术问题。拥有一支运转良好的团队比拥有一个现代化的技术团队更重要。