- Leaders within a team who understand the centrality of the domain can put their software project back on course.
- Software developer is like a researche, both have the responsability to tackle the messiness of the real world through complicated domain that has never been formalized.
- There are systematic ways of thinking that developers can employ to search for insight and produce effective models.
## Effective Java, 2nd Edition | |
by Joshua Bloch | |
*I, [Michael Parker](http://omgitsmgp.com/), own this book and took these notes to further my own learning. If you enjoy these notes, please [purchase the book](http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp/0321356683)!* | |
### Chapter 2: Creating and Destroying Objects | |
#### Item 1: Consider static factories instead of constructors | |
* An instance-controlled class is one that uses static factories to strictly control what instances exist at any time. |
#/bin/sh | |
speed="0.7" | |
mkdir "speed-${speed}x" | |
for f in *.mp3 | |
do ffmpeg -i "$f" -filter:a "atempo=${speed}" "./speed-${speed}x/$f" | |
done |
To me, legacy code is simply code without tests. I’ve gotten some grief for this definition. What do tests have to do with whether code is bad? To me, the answer is straightforward, and it is a point that I elaborate throughout the book: Code without tests is bad code. It doesn’t matter how well written it is; it doesn’t matter how pretty or object-oriented or well-encapsulated it is. With tests, we can change the behavior of our code quickly and verifiably. Without them, we really don’t know if our code is getting better or worse.
Four Reasons to Change Software: For simplicity’s sake, let’s look at four primary reasons to change software.
Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.
- Follow standard conventions.
- Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
- Boy scout rule. Leave the campground cleaner than you found it.
- Always find root cause. Always look for the root cause of a problem.
http://martinfowler.com/books/refactoring.html
Five or six years ago I was working on an essay about refactoring CSS. I didn't do that, but I did find these notes while working on something new. Hope they're useful! —Dean
p7 "When you find you have to add a feature to a program, and the program's code is not structured in a convenient way to add the feature, first refactor the program to make it easy to add the feature, then add the feature."
p7
Uncle Bob blogou no Clean Coder sobre uns code reviews que ele fez do código (e das refatorações) de um cara chamado John MacIntyre.
Uncle Bob criticou a conclusão do cara de que refatoração não vale a pena para projetos reais: refatoração é uma maneira efetiva de evitar que o código apodreça e fique difícil de manter.
O que achei de mais interessante sobre o post do Uncle Bob é que ele pegou o código inicial do cara e foi fazendo pequenas refatorações, no estilo Baby Steps. No final, acabou melhorando drasticamente a estrutura do código e tornando-o muito mais extensível. O exemplo é bem pequeno mas, mesmo assim, houve uma melhora significativa.
O código inicial:
def recursive_fib(n): | |
if n <= 1: | |
return n | |
return recursive_fib(n - 2) + recursive_fib(n - 1) | |
def memoized_fib(n): | |
f = [0] * (n + 1) | |
f[0] = 0 | |
f[1] = 1 |
function cnpj(s) { | |
let cnpj = s.replace(/[^\d]+/g, '') | |
// Valida a quantidade de caracteres | |
if (cnpj.length !== 14) | |
return false | |
// Elimina inválidos com todos os caracteres iguais | |
if (/^(\d)\1+$/.test(cnpj)) | |
return false |