构建商业级PHP与MySQL应用：项目组织与最佳实践

需积分: 10 183 浏览量更新于2023-03-16 收藏 7.23MB PDF 举报

"《Expert PHP and MySQL》（Apress，2013年版）是一本专为经验丰富的PHP开发者和MySQL技术专家量身打造的实用指南，它不仅深入讲解语言语法，更侧重于传授如何应用成熟的软件开发方法来构建高质量、商业级别的PHP和MySQL项目。作者Marc Rochkind引导读者面对现实世界应用程序开发中的复杂挑战，如错误处理、数据库设计、项目组织、用户界面与用户体验等。书中的核心内容包括： 1. 项目组织：从项目启动开始，强调清晰的合同和书面需求，确保项目的正确方向和客户满意度。 2. 需求管理：学习如何制定和管理项目需求，以满足客户期望并支持后续的修改和扩展。 3. 平台与工具选择：介绍适合商业应用的开发平台和工具，建立稳定的开发环境。 4. 数据库设计：指导读者创建健壮的模型和数据库结构，以及何时将功能迁移到数据库以提高效率。 5. 应用结构：探讨如何设计高效且易于维护的应用架构，包括错误处理策略和安全性考虑。 6. 报告生成：涵盖了在线、下载和打印报告的生成技术，满足不同的输出需求。 7. 数据转换：处理从旧系统到新应用的数据迁移问题，确保数据的完整性和一致性。在书中，作者特别关注了错误处理的重要性，不仅在PHP语法层面，还涉及MySQL错误处理、日志记录以及保护应用内部细节免受错误消息泄露。通过本书，读者可以提升PHP编程的生产力、可靠性和安全性，从而跨越从个人编程到商业级应用开发的关键一步。正如Fred Brooks在其著作《The Mythical Man-Month》中所述，一个功能完善的商业级程序的成本远高于调试后的同等功能程序。《Expert PHP and MySQL》旨在帮助读者理解并克服这一挑战，实现高效、可维护的商业级PHP/MySQL项目开发。"

Chapter 1 ■ projeCt organization

Poor Development Processes

Even with a good set of requirements, a project can get into big trouble if the development processes are poor. Among

the sins are

Waiting until late in development to integrate the components.•

Inadequate unit testing, resulting in failed integration and a lot of wasted time.•

Poor allocation of modules to people, without clear and minimal interfaces.•

An awkward and/or frequently changing database schema.•

Sloppy programming habits, not corrected during code walkthroughs.•

System tests with gaps in coverage.•

Not engaging the customer with frequent demos and alpha releases.•

Changed Priorities

This was the killer of projects at Bell Labs when I was there in the 1970s. A project would get started, get staffed

at a level only AT&T (Bell Labs’ owner) could afford, and then get killed a few years later because technology had

improved (I already mentioned the AMDF project), the personnel were needed on a more important project, or the

economics changed. Maybe another company would have thought more carefully before starting a project with such a

questionable future, but in those days AT&T was a regulated monopoly and didn’t have to watch its expenses.

Today’s equivalent of changed priorities is probably VC drying up.

Sabotage

Sabotage is a deliberate attempt by a manager to kill the project, usually surreptitiously. A common situation is when

someone who never supported the project replaces a manager. This and other forms of corporate in-fighting are

outside the scope of this book; I list this situation here only to acknowledge that it’s pretty common.

Managing the Project

By definition, management is the use of resources to accomplish an objective. In a software project, the objective is

to satisfy the customer, and on a day-to-day basis, its proxy is the requirements. The resources are mostly people,

although equipment and outside services may come into the picture as well.

There’s a lot to management, but, there are five essential tasks that will lead to success if done right. The first

three mirror the three dimensions I discussed earlier.

1. Keep the requirements from expanding unnecessarily.

2. Get the right people onto the team.

3. Closely monitor the schedule, and change it when necessary.

4. Make sure all the work is assigned.

5. Keep the people happily focused on their assignments.

Chapter 1 ■ projeCt organization

That’s it! Do these five and, if the requirements are right, the project will be successful. Fail at any one of them

and the project will fail.

I’ve already explained why the first three tasks are so critical, and I’ll have much more to say about requirements

