Single Responsibility Principle too much or no?

Have you ever heard of the Single Responsibility Principle? What does it sound like when it comes to mind? To me it kind of sounds like an object is tasked to do one thing.

In Jon Reid’s “Single responsibility Principle: Is it a fundamental mistake?”, he talks about the different problems that arises when applying the SRP. He starts off explaining that in order to apply the principle, we must keep subdividing until the class cannot be subdivided any further. That task sounds like a nightmare right? It gets worse. He goes on talking about classes and an important concept called “Cohesion”. Simply put, cohesion expresses how closely related parts of your code are with one another. For example the more each method uses the same instance variable the more cohesive the class is therefore that class must be narrowed down according to Reid. There is a such thing however as extracting too much from classes but he doesn’t really go into detail describing when you know you’ve narrowed down too far he only states you’ll know when you’re there which doesn’t help much.

I thought this blog was sort of confusing because he didn’t go into detail about how to not make the mistake about breaking down your code too far; I guess he just wants us to learn through trial and error which makes sense over time. I don’t think I will try to change my way of coding because the way he described SRP kind of made me want to sway away from the idea. There just seems to be too much room for error in my opinion. Yes I agree it is good to narrow down your code but you do run into the problems he mentioned.

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

B3: Behavior-Driven Development

https://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Model-Based Testing

This week’s blog is going to be about “The challenges and benefits of model-based testing” by Greg Sypolt.  In this blog, Greg talked about what model-based testing(MBT) is, how it works, how model-based testing differ from other kinds of testing, the challenges that are faced when using model-based testing, and the benefits of using it. Model-based testing is a kind of test where test cases are automatically generated from models. It focuses on the models based on the system requirements or specifications. The model-based testing works by generating tests automatically from models created by the software developers and testers, then it runs assertions for both generation of tests and execution, and reports the testing results. Model-based testing is different because it is more in the software development process than a scripting task. It focuses more on building a testable application and creating models based on user’s perspectives.  There are many challenges to address before you can use model-based testing to its full benefits. Software developers and testers have to be trained on model-based testing. The tool has to be scalable and be able to handle complex models and provide a reliable test coverage. Fine-tuning the MBT tool could also be challenging. However, it will offset the long-term goal of reduction of test maintenance. Test coverage is guaranteed and there is zero test suite maintenance.

I think this blog post is very helpful in introducing model-based testing. It is fairly brief but still shows you the idea behind model-based testing. This blog post is really interesting since model-based testing is a move away from the traditional testing. Instead of having a set of particular tests with defined test objectives and deliverables that should be achieved, model-based testing is done from models and not from the source code. A thought-provoking section of the blog for me is where he talked about the challenges of model-based testing. Greg said that model-based testing requires a shift in mindset and culture in how to develop and test applications. It made me think of how different it really is from the traditional way of testing. Learning about model-based testing changed the way I think about software testing since it is an approach that I haven’t really seen before. Now, I wonder in the future, what else kind of testing we are going to come up with.

From the blog CS@Worcester – Computer Science by csrenz and used with permission of the author. All other rights reserved by the author.

TheCurrentStateOf, SD 01110

CS SERIES (4)As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.

The information collected on programming languages was interesting to me as Javascript, Java, and Python are the top three current primary programming languages for those companies. On top of that, Go is used around 6% and of the companies who are considering using another programming language in the next 12 months, Go is the second on that list. I like seeing this data to know what is currently popular and may be an upcoming popular language as this is constantly changing. Novoseltseva points out how about 37% “of respondents said they’re not planning to use any new programming languages in the coming 12 months” and it makes me wonder whether it is because they do not want to change their ways or if they are already so on top of the updates that they do not need to for now. It also makes me wonder how companies in the New England region are doing in terms of exploring new languages or ways to keep up to date on their projects.

Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.

Article: https://apiumhub.com/tech-blog-barcelona/interesting-facts-software-development/

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

Behavior-Driven Development

