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
When you are rapid prototyping for features should you really worry about code quality & optimization?.
Looking back at the number of times a "prototype" ended up becoming the product, the answer would be yes.
Don't forget that you are not only prototyping the feature, you are also prototyping the design.
Yes to quality. No to optimization. This question should be community wiki.
I would focus on clarity.
If quality and optimisation are requirements for the prototype then yes. If not, then no. Just because you are doing rapid prototyping you don't abandon standard operating procedures like programming to a specification, using source code control, testing, etc. It is, perhaps, relatively unusual for high performance to be a requirement for a rapidly developed prototype, but that's another matter.
Yes. Focus on quality, clarity and simplicity AND comments to explain what its doing and why (don't bother with the how, unless its really complicated, that is what the code is for).
Just about all work we do here starts out as a what if? And if it works we continue with it.
We write comments that describe what should happen, before we write the code, then write the code to match the comments. Writing the comments first forces you to think about how you will structure it all. We've found that it prevents a lot of FALSE assumptions and actually makes development faster.
It also makes reusing this when you come back to it so much easier - you don't need to read the code and understand it, just read the comments. Don't go for the nonesense of self-documenting code, all that does is self-document the bugs, you've got nothing to check to see if the code matches the comments/documentation at all.
You can worry about optimization later - see this description of a huge win I got by changing from MFC CMaps to STL when working on a hobby project parsing some Apache log files. This was done after I had the initial concept working and only when it became apparent there was a problem with performance.
Related
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 6 years ago.
Improve this question
I'm working in company with a big system with a messy code structure. I want to work with the right standards like polymorphism and design patterns.
But the code is such a mess and needs to be heavily refactored to do that. Also my current company gives me tasks, and if I have would heavily refactor, that will open many bugs in the system as it's not unit tested, of course.
What do you think? Should I work on the tasks on this bad structure to finish the work? Or tell them that we need rebuild many things (also they won't find a difference as the features already work now).
I think you need to start off with some unit tests.
Whilst doing the tasks you have been assigned, you could write some tests to test the code you are about to change, then you can refactor it.
Now you can start to write the code for your task, test-first.
If the code that is already there works, then refactoring is the best option. If it doesn't work, then a rewrite becomes possible.
Well...you need to work on multiple aspects.
First, learn best practices to write clean code (if you haven't yet) and request your team members the same. There are many useful books and online resources available for the same.
Second, do not expect that the situation will change overnight. Adopt "Boy scout rule" - it will gradually improve the code quality.
Third, start building your corpus of unit tests. Slowly, testable code will emerge out of the sea of untestable monolith.
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 8 years ago.
Improve this question
I hope this is not a vague/broad/subjective question. If it is, please close it.
Anyway, at several programming competitions (like Google's Code Jam, Facebook's Hacker Cup and so on), by the time I've successfully understood a problem and have an inkling of how to approach it, I see that half the questions are already solved by many people.
My question is, how do these people get so good? Is it pure genius? Is it experience? Is it the ability to think really fast? How would you suggest I improve my skills? I would say I'm a competent programmer. I can eventually solve some of those questions.
Additionally, whenever I inspect the code of winners, I see a LOT of macros being used. This implies to me that they sort of have a template (like #define for loops to some abbreviated version) which they use to program faster. Does this make a significant difference?
The thing is, you're competing against people who've spent massive amounts of time mastering their skill to compete in these competitions. You're unlikely to catch up any time soon, but...
How do these people get so good?
Have the theoretical knowledge to solve the problems and practice, practice, practice.
Is it pure genius?
It can be, but practice can to a reasonable extent make up for it.
Is it experience?
Yes.
Is it the ability to think really fast?
Not really. Practice allows you to approach the problem correctly and skip insignificant details in the problem statement.
How would you suggest I improve my skills?
Get the theoretical knowledge and practice.
Do macros make a significant difference?
It may cut 10% off of your time, but probably not much more.
Statistically speaking, any programming competition with a large enough audience will attract super-talents who can churn out nice and elegant code at super-speed. It's like running the marathon. Running it in 4 hours is really good, even if the world record is around 2 hours. Don't worry about it.
Focus on code quality and elegance instead, instead of being able to churn out code at super-speed. Practise, have fun, and don't look too much at how fast other people are working.
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
Over the years, I've discovered that green-programmers tend to read the comments rather than the code to debug issues.
Does having one person document the other person's code (and vice-versa) with the code writer's approval increase code quality in the long term?
Is this a good idea?
aside: I'm looking for middle-ground between solo programming and pair programming in terms of budgeting.
People tend to look for the easiest solution to a problem. If there's an "human" description available, it's likely to be utilized before the reader delves into esoteric code. IOW, the comments will often be considered first, regardless of how green the programmer happens to be.
Comments should maintained as well as possible. Unfortunately, they can easily become stale (because they cannot be validated by the compiler). Therefore, they should be kept to a reasonable minimum, because, ultimately, the code itself is the only real comment that can be trusted.
As for who should write the comments, it depends at what level the comments are being written. For example, at higher levels the comments should describe the outside behavior of a module, and could be written by a larger group of people. Internally, however, the comments should explain the intent of the various chunks of code. That way, its easier for the reader to glean the mannerisms of the code. Those comments should be written by the coder.
I've found that "pair programming" works best when one person writes the code and the other one writes unit tests (working side by side so they can see what each other is doing). You can swap the roles around occasionally too.
You run a higher risk of misinterpreting algorithms if the original author does not document the code. In my opinion, the only thing more frustrating than inadequately documented code is incorrectly documented code.
You may wish to try this approach:
Perform code reviews with a developer that was not involved in the programming effort.
Have the review performed without the physical presence of the code's author. Just the reviewer, a copy of the code from source control, and written documentation.
If the reviewer can not reasonably understand the code without outside assistance, it is not adequately documented and should be given back to the author.
Repeat as necessary.
I find it works best when the helper does the broad scope thinking (i.e. What are we trying to accomplish) and the keyboard cowboy does the detail scope thinking. I don't think comments have anything to do with it.
I tend to write comment first and code immediately after that or at times or at times side by side. By the time I end up writing my comment the code becomes very clear in my mind (thanx to the fact of verbalizing my ideas while writing the comment). I don't like to comment the code which I haven't written. And whenever I come back to revise the code, first read the original comments, then think of new comments, write them and write the code side by side.
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
Robert C. Martin offers in the fist chapter of his book 'Clean Code' several definitions of 'clean code' from differen well known software experts. How do you define clean code?
Easy to understand.
Easy to modify.
Easy to test.
Works correctly (Kent Beck's suggestion - very right).
These are the things that are important to me.
Code I'm not afraid to modify.
Code that doesn't require any comments to be easily understood.
Code which reads as close to a human language as possible. I mean it on all the levels: from syntax used, naming convention and alignment all the way to algorithms used, quality of comments and complexity of distribution of code between modules.
Simplest example for naming convention:
if (filename.contains("blah"))
versus
if (S_OK == strFN.find(0, "blah"))
Part of it depends on the environment/APIs used, but most of it is of course the responsibility of the developer
Point-free Haskell code. (Not really, though.)
Code in which the different modules or classes have clearly defined contracts, is a good start.
Code which doesn't break in multiple places when you make a single, seemingly insignificant change. It is also easy to follow the control path of the program.
Reusable code is also important. So not only important is the quality of the code, but where do you put.
Example, business logic into a Controller is a useless code
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'm working on a project that's been accepted as a proof of concept and is now on the schedule as an actual production project. I'm curious how others approach this transition.
I've heard from various sources that when a project starts as a proof of concept it's often a good idea to trash all of the code written during that rapidly-evolving phase and essentially to start over with a clean slate, relying on what you learned from the conceptual phase but without working to clean up the potentially messy code that you wrote the first time around. Kind of the programming version of "throw away the first copy of that angry email you're about to send and start all over" theory.
I've done it this was in the past and I've also refactored the conceptual code to use in production, but since I'm in the transition phase for a new project I wanted to get an idea how others do this. Obviously a lot depends on the project itself, and on the conceptual code (if what you generated works but won't scale for example, it's probably best to start afresh, but if you have a very compressed timeline for the project you might be forced to build on what you've already written).
That said, if all things were equal what would you all choose as an approach?
As you already kind of hinted at, the answer is, "It Depends"
Starting over is good because you can help trim out the stuff that was added while you were initially working out the kinks but isn't really needed.
It also gives you a chance to give more consideration to how you want the architecture to be -- without already being dependent on how the proof-of-concept was written...
In practice, though, unless you're in the business of selling the software to the outside world, building upon the prototype is pretty commonplace. Just don't get into the habit of thinking "I'll fix it later" if you run into some code that smells or seems like it could be done in a better way...
Refactor the existing code into the solution.
For me it would depend on how sloppy my POC was. If it is something I would be ashamed to pass onto another developer, I would rewrite it. Otherwise, just go with what you got.
If the code works, use it. Spend a little bit of time refactoring the messiest parts in order to ease future maintenance. But don't fall into the trap of building a new system from scratch.
Throw away everything from the proof of concept except for the lessons learned, and, possibly, some minor code fragments such as calculations etc.
Proof of concept applications should never be more than just the bare minimum to see if the technology in question will work and to start testing some of the boundary conditions.
Once done you are free to redesign the application with your new found knowledge.