I started writing series of blog posting about code metrics. I plan to introduce different metrics and explain their meaning. Also I plan to introduce tools you can use to measure those metrics. Where possible I will introduce you how to use one or another metric. The first metric is the simplest one and it is called Lines of Code (LoC).
When I started building in-house demo application I thought about how to solve temporary data layer so I don’t have to use real database and object mappings for it. Playing with new object model and new components I move way faster if I don’t have any additional ballast that I can avoid. So I wrote simple cache based repository mechanism I can use to imitate real repositories that I will write in the future.
Source code documenting is very important task. Code documentation servers as persisted communication between developers who are using same code. Undocumented or poorly documented code may be hard to understand to other developers who have then waste their valuable time to struggling through the code they don’t understand well. In this posting I introduce you some code documenting tips.
Agile Principles, Patterns, and Practices in C# by Robert C. Martin and Micah Martin describes how to write software using C#. Book covers also most important design patterns and object-oriented development principles. There are very good, close to reality examples for every topic and that makes this book pretty easy to read and understand.
Web page that is not attacked by security team or developers and testers before going to live can be considered as unsecure because nobody knows how it behaves under attacks. Unfortunately there are many web pages that are not secure and not event tested with security in mind. If some of these web pages happen to be a e-commerce sites then it is not hard to guess what kind of data attacker may find in this system about us. How can we be sure that our systems are protected against attacks? (more…)
After reading the books Ship it! and The Pragmatic Programmer, I suggest you to read both of them, I got some proof that I am right and the fast way I sometimes like to move is not my personal bad behaviour but suggested way to develop software. Officially it is calledtracer bullet development. This method suggest you to write some code to make system work for customer so they can see how the system is planned. But this is not a usual prototyping procedure but involves some real coding work too.
The Pragmatic Programmer: From Journeyman to Master is good reading for all developers and good addition to Ship it! A Practical Guide to Successful Software Projects. The Pragmatic Programmer is about developers everyday work and provides solutions and ideas about how to solve problems we may face more than once.
Loggers are one of most popular examples about interfaces for sure. And there are a lot of implementations of loggers. Some implementations are simple and yet powerful, some implementations may be more complex. All we have to is to select implementation we need and integrate it to our application. It seems like good idea at first place but as soon as we need to switch from one implementation to another we discover nasty dependencies we have to change in all places where we are logging. Let’s see how to avoid these dependencies.
I’m sure you have seen classes that initialize a lot of objects in their constructor. These classes may be hard to test because of those object creations I mentioned. To get around this problem we use Extract and override factory method refactoring so we can extend these classes and override some factory methods.
Sometimes you are not able to use Extract Interface refactoring because interface of parameter may be too large or there may be no interface at all. You just have class to pass in and you are not able to fake it or extend it to get class testable. In this case you have to use Adapt Parameter refactoring to create adapter that is seen through common some common class of interface.
This winter I read book Death March by Edward Yourdon. Death March is about death march projects and how to survive them. There are also chapters describing decisions that you should never make when managing death march project. And there are great tips that help you avoid bad mistakes in death march projects. The book describes also developers life in such projects and gives them some good advises how to stay alive.
In legacy code you may find classes with constructor where some objects are created and initialized. These classes are not easily testable because they depend on other classes and therefore when you unit test these classes they may also throw exceptions of classes they depend on. In these cases we can use parameterize constructor refactoring.
I finished yesterday another great book: Ship it! A Practical Guide to Successful Software Projectsfrom pragmatic series. This book is not theory book that leaves you with many questions and no idea how to move along. Instead, you get an good idea about how to develop software and manage software projects successfully.
Extreme Programming Explained is overview and guide to extreme programming (XP). The author of this book – Kent Beck – is well known XP evangelist with great experiences on the field. XP is not very simple thing to start with when one has worked some years on “classic” way. Kent shows us the way to XP and gives great explanations and suggestion about how to get started with XP.
Software Estimation - Demystifying the Black Art is another masterpiece by Steve McConnell. I introduced in last june book Code Complete 2 by same author - it is suggested reading for developers. Software Estimation, as title sais, tells about how to estimate software projects. Estimating is not easy thing to do if you want to achieve good estimates.
Death march projects are standard in software development and they are usually the most complex ones to handle. It seems to me that this is more like question how to handle the chaos and how to survive it with as less losses as prossible. There are some signals of dangers I would like to share with you.