What is Behavior-Driven Development you ask? To know that you must know what Test-Driven Development (TDD for short) is first. Keeping it short, TDD is a software development methodology that states for each unit of software, the developer must:

  • Add a test
  • Run all tests, see if one fails
  • Write code
  • Run test to implement code again
  • Refactor code to past test
  • Repeat

Knowing what TDD is, Behavior-Driven Development is merely an extension of TDD that makes more specific choices; meaning it focuses on specifying behavior and how the user wants the application to behave.

In Clemens Helm’s blog about Behavior Driven Development, he talks about the initial steps of BDD which starts off with the piece of functionality that is most important to the user; in other words we should develop software by centering our users. The purpose of this is so that developers know where to start and are on the same page in the development process of the project.

Some advantages I see from BDD is that it helps shift the focus to the expected end result and functionality of the program between the developers, QA, project managers, and business team. I found this particularly interesting because I always thought that communication was the utmost important part when it comes to creating anything as a team but I guess in a real work environment that is not always the case. I see that is what we’re learning to do in our Software Quality Assurance and Testing class; working as a team with different roles and I believe this is a very good skill to develop. I think that I will most likely try to incorporate this in the way I work with others in the near future.

 

Share your thoughts in the comments below! ?

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Software Development Trends

Today I read an article titled “Software Development Trends in 2018 That Will Dominate in 2019” This was a very interesting article that talks about the current trends involved in software development and how they will continue to be a force to be reckoned with in 2019. The article talks about 5 different trends that will be huge in 2019: Artificial Intelligence (AI), Progressive Web Apps, Blockchain Technology, Cybersecurity, and Low-code Development.

I chose to write about this article because I already knew that AI is one of the biggest current trends in software development, but I thought it would be interesting to read up on other trends in the world of software development. This article did not disappoint as I was able to learn more about Blockchain technology. I personally never heard of that before reading this article. I read that it was being used in the medical field, and it was being applied to the medical data in order to store it safely within a network. This appealed to me because my sister, and mother both work in the medical field, and I am sure that this could be useful in their line of work.

Although, I knew that AI was going to continue to be a huge trend in Software Development, I learned that AI will be used by “more than 40% of the organizations to automate their business in 2019” (Williams).

This article didn’t elaborate on low-code development too much unfortunately, but basically, it allows developers to build software without much expertise in coding. This part actually brings up an intriguing thought. While it does help people without expertise code more, could this be a bad thing for other developers? If everyone is given the opportunity to easily learn code, will that possibly take away opportunities from the extremely hard working developers? I don’t believe that will actually happen because the software development field is constantly evolving, so those with expertise in the field will continue to thrive.

Cybersecurity was the last trend that will continue into 2019, and I do feel like this is a given. The article mentions that 18% of companies did report at least one security incident in 2018. This is still an alarming number because some companies have a lot of important information that shouldn’t be leaked or taken. The trend that will continue is that these companies will look for Cybersecurity developers and thus, better programs will constantly be developed to virtually guarantee complete protection for any company’s data.

 

Article: https://medium.com/@Jessicawlm/software-development-trends-in-2018-that-will-dominate-2019-db1a1681c84d

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The two ways of testing

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

 

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

The Importance of Names

I’ve heard a lot of great things about “Clean Code” by Robert “Uncle Bob” Martin, and when I saw that the Coding Blocks Podcast had done a small series reflecting on the material of the book, I jumped right in.

Clean Code (although I haven’t read it yet) is a book that aims to set a standard in software craftsmanship, so that code isn’t lost as a result of being difficult to reuse, refactor, or even… well, read. The podcast reflected on Chapter 2 of the book, Meaningful Names. Allen Underwood and Michael Outlaw discussed major points that the chapter touched on and their personal experiences with each.

