Search Results

Search found 2 results on 1 pages for 'gordonm'.

Page 1/1 | 1 

  • What to do when you inherit an unmaintainable codebase?

    - by GordonM
    I'm currently working at a company with 2 other PHP developers aside from me, and 1 junior developer. The senior developer who originally built the system we're all working on has resigned and will only be here for a matter of weeks. The other developer, who is the only other guy who knows anything about the system, is unhappy here and is looking for a new job. I'm very real danger of being left behind as the only experienced developer on this codebase. Since I've joined this company I've tried to push for better coding standards, project documentation, etc and I do think I've made some headway, but the vast majority of the code is simply unmaintainable and uncommented. A lot of this has to do with the need to get things done fast at points in the project before I joined, but now the technical debt is enormous, even with the two developers who do understand the system on board. Without them, it will simply be impossible to do anything with it. The senior developer is working on trying to at least comment all his code before he leaves but I think the codebase is simply too vast to properly document in the remaining time. Besides, when he does comment it still doesn't make things as clear as it could. If the system was better organized and documented I could probably start refactoring it incrementally, but the whole thing is so tightly coupled that it's very difficult to make any changes in one module without having unintended knock-on effects in other modules. Naturally, there's no unit tests either, and I honestly don't think this codebase could possibly be unit tested anyway given how it's implemented. There also never seems to be enough time to get things done even with 3 developers and 1 junior developer. With one developer and one junior, neither of which had significant input into the early design of the system, I don't see how we could possibly get anything done with keeping the current system working, implementing new features as needed and developing a replacement for the current codebase that is better organized. Is there an approach I can take to cope with this situation, or should I be getting my own CV in order as well at this point? If it was just me and the junior designer who would be left I'd go for the latter option almost without question. However, there's a team of front-end developers and content managers as well, and I'm worried what would become of them if I left and put them in a position where there would be no developers at all. The department might just be closed down altogether under such circumstances, and then I'd have their unemployment on my conscience as well!

    Read the article

  • Namespace constants and use as

    - by GordonM
    I'm having some problems with using constants from a namespace. If I define the constant and try to use as it, PHP seems unable to find it. For example, in my file with the constants I have code along the lines of the following: namespace \my\namespace\for\constants; const DS = DIRECTORY_SEPARATOR; Then in the consuming file I have: namespace \some\other\namespace; use \my\namespace\for\constants\DS as DS; echo (realpath (DS . 'usr' . DS 'local')); However, instead of echoing '/usr/local' as expected I get the following notice and an empty string. Notice: Use of undefined constant DS - assumed 'DS' If I change the code as follows: use \my\namespace\for\constants as cns; echo (realpath (cns\DS . 'usr' . cns\DS 'local')); I get the expected result, but it's obviously quite a bit less convenient than just being able to pull the constants in directly. You can alias a class/interface/trait in a namespace, are you not able to alias a constant too? If you can do it, then how?

    Read the article

1