Refactoring is more than a technical task. Refactor has business value because its main purpose is to ensure that business language and knowledge are reflected into the code.
Source: Refactor is about knowledge and meaning
Wonderful post by Fran Iglesias at dev.to.
But every ten-line bit of repeated code has nine two-line bits and eight three-line bits. There's probably something there to extract. Start there, with smaller abstractions. Start refactoring at the bottom!
I like Eric Normand’s idea: when in doubt, refactor few lines of code rather than more lines. Extract 2 or 3 lines and give them a name (method or function). I am aware he usually uses Clojure where you often see short functions. But it applies to other programming languages as well.
There is a nice article that compares several git workflows:
I admit I don’t use git on a daily basis. Therefore I value they show the git commands.
At work we use trunk based development.
Here are concepts that are frequently asked about in web development interviews.
In other words 10 import Javascript concepts you need to know not only for interviews but for every day coding (unless you just copying code from the internet).
Tuning SQL isn’t always easy, and it takes a lot of practice to recognise how any given query can be optimised. One of the most important slides of my SQL training is the one summarising "how to be fast"
Lukas Eder from JOOQL posts some code to benchmark SQL statement. Comes in flavours of PostgreSQL, Oracle and SQL-Server. Handy.
Choosing the correct log level shouldn't be a chore
Dan Lebrero has a nice idea: change vague error logging methods like “debug”, “warn”, “error” into something meaningful, i.e. what will be the effect off invoking them: “toInvestigateTomorrow” and “wakeMeInTheMiddleOfTheNight”. 🙂
Brian Goetz, Java Language Architect at Oracle, gave an interesting presentation “From Concurrent to Parallel” (available on InfoQ) on the subject back in 2009. Here are the most important points of his talk.
Java 8 introduces the Stream library (which was, in Brians words, developed as a showcase for the new Java 8 language features). Just calling “.parallel()” advices the library to process the stream “in parallel”, i.e. in multiple threads.
Parallel processing is an optimization and therefore the general questions regarding optimizations have to be answered:
Only if the answer to all these questions is “yes” you may take the time to investigate whether “.parallel()” will increase the performance.
Compared to sequentionally processing a stream, processing it in parallel has overhead costs: splitting the data, managing the threads that will process the data and combining the results. So you may not see as much speed up as you might hope for.
Brian talks about several factors that undermine speedup.
He talks about a simple model called “NQ model”. N*Q should be greater than 10.000. N is the number of data items. Q is factor that expresses how CPU-expensive the processing step is. “Summing numbers” or “finding the max of integers” is very inexpensive and Q would be near 1. More complex tasks would have higher values of Q. So if all you want is to add up numbers, you need a lot of numbers to see a performance gain.
If the data to be processed is saved next to each other in RAM, it will be transfered together in CPU caches. Accessing cache memory instead of main memory is very fast, so data in an array is processed much faster than data in a linked list that is spread all over the main memory. Also when the data in an array is just pointers data access will be slow. As a demonstration, Brian shows that summing up an array of (native) integers in parallel scales well with number of CPU cores. Summing up an array of Integer-objects scales very poorly because there are just pointers in the array.
The more indirections (pointers) you work with the more cache-misses will have the CPU wait for memory access.
In order to process data in parallel, the source of the data has to be splitted in order to hand parts of the data to different CPUs. Splitting arrays is simple, splitting linked list is hard (Brian said: linked list are splitted into “first element, rest”).
When the result combination is the sum of numbers, that is easy to calculate. If the result is a set, and the result combination is to merge the resulting sets, this is expensive. It might be faster to sequentially add each result into one set.
Operations like “limit()”, “skip()” and “findFirst()” depend on the order of the data in the stream. This makes the pipelines using them “less exploitable” regarding parallelism. You can call “unordered()” if the order is not meaningful to you and the JVM will optimize those operations.
Of course you will lose performance if you have to mutate shared state and guarding access to it with locks etc.
Brian mentions that parallel streams where built for CPU-heavy tasks. If you do mainly IO in the processing steps than use ThreadPools and Executors etc.
As stated in the Streams API documentation, the API uses one JVM wide Fork-Join-Pool with a number of threads that defaults to the number of processors on the computer system. Why? Because it is expected that a processing steps will utilize the CPU as much as possible. So there is no sense in having more threads then CPU cores.
In contrast, when having IO-heavy tasks you want to have many more threads than CPU cores because the threads will wait for IO most of the time and therefore not utilize the CPU.
In Java, a synchronized method is not thread safe if it reads from and writes to one or more static member variables.
Consider:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
public class SomeClass { static int someCounter = 0; synchronized void doSomething() { for(int i = 0; i < 20; i++) { someCounter++; // do something that takes a bit of time, e.g. // java.net.InetAddress.getByName("www.wikipedia.org"); System.out.println("counter="+counter); } } } |
and assume the access to someCounter is somehow thread safe because of the synchronized keyword on doSomething.
As soon as you call doSomething concurrently on multiple SomeClass instances, it will not print unique numbers. This is because the all instance share the same static member variables. Between the increment of someCounter and printing it, its value might have already changed by another instance.
That particular bug was a bit hidden because a “SomeClass” instance was “cached” in a JEE stateless session bean. Of course the JEE container creates multiple instances of the session bean and hence multiple instances of SomeClass.
