-
Notifications
You must be signed in to change notification settings - Fork 0
/
the_pragmatic_programmer.html
112 lines (103 loc) · 7.2 KB
/
the_pragmatic_programmer.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="generator" content="Pelican" />
<title>The Pragmatic Programmer [Highlights]</title>
<link rel="stylesheet" href="/theme/css/main.css" />
<meta name="description" content="Rather than construction, software is more like gardening— it is more organic than concrete. You plant many things in a garden according to an..." />
</head>
<body id="index" class="home">
<header id="banner" class="body">
<h1><a href="/">Marco Santoni</a></h1>
<nav><ul>
<li><a href="/pages/about.html">about</a></li>
<li><a href="/pages/bookshelf.html">bookshelf</a></li>
<li class="active"><a href="/category/posts.html">posts</a></li>
</ul></nav>
</header><!-- /#banner -->
<section id="content" class="body">
<article>
<header>
<h1 class="entry-title">
<a href="/the_pragmatic_programmer.html" rel="bookmark"
title="Permalink to The Pragmatic Programmer [Highlights]">The Pragmatic Programmer [Highlights]</a></h1>
</header>
<div class="entry-content">
<footer class="post-info">
<abbr class="published" title="2018-02-10T14:31:00+01:00">
Published: Sat 10 February 2018
</abbr>
<address class="vcard author">
By <a class="url fn" href="/author/marco-santoni.html">Marco Santoni</a>
</address>
<p>In <a href="/category/posts.html">posts</a>.</p>
</footer><!-- /.post-info --> <blockquote>
<p>Rather than construction, software is more like gardening— it is more organic than concrete. You plant many things in a garden according to an initial plan and conditions. Some thrive, others are destined to end up as compost. [...] You constantly monitor the health of the garden, and make adjustments (to the soil, the plants, the layout) as needed.</p>
</blockquote>
<p><em>The Pragmatic Programmer: from Journeyman to Master</em> by Andrew Hunt and David Thomas is a guide to best practices of software development. A software developer is like a woodcrafter. There are good practices that help him in achieving quality and efficiency in its work. I will summarize here some interesting hints that you can find in the book.</p>
<p>The book was originally published in 1999, so technologies and tools are quite outdated. However, the main principle remain surprisingly up to date.</p>
<p><img alt="The Pragmatic Programmer" src="/images/pragmatic_programmer.jpg"></p>
<h2>1. Don't Repeat Yourself</h2>
<blockquote>
<p>DRY— Don't Repeat Yourself The alternative is to have the same thing expressed in two or more places. If you change one, you have to remember to change the others [...]. It isn't a question of whether you'll remember: it's a question of <strong>when you'll forget</strong>.</p>
</blockquote>
<h2>2. Coding over GUIs</h2>
<blockquote>
<p>A benefit of GUIs is WYSIWYG— what you see is what you get. The disadvantage is WYSIAYG— what you see is <strong>all</strong> you get.</p>
</blockquote>
<h2>3. One Editor for All</h2>
<blockquote>
<p>We think it is better to know one editor very well, and use it for all editing tasks: code, documentation, memos, system administration, and so on. Without a single editor, you face a potential modern day Babel of confusion.</p>
</blockquote>
<h2>4. Always Source Control. Always.</h2>
<blockquote>
<p>Always. Even if you are a single-person team on a one-week project. Even if it's a "throw-away" prototype. Even if the stuff you're working on isn't source code. Make sure that everything is under source code control— documentation, phone number lists, memos to vendors, makefiles, build and release procedures, that little shell script that burns the CD master— everything.</p>
</blockquote>
<h2>5. Things can Happen</h2>
<blockquote>
<p>It goes THIS CAN NEVER HAPPEN... "This code won't be used 30 years from now, so two-digit dates are fine." "This application will never be used abroad, so why internationalize it?" "count can't be negative." "This printf can't fail.". Let's not practice this kind of self-deception, particularly when coding.</p>
</blockquote>
<h2>6. Become a User</h2>
<blockquote>
<p>There's a simple technique for getting inside your users' requirements that isn't used often enough: become a user. Are you writing a system for the help desk? Spend a couple of days monitoring the phones with an experienced support person. Are you automating a manual stock control system? Work in the warehouse for a week. As well as giving you insight into how the system will really be used, you'd be amazed at how the request "May I sit in for a week while you do your job?" helps build trust and establishes a basis for communication with your users. Just remember not to get in the way!</p>
</blockquote>
<h2>7. Web Docs over Files</h2>
<blockquote>
<p>Web-based distribution also avoids the typical two-inch-thick binder entitled Requirements Analysis that no one ever reads and that becomes outdated the instant ink hits paper. If it's on the Web, the programmers may even read it.</p>
</blockquote>
<h2>8. Quality, quality, quality.</h2>
<blockquote>
<p>Teams as a whole should not tolerate broken windows— those small imperfections that no one fixes. The team must take responsibility for the quality of the product, supporting developers who understand the no broken windows</p>
<p>Some team methodologies have a quality officer— someone to whom the team delegates the responsibility for the quality of the deliverable. This is clearly <strong>ridiculous</strong>: quality can come only from the individual contributions of all team members.</p>
</blockquote>
<h2>9. Marketing the Project</h2>
<blockquote>
<p>There is a simple marketing trick that helps teams communicate as one: generate a brand. When you start a project, come up with a name for it, ideally something off-the-wall.</p>
</blockquote>
<h2>10. Manual Ensures Errors</h2>
<blockquote>
<p>A great way to ensure both consistency and accuracy is to automate everything the team does.</p>
</blockquote>
<h2>Reference</h2>
<p>Hunt, Andrew; Thomas, David. The Pragmatic Programmer: From Journeyman to Master. Pearson Education. Kindle Edition.</p>
</div><!-- /.entry-content -->
</article>
</section>
<section id="extras" class="body">
<div class="social">
<h2>social</h2>
<ul>
<li><a href="https://linkedin.com/in/msantoni">linkedin</a></li>
<li><a href="https://twitter.com/mrsantoni">twitter</a></li>
</ul>
</div><!-- /.social -->
</section><!-- /#extras -->
<footer id="contentinfo" class="body">
<address id="about" class="vcard body">
Proudly powered by <a href="https://getpelican.com/">Pelican</a>, which takes great advantage of <a href="https://www.python.org/">Python</a>.
</address><!-- /#about -->
<p>The theme is by <a href="https://www.smashingmagazine.com/2009/08/designing-a-html-5-layout-from-scratch/">Smashing Magazine</a>, thanks!</p>
</footer><!-- /#contentinfo -->
</body>
</html>