Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I've been holding off on releasing a library I wrote because it is the first library which I'll be releasing publicly. Here are my concerns:
The library isn't complete it is in a very usable state, I'd say it is version 0.3, however it still lacks a number of features which I would like to at some point implement, and control how they're implemented (meaning not merging someones implementation).
I'm fearful of criticism, I know there are a few things which should be reorganized/refactored, but I wrote the initial class quickly to be functional for another project I am working on.
So when is the best time to release? Should I just throw it up on github and work on the issues post-release? Or should I wait until I refactor and feel completely comfortable with what I have written?
Most classes/libraries I see are always very elegantly written, however I have not seen any in very early release stages, are a lot of classes fairly sloppy upon initial release?
Release early, release often.
Criticism is a good thing as long as its constructive. Ignore the haters, pay attention to the folks filing bug reports and commenting.
The internal structure of the code matters, but it matters more if it works for its intended purpose. In general, refactoring will change how code works internally but will not affect how it is used. Same inputs and outputs.
You need to get something half-way
useful first, and then others will say
"hey, that almost works for me", and
they'll get involved in the project.
Linus Torvalds
Linux Times (2004-10-25).
It depends on why you are doing this. If it's to provide something useful and it's useful and has benefits that no other library has, then go for it. Just list the status and what's coming next.
If you are doing this to point to on a resume, get it in good shape (the code, not necessarily feature complete). Imagine a future employer poking around the code to see what it looks like, not downloading and running the code.
Whether you release the code in an incomplete state or not, it's always worthwhile having enough documentation to allow users to understand how to use the library.... even if it's only API docs. Make sure that anything incomplete is tagged as TO DO - it helps to maintain a target list of tasks to complete, and lets users know that the feature/method/whatever hasn't been forgotten.
Providing a set of code style/standard documents (perhaps with architectural notes on class relationships) allows other developers to contribute more readily, and in a manner that enhances the library rather than making it a hotch-potch of spaghetti code. It's never easy releasing a library, then having to refactor, while maintaining backward compatibility for users who have already taken up and are using that library in a production setting.
EDIT
Don't be afraid of criticism... it goes with the territory.
Some critcism can be constructive (take heed of that).
There'll be plenty of other people who criticise your code (for whatever their reason) without being constructive, or who just denegrate your work. The difference is, you've produced the goods, they probably haven't ever contributed to any OS product/library.
Users expect you to fix their problems immediately, or to write their code for them to use your library, or simply say "it doesn't work" without any explanation of what they mean. You have to learn to live with that 24x7x365.
But just once in a while, somebody will thank you for saving them hours of work, or for providing something useful... and suddenly all the stress and hassle feels worthwhile.
I read a document by Joshua Bloch, a pricipal software engineer at Google that talked a lot about the best type of API design. Basically, once you release it, it is more or less set. He says
Public APIs are forever - one chance to get it right
You can check out the slides here. It's definitely worth reading. I have a PDF of it as well; let me know if you need it.
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'm working on an application and I needed an API wrapper for it. I noticed that most of the API calls I needed weren't implemented, so I went ahead with adding them in. There are a few bugs that need fixing which I'm planning to fix as well.
My problem is that development of the wrapper is almost non-existant at the moment. A bug submitted with a patch from October 2009 has been ignored so far.
I've emailed the main developer so I can commit my changes or even submit them somewhere, since on the homepage, it said that he's the person to contact with this sort of stuff. I've also asked about this on the discussion board, with no response.
My question is, how long should I wait for a response before forking this wrapper? It's one of only two open source wrappers for this API and listed on the API Doc's page. I hate to see that there's no improvements to it.
So, how long should I wait. What's normal for this kind of thing?
In case it matters: the licence is Simplified BSD
UPDATE:
The original developer finally responded; so I didn't end up forking. Apparently he was just very busy with work.
A good (relevant) article to read for anyone coming across this question: http://dashes.com/anil/2010/09/forking-is-a-feature.html
And thanks to everyone for your answers!
You can fork any time you want. Once I was in similar situation. As I had informed project admin that I'm going to fork, I obtained a response and it wasn't necessary :P
BTW I have written to sourceforge crew (project was hosted on sf) and that was their advice to fork.
Perhaps I am a little late but would like to answer on the level of definition.
The term Forking (branching away) refers to a split between groups and development in different directions. In this case a branching away can not clearly be seen so there was not actually a forking of a product. The action was clearly an alteration (extension) for a personal need. Should a product experience alterations and the result again be returned to the group it comes from is forking also not the proper definition. By definition open source encourages you to alter.
It depends if you plan to maintain your fork. If you do then the chances are it will become a better project than the original. Otherwise maybe wait a couple of weeks. Still, even if you released today there's nothing to stop the original project merging your changes so the community as a whole benefits either way.
There's no protocol, just call your fork something else and give the original prosjekt plenty of kudos for the original work.
Forks happen all the time, it's not necessarily a 'divorce' with the origial maintainers ... just happy coding.
Your additional calls might be usefull for someone else, but then again it might not.
Does the project has a publicly known mailing list/bug tracker, and if is - is it affordable to submit a patch there? Also, can't be a developer - become a maintainer at one of popular Linux distros, (submit a Gentoo bug/Launchpad entry).
If there's no sense in such actions - just fork.
Sounds like you've done the right thing though and tried to stay within the existing branch and now it is appropriate to fork.
If nothing else, forking is a more powerful action than most other things i.e. if you fork and still don't get the original developer's attention then you can be satisfied that you did the right thing. Of course once forked, there's no real reason why there can't be some convergence at a later stage.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Often there are situations where a project is passed on someone else. And often this process is unpleasant for both sides - the new owner complains about horrible documentation, bugs and bad design. The original owner is then bothered for months with questions about the project, requests to fix old bugs etc.
I might soon be in a situation where one of my projects will be given to someone else so I can focus on my other projects. I wonder what should I do to make this transfer as smooth as possible. What i already have is a decent documentation, the code is quite good commented and i'm still improving it. Its a medium sized project, not very large but still its not something you can code in a week.
I'm looking for a list of things that should be done in order to help the future owner taking over the project and at the same time will spare me all those annoying questions like "and what does this function do, what purpose does this class have...". I know documentation is a must - what else?
Note: although my project is in C++ i believe this is a language-agnostic question. If there are things you think are specific to some language, please mention them too.
Documentation is one thing, getting it into the head of your new project owner another. IMHO this is a typical situation where "less is more" - the less documentation your colleague has to read to understand something, the better. And, of course, learning takes time - for both of you, accept it.
So
instead of writing lots of documentation, make your code self-commentatory
have all documents / source code etc. in a clean and well named folder structure
make sure your build-process is almost completely automatic
don't forget to document your deployment process, if it is not automatic, too
clean-up, clean-up clean-up!
When taking over a project, documentation is of course desirable, but even more so is a good test suite. Trying to modify a program that you have no means of testing for correctness is a nightmare.
Documentation, but on all levels:
API docs
High level architecture: What components are there, what are their relationships and dependencies
For each component, a high level description pointing to important code sections
Tutorials: If you want to do X, here's how
Data: What data does it use and how, database schemas
Idioms: If you've created some idioms within your code, explain them
And, to start, give the guy a personal introduction to all of the above in person, hopefully doing some needed change in a pair programming way
the new owner complains about horrible documentation, bugs and bad design.
I suspect that no matter what you would do, new owner will always complain about something. People are different, so something that looks easy to understand for you, will look horrible and extremely complicated for someone else.
The original owner is then bothered for months with questions about the project, requests to fix old bugs etc.
In this case you should clearly refuse to help. If you won't refuse, you'll probably end up doing someone else's job for free. If maintaining the project is no longer your job, then the new guy should fix his problem without your help. If "the new guy" can't deal with that, he isn't suitable for the job and should quit.
Its a medium sized project,
"Medium sized" compared to what? How many lines or code, how many files, how many megabytes of code?
I wonder what should I do to make this transfer as smooth as possible. What i already have is a decent documentation, the code is quite good commented and i'm still improving it.
I would handle it like this:
First, do a sweep through the entire code and:
1.1 Remove all commented out blocks of code.
1.2 Remove all unused routines and classes (I'm talking about "forgotten" routines, not parts of utility library).
1.3 Make sure all code follow consistent formatting rules. I.e. you shouldn't mix class_a, ClassA and CClassA in same app, you shouldn't use different styles for putting brackets, etc.
1.4 Make sure that all names (class, variable, function) are self-explanatory. Your code should be as self-explaining as possible - this will save you from writing too much documentation.
1.5 In situations when there is a complicated or hard to understand function, write comments. Keep them as short as possible, and post only when they are absolutely necesarry.
1.6 Try to make sure that there are no known bugs left. If there are known bugs, document them and their behavior.
1.7 Remove garbage from project directories (files that are not used in project, etc.)
1.8 If possible, make sure that code still compiles and works as expected.
Generate html documentation with doxygen. Reveiw it few times, modify code comments a bit until you're satisfied. Or until you're somewhat satisfied with the result. Do not skip this step.
If there is a version control repository (say, git repository) with entire development history, hand it over to a new maintainer, or give him(her?) a functional copy of the repository. This will be useful for (git )bisecting and finding source of the bugs.
Once it is done, and code is transferred to a new maintainer, do not offer "free help", unless you're paid for it (or unless you get something else for helping, or unless it is order from your boss which makes helping new maintainer a part of your current task). Maintaining the code is no longer your job, and if new maintainer can't handle it, he isn't qualified for the job.
I think most of the problems can be avoided with just two simple rules.
Keep the code consistent with platform style guide.
Naming, naming and naming.
If the project is huge, then you just need to run some code camps with the new guys. There's no shortcut for this one.
Remember also that complaining happens mostly because new guy is not qualified enough, i.e. doesn't understand something. That's why it is important to keep things simple. And in case he is more qualified, then I guess you deserve it ;)
Some good advice where to start hacking/changing things is always better than documentation. Consider documentation as a backup material after you are familiar with the code, it should never be the starting point (except if you are exceptional technical writer with unlimited resources and time)
If there is good documentation and commented code as you say, then you've done your part. Just make sure that the documentation includes high-level documentation (architecture, data flow, etc.) as well as lower module or procedure-level documentation.
If this is a situation where you can, I would strongly suggest you protect yourself with some type of contract that specifies what future support (if any) you will provide and for how long.
I think for a situation like this the most important thing is a working, complete build that automatically compiles, documents, and tests the project. That way, there is a well defined point at which the new developer has it working. He can then figure stuff out from the tests and documentation, in principal.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
This may sound like a foolish question or an observation, but i have seen that most of the times when one tries to look at the opensource code, there are no comments or just one or two lines at the start of the function telling what the function is used for e.g. register a user or data in table etc. There is no code which actually explains what exactly the function is doing etc.
Is it done intentionally (removal of comments) when a code is released to open source community to make things difficult to understand by others?
There is a line of thought that says that comments are unnecessary when the code speaks for itself. I don't believe comments would be removed on purpose, though.
I've seen both sides, and frankly code in general is insufficiently documented.
I've been congratulated and thanked for leaving copious breadcrumbs but that's because I've had to sift through too much undocumented code to want to subject anyone else to it.
Call it an ethical obligation.
My reason to document code: my short-term memory is junk. I write comments to remind myself of why I did something. Everyone else benefiting from that is gravy.
I don't think there is a practice or policy to remove comments when releasing software as Open Source. A sneaky software publisher might think that a good idea (maintaining de facto exclusivity, because nobody can't understand it, while having released an open source product) but this would cripple the Open Source project from the start and most likely render it unusable.
The code you are talking about is probably just very little documented. As ocdecio says, that can be either a good sign (the code speaks for itself and does not need comments) or a bad one (it is badly documented, bad code). Both cases are entirely possible. :)
What are you comparing it to?
I doubt that closed-source code has better comments.
As for what functions do, there is probably API documentation. No need to duplicate those in comments.
As a rule, functions should be small enough and written in a way that allows working out how it works by just reading them. A comment on top of the function describing what it does helps getting a quick overview of the function itself when reading through the whole source code file (unless the function name speaks for itself).
Many projects are organized in that way, and that is great.
However, what I am often missing when trying find my way around a larger codebase is something describing the big picture, i.e. the general architecture, principles, what goes where and similar things.
All open source is not made the same. This is what we call a generalization.
If you look at the website Ohloh, which tracks a very large amount of the open source software in existence, it paints a much different picture:
http://www.ohloh.net/languages?query=&sort=code
For instance, in the C language, there are 252+ million lines of comments, approx 1 in every 5 lines of C is a comment. For Java, nearly 1 in 3 lines is a comment. That's not bad.
Open source software has bad comments and bad documentation most of the time. There are various reasons why, some better than others. Usually they relate to laziness or the developers 'being in the moment'. None of the reasons are good reasons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I write hobby code from time to time. The thing is these tools, classes or tiny libraries of code end up in a flash stick with hopeless future! I would love to develop my projects further, and let other programmers trust them. If you were going to use something you found on the Internet, what is the most important thing you look for in that programming tool or small library? e.g. would you consider separate documentation a must?
Thanks for all contributers. I'll try my best to summarized what have been said. Feel free to modify the list. Corrections and additions are more that welcome :)
Start a blog and let others know you
are here.
Choose the most
suitable license. Possibly Open
Source licenses are the best for
hobby projects.
Put your project where people can
reach it. Consider google-code,
github, sourceforge or
other sites.
Use public version-control and
bug-tracker, So others can acquire the
latest source code of your project to
compile and use.
Write a decent documentation, beside
commenting your code clearly of
course. The documentation should
explain the purpose of the library
and provide at least simple examples.
Write tests if you are willing to provide real-world code.
If you are building a library, put a
lot of effort into designing a stable
interface.
Get a blog, release code through it. Explain why you wrote it, what problem it solves. And encourage others to improve upon it, keep the code posted as current as possible. If your tools are useful you will very quickly develop a following that 'trusts' your code.
Separate documentation isn't a must for small tools, but anything creeping into the framework world should probably have ample documentation and examples if you want any serious adoption from the community at large.
The most important thing is that the library is that it be open source, so I can read the code myself. If that is not possible then I insist on documentation.
Also consider using a project-hosting site (like google code or github).
Have a clear license with your code if you don't have one already
(preferably one which encourages modifying / improving / sharing your
code ...)
Have public version control and/or a public bug/issue tracker and/or a mailing list. There are a lot of good sites which offer these services for free.
Seperate documentation is not a deciding factor to me (if the code is well documented and the code quality is high).
Documentation explaining why you wrote it, when you started it, and it's intended function. Understanding where you're coming from will allow me to see future ideas as well as short coming you may not have seen.
Technical documentation explaining the API and some examples on how to implement it. Ideally, keep your documentation in the format that follows the language. For example C# tends to use the XML syntax for defining items. This allows me to feel at home when I'm reading it.
Clean code -- I can't stress this enough because far too many people write exceptionally ugly code. If you're code is ugly and/or unreadable, it may be easier for me to write it from scratch on my own. At the very least, make your code consistent. If I can't understand the code, I won't feel comfortable with it.
Historical records explaining your changes. Seeing how the project has grown allows me to plan better. It also allows people to see how you learn from your mistakes and get a sense of your skill level. Compared to a forum, you can get a feel for how fast things get fixed and then placed in to a new release.
Think long and hard on what kind of license you want there. Public domain? BSD? GPL? More restrictive?
A note on whether or not you mind being contacted and if there are any restrictions in this. For example, would you mind updates? Me explaining security holes? Or perhaps you might use a forum or wiki?
The ability for me to get your latest work and/or nightly builds. SVN or something. This is useful so I know if a bug I found is already fixed.
I think that documentation is a key point for your project.
The document must indicate:
what is the purpose of your library
what are the main features
a really short tutorial, to make it run in 5 minutes.
Many examples
I let people trust my code in a number of projects, but I urge people to make and maintain their own tests, and I make sure that I'm content with the unit tests.
Documentation is always good, but I'm very guilty of finding time to do as much as I would like. But having the author fairly contactable is helpful.
Posting it in an open source repository such as code.google.com or sourceforge.net is probably where to start...
Next to attract attention, document clearly and succintly the purpose of the library / application as outline in one of the answer above.
Finally, blogging and direct mail exchanges happen...
One reason documentation helps people trust your code, is that they know whether a given feature is something which you intended the code to do (and which you will, all else being equal, preserve in future versions of the code), or something that the current code just so happens to do, but which might change at any time as a side-effect of a bugfix or just a refactor.
Some people prefer find out what code really does by looking at it, and that's fine, but documentation tells you (a) what the code is supposed to do, and with any luck (b) what the next version of the code will do. If I want to use your code long-term, and take bugfix updates as you provide them, then I need to know that you've designed an interface that I can rely on and that you're willing to stick to. Documenting it is a strong hint that you're at least trying to do that.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
How would you maintain the legacy applications that:
Has no unit tests have big methods
with a lot of duplicated logic have
have No separation of concern
have a lot of quick hacks and hard coded
strings
have Outdated and wrong
documentation
Requirements are not properly documented! This has actually resulted in disputes between the testers, developers and the clients in the past. Of course there are some non-functional requirements such as shouldn't be slow, don't clash and other business logics that are known to the application users. But beyond the most common-sense scenario and the most common-sense business workflow, there is little guidance on what should be ( or not) done.
???
You need the book Working Effectively with Legacy Code by Michael C. Feathers.
Write tests as soon as you can. Preferably against the requirements (if they exist). Start with functional tests. Refactor in small chunks. Anytime you touch code, leave it cleaner and better than when you started.
Two things.
Write unit tests as you have the chance.
Once you have enough unit tests to be confident, start refactoring.
The rate at which you accomplish this may be slow.... Typically, you're supposed to "just maintain it" not fix it.
During the "learning how to maintain it" phase, however, you can write a lot of unit tests.
Then, as bugs are found and enhancements requested, you can add yet more tests.
It's Agile, applied to legacy.
I have seen, worked and am working in a codebase which satisfies all the conditions that is mentioned in the question :-)
The approach followed in maintaining this codebase is NOT TO BREAK ANYTHING. FWIW, the code works and the end users are happy. No one is going to listen to the developer cries that there is duplication of code, hard coded strings etc. We just steal some time to fix whatever possible and take the utmost care to not introduce new bugs..
I think I would create a small set of Up To Date information: What Action calls which functions etc.
From there, I would look at refactoring. Duplicated Logic seems to be something that could be refactored, but remember that
That can be a huge task when you realize in how many many places that logic is called and
Two function that seem similar may have a tiny difference, i.e. a - instead of a +
I think the biggest urge to resist is "Just rebuild the whole damn thing!" and get an overview of the system first, to demystify the beast.
sudo rm -rf /
But more seriously, I think it has to be evaluated. If the code continually is a source of requests for change and the changes are difficult then before long you have to consider if it is worth it to try and refactor/re-engineer the system into something more modern. Of course this isn't always practical, so you often end up with just a few people on the team who are responsible for maintaining the legacy parts. As much as possible, everyone on the team should be able to maintain all parts of the system......
One more thing that I think is important is to track the amount of time and effort that a team spends working on a legacy system doing maintenance/feature requests. These metrics can be convincing when evaluating the planning of a new effort to replace the legacy systems/components.
I basically agree with everything Paul C said. I'm not a TDD priest, but anytime you're touching a legacy codebase -- especially one with which you're not intimately familiar -- you need to have a solid way to retest and make sure you've followed Hippocrates: First, do no harm. Testing, good unit and regression tests in particular, are about the only way to make that play.
I highly recommend picking up a copy of Reversing: Secrets of Reverse Engineering Software if it's a codebase with which you're unfamiliar. Although this book goes to great depths that are outside your current needs (and mine, for that matter), it taught me a great deal about how to safely and sanely work with someone else's code.