27,59 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Software legend Max Kanat-Alexander shows you how to succeed as a developer by embracing simplicity, with forty-three essays that will help you really understand the software you work with.
About This Book
- Read and enjoy the superlative writing and insights of the legendary Max Kanat-Alexander
- Learn and reflect with Max on how to bring simplicity to your software design principles
- Discover the secrets of rockstar programmers and how to also just suck less as a programmer
Who This Book Is For
Understanding Software is for every programmer, or anyone who works with programmers. If life is feeling more complex than it should be, and you need to touch base with some clear thinking again, this book is for you. If you need some inspiration and a reminder of how to approach your work as a programmer by embracing some simplicity in your work again, this book is for you.
If you're one of Max's followers already, this book is a collection of Max's thoughts selected and curated for you to enjoy and reflect on. If you're new to Max's work, and ready to connect with the power of simplicity again, this book is for you!
What You Will Learn
- See how to bring simplicity and success to your programming world
- Clues to complexity - and how to build excellent software
- Simplicity and software design
- Principles for programmers
- The secrets of rockstar programmers
- Max's views and interpretation of the Software industry
- Why Programmers suck and how to suck less as a programmer
- Software design in two sentences
- What is a bug? Go deep into debugging
In Detail
In Understanding Software, Max Kanat-Alexander, Technical Lead for Code Health at Google, shows you how to bring simplicity back to computer programming. Max explains to you why programmers suck, and how to suck less as a programmer. There's just too much complex stuff in the world. Complex stuff can't be used, and it breaks too easily. Complexity is stupid. Simplicity is smart.
Understanding Software covers many areas of programming, from how to write simple code to profound insights into programming, and then how to suck less at what you do! You'll discover the problems with software complexity, the root of its causes, and how to use simplicity to create great software. You'll examine debugging like you've never done before, and how to get a handle on being happy while working in teams.
Max brings a selection of carefully crafted essays, thoughts, and advice about working and succeeding in the software industry, from his legendary blog Code Simplicity. Max has crafted forty-three essays which have the power to help you avoid complexity and embrace simplicity, so you can be a happier and more successful developer.
Max's technical knowledge, insight, and kindness, has earned him code guru status, and his ideas will inspire you and help refresh your approach to the challenges of being a developer.
Style and approach
Understanding Software is a new selection of carefully chosen and crafted essays from Max Kanat-Alexander's legendary blog call Code Simplicity. Max's writing and thoughts are great to sit and read cover to cover, or if you prefer you can drop in and see what you discover new every single time!
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 258
Veröffentlichungsjahr: 2017
Ähnliche
Understanding Software
Understanding Software
Copyright © 2017 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: September 2017
Production reference: 1270917
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78862-881-5
www.packtpub.com
Credits
Author
Max Kanat-Alexander
Acquisition Editor
Dominic Shakeshaft
Content Development Editor
Dominic Shakeshaft
Editor
Amit Ramadas
Indexer
Pratik Shirodkar
Production Coordinator
Arvindkumar Gupta
Cover Work
Arvindkumar Gupta
About the Author
Legendary code guru Max Kanat-Alexander brings you his writings and thoughts so that your code and your life as a developer can be healthy, and embrace simplicity. Why make life hard when making software can be simple?
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www.packtpub.com/mapt
Get the most in-demand software skills with Mapt. Mapt gives you full access to all Packt books and video courses, as well as industry-leading tools to help you plan your personal development and advance your career.
Why subscribe?
Customer Feedback
Thanks for purchasing this Packt book. At Packt, quality is at the heart of our editorial process. To help us improve, please leave us an honest review.
If you'd like to join our team of regular reviewers, you can e-mail us at <[email protected]>. We award our regular reviewers with free eBooks and videos in exchange for their valuable feedback. Help us be relentless in improving our products!
Foreword
I started writing on www.codesimplicity.com in 2008 for one reason only – I wanted to make the world of software development a better place. I wasn't trying to be famous, or get contracting jobs, or push some ideology on people. My intention was purely to help people.
What I had observed was that there was a lot of opinion in the field of software engineering, but not a lot of facts or basic principles. Now, this might seem like a shocking statement to some people, because surely software development is a scientific field where we all know exactly what we're doing – we work with highly technical machines and we use a lot of complex systems to accomplish our jobs. There must be a science to it, right?
Well, the problem is that in order to be a science you must have laws and a system of organized information based on those laws. Usually, you also must demonstrate that your laws and your system actually work without exception in the physical universe. It's not sufficient to just have some information about technology. You must have basic principles.
There are many ways to derive these basic principles. The most popular and accepted way is through the scientific method. There are other ways, too. The whole subject of how you discover these things is covered by a study called "epistemology," which is a word that means "the study of how knowledge is known." For example, you know your name. How do you know that that is your name? How do you know that's true? If you wanted to understand how to build a house, what would you do to gain that knowledge? And so on.
I'm sort of over-simplifying it, and perhaps some philosophy professors will come after me and write bad reviews because I'm not really explaining epistemology or how I used it, but I hope that what I've written here is enough for the common reader to get that what I wanted was some method that would lead to the development of basic principles. Various methods of epistemology, including the scientific method, helped me discover these.
My first book, Code Simplicity, is a description of those basic principles of software development. But there's more to know than just those basics. True, you could derive everything there is to know about software design from those laws in Code Simplicity, but since I've already derived a lot of stuff from them, why not just share that with you now?
This book is a collection of my writings since Code Simplicity, as well as some additional content that I wrote before Code Simplicity but which didn't really fit in that book. Most of the content in this book is also on my website, but in this book it's been organized, curated, and edited for maximum readability. Also, you get to read it in book format, which is often easier to digest and understand.
There is one chapter in the book that is not on my website and never will be – the one called "Excellent Software." I actually wrote it years ago as part of the first draft of Code Simplicity, but could never bring myself to give it away for free.
The book doesn't have to be read in order. It's designed so that it reads nicely if you go from page to page and read each section in sequence, but you can also skip around and read any of the sections you want if you think some part will be more interesting than another.
To help both kinds of readers, I've split the book into a few parts. That way, people reading in order get a consistent flow, and people who want to skip around know what each part covers.
The first three parts of the book cover some foundational principles of being a programmer and then get into aspects of software complexity and simplicity. After that comes "Engineering in Teams," a whole new set of principles developed since Code Simplicity based on my experience successfully applying the principles of Code Simplicity across large engineering organizations.
Then comes a section where I write about the philosophy behind the principles of software design, "Understanding Software." This includes the article "The Philosophy of Testing," which is a more thorough coverage of the basic principles of testing than was found in my first book.
Then comes the section "Suck Less," based on one of my most popular blog articles of all time. It starts off explaining why "Suck Less" works as a philosophy for product management in software development, and then goes on to talk about how you can make your software suck less and specific ways to become a better programmer yourself.
Overall, the whole point of the book is to help you be a better software developer, and that is the only point. I would much rather live in a world where software is simple, well-designed, reliable, fast, and easy to make, wouldn't you? In this book and Code Simplicity, I've told you how to do it – all you have to do is apply the data that I've given you.
Best of luck.
Max Kanat-Alexander
August 2017
Part One. Principles for Programmers
Chapter 1. Before You Begin…
One of the major goals that I have with researching software design is the hope that we can take people who are "bad programmers" or mediocre programmers and, with some simple education and only a little experience, bring them into being good programmers or great programmers.
I want to know – what are the fundamental things you have to teach somebody to make them into a great programmer? What if somebody's been programming for years and hasn't gotten any better – how can you help them? What are they missing? So I've written quite a bit about that in this book, particularly in Part Seven -Suck Less.
However, before somebody can even start on the path of becoming a better software developer, one thing has to be true:
In order to become an excellent programmer, you must first want to become an excellent programmer. No amount of training will turn somebody who does not want to be excellent into an excellent programmer.
If you are a person who is passionate about software development – or even just somebody who likes being good at their job – it may be hard to understand the viewpoint of somebody who simply doesn't want to get any better. To fully grasp it, it can be helpful to imagine yourself trying to learn about some area that you personally have no desire to be great in.
For example, although I admire athletes, enjoy playing soccer, and sometimes enjoy watching sports in general, I've never had a desire to be a great athlete. There's no amount of reading or education that will ever turn me into a great athlete, because I simply don't want to be one. I wouldn't even read the books in the first place. If you forced me to take some classes or go to some seminar, it would leave my mind as soon as I took it in, because I would simply have no desire to know the data.
Even if I was playing sports every day for a living, I'd think, "Ah well, I don't have any passion for athletics, so this information simply isn't important to me. Some day I will be doing some other job, or some day I will retire and not have to care, and until then I'm just going to do this because they pay me and it's better than starving."
As hard as this can be to imagine, that is what happens in the minds of many "bad" programmers when you tell them how or why they should write better code. If they don't sincerely want to be the best programmers that they can be, it does not matter how much education you give them, how many times you correct them, or how many seminars they go to, they will not get better.
If You're Going To Do It Then Do it Well
So what do you do? To be fair, I may not be the best person to ask – if I'm going to do something, I feel that I should do my best to excel in it. Perhaps the best thing you can do is encourage people to follow that concept.
You could say to them something like: "If you're going to be doing it anyway, why not do it well? Wouldn't it at least be more enjoyable to be doing this if you were more skilled at it? What if some other people were impressed with your work, how would that feel? Would it be nice to go home at the end of the day and feel that you had done something well? Would your life be better than it is now, even if only a little? Would your life get worse?"
However you do it, the bottom line is that people must be interested in improving themselves before they can get better. How you bring them up to that level of interest doesn't really matter, as long as they get there before you waste a lot of time giving them an education that they're just going to throw away as soon as they hear it.
-Max
Chapter 2. The Engineer Attitude
The attitude that every engineer should have, in every field of engineering, is:
I can solve this problem the right way.
Whatever the problem is, there's always a right way to solve it. The right way can be known, and it can be implemented. The only valid reason ever to not implement something the right way is lack of resources. However, you should always consider that the right way does exist, you are able to solve the problem the right way, and that given enough resources, you would solve the problem the right way.
The "right way" usually means "the way that accounts for all reasonably possible future occurrences, even unknown and unimaginable occurrences."
A bridge that could stand up to any reasonably possible environmental condition or any reasonably possible amount of traffic without constant maintenance would be built the "right way."
Software code that maintained its simplicity while providing the flexibility needed for reasonably possible future enhancements would be designed the "right way."
There are lots of invalid reasons for not solving a problem the right way:
The solution here is to assign an experienced and trusted engineer who understands the basic laws of the subject you're working in to determine the right way by himself or herself, probably after carefully studying the existing arguments and collecting relevant information, following standard, valid engineering procedures.
I am too lazy/tired/hungry/discombobulated to do this the right way, right now. This happens to everybody from time to time. It's 1 in the morning, you've been working on the project for 15 hours straight, and you just need the damn thing to work, right now! Give it a rest, though, and come back later. The world isn't ending, and the problem will still be here and solvable later.Go to sleep, go eat something, take a walk – do whatever it takes to get into a mental space where you're willing to solve the problem the right way, and then come back. If you're in a state where you can't solve the problem the right way, then it's really time to take a break.
You're not being delinquent in your duties if you do so – you're actually correctly taking responsibility for the success of the project by saying "this needs to be done right, and the way to do it right, right now, is to take a break and come back later".
Mostly, it all just takes the constant and continual belief in yourself that you can solve the problem the right way.
-Max
Chapter 3. The Singular Secret of the Rockstar Programmer
Before all the laws of software, before the purpose of software, before the science of software design itself, there is a singular fact that determines the success or failure of a software developer:
The better you understand what you are doing, the better you will do it.
"Rockstar" programmers understand what they are doing far, far better than average or mediocre programmers. And that is it.
This fact makes the difference between the senior engineer who can seem to pick up new languages in a day and the junior developer who struggles for ten years just to get a paycheck, programming other people's designs and never improving enough to get a promotion. It differentiates the poor programmers from the good ones, the good programmers from the great ones, and the great ones from the "rockstar" programmers who have founded whole multi-billion dollar empires on their skill.
As you can see, it isn't anything complicated, and it isn't something that's hard to know. Nor is it something that you can only do if you're born with a special talent or a "magical ability to program well." There is nothing about the nature of the individual that determines whether or not they will become an excellent programmer or a poor one:
All you have to do in order to become an excellent programmer is fully understand what you are doing.
Some may say that they already understand everything. The test is whether or not they can apply it. Do they produce beautifully architected systems that are a joy to maintain? Do they plow through programming problems at a rate almost unimaginable to the average programmer? Do they explain everything clearly and in simple concepts when they are asked for help? Then they are an excellent programmer, and they understand things well.
However, far more commonly than believing that they "know it all", many programmers (including myself) often feel as though they are locked in an epic battle with an overwhelming sea of information. There is so much to know that one could literally spend the rest of his life studying and still come out with only 90% of all the data there is to know about computers.
The secret weapon in the epic battle, the Excalibur of computing knowledge, is understanding.
The better that you understand the most fundamental level of your field, the easier it will be to learn the next level. The better you understand that level, the easier the next one after that will be, and so on. Then once you've gone from the most fundamental simplicities to the highest complexities, you can start all over again and find amazingly that there is so much more to know at the very, very bottom.
It seems almost too simple to be true, but it is in fact the case. The path to becoming an excellent programmer is simply full and complete understanding, starting with a profound grasp of the basics and working up to a solid control of the most advanced data available.
I won't lie to you – it sometimes is a long path. But it is worthwhile. And at the end of it, you may find yourself suddenly the amazing senior engineer who everyone comes to for advice. You may be the incredible programmer who solves everything and is admired by all his peers. You might even come out a "rockstar" with millions of dollars and a fantastically successful product. Who knows?
I can't tell you what to do or what to become. I can only point out some information that I've found to be truthful and valuable. What you do with it is up to you.
-Max
Chapter 4. Software Design, in Two Sentences
It is possible to reduce the primary principles of software design into just two statements:
And that is pretty much it.
If all you knew about software design were those two principles, you could evolve every other general principle of software development.
-Max
Part Two. Software Complexity and its Causes
Chapter 5. Clues to Complexity
Here are clues that tell you that your code may be too complex:
-Max
Chapter 6. Ways To Create Complexity: Break Your API
An API is a sort of a promise…"You can always interact with our program this way, safely and exactly like we said." When you release a new version of your product that doesn't support the API from your old version, you're breaking that promise.
Above and beyond any vague philosophical or moral considerations about this, the technical problem here is that this creates complexity.
Where once users of your API only had to call a simple function, now they have to do a version check against your application and call one of two different functions depending on the result. They might have to pass their parameters a totally different way now, doubling the complexity of their code if they keep both the old way and the new way around. If you changed a lot of functions, they might even have to re-work their whole application just to fit with the way your new API works!
If you break your API several times, their code will just get more and more and more complicated. Their only other choice is to break their compatibility with old versions of your product. That can make life extremely difficult for users and system administrators trying to keep everything in sync. You can imagine how quickly this could spiral out of control if every piece of software on your system suddenly broke its API for interacting with every other piece of software.
For you, maintaining an old API can be painful, and getting rid of it can make life so much simpler. But it's not complexity for you that we're talking about particularly here, it's complexity for other programmers.
The best way to avoid this problem altogether is don't release bad APIs. Or, even better (from the user's perspective), create some system where you promise to always maintain the old APIs, but give access to more modern APIs in a different way. For example, you can always access old versions of the salesforce.com API merely by using a different URL to interact with the API. Every time you interact with the Salesforce API, you are in fact specifying exactly what version of the API you expect to be using. This approach is a lot easier in centralized applications (like salesforce.com) than in shipping applications, because shipping applications have to care about code size and other things. Maintaining old APIs is also very difficult if you only have a small team of developers, because that maintenance really takes a lot of time and attention.
In any case, releasing an unstable or poor API is going to either complicate your life (because you'll then have to maintain backwards compatibility forever) or the life of your API users (because they'll have to modify all of their applications to work with both the "good" and "bad" API versions).
If you choose to break your API and not provide backwards-compatibility, remember that some API users will never update their products to use your new API. Maybe they just don't have the time or resources to update their code. Maybe they are using a tool that interacts with your product, but the maintainer of the tool no longer provides updates. In any case, if the cost of fixing their code is greater than the value of upgrading to new versions of your product, they could choose to remain with an old version of your product forever.
That can have a lot of unforeseen consequences, too. First they keep around an old version of your product. Then they have to keep around old versions of certain system libraries so that your product keeps working. Then they can't upgrade their OS because the old version of your product doesn't work on the new OS. Then what do they do if some unpatched security flaw is exploited on their old OS, but they're still tied to your old product and so can't upgrade their OS? Or some security flaw in your old product is exploited? All of these situations are things that you have to take responsibility for when you choose to break your API.
And yet, having no API can lead to the same situation. People create crazy "hacks" to interact with your system, and then they can't upgrade because their hacks don't work on the new version. This is not as bad as breaking your API, because you never promised anything about the hacks. Nobody has the right to expect their hacks to keep working.
But still, if management orders them to integrate with your product, those clever programmers will find any possible way to make it work, even if it sticks them with one version of your product forever.
So definitely make an API if you have the development resources to do it. But put a lot of careful thought into your API design before implementing it. Try actually using it yourself. Survey your users carefully and find out exactly how they want to use your API. Generally, do everything in your power to make the API as stable as possible before it's ever released. It's not a matter of spending years and years on it, it's just a matter of taking some sensible steps to find out how the API should really work before it's ever released.
And once it's released, please, please, if you can help it, don't break the API.
-Max
Chapter 7. When Is Backwards-Compatibility Not Worth It?
This title might seem a bit like a contradiction to the previous chapter…and of course, you really shouldn't break your API, if you can help it. But sometimes, maintaining backwards compatibility for any area of your application can lead to a point of diminishing returns. This applies to everything about a program, not just its API.