in Chapter 2.

Task 4, surprisingly often overlooked, is to ensure that you develop all of the deliverables. It’s too easy to

get wrapped up in the complexities of managing the programming and forget more mundane requirements like

documentation, training, installation, and support. Task 5 is to make sure that you actually execute the plans you’ve

hatched by doing the first four tasks. Programmers are notorious for getting distracted from their main mission.

What’s more, you have to keep them happy, or their productivity will drop all the way to zero, and perhaps even go

negative.

I’ve been careful to use the term “management” and not “manager.” All projects must have management, no

matter how small; without it, the resources are not being applied to accomplishing the objective. With a team of one

or two, there’s no need to designate one of them as the manager. But teams of three or more need to know who’s the

boss. It’s too inefficient to decide matters by consensus, and it runs the risk of losing track of the path toward the goal.

More than a half-dozen people, and there needs to be a full-time manager.

But, however you arrange it, the five essential tasks need to be done. You might argue that a schedule and work

assignments are unnecessary with a collaborative, egoless, team-oriented approach, but I don’t agree. I think that

leads to guaranteed failure: a late project, with unpopular jobs, such as conversion, documentation, or training, left

incomplete or haphazardly done.

Here’s how I did things for SuperSked, the checker-scheduling software for supermarkets. By the time I was

brought in to manage engineering, they had already spent a year burning through $500K or so of VC that was

supposed to get them a Windows version of their system, which had originally been built for character-oriented UNIX

terminals. After a year, they had a fancy object-oriented user-interface framework completed, and nothing else.

I agreed to take another $250K or so of VC money and finish the system in about six months. If I failed, the plug would

be pulled, and the company would fold.

So, of the three dimensions—requirements, resources, and schedule—two were already fixed. Actually, so were

requirements, since the new system had to completely replace the old system, which meant it had to provide the same

demand forecasting, adherence to union rules, cost optimization, and printed schedules that the old system provided,

but on Windows.

I decided that it was doable and signed on. There were about eight people in development, including a

mathematician who worked on the optimization algorithm and a testing specialist. The new CEO and I fired three

people who were technically competent enough but were spending too much time arguing that the existing system

was on the right track. After a week or so of study, I threw out 100% of the code that they had spent a year writing

but kept the database design, which was excellent. I hired two programmers, one recommended to me by a former

colleague and one from a newspaper ad.

That concluded tasks 1 and 2 on the list: the people and the requirements.

I knew the endpoint of the schedule, but not the intermediate points. Since we had six months of life left,

I planned the development for four, to give us one month for system testing and one month for unforeseen problems,

which, by definition, can’t be planned for.

So, I plotted out the system as best I could and divided the work into 16 weekly segments. Of course, we didn’t

stick exactly to that plan—one never does—but I had to convince myself that the problem had a solution. Task 3 done.

Then I divided up the work, unilaterally. In other projects this would be done collaboratively, but there was no

time for that. I just told the people what I wanted them to do. That was task 4.

With all this set up, my only management job was task 5, keeping everyone focused. I did that with a weekly

meeting in which we went around the room so each person could state very quickly where he was. We also had the

existing system to maintain, so customer issues were on the table, too.

The weekly meetings usually resulted in a few items that required my further attention, which I handled by

visiting, privately, whoever was involved. A strict rule was that we never discussed anything at these weekly meetings.

They were for status only. They never went more than a half-hour.

Chapter 1 ■ projeCt organization

Many on the team were used to meetings that dragged out, meetings where there’s an attempt to reach a decision

on some matter. I explained at the first meeting that I only wanted status, but it didn’t catch on right away. At one

point one of the founders of the company, Seth (not his real name), started jabbering about his attempts to find a

solution to something he was working on. Following is the conversation that ensued:

Me: “Seth, stop talking.”

Seth: “I’m explaining what I’ve been working on.”

Me: “I know, but this is a status meeting. Just tell us whether it’s finished, in-progress, or not started.”

Seth: “It’s in-progress, but I need to explain that it’s gotten complicated.”

Me: “Seth, you’ve confused this with a meeting at which people talk. It’s not. It’s a meeting where I do almost all

of the talking, and you can talk when it’s your turn, but you can only say one of three things.”

