I was recently chatting with a reader and the topic of how to structure packages came up.
Basically, the traditional way is to structure by layer and each layer got its own subpackage. For the imaginary Evil Corp with their project doom it would look like: * com.evil.doom.model * com.evil.doom.service * com.evil.doom.controller * com.evil.doom.dao Perfectly reasonable. But it has some drawbacks. It encourages spaghetti code. Sooner or later your code will be entangled like hell inside each subpackage. It is not clear, where the boundaries of functionality is.
and you should be aware of. Yes, you. It is one we all have committed.
Building a production system with a deadline in a tech stack almost nobody on the team knows. Just because, one little dev guy wanted to use it.
Alejandro wrote in with an interesting piece of a tutorial having the same problem as my client.
*”Last week i was reading about Google Sing-In in with Spring Social and one article that I read had exactly this problem: http://littlebigextra.com/part-1-authorising-user-using-spring-social-google-facebook-and-linkedin-and-spring-security/
I didn't write on Friday. No, I did not forget it. Actually, I planned t for the afternoon, right after I fix a bug in the job platform. While the deployment was running, I check my email and got an urgent help call, which basically was like "We got a huge problem in our self-coded portal with Spring Boot, and can't find the problem. Can you help?"
Sure, I did and so part of my weekend :-)
It started as a short tutorial app for you guys and moved on to become an own product. Let's see if that works. However, today I'll share with you what I learned this time.
The purpose was to learn a new thing, building something simple with a spreadsheet.
Strangely, I am a bit obsessed with spreadsheet usage recently. They have their place and time to be used. And they can be a bad solution, becoming a maintenance nightmare. I believe those situations are a good opportunity for generating new business. Or starting out with your own.
For a dev the complexity of tech counts. For some, it is the most important. Yet, it is meaningless without business context; mostly aside free fun coding.
To one of my last emails reader B chimed in and I got the permission to share parts of it. However, she wants to stay anonymous, which I’ll respect.
I read an interesting article and thought I’d share it with you. It is about the problem with online courses, but can also be applied to other material online, even tutorials. It’s talking about art classes as the author is an art instructor but the problem applies to other fields too. Art is interestingly close to coding. Try reading it and substitute art or design with code and I bet it still makes sense :-)
One thing disturbs me a bit in the dev communities. It’s a similar problem I also notice in other professions. People want everything right now. They don’t want to wait. They want the result. Now, better even yesterday.