Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've been wanting to help out with an open source project for some time now. I want to do this for two main reasons. I am a strong supporter of foss and I want to gain experience.
I've struggled to find a project that I thought I would want to help with. There are many I would like to help with, but they are far to complex for what I would want to start with. However, I recently found a browser, uzbl, which seems like it is complex enough for me to be able to learn from, however simple enough for me to be able to wrap my head around.
It is a simple lightweight browser which uses webkit and gtk.
Now that you are familiar with my positon, here is my question.
What is the best way to go about understanding the code base?
Now I realize this is a subjective question. However, I feel if I have the suggestions of more experienced developers, I may be able to cut down on the wrong turns I make.
Should I familiarize myself with the libraries used first? Or should I look through the core code and concern myself with what goes in under the hood after I have a basic understanding of the global picture?
How do you guys go about understanding the code base of a new project?
Thank you for your time and effort.
First, compile and run it. With many projects, simply accomplishing that task will give you some understanding :-)
Second, it's good to have some problem to solve. Some small task, like fix a minor bug somewhere. Just debug, search for the bug origin, try to fix it. Then run unit tests (if any), see what else you broke with your fix. Investigate that, too.
Then repeat. A dozen of bugs, preferably in different areas, give some better understanding of the codebase.
After that, I usually start wondering around the product, just looking how it works and playing with it. Natural curiosity takes over sooner or later, and I find a feature that interests me. In a "wow, I wonder how it works" kind of way. Then I try to sketch a high-level design for that feature myself. Along the lines of "what would I do if I had to create this feature? Very briefly, just in my mind, no fancy diagrams and whatnot.
In doing so, I inevitably find myself in need to know more about the system: after all, you can't design a fully isolated feature, can you? You'll have to interact with the rest of the system, and you need to know how. So I go into code and find out.
Then, a moment may come when I realize that I really don't know how to design this little part of that feature. I think, and I think, and I think, and I just don't know. So then comes the sweetest part: I go into the code and look how is it designed in the first place. Sometimes I would be disappointed in the project. But more often, I would be disappointed in myself. But that's exactly what's precious: that's how I learn.
I have found two things (in addition to the answer by Fyodor Soikin) that really help. One is getting doxygen to do document everything for me. It makes it a lot easier when I can go through the function declarations, and click the data structure which is supposed to be passed in so I can see all the members it contains (if there is no current documentation you can just set EXTRACT_ALL = YES). I also find it very useful to compile the project with debuggin symbols then run it in gdb so that you can follow it from start to finish.
I would look for their tests first, and look at those. If there aren't tests, I probably wouldn't bother with the project. If there are tests, they should be instructive as to how the software works. Step through the tests in the debugger to understand how the high level components fit together.
i just joined this new group and basically haven't even really done any heavy lifting development but just some basic web store migration stuff. and i've been given the challenge of coming up with improvement areas for the development process. I'm thinking of using Joel's list as the basis for determining what can be improved in my team, and besides that perhaps ask few of my seniors there who have been around for a while.
i'm not exactly sure why i was given this but i'll take it on anyway as it sounds like a good challenge. but what other tips or resources that you would advice me on how to do this properly.
P.S: i have about two weeks to do this, thus please suggest something practical and nothing to big as it's just lil ol me who has to do this within this time frame. :)
thanks
Having been in this tricky position a few times let me give you one piece of candid advice.
The person who gave you this task almost certainly has an idea in mind, and they would like you to reinforce that idea.
How you react to this is up to you and the environment in which you work.
I think you'll probably have to start by finding out where the major weaknesses are. Given your time-frame, you'll have to focus on the a few of the major issues.
Try and find out where time is being wasted. Interview your colleagues, customers, etc to try and find out where the pain is being felt. Observe the team at work and try to identify areas of inefficiency.
You'll probably find people are more receptive to your recommendations if you focus on the immediate problems, as opposed to coming at them with a range of good practices.
Once you've identified a few problem areas you'll be able to research some possible solutions in depth. Without a tighter focus, you'll be swamped by the different possibilities. And, in practice, you'll probably need to introduce new initiatives gradually anyway, which will involve you reviewing the next steps incrementally.
In order to decide what to improve you have to take into account the current status (obviously). Try to find "pain points" - the things that cause grief to the developer's while doing their job:
Do they have proper tools?
Are they fully aware of the current development goals?
Do they have an optimal development environment?
Are you using Agile/TDD/Pair programming?
I've choose the points above because they can be fixed easily in two weeks.
You've been working in this company for enough time to come up with several points of improvement, also talk to the other developers to find out what they think could improve their work.
Whatever you decide remember that your goal is to improve the development process for the dev team but also for the end customer - think on how you can provide high quality software in less time (within budget).
Since most humans come with a brain, teams usually already know what the problems are and how they can be solved. Only, there is a reason why the situation is like it is and there are forces which actively prevent change.
So just ask them what needs to be done and then find out a way how you can either do it or talk them out of it.
I'm considering adopting .nettiers for a new project as it seems to provide a lot of functionality I could use.
Is anybody using it in anger (I'm getting the feeling it hasn't got the following it once had) and if so, what are your perceptions of it?
Also, I can't find any comparative performance metrics against things like SubSonic. Anybody have any strong feelings about its performance and scalability?
Many thanks
Tony
When I used NetTiers, I was very happy with it to an extent. You really need to learn the best ways to use it. There were definitely some weird bugs, things that had arbitrary limits and so forth. You have to be careful with it but it can definitely improve your productivity if you learn. I know CodeSmith has started putting more resoucres in it. The version 2.3 might be very solid. Although, the latest current stable version may be pretty solid, I haven't used it in awhile.
Honestly, at this point I prefer LLBLGen. I did try SubSonic a couple times. I didn't run into major bugs but I ended up switching, in both cases, to NetTiers. With SubSonic I felt that I was just typing out way too many string literals and it just didn't feel as mature as other alternatives.
Look at this. It provides you with a good X vs Y comparison between the two of them.
A Key point that i always revise when selecting a framework to work with is:
Will this Simplify, Make me more Productive, if you answer "Yes of course" to this, it doesnt matter what other benchmarks say, even if it's 10% slower in running than SubSonic or even faster, you should go with the framework you develop the fastest and most that you are the most comfy in.
I had some time this afternoon to run a head to head comparison between netTiers and SubSonic.
I used code generated using SubStage (part of the SubSonic 2.1 release) and I used RepositoryRecord as my base class.
I ran the same test against the same database using code generated by .netTiers 2.2
The test was a derivative of the one that Rob Conery used in his post:
http://blog.wekeroad.com/blog/subsonic-scaling/
When i say derivative, I mean I just wrote 100,000 records into the database.
I repeated each test on the same PC three times.
I found that .netTiers accomplished the task in 90 seconds.
Subsonic completed it in 104 seconds.
There was no more than a one second deviation from these averages.
Look at this. It provides you with a
good X vs Y comparison between the two
of them
Thanks - I've already read this post before, but it's over two years old and both projects have advanced a great deal since then.
Asking whether or not a framework will make me more productive or not is a very important consideration, but it's not the only one.
Another for me has to be "am I going to lose potential productivity gains because the framework I adopt is full of bugs, nasty to use, or just a PIA?" which is why I asked if people are using it in anger and what their experience is.
If .nettiers is 10% slower than subsonic, but gives me a whole bunch more features (such as better validation, business rule enforcement etc) then I can live with that. If its ten times slower, then I'd not consider it.
Many thanks
Tony
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Recently we added a couple web service machines, and they couldn't successfully email out. We (IS) did not notice this, and the exceptions were being swallowed up and logged, but no-one noticed for about a month.
Needless to say, many purchase orders, and retraction of purchase orders, were never sent out for the past month.
While this isn't any one person's fault really, is there any GOOD way to break this to someone non-technical that is higher up in the company than you?
Thanks in advance for any advice, I'm freaking out just a bit. :)
Edit: Reading this over, I'm more asking for tips on how to break the news. I understand there isn't a GOOD way, just maybe successful tips that have worked for you in the past.
Resolution in case anybody was wondering...
new web service machines IPs weren't added to our mail servers list of trusted IPs. :)
Put emphasis on the fact that the problem was discovered and fixed swiftly by your team. Have detailed metrics on the number of failures, which customers were affected, etc. ready, in-hand. Have a contingency plan ready to describe that will prevent similar issues from happening in the future. Engender a sense of comradery with the higher-up because you are all on the same team and it's a team problem. If you convey a sense of urgency and give the impression that you appreciate the impact to the bottom line as much as they do, they will respond much better.
Lowly techs often make the mistake of going to upper management with their tail tucked between their legs, like a child who shamefully shows his parents the lamp he broke and waits for a spanking. You are an adult and a professional - leap into action and coordinate the right people to be in place to make the right decisions to fix it. In a case like this, that inevitably means bringing in upper management, but do so with an intention of solution seeking, not fear.
You bring shame to your department. You know what you must do.
http://en.wikipedia.org/wiki/Seppuku
Gee, bad news for ya - but it is someones fault.
The folks who built the server and installed the apps and signed off on putting them into production use without testing them. :-)
Pretty much the only way to break this to the management is to acknowledge the MAJOR FUBAR and show them the plan for making sure this kind of situation doesn't happen again.
Good luck. :-)
Raise the issue as soon as possible.
Come with a clear plan/lists of steps of how to mitigate the problem:
how to fix the issue, so further processing works fines
is it possible to determine which transactions are affected
what is necessary to ensure this does not happen again - automated tests for deployment, preproduction stage for new servers, anything else?
Be proactive in resolving the situation. As long as it's not a direct fault of yours, you might even benefit from the whole snafu.
Being honest and direct is the best, rather than trying to cover up certain aspects of what happened.
Don't blame anyone, simply accept that a problem happened, propose a solution, and execute on that solution. Communicate this plan to your superiors and be clear about why you are taking the steps you are taking to solve the problem.
The time to find responsible parties and blame comes after, solving issues having to do with collecting money from customers comes first.
Once the immediate problem is solved, then find a way to ensure that whatever caused this problem cannot happen again. Have a plan.
Point out
What happened
Why it happened
What you think the fallout was (ie, missed purchase order retractions)
What you've already done to fix it
What you need to do to (if there's more fixing needed)
What management needs to do, say, spend (if needed)
What can be done to prevent similar incidences in the future
Be proactive about reporting it and spin the negative into a positive ("we've learned the following valuable lessons").
Avoid pointing the finger wherever possible unless asked, and try to spin that in a positive light too. Techs make mistakes; they are human after all. If they can learn from the mistakes made they're probably worth keeping around.
Whatever you do, make sure you have agreed on it beforehand with your immediate superior, at least. Even if you are iS director.
lie or cover it up :-), if you can shed the blame to a new intern ill award you 10 kittens!
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I am looking for an easily digestible book to present to my boss/team.
Background info: More and more of our meetings at work involve my boss/team pondering how to implement more "best practices" around here. ("Here" = a very small application development shop. 4 developers)
The following things are items that my whole team agrees that we need:
Nightly builds
Decomposing "bugs" in our bug-tracker into smaller, more-specific items
Automated testing
The problem we face is how to get started.
I believe that if my shop could simply choose a clear and specific plan or set of rules, then everything else would fall into place. Right now we are stuck in discussions of fuzzy, feel-good ideas and nice-sounding buzzwords.
Please recommend to me your favorite book (or online resource) that contains clear, discrete, sequential steps for implementing a management scheme for guiding a TDD or Agile team/shop.
I realize that there are other paradigms besides TDD and Agile that would also address these concerns, but my own self-interests and biases point toward TDD and Agile so I would love to harness my team's desire for change and "nudge" it in that direction. Or feel free to slap me down if you vehemently disagree with my sentiments! I will take no offense. :)
As others have stated, I think these questions are answered best when respondents list only one book recommendation per answer.
Thank you all.
To throw another Pragmatic Programmers title in the mix: Ship It!
Great book - take a look, might suit your needs with management.
For your needs I recommend Test Driven Development: By Example (Kent Beck). It is clearly-written, more practical than theoretical, and prescribes time-tested recipes to adopt an agile, test-driven approach.
I suggest that you start with what you agree on: Nightly Builds and Automated tests. Nightly builds is a no-brainer. For Automated tests I would start with:
Each commit with new functionality should have at least one automated test
Each commit that fixes a bug should have at least one automated test that fails without the fix and succeeds with the fix
If you do this, you will start to gain experience. With this experience it will be much easier to understand all the good advice that the literature has.
There is a lot of good books on good practises, but you have to figure out what works for your team.
Agile methods are not really methods...
There are more a spirit. The main is a focus on :
communication
reactivity to changes
customers orientation
This can be achieved in lot of ways, and it's more important to find your way to do it. If you want an example of what this spirit can be, you can read the free 37signals' online book, Getting Real.
But there are some steps you can start with
They are no big rules you must enforce, but you can try the following and see how it goes with you team :
Quick stands up meetings. 5-15 minutes daily meeting where everybody stays up on his feet and explain what he has accomplished, what need to be done and what can prevent him from doing it. Keep it under 15 minutes, with the minimum number of people.
Set simple goals for short term deadlines instead of big goals in weeks.
Build small team (3 persons) and divide the work between them. Put them in the same room and ensure they have at least half a day to work without ANY interruption.
Set many little regular review with your customer. Don't write specs. Sketch, design, prototype, show to the customer, fix/adapt/change then build. Then do it again.
Testing, versioning, bug tracking are tools, not methods. No one cares how you do it and with what software are long as you do it. They are not the issue.
It's not really a step-by-step book, but full of great advices and easy to digest: Practices of an Agile Developer. And if you want to have in house TDD training, I recommend netobjectives. I had their TDD course ones and it really opened my eyes.
Sadly, even the most clear and specific plan can turn out to be disputable.
I'll tell you what works. Starting TDD immediately. It has boundaries. It's relatively easy. You'll still have a million questions.
You are free to say, "But what about nightly builds?" "What about using the bug tracker?"
A lot of pondering can mean one of two things.
First, it can mean that someone is muddying the waters with "concerns" and "questions". Sometimes this is really displeasure at changing, voiced as "concerns". Sometimes this is really crushed egos ("I thought I was pretty sharp, now someone is saying I must have improvements imposed on me.")
Second, it can mean that this is dauntingly large. Consequently, don't look at this as "Many New Best Practices". Look at this as just a few incremental improvements. You're not changing yourselves fundamentally (well, that could happen, but don't start out with that as your plan.)
My experience is that you can only do one new thing at a time. Do TDD until it's boring. Then do something else. Often nightly builds become obvious after you have a robust test suite. Then when that's boring, do some other small, incremental process improvement.
One thing at a time. Baby steps. Avoid throwing out babies with bath-water. All you want is to be a little better next month than you are this month.
If there are concerns on adopting one small incremental improvement, find the root cause. Who's ego is bruised? Who's worried about change?
You can print him Scrum and XP from the Trenches by Henrik Kniberg, It's more focusing on agile development process that on TDD, but it's an easy and quick read.
Check out books by Marty Cagan.
my favorite is Planning Extreme Programming
EDIT: it provides a complete replacement for traditional project management geared towards an XP/Agile team
the danger is, adopting modern development methods and then strangling them with archaic project-management and administration practices!