注重实效的程序员之快速参考指南


最近在看《程序员修炼之道——从小工到专家》,很有启发的一本书(虽然到现在为止我还没什么大型项目的工作经验,但就平时的一些问题总结来看,这本书也是极好的!),下面是该书最后的附录中给出的一个快速参考指南,值得作为tips牢记在心,加速升级,迎娶白富美-走上人生巅峰*^_^* :

1.关心你的技艺
Care About Your Craft

如果你不在乎能否漂亮的开发出软件,你又为何要耗费生命去开发软件呢?

2.思考!你的工作
Think! About Your Work

关掉自动驾驶仪,接管操作。不断地批评和评估你的工作。

3.提供各种选择,不要找蹩脚的借口
Provide Options, Don’t Make Lame Excuses

要提供各种选择,而不是找借口。不要说事情做不到;说明能够做什么。

4.不要容忍破窗户
Don’t Live with Broken Windows

当你看到糟糕的设计、错误的决策和糟糕的代码时,修正它们。

5.做变化的催化剂
Be a Catalyst for Change

你不能强迫人们改变。相反,要向他们展示未来可能会怎样,并帮助他们参与对未来的创造。

6.记住大图景
Remember the Big Picture

不要太过专注于细节,以至忘了查看你周围正在发生什么。

7.使质量成为需求问题
Make Quality a Requirements lssue

让你的用户参与确定项目真正的质量需求。

8.定期为你的知识资产投资
Invest Regularly in Your Knowledge Portfolio

让学习成为习惯。

9.批判地分析你读到的和听到的
Critically Analyze What You Read and Hear

不要被供应商、媒体炒作、或教条左右。要依照你自己的看法和你的项目的情况去对信息进行分析。

10.你说什么和你怎么说同样重要
It’s both What You Say and the Way You Say it

如果你不能有效地向他人传达你的了不起的想法,这些想法就毫无用处。

11.不要重复你自己
DRY – Don’t Repeat Yourself

系统中的每一项知识都必须具有单一、无歧义、权威的表示。

12.让复用变得容易
Make It Easy to Reuse

如果复用很容易,人们就会去复用。创造一个支持复用的环境。

13.消除无关事物之间的影响
Eliminate Effects Between Unrelated Things

设计自足、独立、并具有单一、良好定义的目的的组件。

14.不存在最终决策
There Are No Final Decisions

没有决策是浇铸在石头上的。相反,要把每项决策都视为是写在沙滩上的,并为变化做好计划。

15.用曳光弹找到目标
Use Tracer Bullets to Find the Target

曳光弹能通过试验各种事物并检查它们离目标有多远来让你追踪目标。

16.为了学习而制作原型
Prototype to Learn

原型制作是一种学习经验。其价值并不在于所产生的代码,而在于所学到的经验教训。

17.靠近问题领域编程
Program Close to the Problem domain

用你的用户的语言进行设计和编码。

18.估算,以避免发生意外
Estimate to Avoid Surprises
在着手之前先进行估算。你将提前发现潜在的问题。

19.通过代码对进度表进行迭代
Iterate the Schedule with the Code
用你在进行实现时获得的经验提炼项目的时间标度。

20.用纯文本保存知识
Keep Knowledge in Plain Text

   纯文本不会过时。它能够帮助你有效利用你的工作。并简化掉时和测试。

21.利用命令shell的力量
Use the Power of Command Shells

   当图形用户界面无能为力时使用shell。

22.用好一种编辑器
Use a Single Editor Well

   编辑器应该是你的手的延伸;确保你的编辑器是可配置、科扩展和可编程的。

23.总是使用源码控制
Always Use Source Code Control

   源码控制是你的工作的时间机器–你能够回到过去。

24.要修正问题,而不是发出指责
Fix the Problem, Not the Blame

   bug是你的过错还是别人的过错,并不是真的很有关系–它仍然是你的问题,它仍然需要修正。

25.调试时不要恐慌
Don’t Panic When Debuging

   做一次深呼吸,思考什么可能是bug的原因。

26.“Select”没有问题
“Select” Isn’t Broken

   在OS或编译器、甚或是第三方产品或库中很少发现bug。bug很可能在应用中。

27.不要假定,要证明
Don’t Assume It – Prove It

   在实际环境中–使用真正的数据和辩解条件–证明你的假定。

28.学习一种文本操纵语言
Learn a Text Manipulation Language

   你用每天的很大一部分时间处理文本,为什么不让计算机替你完成部分工作呢?

