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
Are having APIs for the sake of QA testing a good or bad idea?
We're developing an application from scratch and we've been creating backdoor APIs to ease the jobs for the QAs. These backdoors do things many things like change the date of the server to emulate progression of time etc. I'm quite mixed on this. The number of these backdoors almost rival the real APIs that'll be used in Production.
Is this the recommended approach? The obvious benefit for this is that it makes the lives of the QA must easier. I can see many disadvantages with this also like maintaining the functionality of these test APIs, ensuring that these backdoor APIs are not exposed in production.
If others have used this approach, what are some good means to ensure that these APIs aren't exposed in production?
For those who are against this approach, are there alternatives to making the work for QA easier?
Thanks
If it's not causing QA to miss issues, it's a good thing to do; if you can make their job easier without costs in the future, do it.
However, normally anytime you test one API but use another API, you're not actually testing the real API that's going into production. If QA has a hack around the normal API, they should also be testing the difference between the hack and the real world.
In this case, it sounds like they have helper methods to modify the state, to enable testing. If there's not a good way to do this otherwise, what they're doing might be pretty darn reasonable... or, at the very least, there may be better ways to spend your time improving things.
But overall; is it regularly (repeatedly) causing them to miss bugs they should have caught?
What build system are you using?
For any software that has any time/scheduling logic, I think it's pretty essential to add a class called SystemClock with a method called 'currentTime().'
In our Android project, we inject the starting time from a Gradle variable, and then we can be sure that there is no way the code can get into production with shifted time (because the variable is defined for the debug build only).
For our iOS release, we were able to use an Extension. That's really a great way to do it because it's only compiled into the test scope. Then it replaces the getCurrentTime method with the shifted one.
The other option you have in the Java world is Aspects. They can be handy for doing mixins in a test build that are not there in production.
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
First of all, I love Python, and I currently use it for most stuff. However, as a PhD student, I mostly implement prototypes for testing and evaluating ideas. This also includes that I'm usually the only one coding, and that -- while I certainly try to write half-way efficient code -- performance is not a primary issue. And for quick prototyping, Python is for me just neat.
Now I consider to go with some of my stuff more "serious", i.e., to bring it into a productive environment, make it better maintainable, and maybe more efficient. So I wonder if it's worthy to rewrite my code to, say, Java (with which I'm also reasonably familiar). I know that Python is not slow, but things like Java's static typing including seems to make it less prone to errors on a larger scale, particularly when different people work on the same project.
It's only worth it if it solves a real problem, note, that problem could be
I want to learn something better
I need it to go faster to reduce power requirements in my colo.
I need to hire more people and the talent pool for [insert language here]
is too small.
Insert innumerable real problems here.
Python and Java are both suitable for production. Write it in whatever makes it easiest to solve the problems you and or your team are facing and if you want to preempt some problems make sure you've done your homework. Plenty of projects have died because they chose C/C++ believing performance was going to be a major factor without thinking about the extra effort involved in using these language well.
You mentioned maintainability. You're likely to require more code to rewrite it in Java and there's a direct correlation between Bugs and LOC. It's up for debate which one is easier to maintain. I'm sure both camps believe theirs is.
Of the two which one do you enjoy coding with the most?
The crucial question is this one: "Java's static typing including seems to make it less prone to errors on a larger scale". The crucial word here is "seems." Sure, Java will help you catch this one particular type of error. But how important is that, and what do you have to pay for it? The overhead imposed by Java's type system means that you have to write more lines of code, which means reduced productivity. I've used both and I have no doubt that I'm more productive in Python. I have found that type-related bugs in Python are generally easy to find and fix. Keep in mind that in a professional environment you're not going to ship code without testing it pretty carefully. The bottom line for a programming environment is productivity - usable functionality per unit of effort, not the number of bugs you found and fixed during development.
My advice: if you have a working project written in Python, don't rewrite it unless you're certain there's a benefit.
Java is inherently object oriented. Alternatively python is procedural.
As far as the ability of the language to handle large projects you can make do with either.
As far as producing more usable products I would recommend java script as opposed to java because of its viability in the browser. By embedding your js in a publicly hosted website you allow people with no coding knowledge to run your project seamlessly in the browser.
Further more all the GUI design features of HTML are available at your disposal.
That said any language has it's ups and downs and anything I've said here is simply my perception.
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 am going to develop a (relatively) simple game for the Android platform.
It's gonna be 2D-Game (no heavy stuff, maybe simple animations)
I am considering using a framework (like AndEngine)
What are the advantages/disadvantages of using a framework? (rather than developing from scratch)
Thanks!
Well this can be a broad subject, nonetheless I'll toss in my 2 cents.
There are plenty of advantages using a framework and this applies to many other scenarios. Just think of a framework as a bridge to shorten the path and not have to reinvent the wheel.
A framework will pretty much handle the boring plumbing you would have to do otherwise.
Using a framework will, in most cases, make you code faster and some will probably «force» you to code in a cleaner and more organized fashion. Although this has much more to do with the programmer itself...but there are opinionated frameworks out there that will at least lead you the way.
The biggest disadvantage is not using a framework in itself, but picking the right framework. I think you have to make a few questions before deciding to pick Framework A, B or C such as : Is it sufficientlly mature for my needs? Does it have a good community or vendor support? Is it here to stay? What happens if the framework loses pace or support? Will I be in trouble?
There are other disadvantages of course. You may be putting yourself open to the risk of learning the Framework and neglecting the language behind it. For example, you may know jQuery but it's not liquid that you know javascript. See where I'm going?
Also, you can find yourself shackled by the framework limits. You may not be able to have full control of the code you write or at least not be able to express your code better because the framework it self has tight bounds. In other words, you are forced to respect its limits and work the way it is required. Again, pick the right framework for your needs.
I hope this helped.
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
in private and in companies it is over and over again a problem that I or we developers comment in fact our code but generally nobody knows exactly how the code of the whole project works together. When I write my own code and the project is getting bigger I sometimes have this problem too. Although I write tons of comments, after 3 months you don't know what the whole thing exactly does, that means how the different methods and classes work together.
How do you solve this in your company or in private (if there is just marginal project development and no requirements specification). Or do you have always such a good project development with contract document and requirements specification that you don't have to worry about that?
Code complete can explain the solution to your problem better than I ever could.
I find the best way to solve this is to write a functional test using a unit test framework.
In a functional test you write a test which loads up several if not all the core components laid bare. This shows that all the components work correctly together but also you get a documents which shows you in one place how everything connects.
Depending on how complex you interactions are, you may not be enough and you need to document it. Personally I would prefer to make the code simple so that documenting it is not really needed or is relatively easy to explain.
If documenting it sounds too hard, its time to refactor your code so that its not.
Take your time a create some short and simple design documents, add some UML diagrams to just show the basic ideas behind the whole application. This would give new team players a quick overview. Publish this documentation on an internal wiki and encourage the team to enhance, if necessary.
Then, as Peter suggested, some well documented test cases really help: Read the test code and learn how to use the API. (and, as a secondary effect, test the code ;-) )
I would not put too much effort on comments, especially on line comments. The tend to become out dated, because no unit test verifies that line comments are still valid and, even worth, no one ever deletes unnecessary comments.
Good question. Part of what you are asking relates to code maintainability. In my view the two main things you can do to improve this are:-
Write some design documentation
Develop maintainable and clearly written code
From past experience the first item is very often neglected on software projects due to time constraints, but I think that if you can produce at least a class diagram of your system, then this is worth a lot in terms of understanding how objects interract when you revisit the code in a few months. Depending on the complexity, then sequence diagrams can also be useful. Producing this documentation will also be of benefit to new members of the team, in quickly having an overview of how the software is structured.
I can't stress enough the importance of writing clear and maintainable code. My eyes were recently opened when I read Clean Code by Robert Martin. You owe it to yourself and your fellow developers to read at least the first couple of chapters in this book. That alone will immediately improve the readability and maintainability of your code.
The idea is that the code should read almost like a narrative, where methods follow in a logical order, are short, appropriately named, and take few parameters. Doing this almost eliminates the need for code comments, and improves the code structure.
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 2 years ago.
Improve this question
We are a start-up, with a few (14) clients using our products. These products were developed in a closed source web development framework only maintained by one developer on the core.
Basically the framework server is required to be able to run any application built in it. So there is no code, in our layer of the application. Think of it as a CMS that allow us to develop in a proprietary language of the framework server itself.
This framework is built on Java, and is closed source. It has a layer of plugins that need to use a proprietary IDE to build them.
There is at this moment only 3 total developers in the company mother of this framework, one that is able to code on the framework itself, and 2 that are able to code on the IDE to build plugins. We are the only company holding paying the salaries of 2 of the 3 developers, the 3rd is the owner.
At this moment we don't know if there is documentation for the framework level.
We know there is no documentation for the plugin layer.
The ONLY reason keeping us developing in this framework is that we already have invested in it, and changing will cost us.
I am in the middle technology management, and I have been advising my IT Director/President of some changes, but apparently I am not getting through. I am advising to start developing new components in another framework (ASP.NET MVC, Symfony, SPRING MVC) with our own team of developers, and this components to integrate 100% with our old application, until we get comfortable to a point of porting the old applications from the old framework to the new one.
Either way there could be many variations of this plan. Any advice from knowledge of SO.
As an alternate question:
Why would you build a business on a close web development framework that only has one developer and no documentation?
Last Comment:
I think that probably Bruce is right. My upper management team is more concern about continuing to sell and support our current product than to the risk that constituted continuing with it. Probably when we grow from 14 clients to 30 clients they will see the lack of scalability that we own, and take some other actions but for now. I think this battle is all done until 2011. Thanks for your input.
Scrap it and migrate as fast as you can because you're only throwing good money after bad. This is what is known as the Sunk Cost Fallacy
Management in a small company is concerned about staying in business and satisfying customers. If the current architecture is supporting that, then the managers will be happy and resistant to change. If business is shaky, they may not have the resources (cash) to support investing in the time and tools for developing a new framework.
If the business is doing well enough to support investing resources in the new framework, it is up to you to make the case that the Return on Investment (ROI) will be worth the investment. They can then decide if they have enough time and cash to pay for the change.
The cases for changing would be:
Measurably improved development efficiency.
Measurably improved quality.
Noticeably increased functionality.
Risks associated with staying with the current platform.
From what you've said, the major road block to changing software is that the owner developed your current undocumented code.
Focus on bringing the owner on board with you. Once the owner votes for changing to new code, you'll be able to get something done, until then you're probably stuck with band-aids.
Looking at the current development on the market, the only reason is a bad strategy.
You may try to open the product on a dual-license base, but if there is no documentation, it is unlikely that developers from outside will jump on it (although maybe the IDE could help a little bit at that end).
Stipulating the change could be based on a risk vs. opportunities assessment.
From the scenario you describe, I think that a central factor to be considered seriously is Human Resources:
What happens if people come and leave?
How likely can growth be handled?
Also seriously consider the knowledge part of the picture: as an organization you need to manage a better equilibrium between tacit and explicit knowledge.
Maybe try to determine the barriers for change (individual and organizational) i.e.:
ability (can, to be aware of),
readiness for change (want, should),
shared reality,
system thinking
analyze them and integrate results to support a more informed decision making process.
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 7 years ago.
Improve this question
We are developing a Java EE application backed by any database of customer choice.
We will sell to customers based on per user license price. How do I make sure, the application is getting used as per our conditions, i.e., not easily hackable? Are there any tutorials available?
Bill Karwin's answer was the most useful of the answers from the question mentioned in the comments. Assuming that you will go ahead with a "protection" scheme, try to do the bare minimum. Anything else tends to frustrate users immensely and leads to lower repeat business and/or an increased desire to hack around your frustrating system.
From your question, it's tough to tell if each user will install the application. If so, you probably just need to require a license code that they must contact you in some way to get. If it's a client-server thing, then your options are a lot more limited; in fact, I can't think of a single solution I've ever designed in my head or come across in practice that isn't massively frustrating. You could probably do a license code solution here, too, except the license code would somehow carry a payload that indicated the number of users they paid for and then disallow the creation/use of users in excess of that number. At that point, though, you're really walking that frustration line I mentioned.
If you can obfuscate - this is the way to go for a start. But it could be painful if you use inversion of control frameworks (e.g. spring). I heard that it's possible to obfuscate spring context as well, never tried it though. Also (just guessing) there could be some surprises with reflections, dynamic proxies and such. As to the licensing, I can suggest using TrueLicense. It has very flexible means of handling various aspects of protection as well as free trial periods out of the box. Works very well and has great documentation.
Do clients pay for support of this application? If so, there is a chance that support is a bigger pay-off than the licensing of the application itself. If so, you may consider not locking down the application, but rather, choosing to only provide support for authentic copies of the software (unmodified copies proved via checksums and the such). Many businesses licensing this software would be more inclined to avoid any modifications (even though the chance of them wanting to actually do this is probably tiny) in order to not jeopardize their support.
FYI: This is how Oracle tends to operate with their e-Business Suite. You can modify pretty much any component you want. Good luck on getting support, though!
Look at how Atlassian sells their products. I believe this is an approach that works very well, and probably would for you too. Note: There should be added value in subscribing to updates!