Python实用指南：数据科学实战与机器学习测试驱动

需积分: 10 103 浏览量更新于2024-07-19 3 收藏 8.4MB PDF 举报

《Thoughtful Machine Learning with Python 2017》是一本实用指南，由作者Matthew Kirk撰写，旨在帮助读者在日常工作中应用机器学习技术。该书强调实践性，不局限于学术理论，注重将机器学习算法融入代码，并通过Python的Numpy、Pandas、Scikit-Learn和SciPy等数据科学库进行测试。本书适合软件工程师和业务分析师这类对数据科学感兴趣的读者。书中采用了一种以测试驱动的方法（Test-Driven Approach），这表明作者注重在实际操作中确保算法的有效性和准确性。读者将跟随作者的脚步，从基础概念出发，逐步掌握如何构建和优化模型，以及如何利用这些工具处理和分析数据。书中的图表和高亮代码示例有助于读者理解，同时，书籍的版权信息显示了出版年份为2017年，由O'Reilly Media Inc.出版，版权所有。《Thoughtful Machine Learning with Python》特别适合希望通过实践学习和应用机器学习的初学者和有一定经验的专业人士，它不仅提供了理论知识，还提供了实用的编程技巧和案例研究，使读者能够在实际项目中运用所学。如果你是软件工程师，希望提升数据科学技能；或者你是业务分析师，想要深入理解如何利用数据驱动决策，那么这本书将是你的得力助手。在编写过程中，作者遵循了严谨的编辑流程，包括Mike Loukides和Shannon Cutt的编辑指导，Nicholas Adams的生产编辑工作，James Fraleigh的校对，Charles Roumeliotis的审阅，Wendy Catalano的索引编制，以及David Futato和Randy Comer的专业设计。整个出版过程确保了内容的专业性和质量，而1月2017年的首次发布和后续修订也保证了信息的时效性。无论你是入门者还是进阶者，这本书都将成为你在机器学习旅程中不可或缺的参考资料。

we cannot say the same about software, which grows ever more complex. Cata‐

strophic bugs strike with regularity, wasting billions of dollars.

Why is it that airlines have become so safe and software so buggy?

Writing Software Right

Between 1929 and 2014 airplanes have become more complex, bigger, and faster. But

with that growth also came more regulation from the FAA and international bodies as

well as a culture of checklists among pilots.

While computer technology and hardware have rapidly changed, the software that

runs it hasn’t. We still use mostly procedural and object-oriented code that doesn’t

take full advantage of parallel computation. But programmers have made good strides

toward coming up with guidelines for writing software and creating a culture of test‐

ing. These have led to the adoption of SOLID and TDD. SOLID is a set of principles

that guide us to write better code, and TDD is either test-driven design or test-driven

development. We will talk about these two mental models as they relate to writing the

right software and talk about software-centric refactoring.

SOLID

SOLID is a framework that helps design better object-oriented code. In the same ways

that the FAA defines what an airline or airplane should do, SOLID tells us how soft‐

ware should be created. Violations of FAA regulations occasionally happen and can

range from disastrous to minute. The same is true with SOLID. These principles

sometimes make a huge difference but most of the time are just guidelines. SOLID

was introduced by Robert Martin as the Five Principles. The impetus was to write

better code that is maintainable, understandable, and stable. Michael Feathers came

up with the mnemonic device SOLID to remember them.

SOLID stands for:

• Single Responsibility Principle (SRP)

• Open/Closed Principle (OCP)

•

Liskov Substitution Principle (LSP)

• Interface Segregation Principle (ISP)

• Dependency Inversion Principle (DIP)

Single Responsibility Principle

The SRP has become one of the most prevalent parts of writing good object-oriented

code. The reason is that single responsibility defines simple classes or objects. The

2 | Chapter 1: Probably Approximately Correct Software

1 Robert Martin, “The Dependency Inversion Principle,” http://bit.ly/the-DIP.

2 Atul Gawande, e Checklist Manifesto (New York: Metropolitan Books), p. 161.

Dependency Inversion Principle

The DIP is a principle that guides us to depend on abstractions, not concretions.

What this is saying is that we should build a layer or inheritance tree of objects. The

example Robert Martin explains in his original paper

is that we should have a Key

boardReader inherit from a general Reader object instead of being everything in one

class. This also aligns well with what Arthur Riel said in Object Oriented Design Heu‐

ristics about avoiding god classes. While you could solder a wire directly from a guitar

to an amplifier, it most likely would be inefficient and not sound very good.

The SOLID framework has stood the test of time and has shown up

in many books by Martin and Feathers, as well as appearing in

Sandi Metz’s book Practical Object-Oriented Design in Ruby. This

framework is meant to be a guideline but also to remind us of the

simple things so that when we’re writing code we write the best we

can. These guidelines help write architectually correct software.

Testing or TDD

In the early days of aviation, pilots didn’t use checklists to test whether their airplane

was ready for takeoff. In the book

e Right Stu by Tom Wolfe, most of the original

test pilots like Chuck Yeager would go by feel and their own ability to manage the

complexities of the craft. This also led to a quarter of test pilots being killed in action.

Today, things are different. Before taking off, pilots go through a set of checks. Some

of these checks can seem arduous, like introducing yourself by name to the other

crewmembers. But imagine if you find yourself in a tailspin and need to notify some‐

