I am reading "Clean Code" and "Clean Architecture" by Robert C. Martin (not finished yet), but I don't really understand enough. If I have clean code, do I have clean architecture too? If I have clean code and clean architecture, do I have good project structure? So, what is the difference between them? The clean code, clean architecture, and good project structure. What is the correlation between them or how they are three related, how can I get good project structure, clean architecture, and clean code?
Thank you.
"Clean Architecture" is about boundaries and dependencies between "sub systems" and components of your software system. It helps structuring your code for changeability. By that following "Clean Architecture" will give you a "good" project structure.
For further details on how "Clean Architecture" makes your project structure "scream" pls refer to my blog series: http://www.plainionist.net/Implementing-Clean-Architecture-Scream/
"Clean Code" is about the implementation of your "sub systems", components, classes and functions. It helps in structuring your code for readability and maintainability.
Related
I'm some kind of 'Maven expert' in my company, the problem being that I have a good basic knowledge of Maven, but I'm absolutely not an expert when it comes to release, etc...
I'm desperately searching for some kind of good online training for Maven that is not for beginners and that will speak about release and other advanced stuff.
I have no problem to have a course that starts at the very beginning of Maven, but I want to go further than basic dependency management, basic lifecycle and simple project build, my real goal being to be comfortable with full Maven release.
Has anyone a good website, or something for me ?
Thank you,
Seb
This is a question that's broader than just Maven. Because what you do with Maven is determined by the dev process.
If you're interested in general in dev/release process, you could research Continuous Deliver topic as well as Continuous Integration. You could start with Continuous Delivery book which gives a good perspective on both CI & CD (it's pretty boring though).
As for the videos, you could just search in the internet for Continuous Delivery. I like in particular videos from Sam Newman.
As for the Maven itself, there are books like Maven Complete Reference or Apache Maven 2 Effective Implementation (which is a bit old, but Maven was pretty stable from the end user perspective, so not much changed).
I am developing a Java framework/API to solve a problem at a client. The code/idea is my property (not the client's). I think it might be useful for others, so I would like to publish it as a open source project.
By publishing I mean bringing it out in the open - making it available as a Maven project.
I can think of conforming to Maven structure, proper documentation/example usage available on a web site, and unit tests, maybe some code coverage threshold.
But does it have to be run by some committee? Do I have to present it to somebody? What steps do I need to take to eventually have it available as a Maven dependency?
There's no committee or approval process that I know of. All you have to do is put your code into a public Github repo. This is how open source software works.
Per Kapep's excellent suggestion below, you have to choose a license as well. Apache, Creative Commons, Gnu, MIT - these are a few of your choices. Know what they mean before you decide.
Your problem begins on that day - you'll have to make others aware of it and see if it's adopted by others. If it's good, you'll have the nice problems of dealing with a user base and having others change your code. If not, it'll languish in the repo.
I have recently been charged with building out our "software infrastructure" and so I am putting together a continuous integration server.
After a build completes would it be considered bad form for the CI system to check in some of the artifacts it creates into a tag so that it can be fetched easily later (or if the build breaks you can more easily recreate the problem.)
For the record we use SVN and BuildMaster (free edition) here.
This is more of a best practices question rather than a how-to question. (It is pretty easy to do with BuildMaster)
Seth
If you believe this approach would be beneficial to you, go ahead and do it. As long as you maintain a clear trace of what source code was used to build each artifact, you'll be fine.
You should keep this artifact repository separated from the source code repository.
It is however a little odd to use a source code repository for this - these are typically used for things that will change, something your artifacts most definitely should not.
Source code repositories are also often used in a context where you want to check out "everything", for example the entire trunk. With artifacts you are typically looking for a specific version, and checking out all of the would only be done if exporting them to some other medium.
There are several artifact repositories specialized for this, for example Artifactory or Apache Archiva, but a properly backed up file server will thought-through access settings might be a simple and good-enough solution.
I would say it's a smell to check in binaries as a tag. Your build artifacts should be associated with a particular build version in your build system, and that build should be associated with a particular checkin. You should be able to recreate the exact source code from that information. If what you're looking for is a one-stop-function to open the precise source-code revision that generated the broken build, I'd suggest that you invest some time into building a Powershell module that will do that for you.
Something with a signature like:
OpenBuild -projectName "some project name" -buildNumber "some build number"
We have several enterprise projects on maven2, do you think it would be a good idea to switch now to maven 3?
I heard the migration is not hard but there are not big improvements unless you're going to use the parallel builds. But our build machine is already almost choked up so I don't think we can use it.
Has someone experienced problems or big improvements?
The most important thing is to do some test builds with Maven 3 to see if there a any big problems. If not it's not a big deal. Improvments are there, cause Maven 3 is usually a little bit faster than the same build in Maven 2. So it might be worth to analyze it in detail.
I'm setting up my team's source control + build/integration process from scratch. We were using VSS and a tool we created in-house to perform the build process. We decided to move on to a more modern environment. I have the SVN running, and I would like to set a continuous integration process with CruiseControl.NET.
Is there a good step-by-step starter guide that will get me started with the best practices of this tool?
Before leveraging CruiseControl to it's fullest extent, you need to create an automated build script that can be run by msbuild or nant. After you get your project building in one step, then you can start integrating CruiseControl into the mix. Here are some resources to help get you started:
CruiseControl.net Wiki - A very good resource.
CruiseControl.net SourceControl Block - Shows how to use svn with CruiseControl.net with the sourcecontrol block
Getting CruiseControl.net, MsBuild, and SVN setup - A resource stepping you through the steps to get everything meshing together.
An excellent resource I've found for CI recently is by Martin Fowler, author of the famous "Enterprise Application Architecture" book.
URL: http://martinfowler.com/articles/continuousIntegration.html
Here are some links that might be useful:
http://www.codeproject.com/KB/dotnet/cruisecontrol_continuous.aspx
http://devlicio.us/blogs/ziemowit_skowronski/archive/2007/03/10/continuous-integration-1-the-environment-and-the-first-build.aspx
http://code.google.com/p/ci-factory/
One tip we have learned - if you have a reasonably large team and the product you're referring to is some "push to QA so people can test" type of scenario, resist the urge to have it build every single time someone checks something in. It will likely take down QA for some amount of time and cause QA to be disrupted a lot before you figure out that people are checking stuff in all day long.
For a "push to QA" scenario, just have it go off every evening if it detects changes.
For a "see if it builds" scenario, once every hour is good (again, people check in stuff way too often on a decent sized team to make instant builds worthwhile)
If you're looking a .NET CI could I suggest you have a look at Team City. I think it's better and it is free for up to 20 users.
Really, the documentation is pretty solid