学会做听话的人

敏捷开发貌似已经不是什么新话题了～ 个人单枪匹马就能建立一个帝国的英雄时代已经过去， 现在最流行的一句话是 together， we achieve。 这本书是其中很平凡的一本。 我手头上关于软件工程 软件过程啥的还有类似 agile software construction， 人月神话， 软件工程思想， 编程精粹 等等。 我觉得， 类似的书精读一两本就可以了， 择其善者落到实处。

就北美的信息产业来讲， 一个普遍的现象是 无论那公司在招聘广告中怎么强调他们要招的是most innovative， passionate blablabla的人 员工们适应以后都反映他们只是要招听话的人而已， 创新， 甚至编程的基本功并没被摆到像招聘广告中说的那么重要的位置上～ 这对于初出象牙塔的人感觉还蛮不适应的， 或者说， 会有一种 expectation-distortion based depression。 这本书偏重讲在一个团队里程序员该如何自处的～ 对我来说无异于雪中送炭， 虽然现在公司中老板讲的是规范的一套， 底下人做的是完全不规范的另一套， 小公司要效益没办法呀～

为什么专门为这本写个总结， 一是因为这个周末刚好看的就是这本， 然后我发现我英文阅读的功力貌似有所提高， 一天看了200页， 踏踏实实这么一个字一个字滴看下来哟 还是在周末一下刷豆瓣一下聊QQ的情况下^o^ 二是这本更注重实际运用～ 跟其他提建议的书不一样的地方在于， 作者意识到任何一条建议的采纳都需要有一个折中， 极端总是不好的～ 然后对每条建议都会有一个what it feels like， 还有一个keep your balance。 个人觉得这个keep your balance是帮助最大的一个部分。 在给出建议和论述为什么要这么做的部分， 这本书跟其他书没有太大区别， 如果读过其他 读完总结完就知道每条规则大概怎么指导实际的行为了， 我是说， 一些小的猫腻～ 跟其他提供项目实践的建议的书相比， 就是看完感觉没有那么虚， 感觉作者不是那么的 站着说话不腰疼。

好了 剩下就是对这些建议的总结， 分为负面+正面的行为心理表现～ 大家见仁见智吧～ 再次强调， 想要实践每一条之前， 先看一下那一条的keep your balance。

1. “The first and most important step in addressing a problem is to determine who caused it. Find that moron! Once you’ve established fault, then you can make sure the problem doesn’t happen again. Ever.”
Blame doesn’t fix bugs. Instead of pointing fingers, point to possible solutions. It’s the positive outcome that counts.

2. “You don’t need to really understand that piece of code; it seems to work OK as is. Oh, but it just needs one small tweak. Just add one to the result, and it works. Go ahead and put that in; it’s probably fine.”
Don’t fall for the quick hack. Invest the energy to keep code clean and out in the open.

3. “You have a lot invested in your design. You’ve put your heart and soul into it. You know it’s better than anyone else’s. Don’t even bother listening to their ideas; they’ll just confuse the issue.”
Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea is better.

4. “When you discover a problem in someone else’s code, just keep it to yourself. After all, you wouldn’t want to hurt their feelings or cause trouble. And if that someone else happens to be your boss, be extra careful, and just follow orders.”
Do what’s right. Be honest, and have the courage to communicate the truth. It may be difficult at times; that’s why it takes courage.

5. “Technology changes so fast it’s overwhelming. That’s just the nature of it. Stick to your old job with the language you know; you can’t possibly keep up.”
Keep up with changing technology. You don’t have to become an expert at everything, but stay aware of where the industry is headed, and plan your career and projects Accordingly.

6. “Don’t share what you know—keep it to yourself. It’s to your advantage to be the Smart One on the team. As long as you’re smart, you can forget about those other losers.”
Raise the bar for you and your team. Use brown-bag sessions to increase everyone’s knowledge and skills and help bring people together. Get the team excited about technologies or techniques that will benefit your project.

7.“That’s the way you’ve always done it, and with good reason. It usually works for you just fine. The ways you learned when you first started are clearly the best ways. Not much has changed since then, really.”
Learn the new; unlearn the old. When learning a new technology, unlearn any old habits that might hold you back. After all, there’s much more to a car than just a horseless carriage.

8. “Accept the explanation you’ve been given. If you’re told where the problem lies, that’s where you look. Don’t waste your time chasing ghosts.”
Keep asking Why. Don’t just accept what you’re told at face value. Keep questioning until you understand the root of the issue.

9. “We haven’t had a code review in a long time, so we’re going to review everything all this week. Also, it’s probably about time we made a release as well, so we picked three weeks from Tuesday for a next release.”
Tackle tasks before they bunch up. It’s easier to tackle common recurring tasks when you maintain steady, repeatable intervals between events.

10. “Developers are creative and intelligent and know the most about the application. Therefore, developers should be making all the critical decisions. Anytime the business people butt in, they just make a mess of things; they don’t understand logic the way we do.”
Let your customers decide. Developers, managers, or business analysts shouldn’t make business-critical decisions. Present details to business owners in a language they can understand, and let them make the decision.