one of a problem immediately. If you didn’t know their name it’d be hard to commu‐

nicate.

The same is true for good software. Having a set of systematic checks, running regu‐

larly, to test whether our software is working properly or not is what makes software

operate consistently.

In the early days of software, most tests were done after writing the original software

(see also the waterfall model, used by NASA and other organizations to design soft‐

ware and test it for production). This worked well with the style of project manage‐

ment common then. Similar to how airplanes are still built, software used to be

designed first, written according to specs, and then tested before delivery to the cus‐

tomer. But because technology has a short shelf life, this method of testing could take

4 | Chapter 1: Probably Approximately Correct Software

3 Nachiappan Nagappan et al., “Realizing Quality Improvement through Test Driven Development: Results and

Experience of Four Industrial Teams,” Empirical Soware Engineering 13, no. 3 (2008): 289–302, http://bit.ly/

Nagappanetal.

months or even years. This led to the Agile Manifesto as well as the culture of testing

and TDD, spearheaded by Kent Beck, Ward Cunningham, and many others.

The idea of test-driven development is simple: write a test to record what you want to

achieve, test to make sure the test fails first, write the code to fix the test, and then,

after it passes, fix your code to fit in with the SOLID guidelines. While many people

argue that this adds time to the development cycle, it drastically reduces bug deficien‐

cies in code and improves its stability as it operates in production.

Airplanes, with their low tolerance for failure, mostly operate the same way. Before a

pilot flies the Boeing 787 they have spent X amount of hours in a flight simulator

understanding and testing their knowledge of the plane. Before planes take off they

are tested, and during the flight they are tested again. Modern software development

is very much the same way. We test our knowledge by writing tests before deploying

it, as well as when something is deployed (by monitoring).

But this still leaves one problem: the reality that since not everything stays the same,

writing a test doesn’t make good code. David Heinemer Hanson, in his viral presenta‐

tion about test-driven damage, has made some very good points about how following

TDD and SOLID blindly will yield complicated code. Most of his points have to do

with needless complication due to extracting out every piece of code into different

classes, or writing code to be testable and not readable. But I would argue that this is

where the last factor in writing software right comes in: refactoring.

Refactoring

Refactoring is one of the hardest programming practices to explain to nonprogram‐

mers, who don’t get to see what is underneath the surface. When you fly on a plane

you are seeing only 20% of what makes the plane fly. Underneath all of the pieces of

aluminum and titanium are intricate electrical systems that power emergency lighting

in case anything fails during flight, plumbing, trusses engineered to be light and also

sturdy—too much to list here. In many ways explaining what goes into an airplane is

like explaining to someone that there’s pipes under the sink below that beautiful

faucet.

Refactoring takes the existing structure and makes it better. It’s taking a messy circuit

breaker and cleaning it up so that when you look at it, you know exactly what is going

on. While airplanes are rigidly designed, software is not. Things change rapidly in

software. Many companies are continuously deploying software to a production envi‐

Writing Software Right | 5

ronment. All of that feature development can sometimes cause a certain amount of

technical debt.

Technical debt, also known as design debt or code debt, is a metaphor for poor system

design that happens over time with software projects. The debilitating problem of

technical debt is that it accrues interest and eventually blocks future feature develop‐

ment.

If you’ve been on a project long enough, you will know the feeling of having fast

releases in the beginning only to come to a standstill toward the end. Technical debt

in many cases arises through not writing tests or not following the SOLID principles.

Having technical debt isn’t a bad thing—sometimes projects need to be pushed out

earlier so business can expand—but not paying down debt will eventually accrue

enough interest to destroy a project. The way we get over this is by refactoring our

code.

By refactoring, we move our code closer to the SOLID guidelines and a TDD code‐

base. It’s cleaning up the existing code and making it easy for new developers to come

in and work on the code that exists like so:

1. Follow the SOLID guidelines

a. Single Responsibility Principle

b. Open/Closed Principle

Liskov Substitution Principle

d. Interface Segregation Principle

e. Dependency Inversion Principle

Implement TDD (test-driven development/design)

3. Refactor your code to avoid a buildup of technical debt

The real question now is what makes the software right?

Writing the Right Software

Writing the right software is much trickier than writing software right. In his book

Specication by Example, Gojko Adzic determines the best approach to writing soft‐

ware is to craft specifications first, then to work with consumers directly. Only after

the specification is complete does one write the code to fit that spec. But this suffers

from the problem of practice—sometimes the world isn’t what we think it is. Our ini‐

tial model of what we think is true many times isn’t.

Webvan, for instance, failed miserably at building an online grocery business. They

had almost $400 million in investment capital and rapidly built infrastructure to sup‐

6 | Chapter 1: Probably Approximately Correct Software

剩余215页未读，继续阅读

xinconan2

粉丝: 269
资源: 399

Python实用指南：数据科学实战与机器学习测试驱动

Thoughtful Machine Learning with Python A Test Driven Approach

Thoughtful Machine Learning with Python A Test-Driven Approach

Thoughtful Machine Learning with Python

Can you give me some advice about my first anniversary with my girlfriend. What should I do to make her happy.

这个视频脚本要包含三个章节，20个分镜头

thulac如何安装

创建10个好的博客昵称

请给我一段能用于训练ai对话性格的代码

Help me write a 600-word review for getting up late today

最新资源