MUGOYA DIHFAHSIH

This article aims to give a  solid  explanation of SOLID Principles and give some insight on their benefits and potential issues when applying them. Let’s go through each of them briefly. S — Single Responsibility Principle(S.R.P) A class should have one, and only one, reason to change. When requirements change, this implies that the code has to undergo some reconstruction, meaning that the classes have to be modified. The more responsibilities a class has, the more change requests it will get, and the harder those changes will be to implement. The responsibilities of a class are coupled to each-other, as changes in one of the responsibilities may result in additional changes in order for the other responsibilities to be handled properly by that class. What is a responsibility?! A responsibility can be defined as a reason for change. Whenever we think that some part of our code is potentially a responsibility, we should consider separating it from the class. Let’s say we

6: Recognize and Retain Your Top Talent Too many software development books concentrate on technology or management practices. At the end of the day, a lot of your success in software development will come down to who you have working for you and how happy they are in their work. You can have the best technology and organize your team in the best way possible, but if you have the wrong team it won't do you much good. Another surprise, given the effort so many organizations put into recruiting talent, is their failure to recognize and  retain  that talent after they join the organization. Organizations that are successful at retaining their top talent start by recognizing their top talent. Plenty of metrics can be gathered around a developer's productivity and quality. Don't forget, however, the more subjective criteria summarized in Table 3. Who are the developers who always show up at other code reviews and make constructive comments? Who is known as the "go to