Search Results

Search found 289 results on 12 pages for 'maintainability'.

Page 1/12 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Can decoupling hurt maintainability in certain situations?

    - by Ceiling Gecko
    Can the fact that the business logic is mapped to interfaces instead of implementations actually hinder the maintenance of the application in certain situations? A naive example with the Java's Hibernate framework would be, that for example (provided I don't have the whole code-base in my head, the project structure is a mess and classes are named with arbitrary names) if I wish to see what's going on in a certain DAO, to see if it actually is doing what it's supposed to do, then instead of traversing backwards up the tree from the point where the data service is invoked (where the tree will end in an interface with no implementation details whatsoever apart from the signature) I have to for example go and look for a configuration XML file to see which class is mapped to said interface as the implementation before being able to access the actual implementation details. Are there any situations where having loose coupling can actually hurt maintainability?

    Read the article

  • Visual Studio Code Metrics and the Maintainability index of switch case

    - by pee2002
    Hi there! As a person who loves to follow the best practices, If i run code metrics (right click on project name in solution explorer and select "Calculate Code Metrics" - Visual Studio 2010) on: public static string GetFormFactor(int number) { string formFactor = string.Empty; switch (number) { case 1: formFactor = "Other"; break; case 2: formFactor = "SIP"; break; case 3: formFactor = "DIP"; break; case 4: formFactor = "ZIP"; break; case 5: formFactor = "SOJ"; break; } return formFactor; } It Gives me a Maintainability index of 61 (of course this is insignificant if you have only this, but if you use an utility like class whos philosophy is doing stuff like that, your utility class will have the maintainability index much worst..) Whats the solution for this?

    Read the article

  • Assessing Relative Maintainability

    - by João Bragança
    We (a contractor, actually) are implementing an off the shelf system to replace a legacy homegrown system for the core domain of the company (designing widgets). Unfortunately both systems will have to run concurrently for some time, as the product just isn't ready yet. Also, the decision was made to only migrate some of the widgets from the legacy system, based on date of last sale activity. Later on a new requirement came down: certain people in the company, most of them outside of the widget development context, want to search all widgets. The search results screen has 3 pieces of data: a GUID, a human readable id that is searchable, and a brief description (may need to be searchable in the future). In the widget details, there will be multiple screens. These screens align very well along SOA / bounded context lines - a screen for marketing data, a screen for sales history, etc. UML ahead! I am probably using the wrong kind of arrows here so please forgive me. The current solution - which is not in production yet - is something like the following: Both systems will be queried and the controller will merge the results. The new system has its own proprietary query language (we've alleviated this a bit with a LINQ provider). It also puts a lot of data on the wire. 15 search results typically run about 60k of unintelligible SOAP-wrapped xml. So I would prefer to avoid querying this system directly. These two systems publish events to help us integrate with other systems, mainly an ERP system. One of these events contains all the data necessary for the search screen. I proposed the following alternative: However I am being told that 'adding another database' will create more maintenance down the road. However, I believe this to be false, as I had to add a relatively simple feature that took several hours longer than anticipated because of this merging code. I want to get a feel for which system is more maintainable in the long run. I personally have not had the burden of maintaining any large system. I want something more than my gut. Specifically I'd like to know if having more, specialized physical databases is more or less maintainable than having less larger physical databases.

    Read the article

  • How is technical debt best measured? What metric(s) are most useful?

    - by throp
    If I wanted to help a customer understand the degree of technical debt in his application, what would be the best metric to use? I've stumbled across Erik Doernenburg's code toxicity, and also Sonar's technical debt plugin, but was wondering what others exist. Ideally, I'd like to say "system A has a score of 100 whereas system B has a score of 50, so system A will most likely be more difficult to maintain than system B". Obviously, I understand that boiling down a complex concepts like "technical debt" or "maintainability" into a single number might be misleading or inaccurate (in some cases), however I need a simple way to convey the to a customer (who is not hands-on in the code) roughly how much technical debt is built into their system (relative to other systems), for the goal of building a case for refactoring/unit tests/etc. Again, I'm looking for one single number/graph/visualization, and not a comprehensive list of violations (e.g. CheckStyle, PMD, etc.).

    Read the article

  • Does the use of mongodb it easier to extend/change database driven applications?

    - by developer10214
    When an application is created which need to store data, an SQL database is used very often. So did I in a lot of asp.net applications. The resulting applications have often an ORM like the entity framework and maybe a business layer. So when such an application needs to be extended(let's say you have to add a comment property to an object), you have to change/extend the database, then the ORM and the business layer and so on. To deploy the changes you have to update the target database and the application. I know that things like code first and fluent can make this approach easier. I tried mongodb, I only used the standard driver and I had to extend some objects and all I had to do was changing the code. So it feels that such approaches are much easier to realize when using mongodb. I don't have much experience with larger applications an mongodb. I know that a SQL database or mongodb doesn't fit for all needs and both have their pros and cons. I want to know if my feeling is right, if yes I would choose rather choose mongodb than SQL database.

    Read the article

  • Are CK Metrics still considered useful? Is there an open source tool to help?

    - by DeveloperDon
    Chidamber & Kemerer proposed several metrics for object oriented code. Among them, depth of inheritance tree, weighted number of methods, number of member functions, number of children, and coupling between objects. Using a base of code, they tried to correlated these metrics to the defect density and maintenance effort using covariant analysis. Are these metrics actionable in projects? Perhaps they can guide refactoring. For example weighted number of methods might show which God classes needed to be broken into more cohesive classes that address a single concern. Is there approach superseded by a better method, and is there a tool that can identify problem code, particularly in moderately large project being handed off to a new developer or team?

    Read the article

  • How would you know if you've written readable and easily maintainable code?

    - by KyelJmD
    How would one know if the code he has created is easily maintainable and readable? Of course in your point of view (the one who actually wrote the code) your code is readable and maintainable, but we should be true to ourselves here. How would we know if we've written pretty messy and unmaintainable code? Are there any constructs or guidelines to know if we have developed a messy piece of software?

    Read the article

  • Is it ok to replace optimized code with readable code?

    - by Coder
    Sometimes you run into a situation where you have to extend/improve an existing code. You see that the old code is very lean, but it's also difficult to extend, and takes time to read. Is it a good idea to replace it with modern code? Some time ago I liked the lean approach, but now, it seems to me that it's better to sacrifice a lot of optimizations in favor of higher abstractions, better interfaces and more readable, extendable code. The compilers seem to be getting better as well, so things like struct abc = {} are silently turned into memsets, shared_ptrs are pretty much producing the same code as raw pointer twiddling, templates are working super good because they produce super lean code, and so on. But still, sometimes you see stack based arrays and old C functions with some obscure logic, and usually they are not on the critical path. Is it good idea to change such code if you have to touch a small piece of it either way?

    Read the article

  • Using lookahead assertions in regular expressions

    - by Greg Jackson
    I use regular expressions on a daily basis, as my daily work is 90% in Perl (legacy codebase, but that's a different issue). Despite this, I still find lookahead and lookbehind to be terribly confusing and often unreadable. Right now, if I were to get a code review with a lookahead or lookbehind, I would immediately send it back to see if the problem can be solved by using multiple regular expressions or a different approach. The following are the main reasons I tend not to like them: They can be terribly unreadable. Lookahead assertions, for example, start from the beginning of the string no matter where they are placed. That, among other things, can cause some very "interesting" and non-obvious behaviors. It used to be the case that many languages didn't support lookahead/lookbehind (or supported them as "experimental features"). This isn't the case quite as much, but there's still always the question as to how well it's supported. Quite frankly, they feel like a dirty hack. Regexps often already are, but they can also be quite elegant, and have gained widespread acceptance. I've gotten by without any need for them at all... sometimes I think that they're extraneous. Now, I'll freely admit that especially the last two reasons aren't really good ones, but I felt that I should enumerate what goes through my mind when I see one. I'm more than willing to change my mind about them, but I feel that they violate some of my core tenets of programming, including: Code should be as readable as possible without sacrificing functionality -- this may include doing something in a less efficient, but clearer was as long as the difference is negligible or unimportant to the application as a whole. Code should be maintainable -- if another programmer comes along to fix my code, non-obvious behavior can hide bugs or make functional code appear buggy (see readability) "The right tool for the right job" -- I'm sure you can come up with contrived examples that could use lookahead, but I've never come across something that really needs them in my real-world development work. Is there anything that they're really the best tool for, as opposed to, say, multiple regexps (or, alternatively, are they the best tool for most cases they're used for today). My question is this: Is it good practice to use lookahead/lookbehind in regular expressions, or are they simply a hack that have found their way into modern production code? I'd be perfectly happy to be convinced that I'm wrong about this, and simple examples are useful for examples or illustration, but by themselves, won't be enough to convince me.

    Read the article

  • Does the use of mongodb enhance extending/changing database driven applications?

    - by developer10214
    When an application is created which need to store data, an SQL database is used very often. So did I in a lot of asp.net applications. The resulting applications have often an ORM like the entity framework and maybe a business layer. So when such an application needs to be extended(let's say you have to add a comment property to an object), you have to change/extend the database, then the ORM and the business layer and so on. To deploy the changes you have to update the target database and the application. I know that things like code first and fluent can make this approach easier. I tried mongodb, I only used the standard driver and I had to extend some objects and all I had to do was changing the code. So it feels that such approaches are much easier to realize when using mongodb. I don't have much experience with larger applications an mongodb. I know that a SQL database or mongodb doesn't fit for all needs and both have their pros and cons. I want to know if my feeling is right, if yes I would choose rather choose mongodb than SQL database.

    Read the article

  • Which is more maintainable -- boolean assignment via if/else or boolean expression?

    - by Bret Walker
    Which would be considered more maintainable? if (a == b) c = true; else c = false; or c = (a == b); I've tried looking in Code Complete, but can't find an answer. I think the first is more readable (you can literally read it out loud), which I also think makes it more maintainable. The second one certainly makes more sense and reduces code, but I'm not sure it's as maintainable for C# developers (I'd expect to see this idiom more in, for example, Python).

    Read the article

  • How to have a maintainable and manageable Javascript code base

    - by dade
    I am starting a new job soon as a frontend developer. The App I would be working on is 100% Javascript on the client side. all the server returns is an index page that loads all the Javascript files needed by the app. Now here is the problem: The whole of the application is built around having functions wrapped to different namespaces. And from what I see, a simple function like rendering the HTML of a page can be accomplished by having a call to 2 or more functions across different namespace... My initial thought was "this does not feel like the perfect solution" and I can just envisage a lot of issues with maintaining the code and extending it down the line. Now I would soon start working on taking the project forward and would like to have suggestions on good case practices when it comes to writing and managing a relatively large amount of javascript code.

    Read the article

  • What can I do to make sure my code gets maintained in a developer light environment?

    - by asjohnson
    I am a contract data analyst, so I bounce between jobs every 3-6 months, which I find to be a good fit for me, but it leads to some problems when it comes to coding. I mostly do statistics (I've asked a similar question on cross validated, but the answers there are not relevant here), but I have also found out that the business world loves excel and loves copying and pasting the same thing over and over again even more. This led me to learn how to write VBA scripts and then VB.NET programs to automate as many of these reports as I can. I am certain my programs are not the most elegant, but I put a good bit of effort into making sure they work under as many cases as I can test, I add in exceptions and try to code so the program can handle changes in the files that it processes, but there is a limit, if you remove a huge portion of the data, there is a good chance my program is going to trip up, which I accept will inevitably happen. Usually a pretty minor change in the code fixes the problem and I do try and comment my code and make it readable under the assumption that some other person will have to read it some day. My problem is that I generally get put on teams of folks with essentially no experience with programming (like VBA would be a huge stretch for anyone I work directly with). I am wondering what I should be doing as the person that wrote the code to do my best to keep it maintained. I have two approaches in mind (outlined next), but would be very happy to get any advice. Solution 1: Find the more tech savvy coworkers and run them through the programs and what basic changes can be made. Honestly automating excel is about as easy as it can get when it comes to programming, so I feel like I could teach someone the basics of maintaining it pretty quick. Solution 2: Get in touch with the IT department and show them what is going on and maybe they will be able to help. The problem here is that the IT department is constantly swamped (as I'm sure many of you know) and I feel like kind of a jerk for dumping more things on them. I do leave my personal email address with places and am willing to answer quick questions via email, but I view the need for more exhaustive maintenance as something of an inevitability and would like to make sure I do my due diligence to make sure it gets done. I imagine some combination of the two approaches outlined there, but is there any kind of heads up I should give IT? I feel like I would be annoyed if I started getting requests to fix a program that I had never seen from some random guy that is no longer there.

    Read the article

  • Which is the most practical way to add functionality to this piece of code?

    - by Adam Arold
    I'm writing an open source library which handles hexagonal grids. It mainly revolves around the HexagonalGrid and the Hexagon class. There is a HexagonalGridBuilder class which builds the grid which contains Hexagon objects. What I'm trying to achieve is to enable the user to add arbitrary data to each Hexagon. The interface looks like this: public interface Hexagon extends Serializable { // ... other methods not important in this context <T> void setSatelliteData(T data); <T> T getSatelliteData(); } So far so good. I'm writing another class however named HexagonalGridCalculator which adds some fancy pieces of computation to the library like calculating the shortest path between two Hexagons or calculating the line of sight around a Hexagon. My problem is that for those I need the user to supply some data for the Hexagon objects like the cost of passing through a Hexagon, or a boolean flag indicating whether the object is transparent/passable or not. My question is how should I implement this? My first idea was to write an interface like this: public interface HexagonData { void setTransparent(boolean isTransparent); void setPassable(boolean isPassable); void setPassageCost(int cost); } and make the user implement it but then it came to my mind that if I add any other functionality later all code will break for those who are using the old interface. So my next idea is to add annotations like @PassageCost, @IsTransparent and @IsPassable which can be added to fields and when I'm doing the computation I can look for the annotations in the satelliteData supplied by the user. This looks flexible enough if I take into account the possibility of later changes but it uses reflection. I have no benchmark of the costs of using annotations so I'm a bit in the dark here. I think that in 90-95% of the cases the efficiency is not important since most users wont't use a grid where this is significant but I can imagine someone trying to create a grid with a size of 5.000.000.000 X 5.000.000.000. So which path should I start walking on? Or are there some better alternatives? Note: These ideas are not implemented yet so I did not pay too much attention to good names.

    Read the article

  • Is it a bad idea to list every function/method argument on a new line and why?

    - by dgnball
    I work with someone who, every time they call a function they put the arguments on a new line e.g. aFunction( byte1, short1, int1, int2, int3, int4, int5 ) ; I find this very annoying as it means the code isn't very compact, so I have to scan up and down more to actually make any sense of the logic. I'm interested to know whether this is actually bad practice and if so, how can I persuade them not to do it?

    Read the article

  • Are flag variables an absolute evil?

    - by dukeofgaming
    I remember doing a couple of projects where I totally neglected using flags and ended up with better architecture/code; however, it is a common practice in other projects I work at, and when code grows and flags are added, IMHO code-spaghetti also grows. Would you say there are any cases where using flags is a good practice or even necessary?, or would you agree that using flags in code are... red flags and should be avoided/refactored; me, I just get by with doing functions/methods that check for states in real time instead. Edit: Not talking about compiler flags

    Read the article

  • Questions about identifying the components in MVC

    - by luiscubal
    I'm currently developing an client-server application in node.js, Express, mustache and MySQL. However, I believe this question should be mostly language and framework agnostic. This is the first time I'm doing a real MVC application and I'm having trouble deciding exactly what means each component. (I've done web applications that could perhaps be called MVC before, but I wouldn't confidently refer to them as such) I have a server.js that ties the whole application together. It does initialization of all other components (including the database connection, and what I think are the "models" and the "views"), receiving HTTP requests and deciding which "views" to use. Does this mean that my server.js file is the controller? Or am I mixing code that doesn't belong there? What components should I break the server.js file into? Some examples of code that's in the server.js file: var connection = mysql.createConnection({ host : 'localhost', user : 'root', password : 'sqlrevenge', database : 'blog' }); //... app.get("/login", function (req, res) { //Function handles a GET request for login forms if (process.env.NODE_ENV == 'DEVELOPMENT') { mu.clearCache(); } session.session_from_request(connection, req, function (err, session) { if (err) { console.log('index.js session error', err); session = null; } login_view.html(res, user_model, post_model, session, mu); //I named my view functions "html" for the case I might want to add other output types (such as a JSON API), or should I opt for completely separate views then? }); }); I have another file that belongs named session.js. It receives a cookies object, reads the stored data to decide if it's a valid user session or not. It also includes a function named login that does change the value of cookies. First, I thought it would be part of the controller, since it kind of dealt with user input and supplied data to the models. Then, I thought that maybe it was a model since it dealt with the application data/database and the data it supplies is used by views. Now, I'm even wondering if it could be considered a View, since it outputs data (cookies are part of HTTP headers, which are output)

    Read the article

  • How to keep a big and complex software product maintainable over the years?

    - by chrmue
    I have been working as a software developer for many years now. It has been my experience that projects get more complex and unmaintainable as more developers get involved in the development of the product. It seems that software at a certain stage of development has the tendency to get "hackier" and "hackier" especially when none of the team members that defined the architecture work at the company any more. I find it frustrating that a developer who has to change something has a hard time getting the big picture of the architecture. Therefore, there is a tendency to fix problems or make changes in a way that works against the original architecture. The result is code that gets more and more complex and even harder to understand. Is there any helpful advice on how to keep source code really maintainable over the years?

    Read the article

  • 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

  • Which approach is the most maintainable?

    - by 2rs2ts
    When creating a product which will inherently suffer from regression due to OS updates, which of these is the preferable approach when trying to reduce maintenance cost and the likelihood of needing refactoring, when considering the task of interpreting system state and settings for a lay user? Delegate the responsibility of interpreting the results of inspecting the system to the modules which perform these tasks, or, Separate the concerns of interpretation and inspection into two modules? The first obviously creates a blob in which a lot of code would be verbose, redundant, and hard to grok; the second creates a strong coupling in which the interpretation module essentially has to know what it expects from inspection routines and will have to adapt to changes to the OS just as much as the inspection will. I would normally choose the second option for the separation of concerns, foreseeing the possibility that inspection routines could be re-used, but a developer updating the product to deal with a new OS feature or something would have to not only write an inspection routine but also write an interpretation routine and link the two correctly - and it gets worse for a developer who has to change which inspection routines are used to get a certain system setting, or worse yet, has to fix an inspection routine which broke after an OS patch. I wonder, is it better to have to patch one package a lot or two packages, each somewhat less so?

    Read the article

  • Implementing new required feature after software release

    - by TiagoBrenck
    Fake Scenario There is a software that was released 1 year ago. The software is to map and register all kind of animals on our planet. When the software was released, the client only needed to know the scientific name of the animal, a flag if it is in risk of extinction and a scale of dangerous(that is a fake software and specification, I don't want to discuss this here). There are already 100.000 animals records saved on DB. New Feature One year later, the client wants a new feature. It is really important to him to know the animals classes, and this is a required field. So he asks me to put a field to input the animal class, and this field is required. Or maybe where this animal was discovered. Problem I have already 100.000 recorded animals without a class or where it was discovered, but I need to insert a new column to storage this information and this column can't be null. I don't have a default value for this situation (there isn't a default animal class or where it was discovered). I don't want to keep the requirement rule only on my software, my DB must have this requirement too(I like to keep business rules on DB too). What are the alternatives to solve this situation? I am on a situation that this new feature cannot be previewed or reviewed for the existing records. The time already passed and I can't go back on time to get it

    Read the article

  • Keep coding the wrong way to remain consistent? [closed]

    - by bwalk2895
    Possible Duplicate: Code maintenance: keeping a bad pattern when extending new code for being consistent, or not? To keep things simple let's say I am responsible for maintaining two applications, AwesomeApp and BadApp (I am responsible for more and no that is not their actual names). AwesomeApp is a greenfield project I have been working on with other members on my team. It was coded using all the fancy buzzwords, Multilayer, SOA, SOLID, TDD, and so on. It represents the direction we want to go as a team. BadApp is a application that has been around for a long time. The architecture suffers from many sins, namely everything is tightly coupled together and it is not uncommon to get a circular dependency error from the compiler, it is almost impossible to unit test, large classes, duplicate code, and so on. We have a plan to rewrite the application following the standards established by AwesomeApp, but that won't happen for a while. I have to go into BadApp and fix a bug, but after spending months coding what I consider correctly, I really don't want do continue perpetuate bad coding practices. However, the way AwesomeApp is coded is vastly different from the way BadApp is coded. I fear implementing the "correct" way would cause confusion for other developers who have to maintain the application. Question: Is it better to keep coding the wrong way to remain consistent with the rest of the code in the application (knowing it will be replaced) or is it better to code the right way with an understanding it could cause confusion because it is so much different? To give you an example. There is a large class (1000+ lines) with several functions. One of the functions is to calculate a date based on an enumerated value. Currently the function handles all the various calculations. The function relies on no other functionality within the class. It is self contained. I want to break the function into smaller functions (at the very least) and put them into their own classes and hide those classes behind an interface (at the most) and use the factory pattern to instantiate the date classes. If I just broke it out into smaller functions within the class it would follow the existing coding standard. The extra steps are to start following some of the SOLID principles.

    Read the article

  • Eliminating Magic Numbers: When is it time to say "No"?

    - by oosterwal
    We're all aware that magic numbers (hard-coded values) can wreak havoc in your program, especially when it's time to modify a section of code that has no comments, but where do you draw the line? For instance, if you have a function that calculates the number of seconds between two days, do you replace seconds = num_days * 24 * 60 * 60 with seconds = num_days * HOURS_PER_DAY * MINUTES_PER_HOUR * SECONDS_PER_MINUTE At what point do you decide that it is completely obvious what the hard-coded value means and leave it alone?

    Read the article

  • Futures/Monads vs Events

    - by c69
    So, the question is quite simple: in an application framework, when performance impact can be ignored (10-20 events per second at max), what is more maintainable and flexible to use as a preferred medium for communication between modules - Events or Futures/Promices/Monads ? Its often being said, that Events (pub/sub, mediator) allow loose-coupling and thus - more maintainable app... My experience deny this: once you have more that 20+ events - debugging becomes hard, and so is refactoring - because it is very hard to see: who, when and why uses what. Promices (i'm coding in javascript) are much uglier and dumber, than Events. But: you can clearly see connections between function calls, so application logic becomes more straight-forward. What i'm afraid. though, is that Promices will bring more hard-coupling with them... p.s: the answer does not have to be based on JS, experience from other functional languages is much welcome.

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >