Disqus - Latest Comments for jhannes

Re: La applikasjonen din overleve et kafka-krasj

Johannes Brodwall — Wed, 21 Aug 2019 17:36:50 -0000

Whops, ja det er riktig lenke.

Når jeg bruker feed-lignende mekanismer så er det som regel veldig enkelt å få klienten til å være konsistent, fordi man skriver dataene man har lest til samme database der man skriver sin posisjon i feed-en og de er dermed i samme transaksjon.

En morsom detalj er at slik jeg forstår Kafka fungerer den jo som en feed internt fordi det er klienten som er ansvarlig for å ta vare på sin egen cursor-posisjon. (Men siden transaksjonen mot Kafka ikke er koordinert med klients andre datakilder er det vanskelig å skrive once-and-only-once logikk for meldingsmottak)

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Mon, 09 Jul 2018 18:07:26 -0000

We are totally speaking past one another now, Valentin. I have no idea how what you're arguing has anything to do with what was being said.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Mon, 09 Jul 2018 03:28:39 -0000

Are you referring to Chakrit's surgeon analogy or something else?

The claim that you seem to be opposed to is "principles do only matter when they bring results". Do you think this is wrong?

Three favorite examples of faulty assumptions: 1. TDD(which I love!) forced onto someone who doesn't understand it will result in tests that are strongly coupled with the code, making the code *harder* to change. Some other intervention beyond insisting on TDD is needed. 2. SOLID principles are not a bad guess (SRP at least), but there is hardly any *scientific basis* for claiming that these are among the most important considerations. Or even that they are significantly affecting maintainability at all. The common analogy with germ theory is deeply flawed. They may be important, but we don't know. 3. DIP is often used to argue against Singletons. I recently took over maintaince of a code base that had extensive use of Singletons. When I confronted the previous architect about this he asked me to consider whether this was at all related to the biggest maintenance issues or just a cosmetic concern. Turns out there were much more important issues.

Re: Dirty Code Monday!

Johannes Brodwall — Tue, 03 Jul 2018 08:39:57 -0000

"Readable" and "simplified" are extremely subjective words in this context. Your convention will involve more lines of code. Why do you think this is simpler? Why is one exit "simpler"? Can you use another adjective than "simple" to describe the preference?

In my experience, assigning a local variable several places and returning once is more error prone. Eg.

String result = null;
switch(something) {
case X: result = "something"; break;
}
return result;

In larger examples (especially with a try/catch) there are often paths with unintented nulls.

Re: Dirty Code Monday!

Johannes Brodwall — Tue, 03 Jul 2018 07:58:27 -0000

I see this often. Why?

Re: Dirty Code Monday!

Johannes Brodwall — Mon, 02 Jul 2018 11:41:20 -0000

Did you peer review this comment? 😉

Re: Dirty Code Monday!

Johannes Brodwall — Mon, 02 Jul 2018 11:19:22 -0000

Dirty Code Monday!

Actually, it's not needed when you return.

Re: Dirty Code Monday!

Johannes Brodwall — Mon, 02 Jul 2018 02:24:16 -0000

If you're already soaking wet, how much harm comes from jumping into the water? 😁

That being said: trying to alternate from the "rules" on purpose stimulated a discussion on good and bad code, which may be especially useful if you're code is pretty bad now.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Thu, 28 Jun 2018 19:08:00 -0000

I accept comments I disagree with, but I don't accept comments that repeat the same argument without taking in new information.

In the case of your other comment, I think the question is a good one. (See answer above)

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Thu, 28 Jun 2018 19:04:28 -0000

I can only speak for my own experience, but I followed up on this in my next blog post http://johannesbrodwall.com...

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Thu, 28 Jun 2018 12:03:01 -0000

Listen: you can not play possibly have read this or my next blog post, as you are asking questions that I have already answered.

If you are not here for an honest discussion, we hopefully both have better things to do.

I'll delete further comments from you if you ramble, continue ask questions I have already answered or ascribe motivations to me (or Bob).

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 18:40:12 -0000

I think you are certainly right, Jeff.

I hope that the next big one talks as much about coding as about code. (Code complete was pretty good in this regard, come to think of it)

Re: How to write better code

Johannes Brodwall — Wed, 27 Jun 2018 17:44:26 -0000

Thank you for very interesting questions. I will try and give a quick answer and if we sense there's more value here, I will try and expand in a blog post. Let me know if you find my answers interesting.

1. TDD and architecture. There are a few questions I want answered before I start writing my first test. The most important ones are: Who are the users? What tasks are they trying to perform? How will they interact with the application (web, mobile, desktop, API)?

For me, many of the applications I end up working on or advising on have a similar top-level architecture: JavaScript (React or Vanilla) on the top (alternatively APIs), Java or NodeJs in the middle and some database (relational or document) in the bottom, if you like.

At this level, "the architecture" is pretty much given.

At the next level, I often will start making an HTML front-end mockup to explore the design of the tasks the application will perform. These I don't test-drive in the Mocha/KarmaJs sense, but develop with a browser and a dev-server that reloads at every change. I've worked on this for between 4 hours and a week, depending on the problem and how many tries I need before I'm reasonably happy.

The front-end will dictate the API for the first methods. I may update the front-end to make API calls to a non-existing backend. Then I use these API calls as basis for my first JUnit unit tests.