Everyone: Laughter at my sarcasm. Seth was laughing, too, fortunately.

Seth: “In-progress.”

Me: “Great report. Next item?”

Many years later I ran into the testing specialist, who told me how much she had enjoyed the project. I told her

I had probably acted like a sarcastic jerk. She disagreed, telling me that I was the first manager they’d had who actually

managed; they were tired of failure, and, what’s more, they all thought my sarcasm was very funny. (It is; I’m very

good at it.)

By the way, we shipped the new system on time, the customers loved it, and the company was sold to a larger

company in the same business that’s still doing well with the product over ten years later. More important to the

investors was that they got their money back and more, after kissing it good-bye. I moved on, but I think the founder,

Seth, is still there, with all his stock intact.

Here was another example of my approach, this time at the next company I went to, also in trouble. A programmer,

call him Brian, had started to irritate the database administrator by getting involved with database issues like

performance and backup, not even close to his assigned job. I asked him to join me in my office.

Me: “I understand you’ve started to help out with the database.”

Brian: “Yeah. It’s really not done right. I’m happy to help.”

Me: “Do you remember your assignment?”

Brian: “Sure. The web update pages.”

Me: “So, that’s what I want you to do. Just that.”

Brian: “I’m doing it. But I also think I should contribute to other things, where I can.”

Me: “Absolutely. You can do whatever you think is best. Totally up to you. Not my place to interfere.”

Brian: Starting to smile, nervously.

Me: “Only you can’t do it here. Here, you can only do your assignment.”

Brian, catching on: “So . . . I’ll do the web update. Not the database.”

Me: “That will be fine. Thanks. By the way, it’s looking really good.” (No idea if that was true, but I wanted him to

go away happy.)

You might be shocked at my dictatorial style, but given our board-imposed constraints, I was going to spend a

maximum of two minutes getting this excellent, but distracted, programmer back on his assignment.

Another important monitoring task is making sure the various components, developed by different people,

fit together and work with the most recent database schema. If the system requires building, it should be built

automatically each night. (PHP programs usually don’t require building, just placement of the files in the appropriate

directories on the server.) Whatever self-checking system tests that have been developed should be run also. Everyone

on the team should get an e-mail each morning with the results. If anything is amiss, fixing it is the top priority—no

further development should be done until the system is integrated and passes its self-checking tests.

Chapter 1 ■ projeCt organization

Dividing the Work

He is all pine and I am apple orchard.

My apple trees will never get across

And eat the cones under his pines, I tell him.

He only says, “Good fences make good neighbors.”

—Robert Frost, Mending Wall

A project with a lot of communication is a happy project, but very little of that communication ought to be about

interfaces between components. Interfaces need to be simple, minimal, and stable. Once set up, if there’s much more

to discuss about them, something’s very wrong. But if the interfaces are right, the system will integrate smoothly and

accommodate change without losing its structural integrity.

The interfaces between components should also be the interfaces between people on the development team.

That allows developers to work at their own pace and in the order that makes the most sense. Bad interfaces—ones

that leak too much information—cause developers to have to wait for each other to complete work, and cause work

already completed to be redone.

This is not to say that the team shouldn’t have important things to talk about every day. It’s fine to talk about the

results of the nightly build and test, new insights about the customer’s evolving needs, and technical problems that

can benefit from a group effort. But it’s not OK to talk frequently about interfaces. They need to be so stable that there’s

nothing to talk about.

Exploiting Database Centricity

That SuperSked application I mentioned a few paragraphs back was the first database-centric project I’d managed

with more than two or three people on it, and development went amazingly smoothly, even though the application

itself was fairly complex. There were almost no integration difficulties. Bugs found through testing were quickly

identified and fixed.

We did a lot of things right: a terrific team of developers, well-understood requirements (it was a replacement for

an existing system), and a tight, but reasonable schedule. But there was one more aspect of the project organization

that really made the difference: all of the components talked only to the database. They got their data entirely from the

user (via forms) or from the database, and they deposited their results back in the database. Components never talked

directly to each other.

Testing was based on database snapshots captured from customers of the existing system and then converted to

the new database, using the same conversion programs that would later be part of the deployed system. A component