11. “Design documents should be as detailed as possible so that any lowly coder can just type in the code. Specify the high-level details of how objects are related, as well as lower-level details such as the interaction between objects. Be sure to include information on the implementations of methods and notes on their parameters. Don’t forget all the fields of the class. Never deviate from the design, no matter what you discover while writing code.”
A good design is a map; let it evolve. Design points you in the right direction. It’s not the territory itself; it shouldn’t dictate the specific route. Don’t let the design (or the designer) hold you hostage.

12. “You are starting a new project, with a laundry list of new technology and application frameworks in front of you. This is all great new stuff, and you really do need to use all of it. Think how great it will look on your résumé and how high-tech your new application will be with that great new framework.”
Choose technology based on need. Determine your needs first, and then evaluate the use of technologies for those specific problems. Ask critical questions about the use of any technology, and answer them genuinely.

13. “We just found a showstopper that you need to fix right away. Stop what you’re doing, and go ahead and make the fix; don’t bother with the usual procedures. No need to tell anyone else about it—just get going. Hurry.”
Keep your project releasable at all times. Ensure that the project is always compilable, runnable, tested, and ready to deploy at a moment’s notice.

14. “Don’t waste time thinking about integrating your code until the very end of the development phase, or at least until development is well underway. After all, why bother integrating code unless it’s done? You’ll have plenty of time at the end of the project to integrate code.”
Integrate early, integrate often. Code integration is a major source of risk. To mitigate that risk, start integration early and continue to do it regularly.

15. “It’s OK to install your product manually, especially to QA. You don’t have to do it all that often, and they are pretty good about copying all the right files.” Deploy your application automatically from the start.
Use that deployment to install the application on arbitrary machines with different configurations to test dependencies. QA should test the deployment as well as your application.

16. “It’s not your fault; the problem lies with our customers—those pesky end users and clients. They always come up with so many changes, way past the deadline. They should just figure out what they want once and for all and then give us requirements so we can implement the system to their satisfaction. That’s how it ought to work.”
Develop in plain sight. Keep your application in sight (and in the customers’ mind) during development. Bring customers together and proactively seek their feedback using demos every week or two.

17. “We’ve got this beautiful project plan with all the tasks and deliverables scheduled for the next three years. When we release the product then, we’ll capture the market!”
Develop in increments. Release your product with minimal, yet usable, chunks of functionality. Within the development of each increment, use an iterative cycle of one to four weeks or so.

18. “We have to deliver a fixed bid for this project. We don’t have all the details yet but need to put a bid in. I need an estimate for the whole team by Monday, and we’ll have to deliver the whole project by the end of the year.”
Estimate based on real work. Let the team actually work on the current project, with the current client, to get realistic estimates. Give the client control over their features and Budget.

19. “You can’t justify the time and effort it takes to write unit tests. It will just delay the project. You’re a darn good programmer anyway—unit tests are just a waste of time, and we’re already in a crunch.”
Use automated unit tests. Good unit tests warn you about problems immediately. Don’t make any design or code changes without solid unit tests in place.

20. “Go ahead and complete all of your library code. There’s plenty of time later to see what people think of it. Just throw the code over the wall for now. I’m sure it’s fine.”
Use it before you build it. Use Test Driven Development as a design tool. It will lead you to a more pragmatic and simpler design.

21. “As long as the code works on your machine, that’s OK. Who cares if it works on some other platform? You don’t have one.”
Different makes a difference. Run unit tests on each supported platform and environment combination, using continuous integration tools. Actively find problems before they find you.

22. “All right, so your unit tests verify your code does what you think it should. Ship it. We’ll find out if it’s what the customers want soon enough.”
Create tests for core business logic. Have your customers verify these tests in isolation, and exercise them automatically as part of your general test runs.

23. “Please use your time sheets to report your progress. We’ll use these for project planning. Always fill in 40 hours each week, regardless of how much you really worked.”
Measure how much work is left. Don’t kid yourself—or your team—with irrelevant metrics. Measure the backlog of work to do.

24. “Users are always complaining. It’s not your fault; they’re just too stupid to read the stinkin’ manual. It’s not a bug; they just don’t understand. They should know better.”
Every complaint holds a truth. Find the truth, and fix the real problem.

25. “Code that works and is understandable is nice, but it’s more important to be clever. You’re paid for being smart; show us how good you are.”
Write code to be clear, not clever. Express your intentions clearly to the reader of the code. Unreadable code isn’t clever.

26. “Comments should help out when the code is too tangled to read. Explain exactly what the code is doing, line by line. Don’t worry about why; just tell us what on Earth it’s doing.”
Comment to communicate. Document code using wellchosen, meaningful names. Use comments to describe its purpose and constraints. Don’t use commenting as a substitute for good code.

27. “Performance, productivity, elegance, cost, and time to market are the most important, critical issues in software development. You have to maximize all of them.”
Actively evaluate trade-offs. Consider performance, convenience, productivity, cost, and time to market. If performance is adequate, then focus on improving the other factors. Don’t complicate the design for the sake of perceived
performance or elegance.

