DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

Cover image for The pragmatic programmer book tips (Part 2)
Wassim Ben Jdida
Wassim Ben Jdida

Posted on

The pragmatic programmer book tips (Part 2)

#10 - It's Both What You Say and the Way You Say It

It's not just what you've got, but also how you package it. Having the best ideas, the finest code, or the most pragmatic thinking is ultimately sterile unless you can communicate with other people. A good idea is an orphan without effective communication.
Β 

#11 - DRYβ€”Don't Repeat Yourself

Every piece of knowledge (code, docs, ...) must have a single, unambiguous, authoritative representation within a system.
Β 

#12 - Make It Easy to Reuse

if you fail to reuse, you risk duplicating knowledge.
Β 

#13 - Eliminate Effects Between Unrelated Things

In a well-designed system, the database code will be orthogonal to the user interface: you can change the interface without affecting the database, and swap databases without changing the interface.
Β 

#14 - There Are No Final Decisions

Β 

#15 - Use Tracer Bullets to Find the Target

when you're building something that hasn't been built before. Like the gunners, you're trying to hit a target in the dark. Because your users have never seen a system like this before, their requirements may be vague. Because you may be using algorithms, techniques, languages, or libraries you aren't familiar with, you face a large number of unknowns. And because projects take time to complete, you can pretty much guarantee the environment you're working in will change before you're done..
we're looking for something that gets us from a requirement
to some aspect of the final system quickly, visibly, and repeatably.

It simply is not fully functional. However, once you have achieved an end-to-end connection among the components of your system, you can check how close to the target you are, adjusting if necessary. Once you're on target, adding functionality is easy.
Β 

#16 - Prototype to Learn

Prototypes are designed to answer just a few questions, so they are much cheaper and faster to develop than applications that go into production. You can prototype Architecture, New functionality in an existing system, Structure or contents of external data, Third-party tools or components, Performance issues, User interface design.
Β 

#17 - Program Close to the Problem domain

By coding at a higher level of abstraction, you are free to concentrate on solving domain problems, and can ignore petty implementation details.
you can invent a mini-language tailored to the application domain that expresses exactly what users want:

// this is my example:
if userA.balance >= transferAmount {
 tx.transfer(balance, toUserB)
} else {
 print "Fill your balance"
}
Enter fullscreen mode Exit fullscreen mode

This language need not be executable. Initially, it could be simply a way of capturing the user's requirements, a specification..
Β 

#18 - Estimate to Avoid Surprises

Quick! How long will it take to send War and Peace over a 56k modem line? How much disk space will you need for a million names and addresses? How long does a 1,000-byte block take to pass through a router? How many months will it take to deliver your project

#19 - Iterate the Schedule with the Code

So you complete the coding and testing of the initial functionality and mark this as the end of the first increment. Based on that experience, you can refine your initial guess on the
number of iterations and what can be included in each. The refinement gets better and better each time, and confidence in the schedule grows along with it

Top comments (0)

🌚 Friends don't let friends browse without dark mode.

Sorry, it's true.