Am 09.11.2010 19:08, schrieb Grant: >>> "Theoretically, a modularized software project will be more easily >>> assembled by large teams, since no team members are creating the whole >>> system, or even need to know about the system as a whole. They can >>> focus just on the assigned smaller task." >>> >>> http://en.wikipedia.org/wiki/Modular_programming >>> >>> I don't mind system administration but I don't want to be a programmer >>> any more. I'd like to hire programmers to work in the manner >>> described above. They would each work on modules and not know about >>> the system as a whole. How can something like this be implemented? >> >> Okay, so this has nothing to do with obfuscation, not trusting people, >> or protecting IP. This is normal software development. >> >> One would want to break a large application into manageable pieces. >> Usually, those pieces would be libraries (where the meaning of >> "library" depends on your programming language of choice: SOs, DLLs, >> JARs, etcetera). If your application is monolithic right now then you >> (and/or your developers) will have to spend some time modularizing it. >> >> So is your question really "how do I modularize my code"? > > I'm most interested in the part about developers not knowing about the > system as a whole. I'd like developers to work on my code, but > prevent them from selling the code or using it themselves. I thought > a good way to accomplish this might be to modularize heavily and > change variable names. >
Well, there are two ways to go here: 1. Modularize what you have. Give every developer only the source he is supposed to work on and binary interfaces (libs + header files for C/C++) and documentation for everything else. Then the devs will be able to run the software but no one will have all the source code. 2. Do not give working code to anyone. Define specs, test cases, prototypes and mock-ups. Then tell your devs to develop against these. When they have finished their modules (classes, units, whatever), it is your job to integrate these modules and see whether they work together as expected. If they don't, improve your specs and tests and give the code back to the devs for another iteration. I favor the second approach, especially as there are tools available to help you and it is safer against reverse-engineering. I repeat myself but: It would help a lot to know more about the project. What programming language? What basic structure? Object-oriented, procedural, distributed (sockets, web services, RPC, ...)? Hope this helps, Florian Philipp
signature.asc
Description: OpenPGP digital signature