29.编写能编写代码的代码
Write Code That Writes Code

   代码生成器能提高你的生产率,并有助于避免重复。

30.你不可能写出完美的软件
You Can’t Write Perfect Software

   软件不可能完美。保护你的代码和用户,使它(他)们免于能够预见的错误。

31.通过合约进行设计
Design with Contracts

   使用合约建立文档,并检验代码所做的事情正好是它声明要做的。

32.早崩溃
Crash Early

   死程序造成的危害通常比有问题的程序要小得多。

33.用断言避免不可能发生的事情
Use Assertions to Prevent the Impossible

   断言验证你的各种假定。在一个不确定的世界里,用断言保护你的代码。

34.将异常用于异常的问题
Use Exceptinos for Exceptional Problems

   异常可能会遭受经典的意大利面条式代码的所有可读性和可维护性问题的折磨。将异常保留给异常的事物。

35.要有始有终
Finish What You Start

   只要可能,分配某资源的例程或对象也应该负责解除其分配。

36.使模块之间的耦合减至最少
Minimize Coupling Between Modules

   通过编写“羞怯的”代码并应用得墨忒耳法则来避免耦合。

37.要配置,不要集成
Configure, Don’t Integrate

   要将应用的各种技术选择实现为配置选项,而不是通过集成或工程方法实现。

38.将抽象放进代码,细节放进元数据
Put Abstractions in Code, Details in Metadata

   为一般情况编程,将细节放在被编译的代码库之外。

39.分析工作流,以改善并发性
Analyze Workflow to Imporve Concurrency

   利用你的用户的工作流中的并发性。

40.用服务进行设计
Design Using Services

   根据服务–独立的、在良好定义、一致的接口之后的兵法对象–进行设计。

41.总是为并发进行设计
Always Design for Concurrency
容许并发,你将会设计出更整洁、具有更少假定的接口。

42.使视图与模型分离
Separate Views from Models
要根据模型和视图设计你的应用,从而以低廉的代码获取灵活性。

43.用黑板协调工作流
Use Blackboards to Coordinate Workflow
用黑板协调完全不同的事实和因素,同时又使各参与方保持独立和隔离。

44.不要靠巧合编程
Don’t Program by Coincidence
只依靠可靠的事物。注意偶发的复杂性,不要把幸运的巧合与有目的的计划混为一谈。

45.估算你的算法的阶
Estimate the Order of Your Algorithms
在你编写代码之前,先大致估算事情需要多长时间。

46.测试你的估算
Test Your Estimates
对算法的数学分析并不会告诉你每一件事情。在你的代码的目标环境中测定它的速度。

47.早重构,常重构
Refactor Early, Refactor Often
就和你会在华园里除草、并重新布置一样,在需要时对代码进行重写、重做和重新架构。要铲除问题的根源。

48.为测试而设计
Design to Test
在你还没有编写代码时就开始思考测试问题。

49.测试你的软件,否则你的用户就得测试
Test Your Software, or Your Users Will
无情地测试。不要让你的用户为你查找bug。

50.不要使用你不理解的向导代码
Don’t Use Wizard Code You Don’t Understand
想到可以生成大量代码。在你把它们合并进你的项目之前,确保你理解全部这些代码。

51.不要搜集需求–挖掘它们
Don’t Gather Requirements – Dig for Them
需求很少存在于表面上。它们深深地埋藏在层层假定、误解和政治手段的下面。

52.与用户一同工作,以像用户一样思考
Work with a User to Think Like a User
要了解系统实际上将如何被使用,这是最好的方法。

53.抽象比细节活得更长久
Abstractions Live Longer than Details
“投资”于抽象,而不是实现。

54.使用项目词汇表
Use a Project Glossary
创建并维护项目中使用的专用术语和词汇的单一信息源。

55.不要在盒子外面思考–要找到盒子
Don’t Think Outside the Box – Find the Box
在遇到不可能解决的问题时,要确定真正的约束。问问你自己:“它必须以这种方式完成吗?它真的必须完成吗?”

56.等你准备好再开始
Start When You’re Ready
你的一生都在积累经验。不要忽视反复出现的疑惑。

57.对有些事情“做”胜于“描述”
Some Things Are Better Done than Described
不要掉进规范的螺旋

58.不要做形式方法的奴隶
Don’t Be a Slave to Formal Methods
如果你没有把某项技术放进你的开发时间和能力的语境中,不要盲目地采用它。

