Entries Tagged 'Code' ↓

Today we had a meeting going over a few future projects and it was brought up we could integrate the new project into an existing project that had 80% the same functionality. However, there comes a lot more complication with this short of merge.

For example, what happens if two people are working in the same project on two different pieces. The first person is finished with their piece and checks it in happy as can be, while the second person finishes later and his change needs to go in ASAP, while the first person’s change can’t go in till the end of the month. Now what?

Now in a perfect world, one would state that the first person shouldn’t check in their code till it can go in, or person two would get the previous version of the first person’s code.

At work we decided to keep the projects separate and not consolidate them even though it would share 80% of the functionality for the UI. But in the end, it allows us to not step on each others toes.

So my question is, how do you handle this?

File and project naming has been a massive debate at work lately as we teach newer employees the greatness of OOP. On my way home, I had an epiphany, and so I just had to write it out. So here is the best file naming reason/description you will ever read:

Your file names should describe your work without the developer having to open it to figure out what it does. In OOP, you should define your parts/pieces first, and then your object in individual classes. For example, you may find a class for Driver, Vehicle, Liabilities, and then one for Quote that incorporate the previous three. The names are meaningful and you do not need to even see the code to understand what is in them.

Now that file naming is covered, how about project naming? In all honesty, I am less concerned with project names than file names. But, they are important none-the-less. Your projects should describe your collection of classes in as few words as you can muster together. For example, the above files might be under the project name “QuoteEngine”. Why? Cause they are the pieces that allow a quote to process and are likely to include the methods for actually submitting a quote as well.

Should your projects include acronyms such as DABL (Data Access/Business Layer)? I personally do not think so. If you have to physically describe it is the (Data Access/Business Layer) then your tiers are not neatly organized enough and you need to separate them better, or better define your classes to help resemble which layer you are in.

Well that is my two cents for the evening.

Today, like most days, my day was spent solving problems that were not mine to begin with, but became either too complex or the person just needs someone to hash it out with. Either way, I enjoy these opportunities.

The majority of problems start with the lack of analysis, or the complication the analysis turns up. This afternoon, I was meeting with one of our tech system guys going over a support issue we received when a co-worker dropped by to hash out his new issue, which brings me to this blog post.

Analyze, Analyze, and then Analyze again! Analysis is a major part of every project and it something that should be taken seriously and completely is at Central (where I work). My co-worker had done quite a bit but had major questions about the project and the path he found best so far, primarily, would the data set he wanted to achieve be too large to handle efficiently. So, considering one of our tech system guys was already at my desk, and I am a bit of a SQL genius myself, we hashed it out.

We estimated that in the worst case scenario we would be approaching 15 MB of data, which is fairly large. However, during our discussion we also established that the data would only need to be pulled out of the database once per day. Now that is very important! Think about it, 15 MB is nothing if all you need it is one time. If you have to call it 25 times a day, that makes a hell of a difference.

However, the code path my co-worker choose would have made him pull out the data 25 times. Analysis with others, or re-analyzing your project due to the questions you are left with should be taken seriously. If the data your application is going to use will never change for 24 hours, then program it so it take advantage of this tidbit. Persist that data outside of your storage solution to reuse throughout the day so you do not have to hit up the server to retrieve that data over and over again (in a sense, cache it).

If the data might exceed a decent size to cache (ie: 15 MB), then write it to a flat file and open, read, and close immediately thereafter. That way, you still only pull the data from SQL Server once, and for the remainder of the day you work with the flat file.

By all means, keep your co-workers informed and when questions arise, talk out your solution with them to see if they have any better ideas, or agree with your approach.