28. “Real programmers work for hours and hours straight, without a break, without even looking up. Don’t break your flow to stop and compile: just keep typing!”
Write code in short edit/build/test cycles. It’s better than coding for an extended period of time. You’ll create code that’s clearer, simpler, and easier to maintain.

29. “Software is complex business. Any fool can write simple, elegant software. You’ll get fame and recognition (not to mention job security) by writing the most sophisticated, complex programs possible.”
Develop the simplest solution that works. Incorporate patterns, principles, and technology only if you have a compelling reason to use them.

30. “You are about to write some new code, and the first decision you need to make is where to put it. It doesn’t really matter where it goes, so just go ahead and add it to the class that happens to be open in your IDE now. It’s easier to keep track of code when it’s all in one big class or component anyway.”
Keep classes focused and components small. Avoid the temptation to build large classes or components or miscellaneous catchall classes.

31. “Don’t trust other objects. After all, they were written by other people, or even by you last month when you weren’t as smart. Get the information you need from others, and then do your own calculations and make your own decisions. Don’t give up control to others!”
Tell, don’t ask. Don’t take on another object’s or component’s job. Tell it what to do, and stick to your own job.

32. “Deep inheritance hierarchies are great. If you need functionality from some other class, just inherit from it! And don’t worry if your new class breaks things; your callers can just change their code. It’s their problem, not yours.”
Extend systems by substituting code. Add and enhance features by substituting classes that honor the interface contract. Delegation is almost always preferable to inheritance.

33. “Do you often get that déjà vu feeling during development? Do you often get that déjà vu feeling during development? That’s OK. You figured it out once. You can figure it out again.”
Maintain a log of problems and their solutions. Part of fixing a problem is retaining details of the solution so you can find and apply it later.

34. “Compiler warnings are just for the overly cautious and pedantic. They’re just warnings after all. If they were serious, they’d be errors, and you couldn’t compile. So just ignore them, and let ’er rip.”
Treat warnings as errors. Checking in code with warnings is just as bad as checking in code with errors or code that fails its tests. No checked-in code should produce any warnings from the build tools.

35. “Stepping line by line through a massive code base is pretty scary. But the only way to debug a significant problem is to look at the entire system. All at once. After all, you don’t know where the problem may be, and that’s the only way to find it.”
Attack problems in isolation. Separate a problem area from its surroundings when working on it, especially in a large application.

36. “Protect your caller from weird exceptions. It’s your job to handle it. Wrap everything you call, and send your own exception up instead—or just swallow it.”
Handle or propagate all exceptions. Don’t suppress them, even temporarily. Write your code with the expectation that things will fail.

37. “Don’t scare the users, or even other programmers. Give them a nice, sanitized error message. Use something comforting like ‘User Error. Replace, and Continue.”’
Present useful error messages. Provide an easy way to find the details of errors. Present as much supporting detail as you can about a problem when it occurs, but don’t bury the user with it.

38. “You need to hold meetings—lots of them. In fact, we’re going to keep scheduling more meetings until we discover why no work is getting done.”
Use stand-up meetings. Stand-up meetings keep the team on the same page. Keep the meeting short, focused, and Intense.

39. “Fred, our expert architect, will deliver a design for you to code. He’s very experienced and very expensive, so don’t waste his time with silly questions or implementation problems.”
Good design evolves from active programmers. Real insight comes from active coding. Don’t use architects who don’t code—they can’t design without knowing the realities of your system.

40. “Don’t worry about that crippling bug; Joe will fix it when he gets back from vacation next week. Just work around it until then.”
Emphasize collective ownership of code. Rotate developers across different modules and tasks in different areas of the system.

41. “It took you a long time and a lot of hard work to get where you are. Keep it to yourself so you look better. Use your superior skills to intimidate your teammates.”
Be a mentor. There’s fun in sharing what you know—you gain as you give. You motivate others to achieve better results. You improve the overall competence of your team.

42. “You’re so smart; just provide neat solutions to others on the team. Don’t waste time trying to educate them.”
Give others a chance to solve problems. Point them in the right direction instead of handing them solutions. Everyone can learn something in the process.

43. “Check in all code as often as you can, especially when you leave for the day, whether it’s ready or not.”
Share code only when ready. Never check in code that’s not ready for others. Deliberately checking in code that doesn’t compile or pass its unit tests should be considered an act of criminal project negligence.

44. “Users make great testers. Don’t worry—if it’s wrong, they’ll tell us eventually.”
Review all code. Code reviews are invaluable in improving the quality of the code and keeping the error rate low. If done correctly, reviews can be practical and effective. Review code after each task, using different developers.

45. “The manager, your team, and the business owners are relying on you to get tasks done. If they want your status, they’ll ask you for it. Just keep your head down, and keep working.”
Keep others informed. Publish your status, your ideas and the neat things you’re looking at. Don’t wait for others to ask you the status of your work.