could be exercised in isolation, since everything it needed was in the database. (A few components required

some data entry.) Then the results in the database could be easily checked. If anything was amiss, it had to be the

component itself, since it couldn’t be an interface problem.

Good news: PHP/MySQL applications, the focus of this book, provide exactly the same advantage. To exploit

that advantage, however, you have to design each component—each form, report, and business-logic module—to

interface only to the database.

There were a lot of conversations between the component developers and the database designer, especially at the

start of the project, as the schema was complicated, with many subtleties. But even those conversations pretty much

stopped once the model was well understood.

Here’s an example of how components interfaced only to the database, instead of directly: the first step in

scheduling the checkers is to forecast demand, based on the time of year, day of week, presence of holidays, predicted

weather, and a few other factors. Second, labor availability had to be established, depending on work schedules,

union rules, training (not everyone could handle the express register), and so on. The results of these two preliminary

steps were then fed into a very advanced optimization algorithm that computed for a while, maybe 10 or 15 minutes,

and then coughed up a schedule, which then got arranged into various reports, including one for posting on the

employee bulletin board.

www.allitebooks.com

Chapter 1 ■ projeCt organization

The obvious thing to do is to work out a way, using XML, for example, for the forecasting and the availability

modules to connect to the optimizer. We didn’t do that. We had them insert data into the database, and we designed

the optimizer to query the database for its inputs. One huge benefit to this was that the programmer working on the

optimizer could just keep running it on the same inputs, without dealing with the predecessor modules at all. And,

once the programmers working on them verified that the data was in the database correctly, they were done. No need

to actually run the optimizer.

To the programmers who had worked on the legacy system, where the data existed internally in huge Fortran-style

arrays, the idea of writing all those numbers into the database seemed very strange. But, once the functions to do it

were coded, the job was done, and they never dealt with interfacing issues again.

Assigning Components to People

Many PHP/MySQL projects are very small, probably because large, corporate developments tend to use fancier

technologies such as Java EE or .NET. I don’t have the numbers, but I’d guess that half of all PHP/MySQL projects are

done by one or two people and a quarter are done by four or fewer. So, the work is usually divided up only a few ways.

For any PHP/MySQL project, and for most others, too, the categories of development jobs are

1. Database design and implementation,

2. CRUD (create, retrieve, update, delete) web pages,

3. Business logic (e.g., scheduling supermarket checkers, routing deliveries, computing

invoices),

4. Reports and other outputs,

5. Conversion,

6. System testing,

7. Documentation, and

8. Training.

If there are two of you, one should do the database, conversion, and reports, because that’s nearly a stand-alone

application. Once the database is loaded with converted data, there should be enough to test the reports. The other

person can do the CRUD and business logic. System testing, documentation, and training can be split up any way

you see fit.

With three people, if the business logic is complex, as it certainly was for SuperSked, that’s a full-time job, and

other jobs can be split as they were for two people.

With more than three, it still makes sense to combine the database and conversion, because conversion exposes

so much about what the database needs to be able to model. Also, once you design and implement the database,

it’s no longer a full-time job. The other components can be split according to their complexity and the skills of the

team members.

Remember, no matter how you assign the components, they only interface to the database, never to one another.

The Workplace

Part of organizing a project is organizing a place for the work.

As far as the technology goes, for PHP/MySQL projects, physical location doesn’t much matter. It’s easy to set up

a development system on your own computer and to send files to the development server for integration. You don’t

require any special hardware; any laptop or desktop running MacOS, Windows, or Linux will do.

剩余327页未读，继续阅读

vanridin

粉丝: 108
资源: 1187

构建商业级PHP与MySQL应用：项目组织与最佳实践

Expert PHP and MySQL01:

Expert PHP and MySQL

PHP and MySQL

Apress.Expert.Android.2013

PHP and MySQL Recipes(Apress,2ed,2016)

Apress Beginning Php And Mysql 5 From Novice To Professional 2Nd Edition.pdf

Apress.Expert.JavaScript.Nov.2013

Expert Oracle JDBC Programming - Apress

Expert Oracle RAC Performance Diagnostics and Tuning(Apress,2014)

Apress.Beginning.PHP.and.MySQL.5.From.Novice.to.Professional

最新资源