An early JUnit unit test may call a POST endpoint to create an entity and the GET endpoint to make sure it was called.

I write this unit test *before* I introduce any backend frameworks or persistence technologies, but when I have a nicely describing few tests, I quickly introduce the technology that seems closest at hand.

I then generally grow the architecture from the tests, only introducing new layers as the need presents itself.

One enabling technique or pattern in this regard is to structure the code along the entities (Uncle Bob strongly recommends this, too): I'll have Java packages com.johannesbrodwall.myapp.products, com.johannesbrodwall.myapp.users, etc. This allows the layering in one package to be simpler than others. I find that crucial for the evolution.

2. Patterns were never meant to "carved in stone". The whole concept of a "Pattern" is "a solution to a given problem in a given context". If you don't have the problem or the context, the pattern is not applicable.

Patterns also come in different flavors. "Null Object" is perhaps one of the "smallest" pattern, but immensely useful. "Adapters" and "Proxies" are very useful design concepts in their place. "Data Access Objects" is a useful word to descibe something that often exists.

I imagine you may mean something like "should one always avoid the Singleton pattern". I've seen good uses and bad uses of the singleton pattern (a more useful variation is the "thread local singleton"). I tend to avoid it myself.

3. "How much control and influence over the code should have the team leader?" I don't think this is a "should" question.

Perhaps a more useful question is: How can a team leader influence the team effectively?

Personally, I pair program and even mob program together with my team. I strive to listen to my pair's solution before possibly offering my own and I try to reach consensus in a programming episode. If I don't, I can't really expect my "decisions" to survive when I'm not present.

I sometimes say things like "I think we need to start over here. Can I just rewrite this whole bit here and explain afterwards?" I may be forceful enough that my pair wouldn't consider saying no. But I try to be less forceful.

As a pair programming partner, I try to make sure that we look around and ask "how is this concern solved other places in the code" and "when we fix this problem here, are there other places we should fix, too." Uncle Bob talks about "the boy scout rule" and we've even made it into a verb: "let's just boyscout this class while we're here."

I think a team lead should try and constantly encourage a push towards code that has better cohersion, less coupling, more self-similarity and less duplication - in that order. I find that I can exhert that influence best through pairing (or mob programming).

4. I think where Agile and code quality connect the most urgently is when it comes to continouos deployment. From an Agile point of view, my most urgent questions about the code base would be "when did you release during the last month" (for example) and "what defects did you release during that time frame".

Answering these questions and improving the answer over time requires certain actions in the code base: Increasing the test coverage where it matters and improving deployment automation to make it less stressful and less work to release.

Another aspect is DDD - in short: Does the changes that your users describe that they want make sense in terms of the changes you need to make in the code base?

5. I very seldom write code comments. The clear exception is API documentation released for consumption beyond the team (open source libraries for example). When I come across code written by others, I very rarely read comments, as I don't trust them. The exception is // TODO, or // HACK or otherwise clearly marked information that is saying something different from the code.

If you like writing comments, I have no objection to that. If you use one of the open source libraries I commit to (Eaxy and Json-buddy) and you miss API documentation, I accept that as an issue or pull request.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 15:14:21 -0000

I'm unclear what you wanted here. You groundlessly accused me of making a personal attack and made assumptions about my motivation. When I offered context for what of Bob's professional actions I object to, you repeat you accusation against me.

What are you trying to accomplish?

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 08:29:43 -0000

I really like "communal". It's much less moralistic than "compassionate"

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 04:41:39 -0000

I think you have many interesting points, Valentin. I'd love you read a free-standing counter-point to my blog post that collects your thoughts into a complete argument. Do you have a blog?

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 04:24:21 -0000

Read my article again for blog post references. ;-)

For examples from his talk, see for example this comment: http://johannesbrodwall.com...

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 03:40:24 -0000

Well, if you're in the one-interface-per-class area, that's a place for DIP, but I would be surprised if LSP comes up.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 03:38:58 -0000

If you weren't kidding, I would understand. I only come to events where I speak these days. Perhaps I should come to DDD meetup? ;-)

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 03:38:00 -0000

Not as much as you think, Kurt: https://blog.cleancoder.com... (<-- This is one of many blog posts where I do feel Bob is right on the money)

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Wed, 27 Jun 2018 03:35:00 -0000

I think the confusion here is that I refer to Clean Code as in the talks he gives and his blog articles as much as the book. The book is wonderful. It's the other parts that I object to.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Tue, 26 Jun 2018 16:18:20 -0000

Maybe the experience is similar but our reaction differ. I often see people with existing code bases where DIP violations was written into the foundation of the system. Not much that can be done. SRP can be applied at a micro level.

As for LSP: most code I encounter hardly uses subtypes, so I don't see that many applications.

Perhaps I'm rearranging deck chairs on the Titanic?

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Tue, 26 Jun 2018 15:11:29 -0000

I love your perspective on this, Mohammad.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Tue, 26 Jun 2018 09:41:14 -0000

Have you seen him talk at conferences? It's fun, but it's also very often a little bit creepy. In the last few days, I've heard from several people who have been quite upset or offended at his "clean code shaming".

The books are not very strong on this, though.

Re: Forget about Clean Code, let’s embrace Compassionate Code

Johannes Brodwall — Tue, 26 Jun 2018 09:14:00 -0000

🍻 Are you coming to JavaZone?