59.昂贵的工具不一定能制作出更好的设计
Costly Tools Don’t Produce Better Disigns
小心供应商的炒作,行业教条,以及价格标签的诱惑。要根据工具的价值判断它们。

60.围绕功能组织团队
Organize Teams Around Fucntionality
不要把设计师与编码员分开,也不要把测试员与数据建模员分开。按照你构建代码的方式构建团队。

61.不要使用手工流程
Don’t Use Manual Procedures
shell脚本或批文件会一次次地以同一顺序执行同样的指令。

62.早测试,常测试,自动测试。
Test Early. Test Often. Test Automatically
与呆在书架上的测试计划相比,每次构建试运行的测试要有效得多。

63.要到通过全部测试,编码才算完成。
Coding Ain’t Done ‘Til All the Tests Run
就是这样。

64.通过“蓄意破坏”测试你的测试。
Use Saboteurs to Test Your Testing
在单独的软件副本上故意引入bug,以检验测试能够抓住它们。

65.测试状态覆盖,而不是代码覆盖
Test State Coverage, Not Code Coverage
确定并测试重要的程序状态。只是测试代码行是不够的。

66.一个bug只抓一次
Find Bugs Once

   一旦测试员找到一个bug,这应该是测试员最后一次找到它。此后自动测试应该对其进行检查。

67.英语就是一种编程语言
English is Just a Programming Language

   像你编写代码一样编写文档:遵守DRY原则、使用元数据、MVC、自动生成、等等。

68.把文档建在里面,不要栓在外面
Build Documentation In, Don’t Bolt It On

   与代码分离的文档不太可能被修正和更新。

69.温和地超出用户的期望
Gently Exceed Your Users’ Expectations

   要理解你的用户的期望,然后给他们的东西要多那么一点。

70.在你的作品上签名
Sign Your Work

   过去时代的手艺人为能在他们作品上签名而自豪。你也应该如此。

检查清单
————————————————

71.要学习的语言
   厌倦了C、C++和JAVA?试试CLOS、Dylan、Eiffel、Objectve C、Prolog、Smailltalk或TOM。它们每一种都有不同的能力和不同的“风味”。用其中的一种或多种语言在家里开发一个小项目。

72.WISDOM离合诗
   What do you want them to learn?   你想让他们学到什么?
   What is their interest in what you’ve got to say?   他们对你讲的什么感兴趣?
   How sophisticated are they?   他们有多富有经验?
   How much detail do they want?   他们想要多少细节?
   Whom do you want to own the information?   你想要让谁拥有这些信息?
   How can you motivate them to listen to you?   你如何促使他们听你说话?

73.怎样维持正交性
     ·设计独立、良好定义的组件。
     ·使你的代码保持解耦。
     ·避免使用全局数据。
     ·重构相似的函数。

74.应制作原型的事物
   ·架构
   ·已有系统中的新功能
   ·外部数据的结构或内容
   ·第三方工具或组件
   ·性能问题
   ·用户界面设计

75.架构问题
   ·责任是否得到了良好定义?
   ·写作是否得到了良好定义?
   ·耦合是否得以最小化?
   ·你能否确定潜在的重复?
   ·接口定义和各项约束是否可接受?
   ·模块能否在需要时访问所需数据?

76.调试检查清单
   ·正在报告的问题是底层bug的直接结果,还是只是症状?
   ·bug真的在编译器里?在OS里?或者是在你的代码里?
   ·如果你向同事详细解释这个问题,你会说什么?
   ·如果可疑代码通过了单元测试,测试是否足够完整?如果你用该数据运行单元测试,会发生什么?
   ·造成这个bug的条件是否存在于系统中的其它任何地方?

77.函数的得墨忒耳法则
   某个对象的方法应该只调用属于以下情况的方法:
     ·它自身
     ·传入的任何参数
     ·它创建的对象
     ·组件对象

78.怎样深思熟虑地编程
     ·总是意识到你在做什么。
     ·不要盲目地编程。
     ·按照计划行事。
     ·依靠可靠的事物。
     ·为你的假定建立文档。
     ·不要只是测试你的代码,还要测试你的假定。
     ·维尼的工作划分优先级。
     ·不要做历史的奴隶。

79.何时进行重构
     ·你发现了对DRY原则的违反。
     ·你发现事物可以更为正交。
     ·你的知识扩展了。
     ·需求演变了。
     ·你需要改善性能。

