Hot answers tagged

130

This is awesome. I wish more software developers took the time and effort to do this. It: States in plain English what the class does (i.e. it's responsibility), Provides useful supplementary information about the code without repeating verbatim what the code already says, Outlines some of the design decisions and why they were made, and Highlights some ...


65

Disclaimer: I am an architect in an agile environment but, as Helmuth von Moltke the Elder says, "No battle plan survives contact with the enemy". In other words, practicalities mean that the exact letter of the guidelines cannot always be followed. Most of the points raised above are followed as best the team can. However, principle 1 (The teams that code ...


35

Let's assume that all specifications are in place and the organization is working perfectly. You've assumed the two biggest "bottlenecks" in the software development processes don't exist (from my personal experiences).


35

The key to working with a large codebase is not having to read the entire codebase to make a change. To enable a programmer to quickly find the code he is looking for, code should be organized, and the organization apparent. That is, each logical unit in the code, from the executable, the library, the namespace, down to the individual class should have a ...


21

2 weeks ? In my second job it was quite common for new hires to only get the 'oh! i get it now!' moment 9 months in.... If it is genuinely a huge product then they will expect a long time to 'get' it, just keep working hard and ask plenty of questions.


13

I would not agree this is a very good approach, mainly due to When you refactor your project, move methods around, the documentation breaks. If documentation is not properly updated, it will result in more confusion than help understanding the code. If you have unit tests for each method/ integration tests for each module, it would be a self ...


12

Even as a not-so-new developer, I often find myself thrust into situations where I have no idea how the software works or is designed (if it was designed). Often if there is someone around to ask, they don't know much more than I do, or are wrapped up in something else. First step - Get prepared. Install a dev environment, get a notebook, clear off a ...


11

One aspect of experienced programmers who move from an IDE to a console / xterm environment, is finding a replacement for the indexing of source code objects (function names, variables). I believe the general term used for Microsoft's Visual Studio is Intellisense or something like that. In the Unix/Linux world, such as vim, one tool used if ctags or the ...


10

Disclaimer: I am not an agile coach/architect - this is what I've seen in agile projects that I've worked on and I think it works well. I don't think it's quite defined by Agile how you do architecture - agile focusses on development methodologies and practices. UML on the other hand is just a language to communicate your architecture which is beyond agile ...


8

Even in your hypothetical, perfect world, there are some issues I can see: Probably the most important, from my own point of view, is dealing with customers. In my own experience, the business has to deal with customers who frequently try to change the project while it's being developed. In some instances, they have tried to wing a change request as a bug ...


8

Books like http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052 should be witness enough to how large, legacy poor quality code bases are common in the industry. My guess at why you have not heard or seen, and, more importantly, you will never likely hear about them until you work on one of them yourself, is, nobody seems capable ...


8

For the most part, your experience is what I know as "the norm". Very often one of your first tasks will be "Go find and fix this bug" and you'll struggle finding your way throughout the source tree (ideally starting at the source code search tool) to search the codebase for the particular error text or something related. If you have a kind or competent ...


7

I don't intent to be part of VIM vs. IDE debate. I guess that is personal pref. But i use a lot of VIM and here is why i find it very powerful to use vim Two parts of the answer: A. Most things VIM allows most thing you can do with IDEs,(i am not trying to put every feature but just a few non-obvious that make vi look limiting) you can go traverse the ...


7

I assume you have already installed the development environment and have all the necessary tools working - if not, start with these. Setting up your dev environment usually takes a lot of time, with long idle periods waiting for software to download/install, while you can still do other things. About your lack of information, I suggest you talk to your ...


6

One tip, ask lots of questions but not as you think of them. Keep a list of questions and when you do get time with a senior developer bring out the list. It's a far more efficient use of their time to answer 10 well thought through questions in on burst than five questions over the course of a day that interrupts their focus. Consider using e-mail if ...


6

I'm personally a fan of a high-level design document - preferably written BEFORE any code - that gives an overview of the design and a list of classes and resources. A top-down design greatly simplifies things - yours might be "game engine -> hardware -> controllers -> joystick"; thus, a new programmer told "fix the 'a' button on the 'xyz controller" would ...


5

If I were you wouldn't worry so much about understanding "how it all works". If you are hired as a junior/inexperienced then focus on your tasks and ask questions when time given. For example when you are given a new task try to use that connection with your seniors to ask more general questions but don't ask too many questions at once. Also try to devote a ...


5

While I admire those who can sit back and read code like they read a novel, I find it a bit tedious at times and that it does not really work with large complex software products and libraries. I wrote a long post about reading and understanding code here that might be useful for this particular discussion - ...


5

Stepping through the code can be great at determining functionality. But I have found the more complex an application is, the more likely you are to be bounced around in the debugger and get completely lost. I would focus on understanding the business rules of a particular piece of functionality of the application. Ideally, focus on the simplest part. ...


5

The nice thing about the PageRank algorithm is that it can be solved iteratively in a distributed way, within the MapReduce framework. However, the working data for Pagerank on ~5M nodes and ~50M edges should fit perfectly well in 4GB ram, never mind 48GB.... Specifically, you don't need to store all data for each web page in memory -- instead, you should ...


5

You're asking if it is important to include all links in RSS - look at other huge services - nytimes.com displays only 25 links in it's feed. It's up to RSS readers software to fetch your feed often enough to get all I guess.


4

In my opinion, Vim gives you a very strong editor with basic features, but it's up to you to spice it up with scripts/addons you'll most likely use in your projects. These will probably be different depending on whether you mostly edit scripts, documentation, or files that need to be compiled. As an example, I use zencoding for the occasional html/css ...


4

On February 3, 2013, Michael Meeks, one of the LibreOffice developers, is giving a talk in a couple of days entitled, "LibreOffice: cleaning and re-factoring a giant code-base, or why re-writing it would be even worse." It sounds like exactly what you're asking for: a discussion of what they've done to take " a poorly-understood, gigantic code-base ...


4

It is not uncommon. At my current job, I was asked to look at the current codebase (~200 dlls, ~500 kloc) and at the end of week 3, present to the boss, architects and team leads the top 10 things wrong with it. The key thing to remember is that you're new. New people have questions. Ask questions. that will help you get your bearings about where ...


4

Other folks have already written some good answers, so I'll just mention them in summary: DON'T PANIC! This happens to everyone. :) Ask questions! You aren't expected to understand the entire codebase. It generally isn't humanly possible anyway. I'll add to those that reading code is a critical skill that you're developing right now. It's rarely ...


4

"I have asked my coworkers this question and they said "a couple weeks." A COUPLE WEEKS TO LEARN A THOUSAND PLUS FILES, HUNDREDS OR THOUSANDS OF LINES LONG EACH???" You are panicking and your panic is making you irrational. Slow down, and take a few deep breaths. Nobody "learns" a large code base in a matter of weeks. In a very large project nobody ever ...


4

Looks like you are completely borked with that lack of branching. At the very least you should be developing on a Dev branch and merging completed code onto Main when your code is working and 'releasable'. This would stop the stupidity of reverting committed work if you failed to meet your deadline and re-committing it afterward. The days of using VSS are ...


4

The most important rule I have found for making it easier for new developers to understand a codebase is perfect agreement is expensive. If new developers must perfectly understand the system they are working on, it prevents all opportunities for on the job learning. I think the programmer's notes are an excellent start, but I would go further. Try to ...


3

Most overwhelming systems, in my experience, have at least a few key parts that seem scariest. I pick one and try to understand just that one. Knowing that key part makes it easier to understand its related parts. My favorite approach to doing this is to use a sequence diagram. To me, a sequence diagram provides me with the picture I need to understand how ...


3

I do all my programming in vim. I actually find it easier than any IDE I've used. You can have multiple files open at the same time, even on the same screen (look up tabs and windows). I'm usually working in X, so I have several (6) xterm screens open: one for c files in vim (several in tabs), another for headers in vim (also tabs), and non-vim windows: ...



Only top voted, non community-wiki answers of a minimum length are eligible