The segment that may have had the most impact on my outlook towards this subject was one of the first ones in the podcast — that the names of variables and methods should be as descriptive as possible, so that you don’t necessarily need to write a comment that explains what it does. This seems self explanatory, but I’ve already caught myself feeling compelled to comment every variable I declare in order to explain the differences between nondescript declarations like numDays and dayNum. Even if it’s just a small personal project, getting in the habit of writing effective variable names is a practice to start sooner rather than later.

They made another great point later on during the show too — Don’t be afraid of long variable/method names! So far in my educational experience, I don’t think I’ve needed to bother with a program that was more than ~500 lines total. In this case, it’s pretty easy to scroll to find what you’re looking for in each class. However when you’re dealing with a full software program, having a variable name that is easily searchable can save an enormous amount of time.

Certain topics touched on, like the “Hungarian Method” for example, I was completely unfamiliar with. I think standards like that may have been more niche or were perhaps prevalent before my time writing code. I agreed with what they said about it in the podcast, and I think the idea of a common naming convention is a good one however having code that is clear and easily readable is a better alternative.

This series of podcasts were really good, so I’ll likely be writing about it a lot more in the near future. There was a whole lot more that they went over, and it definitely made me interested in reading this book.

Here‘s a link to the episode on their website, check it out!

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

Blog 2 CS 443

My blog this week is based upon this article in which the author explores “shift left testing” which is simply a fancy way of testing earliest in the production of a program as possible. In this article the author goes into detail about several different forms of shift left testing, all of which try to push the testing earlier into the development of a program. The author also reviews why the common practice of testing late in production phase has been a major harm to system and software testing.

I found it interesting that the testing phase is often left so late in the development, with some major consequences pointed out by the author. One of these consequences the author highlights about this method is that it often results in “wasted time”. This can happen because “Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.” This article also focuses on what I feel is a much better approach to the development in which each part of the original “V-model” of production is broken into separate “V-models”. This means that for every part of the production phase, whether it be design, coding, fabrication, it is accompanied by a testing phase. This does require more time in the production but will ultimately produce a better program with fewer to no faults. I believe employing this strategy in one’s own personal work would be a very smart idea. This can be done for example while creating a program yourself, with every part of the program you write, you test it to make sure it is correct. This will help by the end of the program when you could generally have several mistakes causing errors throughout the program. One final thing the author points out which I believe could be relevant to those not employing this method is that late testing can lead to missed deadlines, whether it be for a company or for a student working on a project.

From the blog CS@Worcester – James' Blog by jdenesha and used with permission of the author. All other rights reserved by the author.

Blog 2 CS 343

My blog this week is based on this article which talks about the author philosophy behind debugging and how people often fail to debug properly. One of the first things the author talks about is how it is important to once presented with a program to debug, the best thing to do is know and admit that you do not know the answer immediately to whatever problem there is. He says this to follow up with the importance of gathering the information about the problem that will help much more then just simply trying to “guess” a solution. One other important point that the author made in this article is that most programmers tend to try to find a “bandage” for the bug they are presented with. The author believes if someone debugs a program properly “you’ve actually caused some part of the system to go away, become simpler, have better design, etc. as part of your fix”.
I personally found the authors advice of trying to understand the problem further before even attempting to create a fix to be very helpful. Looking at how I’ve done things in the past I know that I would often simply try different things to come to a fix for a problem. One way the author suggests to help fix this is to gather data about the bug until you fully understand the cause of the bug in the first place. You can do this by trying to recreate the bug for yourself to see the cause of the issue, or try referring to the way a proper program should behave. Another point I took away from this article was that when you are debugging something you should be eliminating code to make the program simpler and better in design. Often times you can think the proper way to fix a problem is to add something to the code to handle whatever problem is occurring, when you should rather be making the code simpler to begin with. I feel this is a very smart way to code/debug because anytime you can make the code of a program simpler, yet act in the same way, is good for both other programmers to look at in the future and for the users of the program itself.

From the blog CS@Worcester – James' Blog by jdenesha and used with permission of the author. All other rights reserved by the author.