80.劈开戈尔迪斯结
   在解决不可能解决的问题时,问问你自己:
     ·有更容易的方法吗?
     ·我是在解决正确的问题吗?
     ·这件事情为什么是一个问题?
     ·是什么使它如此难以解决?
     ·它必须以这种方式完成吗?
     ·它真的必须完成吗?

81.测试的各个方面
·单元测试
     ·集成测试
     ·炎症和校验
     ·资源耗尽、错误及恢复
     ·性能测试
     ·可用性测试
     ·对测试自身进行测试

参考链接:注重实效的程序员之快速参考指南 – The Pragmatic Programmer Quick Reference Guide


英文版如下:
The Pragmatic Programmer Quick Reference Guide

This page summarizes the tips and checklists found in The Pragmatic Programmer.

For more information about The Pragmatic Programmers LLC, source code for the examples, up-to-date pointers to Web resources, and an online bibiography, visit us at www.pragmaticprogrammer.com

  1. Care About Your Craft
    Why spend your life developing software unless you care about doing it well?
  2. Think! About Your Work
    Turn off the autopilot and take control. Constantly critique and appraise your work.
  3. Provide Options, Don’t Make Lame Excuses
    Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
  4. Don’t Live with Broken Windows
    Fix bad designs, wrong decisions, and poor code when you see them.
  5. Be a Catalyst for Change
    You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
  6. Remember the Big Picture
    Don’t get so engrossed in the details that you forget to check what’s happening around you.
  7. Make Quality a Requirements Issue
    Involve your users in determining the project’s real quality requirements.
  8. Invest Regularly in Your Knowledge Portfolio
    Make learning a habit.
  9. Critically Analyze What You Read and Hear
    Don’t be swayed by vendors, media hype, or dogma. Analyze information in terms of you and your project.
  10. It’s Both What You Say and the Way You Say It
    There’s no point in having great ideas if you don’t communicate them effectively.
  11. DRY–Don’t Repeat Yourself
    Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
  12. Make It Easy to Reuse
    If it’s easy to reuse, people will. Create an environment that supports reuse.
  13. Eliminate Effects Between Unrelated Things
    Design components that are self-contained. independent, and have a single, well-defined purpose.
  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.
  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.
  16. Prototype to Learn
    Prototyping is a learning experience. Its value lies not in the code you produce, but in the lessons you learn.
  17. Program Close to the Problem Domain
    Design and code in your user’s language.
  18. Estimate to Avoid Surprises
    Estimate before you start. You’ll spot potential problems up front.
  19. Iterate the Schedule with the Code
    Use experience you gain as you implement to refine the project time scales.
  20. Keep Knowledge in Plain Text
    Plain text won’t become obsolete. It helps leverage your work and simplifies debugging and testing.
  21. Use the Power of Command Shells
    Use the shell when graphical user interfaces don’t cut it.
  22. Use a Single Editor Well
    The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.
  23. Always Use Source Code Control
    Source code control is a time machine for your work—you can go back.
  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.
  25. Don’t Panic When Debugging
    Take a deep breath and THINK! about what could be causing the bug.
  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.
  27. Don’t Assume It—Prove It
    Prove your assumptions in the actual environment– with real data and boundary conditions.
  28. Learn a Text Manipulation Language.
    You spend a large part of each day working with text. Why not have the computer do some of it for you?
  29. Write Code That Writes Code
    Code generators increase your productivity and help avoid duplication.
  30. You Can’t Write Perfect Software
    Software can’t be perfect. Protect your code and users from the inevitable errors.
  31. Design with Contracts
    Use contracts to document and verify that code does no more and no less than it claims to do.
  32. Crash Early
    A dead program normally does a lot less damage than a crippled one.
  33. Use Assertions to Prevent the Impossible
    Assertions validate your assumptions. Use them to protect your code from an uncertain world.
  34. Use Exceptions for Exceptional Problems
    Exceptions can suffer from all the readability and maintainability problems of classic spaghetti code. Reserve exceptions for exceptional things.
  35. Finish What You Start
    Where possible, the routine or object that allocates a resource should be responsible for deallocating it.
  36. Minimize Coupling Between Modules
    Avoid coupling by writing “shy” code and applying the Law of Demeter.
  37. Configure, Don’t Integrate
    Implement technology choices for an application as configuration options, not through integration or engineering.
  38. Put Abstractions in Code, Details in Metadata
    Program for the general case, and put the specifics outside the compiled code base.
  39. Analyze Workflow to Improve Concurrency
    Exploit concurrency in your user’s workflow.
  40. Design Using Services
    Design in terms of services—independent, concurrent objects behind well-defined, consistent interfaces.
  41. Always Design for Concurrency
    Allow for concurrency, and you’ll design cleaner interfaces with fewer assumptions.
  42. Separate Views from Models
    Gain flexibility at low cost by designing your application in terms of models and views.
  43. Use Blackboards to Coordinate Workflow
    Use blackboards to coordinate disparate facts and agents, while maintaining independence and isolation among participants.
  44. Don’t Program by Coincidence
    Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
  45. Estimate the Order of Your Algorithms
    Get a feel for how long things are likely to take before you write code.
  46. Test Your Estimates
    Mathematical analysis of algorithms doesn’t tell you everything. Try timing your code in its target environment.
  47. Refactor Early, Refactor Often
    Just as you might weed and rearrange a garden, rewrite, rework, and re-architect code when it needs it. Fix the root of the problem.
  48. Design to Test
    Start thinking about testing before you write a line of code.
  49. Test Your Software, or Your Users Will
    Test ruthlessly. Don’t make your users find bugs for you.
  50. Don’t Use Wizard Code You Don’t Understand
    Wizards can generate reams of code. Make sure you understand all of it before you incorporate it into your project.
  51. Don’t Gather Requirements–Dig for Them
    Requirements rarely lie on the surface. They’re buried deep beneath layers of assumptions, misconceptions, and politics.
  52. Workwith a User to Think Like a User
    It’s the best way to gain insight into how the system will really be used.
  53. Abstractions Live Longer than Details
    Invest in the abstraction, not the implementation. Abstractions can survive the barrage of changes from different implementations and new technologies.
  54. Use a Project Glossary
    Create and maintain a single source of all the specific terms and vocabulary for a project.
  55. Don’t Think Outside the Box–Find the Box
    When faced with an impossible problem, identify the real constraints. Ask yourself: “Does it have to be done this way? Does it have to be done at all?”
  56. Start When You’re Ready.
    You’ve been building experience all your life. Don’t ignore niggling doubts.
  57. Some Things Are Better Done than Described
    Don’t fall into the specification spiral—at some point you need to start coding.
  58. Don’t Be a Slave to Formal Methods.
    Don’t blindly adopt any technique without putting it into the context of your development practices and capabilities.
  59. Costly Tools Don’t Produce Better Designs
    Beware of vendor hype, industry dogma, and the aura of the price tag. Judge tools on their merits.
  60. Organize Teams Around Functionality
    Don’t separate designers from coders, testers from data modelers. Build teams the way you build code.
  61. Don’t Use Manual Procedures
    A shell script or batch file will execute the same instructions, in the same order, time after time.
  62. Test Early. Test Often. Test Automatically
    Tests that run with every build are much more effective than test plans that sit on a shelf.
  63. Coding Ain’t Done ‘Til All the Tests Run
    ‘Nuff said.
  64. Use Saboteurs to Test Your Testing
    Introduce bugs on purpose in a separate copy of the source to verify that testing will catch them.
  65. Test State Coverage, Not Code Coverage
    Identify and test significant program states. Just testing lines of code isn’t enough.
  66. Find Bugs Once
    Once a human tester finds a bug, it should be the last time a human tester finds that bug. Automatic tests should check for it from then on.
  67. English is Just a Programming Language
    Write documents as you would write code: honor the DRY principle, use metadata, MVC, automatic generation, and so on.
  68. Build Documentation In, Don’t Bolt It On
    Documentation created separately from code is less likely to be correct and up to date.
  69. Gently Exceed Your Users’ Expectations
    Come to understand your users’ expectations, then deliver just that little bit more.
  70. Sign Your Work
    Craftsmen of an earlier age were proud to sign their work. You should be, too.

