Hey guys warmly welcome to the blog,this is my very first post so first of all I will tell you some points which will makes you professional in IT field.it's not as easy as you heard or as you seen.it fills with lots of hard working and dedication.i hope following tips will actually guide you.
Language. This is what someone will typically know coming out of University, or after having taken certifications in a programming language. It consists of knowing the core library classes/functions of the language(s) concerned, as well as techniques for exception handling, reflection, concurrency, and so on. Note that superficial knowledge is not enough here - to write a language well, or code review other people's work, you need to know and understand all the features that are available out of the box.
Language skills. Once you know a language, you must then learn how to use it. This involves stylistic aspects - the way you structure, format and document code. It also involves technical aspects - how to use concurrency safely, pessimistic rather than optimistic programming, how to instrument code to permit analysis/debugging, the different forms of collection object and their uses, proper management of loading/binding, and so on.
Design patterns. Since the late 1980s it has become accepted practice to utilize standard abstraction techniques when writing code, mainly for maintainability but also for code quality and productivity. The key reference here is the "Gang of Four" book ("Design Patterns: Elements of Reusable Object-Oriented Software" by Gamma, Helm, Johnson and Vlissides), which uses C++ and Smalltalk for its examples. The GoF book has inspired a decade of further research. A professional programmer must know not only the 23 design patterns from the GoF book but also many additions to and enhancements of these patterns. They will also understand when and how to use each pattern, and how to refactor code - to restructure it to conform more (or less) closely to specific patterns, or just to improve its elegance and readability, without changing its functionality. As well as for programming, there are also design patterns for enterprise application architecture - the key reference here being Martin Fowler's book, "Patterns of Enterprise Application Architecture"
Frameworks. No-one now writes enterprise applications without using an abundance of frameworks - code libraries that embody best-of-breed solutions to common technical problems. Frameworks are based on design patterns, and you cannot properly understand how to use frameworks unless you first gain confidence with application of design patterns. Many frameworks are open source and can be used to build a product intended for commercial sale. Frameworks often have associated domain-specific languages such as XMI (XML Metadata Interchange) and OCL (Object Constraint Language). The productivity advantages of using a framework are enormous, since you may be drawing on hundreds of man-years of previous effort. For example, the HumanEdj framework for human work draws on research going back to the 1980s, and allows you to build collaborative applications in minutes that would otherwise be beyond most development budgets.
Standards. Any software going into a corporate environment must interact with other software in a standardized way. Hence such applications need to conform not only to accepted standards but also to emerging standards. For instance, any Java-based application that talks to a content management system must be aware of JSR-170 and JSR-283, which are standards for communicating with such a system via the Java language. There are many important standards pertaining to application development, some like the above arising from a language-specific community, and others (such as Topic Maps for XML documentation of linked content, or DocBook for technical documentation) from non-language-specific bodies such as ISO and W3C.
Work Management. Any professional developer should have some grasp of the various possible approaches to managing a software project, ranging from traditional waterfall techniques through to the many different agile methods and techniques. There are also design patterns for work management - the key references here are "Organizational Patterns of Agile Software Development" by Coplien and Harrison and my own book "Human Interactions". I will have a lot more to say about this in future postings, since agile techniques are key to the successful management of outsourced application development - whether or not the project is officially viewed as being "agile".
Take Away. The first step towards successful outsourced application development is to make sure you know what is going on. This means that your own staff must be able to understand technical matters at least as well as your outsourcing supplier. To achieve this, you must ensure that your organization possesses people with skills at all the levels described above. Some of these people will have only skills to a certain level - but you will need at least some people who have all the skills right up to level 6. The number of such people required depends on the size of your organization and the number of outsourcing projects you have going on.This is the first step towards outsourcing success and the most crucial. In my own consultancy work, I provide clients proposing to engage in an outsourcing project with a learning trail that their key technical staff should follow, customized to the particular type of project they are considering. If their people are familiar with the material already, all well and good. If not, acquiring this knowledge not only prepares them for the project in question, but is a valuable contribution to their organization's general capability - a contribution that will stand the organization in good stead in future (as well as, of course, being useful professional development for the individuals in question).Only once your organization has developed such an in-house capability are you in a position to code review the work that is done on your behalf, as well as to engage with your supplier as to how the work is being carried out. In the next postings to this series I will discuss how to position yourself so that such engagement is not only painless, but viewed as beneficial by both sides.
No comments:
Post a Comment