The Pragmatic Programmer(R)

| Tags Reading  CS 

#The Pragmatic Programmer: From Journeyman to Master

ISBN: 020161622X READ: 2014-04-13 RATING: 9/10

I recently finished the Pragmatic Programmer,this book about sfortware engineering and best pratices was first published in 1999.The authors boiled down all the practical approaches that they’ve found to work in the real world into this one book.

More detail:www.pragmaticprogrammer.com

###Tip 1: Care about your craft.

Why spend your life developing software unless you care about doing it well?

Programming is half art half engineering. Great programmers are craftsman. And they wrote software with heart.

###Tip 2: Think! about your work.

###Tip 3: Provide options, don’t make lame excuses.

###Tip 4: Don’t live with Broken Windows.

Bugs lead to bugs.

###Tip 5: Be a catalyst for change.

Willing to change, and change the way others do things if it helps.

###Tip 6: Remember the big picture.

###Tip 7: Make quality a requirements issue.

###Tip 8: Invest regularly in your knowledge portfolio.

New knowledge brings new thinking.

###Tip 9: Critically analyze what you read and hear.

Not all info are valuable. Don’t get info overloaded.

###Tip 10: It’s both what you say and the way you say it.

Great programmer communicates well.

###Tip 11: DRY—Don’t repeat yourself.

###Tip 12: Make it easy to reuse.

###Tip 13: Eliminate effects between unrelated things.

Complication comes with relationship.

###Tip 14: There are no final decisions.

No decision is cast in stone. Instead, consider each as being written in the sand at the beach, and plan for change.

Evolution theory applies to software development. We tried different approaches to get to the better one, and there’s always room to improve. That’s why software dev never ends.

###Tip 15: Use tracer bullets to find the target.

Tracer bullets let you home in on your target by trying things and seeing how close they land.

###Tip 16: Prototype to learn.

Small program to test is almost always good.

###Tip 17: Program close to the problem domain.

Programming is the tool for problem solving. The key point is, solve the problem.

Design and code in your user’s language.

###Tip 18: Estimate to avoid surprises.

Estimate before you start. You’ll spot potential problems up front.

Estimate helps, but it hardly get close.

###Tip 19: Iterate the schedule with the code.

###Tip 20: Keep Knowledge in Plain Text

Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.

###Tip 21: Use the power of command shell.

Commands help in automation.

learn to use a command prompt is a great way to improve our performance bay reducing the time we expend searching for some files, we can filtrate our search by date, name, extension, and so on, even we can install or modify features in our OS that we can’t do in the GUI.

###Tip 22: Use a single editor well.

The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.

###Tip 23: Always use source code control.

Source code control is a time machine for your work – you can go back.

###Tip 24: Fix the problem, not the blame.

It doesn’t really matter whether the bug is your fault or someone else’s – it is still your problem, and it still needs to be fixed.

###Tip 25: Don’t panic.

Take a deep breath and THINK! about what could be causing the bug.

###Tip 26: “select” isn’t broken.

It is rare to find a bug in the OS or the compiler, or even a third-party product or library. The bug is most likely in the application.

###Tip 27: Don’t assume it—prove it.

Prove your assumptions in the actual environment – with real data and boundary conditions.

###Tip 28: Learn a text manipulation language.

###Tip 29: Write code that writes code.

###Tip 30: You can’t write perfect software.

###Tip 31: Design with contracts.

###Tip 32: Crash early.

###Tip 33: If it can’t happen, use assertions to ensure that it won’t.

###Tip 34: Use exceptions for exceptional problems.

###Tip 35: Finish what you start.

###Tip 36: Minimize coupling between modules.

###Tip 37: Configure, don’t integrate.

###Tip 38: Put abstractions in code details in metadata.

###Tip 39: Analyze workflow to improve concurrency.

###Tip 40: Design using services.

###Tip 41: Always design for concurrency.

###Tip 42: Separate views from models.

###Tip 43: Use blackboards to coordinate workflow.

###Tip 44: Don’t program by coincidence.

###Tip 45: Estimate the order of your algorithms.

###Tip 46: Test your estimates.

###Tip 47: Refactor early, refactor often.

###Tip 48: Design to test.

###Tip 49: Test your software, or your users will.

###Tip 50: Don’t use wizard code you don’t understand.

###Tip 51: Don’t gather for requirements—dig for them.

###Tip 52: Work with a user to think like a user.

###Tip 53: Abstractions live longer than details.

###Tip 54: Use a project glossary.

###Tip 55: Don’t think outside the box—find the box.

###Tip 56: Listen to nagging doubts—start when you’re ready.

###Tip 57: Some things are better done than described.

###Tip 58: Don’t be a slave to formal methods.

###Tip 59: Expensive too do not produce better designs.

###Tip 60: Organize around functionality, not job functions.

###Tip 61: Don’t use manual procedures.

###Tip 62: Test early. Test often. Test automatically.

###Tip 63: Coding aren’t done until all the tests run.

###Tip 64: Use saboteurs to test your testing.

###Tip 65: Test state coverage, not code coverage.

###Tip 66: Find bugs once.

###Tip 67: Treat English as just another programming language.

###Tip 68: Build documentation in, don’t bolt it on.

###Tip 69: Gently exceed your users’ expectations.

###Tip 70: Sign your work.

Great programmers produce software they’re pround of, and they’re responsible for the work they do, and they take credit. Sign the work!

###How to Maintain Orthogonality

.Design independent, well-defined components.

.Keep your code decoupled.

.> Avoid global data.

.Refactor similar functions.

###When to Refactor

.You discover a violation of the DRY principle.

.You find things that could be more orthogonal.

.Your knowledge improves.

.The requirements evolve.

.You need to improve performance.


Back     Next
comments powered by Disqus