Languages To Learn

Tired of C, C++, and Java? Try CLOS, Dylan, Eiffel, Objective C, Prolog, Smalltalk, or TOM. Each of these languages has different capabilities and a different “flavor.” Try a small project at home using one or more of them.

The WISDOM Acrostic

What do you want them to learn?
What is their interest in what you’ve got to say?
How sophisticated are they?
How much detail do they want?
Whom do you want to own the information?
How can you motivate them to listen to you?

How to Maintain Orthogonality

  • Design independent, well-defined components.
  • Keep your code decoupled.
  • Avoid global data.
  • Refactor similar functions.

Things to prototype

  • Architecture
  • New functionality in an existing system
  • Structure or contents of external data
  • Third-party tools or components
  • Performance issues
  • User interface design

Architectural Questions

  • Are responsibilities well defined?
  • Are the collaborations well defined?
  • Is coupling minimized?
  • Can you identify potential duplication?
  • Are interface definitions and constraints acceptable?
  • Can modules access needed data—when needed?

Debugging Checklist

  • Is the problem being reported a direct result of the underlying bug, or merely a symptom?
  • Is the bug really in the compiler? Is it in the OS? Or is it in your code?
  • If you explained this problem in detail to a coworker, what would you say?
  • If the suspect code passes its unit tests, are the tests complete enough? What happens if you run the unit test with this data?
  • Do the conditions that caused this bug exist anywhere else in the system?

