What do you think?
Rate this book
Software Development and Professional Practice
Software Development and Professional Practice reveals howto design and code great software. What factors do you take into account? What makes a good design? What methods and processes are out there fordesigning software? Is designing small programs different than designing large ones? How can you tell a good design from a bad one? You'll learn the principles of good software design, and how to turn those principles back into great code.Software Development and Professional Practice is also about code constructionhow to write great programs and make them work. What, you say? You've already written eight gazillion programs! Of course I know how to write code! Well, in this book you'll re-examine what you already do, and you'll investigate ways to improve. Using the Java language, you'll look deeply into coding standards, debugging, unit testing, modularity, and other characteristics of good programs. You'll also talk about reading code. How do you read code? What makes a program readable? Can good, readable code replace documentation? How much documentation do you really need?This book introduces you to software engineeringthe application of engineering principles to the development of software. What are these engineering principles? First, all engineering efforts follow a defined process. So, you'll be spending a bit of time talking about how you run a software development project and the differentphases of a project. Secondly, all engineering work has a basis in the application of science and mathematics to real-world problems. And so does software development! You'll therefore take the time to examine how to design and implement programs that solve specific problems.Finally, this book is also about human-computer interaction and user interface design issues. A poor user interface can ruin any desireto actually use a program; in this book, you'll figure out why and how to avoid those errors.Software Development and Professional Practice covers many of the topics described for the ACM Computing Curricula 2001 course C292c Software Development and Professional Practice. It is designed to be both a textbook and a manual for the working professional. What you'll learn How to design and code great software What methods and processes are available to help you design great software How to apply software engineering principles to your daily coding practice Howto tell a good design from a bad one? Understand the characteristics of good programs How to construct professional standard code that you can be proud to show Understand all about coding standards, and apply them to real Java coding Explore debugging, unit testing and modularity All about object-oriented programming (OOP) design principles and great coding How to apply the principles you've learned to specific and real-world coding problems A companion to the ACM Computing Curricular 2001 source C202c Who this book is forSoftware Development and Professional Practice is designed to be both a textbook and a manual for the working professional programmer, and any student of programming who wants to learn the art of the trade. This book assumes you know some Java, enough to read its examples at least, and that you've already done some programming. Now you want to write great code!This book covers many of the topics described for the ACM Computing Curricula 2001 course C292c Software Development and Professional Practice, and will be a great companion to anyone studying this course. Table of Contents Introduction to Software Development Process Life Cycle Models Project Management Essentials Requirements Software Architecture Design Principles Structured Design Object-Oriented Analysis & DesignAn Overview Object-Oriented Analysis & DesignA Play in Several Acts Object-Oriented Design Principles Design Patterns Code Construction Debugging Unit Testing Walkthroughs, Code Reviews and Inspections Wrapping it All Up "
264 pages, Paperback
First published January 1, 2011
4 people are currently reading
21 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
February 17, 2016
The perils of impulse buying from the internet without carefully reading the precis! I had expected this to be an examination of professional practise, with the emphasis on people working in the software development profession. What it actually is instead, is an introduction to the wider aspects of development and professional activity primarily focused on (young) people who have maybe done some coding, but haven't (yet) experienced all the other disciplines that surround the actual cranking out of code.
So, leaving aside my misconceptions, how does it achieve that goal? Well, on the one hand, it does a reasonable job of providing an overview of the other aspects of the SDLC like project management, architecture and testing, and different development methodologies. It goes into enough depth of most to give a decent introduction to the subject, mostly without drowning the reader new to those areas - it gives code examples of some areas (eg OOAD) where this makes some sense to do so and reflects on the presumed target audience's background as coders, and provides plenty of good references throughout. Actually, it's at its best in the chapters which centre around the design, development and, to some extent, testing of code.
So far, so good. Unfortunately, it is rather uneven in quality and focus, and my overriding feeling when I got to the end was that the author had taken his experience and generalised that out to be The Way Things Are Done. So software is developed in Software Development Organisations (no software development inside non-software companies?), every software development ends up with a detailed code inspection (really? even in Agile developments? even in really small teams?) and generally the content is a mix of well-described theory but with some real problems when it goes into detail.
For example, his first descripton of abstraction as "Abstraction means being lazy. You put off what you need to do by pushing it higher in the design hierarchy" - I can understand what he is trying to say here, and in context of the OOAD content later it would almost make sense, but appearing much earlier in the book, in the chapter on design principles it is very misleading.
Another example is his treatment of Use Cases, which were horribly badly explained, with supposed UCs that conflated multiple use-cases into a single item which would lead to a terrible design.
There are several other examples I could give, but my other bugbear is the tone of the writing. Most of the time it's comfortable and professional, but occasionally he drops into this over-conversational style as though he's suddenly realised the age of the target audience and wants to speak to them in their own language, and makes an excellent job of it. Not. (In conscious parody of his style there, I hasten to add). And it just seems so false, and so out of keeping, like your uncle suddenly trying to breakdance at a wedding.
It's a shame, because it's nearly a good book, but it's too uneven, too conversational in style in places, and needs (oh what irony!) a really detailed technical review to fix the bits which are misleading or just wrong.
So, leaving aside my misconceptions, how does it achieve that goal? Well, on the one hand, it does a reasonable job of providing an overview of the other aspects of the SDLC like project management, architecture and testing, and different development methodologies. It goes into enough depth of most to give a decent introduction to the subject, mostly without drowning the reader new to those areas - it gives code examples of some areas (eg OOAD) where this makes some sense to do so and reflects on the presumed target audience's background as coders, and provides plenty of good references throughout. Actually, it's at its best in the chapters which centre around the design, development and, to some extent, testing of code.
So far, so good. Unfortunately, it is rather uneven in quality and focus, and my overriding feeling when I got to the end was that the author had taken his experience and generalised that out to be The Way Things Are Done. So software is developed in Software Development Organisations (no software development inside non-software companies?), every software development ends up with a detailed code inspection (really? even in Agile developments? even in really small teams?) and generally the content is a mix of well-described theory but with some real problems when it goes into detail.
For example, his first descripton of abstraction as "Abstraction means being lazy. You put off what you need to do by pushing it higher in the design hierarchy" - I can understand what he is trying to say here, and in context of the OOAD content later it would almost make sense, but appearing much earlier in the book, in the chapter on design principles it is very misleading.
Another example is his treatment of Use Cases, which were horribly badly explained, with supposed UCs that conflated multiple use-cases into a single item which would lead to a terrible design.
There are several other examples I could give, but my other bugbear is the tone of the writing. Most of the time it's comfortable and professional, but occasionally he drops into this over-conversational style as though he's suddenly realised the age of the target audience and wants to speak to them in their own language, and makes an excellent job of it. Not. (In conscious parody of his style there, I hasten to add). And it just seems so false, and so out of keeping, like your uncle suddenly trying to breakdance at a wedding.
It's a shame, because it's nearly a good book, but it's too uneven, too conversational in style in places, and needs (oh what irony!) a really detailed technical review to fix the bits which are misleading or just wrong.
Displaying 1 of 1 review