Law of Demeter for Functions

An object’s method should call only methods belonging to:

  • Itself
  • Any parameters passed in
  • Objects it creates
  • Component objects

How to Program Deliberately

  • Stay aware of what you’re doing.
  • Don’t code blindfolded.
  • Proceed from a plan.
  • Rely only on reliable things.
  • Document your assumptions.
  • Test assumptions as well as code.
  • Prioritize your effort.
  • Don’t be a slave to history.

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.

Cutting the Gordian Knot

When solving impossible problems, ask yourself:

  • Is there an easier way?
  • Am I solving the right problem?
  • Why is this a problem?
  • What makes it hard?
  • Do I have to do it this way?
  • Does it have to be done at all?

Aspects of Testing

  • Unit testing
  • Integration testing
  • Validation and verification
  • Resource exhaustion, errors, and recovery
  • Performance testing
  • Usability testing
  • Testing the tests themselves

Checklists from The Pragmatic Programmer, by Andrew Hunt and David Thomas.

 

一些额外的链接:

 

,

《“注重实效的程序员之快速参考指南”》 有 25 条评论

  1. 聊聊clean code
    http://tech.meituan.com/clean-code.html
    `
    代码整洁的大前提
      代码大部分时候是用来维护的,而不是用来实现功能的
      优秀的代码大部分是可以自描述的,好于文档和注释
      设计模式只是手段,代码清晰才是目的
    代码整洁的常见手段
      code review
      勤于重构
      静态检查
      多读开源代码和身边优秀同学的代码
    代码整洁的常见技巧
      通用技巧
      面向对象设计技巧
      代码复用技巧
    `

  2. 有前途的程序员的16个习惯,你拥有几个?
    http://www.techug.com/post/good-programmer-good-habit.html
    `
    慎于说Yes
    敢于说No
    构建自己的知识体系
    培养大局观
    代码规范
    代码审查
    一个时间段内只专注于一种类型的语言
    通过注释来写逻辑
    良好的时间管理
    深入理解客户需求
    在编程之前准备好全套算法
    理解并帮助定义验收标准
    绞尽脑汁还是“NO”
    编程之前准备好全套算法
    理解and帮助定义验收标准
    主动一点点
    `

  3. 如何建设高可用系统(High Availability)
    http://mp.weixin.qq.com/s/kQl2hKETOSNA9x5yCSrxKQ
    `
    减少单点
    减少依赖
    限制循环
    控制流量
    精准监控
    无状态
    容量规划
    功能开关
    设置超时
    重试策略
    隔离 – 应用隔离,模块隔离,机房隔离和线程池隔离。
    异步调用
    热点缓存
    缓存容灾
    分级缓存
    系统分级
    服务降级
    流量蓄洪
    服务权重
    依赖简化
    弹性扩容
    灰度和回滚
    减少远程调用
    熔断机制
    运行时加载模块
    代码扫描
    自动备份
    线上压测
    `

  4. 重构-靠谱程序员的必备技能
    http://www.jianshu.com/p/ffd89d5df276
    `
    为什么要重构?
    为了让软件始终可以维护,保证开发效率。

    什么是重构?
    一种以可控的方式整理代码的技术,在不改变软件可观察行为的前提下改善其内部结构。

    什么时候开始?
    事不过三,添加功能,修复 Bug,代码评审时。

    什么时候停止?
    重构到符合简单设计四条原则的 Clean Code。

    前提条件
    测试保护,版本控制。

    重构的过程
    运行测试,识别味道(常见的 22 种),采用手法(66 个),运行测试,提交代码。

    重构与设计的关系
    有了重构技术,我们不用在前期做非常详细的设计,做适当的设计,然后通过重构让设计浮现出来。不用在乎软件是否符合模式,只要符合原则即可。

    大型遗留系统的重构
    在经常需要修改的烂代码上做重构才有最大收益。
    `

  5. 技术人如何修炼内功(高级篇)
    https://mp.weixin.qq.com/s/cUMyqTNfoh3YtKfqXNhiEQ
    `
    计算机基础知识的修炼
    最重要的两个方向就是操作系统和网络、算法和数据结构。

    互联网技术的修炼
    一共有3个大的方向:线上高并发服务方向、大数据方向、专家方向。

    做事的内功
    目标、原则、方法、结果
    慎用我以为
    高效沟通
    解决有效的问题
    任务分配

    做人的内功
    别人对你的印象其实离不开两个因素,靠谱和有脑子。靠谱就是要让人对你产生信任感,有脑子就是灵活、不做作、做事有条理。
    其次就是胆大、心细、乐观,做人一定要敢于去尝试,也要乐观,所谓福祸相依,无论发生什么事都要乐观,一个事情过去了1天、一个月、一年,回头再去看事情的重要程度和后果是不一样的,有可能从坏变好,也有可能从好变坏。
    `

  6. 系统重构的10点经验总结
    https://mp.weixin.qq.com/s/XuPCQn9IfyO46ivH1_Fyuw
    `
    1、重构确定并且聚焦目标
    2、重构要有可量化的指标
    3、重构要有更好的质量
    4、重构之前要和业务方沟通
    5、重构应该用迭代的方式
    6、重构要清晰了解旧系统
    7、重构要提前规划系统切换方案
    8、重构高度重视系统数据
    9、重构要采用成熟的技术选型
    10、重构更加关注重视团队成员
    `

  7. 技术选型:效率至上与实用至上
    http://www.zhuangbiaowei.com/blog/?p=606
    `
    效率考虑
    技术复杂度(复用性):学习并掌握一组技术栈,需要了解多复杂的技术;相应的,当我们掌握了这门技术,他可以在多少地方复用?
    技术友好度(优雅性):在开发的过程中,会不会有各种莫名其妙的陷阱,会不会让我纠缠于各种莫名其妙的细节?

    实用考虑
    业务复杂度(组织性):随着业务的复杂,我们的代码会不会最终无法驾驭?无法维护?无人能懂?
    性能提升度(潜力):随着业务的增长,压力的提升,我们会不会最终被迫放弃现有的技术架构,重头开始?

    也许,我们可以凭借这四个维度,做一个雷达图,以便更加准确的评价候选的技术,这里就先靠文字描述粗略的表达一下吧。
    `

  8. 如何让代码好维护
    https://mp.weixin.qq.com/s/_T2u9wSaQw_8ddqxZAwMlg
    `
    不要重复发明轮子,将公共的方法和函数抽出来做成公共库。投入一定的时间寻找和比较开源的解决方案,而非什么事情都自己实现。

    投入跟多的时间在接口的定义和审核上,一个差接口的危害性超过 500 行烂代码。

    请部门里更有经验的工程师帮助新人修改代码,相互工程师之间,相互抽查代码,这件事的好处不言而喻。虽然投入更多的时间,但是从整体效率的角度来讲,提高代码的可维护性就节省了大量的修改,重构代码的时间,可谓磨刀不误砍柴工。

    要求工程师对自己的代码写单元测试。这就使得程序员有机会从使用者的角度审视和检测自己的代码,这样不但能提高代码的易用性和正确性,而且在代码发生改变的时候,程序员可以确保不会破坏引用此段代码的其他模块或项目。

    从个人角度看,提高代码维护性,最直接的方式就是从好的代码Github上的代码库中学习,多看多总结。

    最后一点,也是我一直要求团队的一点,团队中的每个人都要有大局观意识,埋头苦干的前提是要了解全局,每位工程师都应该知道自己的东西在整个项目构架中的位置和他工作的意义。
    `

  9. [每周一书] 敏捷之道《高效程序员的45个习惯》
    https://bookfere.com/post/634.html
    `
    所有学习上的成功,都只靠两件事:策略和坚持,而坚持本身就应该是最重要的策略之一。

    敏捷开发就是在一个高度协作的环境中,不断地使用反馈进行自我调整和完善。
    先难后易。我们首先要解决困难的问题,把简单的问题留到最后。
    不管路走了多远,错了就要重新返回。
    能容纳自己并不接受的想法,表明你的头脑足够有学识。
    一种把以人为本、团队合作、快速响应变化和可工作的软件作为宗旨的开发方法。
    最高优先级应该是解决问题。
    只关注真正重要的事情,少关注那些占用大量时间而无甚裨益的不重要的事情。
    不停地问为什么。不能只满足于别人告诉你的表面现象。要不停地提问直到你明白问题的根源。
    严格的需求—设计—代码—测试开发流程源于理想化的瀑布式开发方法,它导致在前面进行了过度的设计。这样在项目的生命周期中,更新和维护这些详细的设计文档变成了主要工作,需要时间和资源方面的巨大投资,却只有很少的回报。我们本可以做得更好。
    敏捷的一个主要特点就是持续开发,而不是三天打鱼两天晒网似地工作。
    `

  10. 迪米特法则与重构
    http://zhangyi.xyz/demeter-law-and-refactoring/
    http://www.ccs.neu.edu/research/demeter/demeter-method/LawOfDemeter/paper-boy/demeter.pdf
    `
    在面向对象设计的世界里,有一个寻常却又常常为人所忽略的原则——“迪米特(Law of Demeter)”法则。这个原则认为,任何一个对象或者方法,它应该只能调用下列对象:
    · 该对象本身
    · 作为参数传进来的对象(也可以是该对象的字段)
    · 在方法内创建的对象

    这个原则用以指导正确的对象协作,分清楚哪些对象应该产生协作,哪些对象则对于该对象而言,又应该是无知的。
    `

  11. 左耳朵耗子推荐:每个程序员都该知道的事
    http://www.infoq.com/cn/articles/programer-knowledge
    `
    在每个月月中,我会推荐一些有价值的内容,供你参考。这个月,我将为你推荐五篇阅读文章,这五篇文章我觉得都是比较不错的经验总结,是我们每一个技术人员都需要知道的东西。它们分别是:
    · Stack Overflow 上开出来的一个经典书书单;
    · 美国某大学教授给计算机专业学生的一些建议,其中有很多的资源;
    · LinkedIn 的高效代码复查实践,很不错的方法,值得你一读;
    · 一份关于程序语言和 bug 数相关的有趣的报告,可以让你对各种语言所有了解;
    · 最后是一本 C++ 性能优化的非常有价值的电子书。
    `
    https://stackoverflow.com/questions/1711/what-is-the-single-most-influential-book-every-programmer-should-read
    http://matt.might.net/articles/what-cs-majors-should-know/
    https://thenewstack.io/linkedin-code-review/
    https://cacm.acm.org/magazines/2017/10/221326-a-large-scale-study-of-programming-languages-and-code-quality-in-github/
    http://agner.org/optimize/optimizing_cpp.pdf

  12. 浅谈容量测试与容量规划
    https://www.cnblogs.com/imyalost/p/9630846.html
    `
    一、什么是容量?如何理解?
    二、如何统计容量指标?
    1、统计维度
    2、统计方法
    3、注意事项
    三、容量测试
    1、测试思路
    2、约束/停止条件
    3、选择合适的容量指标
    四、容量规划
    1、为什么需要容量规划?
    2、容量规划四步走
    3、扩容手段
    `

    阿里巴巴的全链路压测
    https://my.oschina.net/cctester/blog/994727

  13. 程序员的六边形会是哪六个维度?
    https://www.v2ex.com/t/885153
    `
    Question:

    参考兵乓球运动选手的六边形:
    * 力量
    * 经验
    * 速度
    * 技术
    * 防守
    * 发球
    ====

    其他不清楚 但有一项肯定是摸鱼
    ==

    – 力量,和 PM battle 的能力
    – 经验,项目经验,业务知识积累
    – 速度,写代码的速度也很重要
    – 技术,代码要优雅,可扩展,可测试,可维护
    – 防守,甩锅踢皮球也是很重要的,不然你就是背锅的那个
    – 发球,从零开始一个项目时选型的能力,或者说架构吧
    ==

    摸鱼
    划水
    带薪蹲坑

    甩锅
    跑路
    ==

    智商
    情商
    运气
    专注
    野心
    韧性
    ==

    – Technology: knowledge of the tech stack and tools
    – System: level of ownership of the system(s)
    – People: relationship with the team(s)
    – Process: level of engagement with the development process
    – Influence: scope of influence of the position
    ==

    产品洞察,技术前瞻,团队协作,强健体魄,抗压能力,甩锅跑路
    `
    https://github.com/jorgef/engineeringladders

回复 a-z 取消回复

您的电子邮箱地址不会被公开。 必填项已用*标注