How to approach the study of the new SDK / API / library?

Question

Let's say that you need to implement some functions that are not trivial (it will take at least 1 working week). You have an SDK / API / library containing (numerous) code examples demonstrating the use of part of the SDK to implement this functionality.

As you approach the study of all samples, extract the necessary information, methods, etc., to use them to implement the "real thing". Key issues are:

• Do you use any tool for flow control diagrams, interactions between functions from the SDK and the sample itself? What schemes do you find useful? (I thought that a UML sequence diagram could be quite useful with a debugger in this case).

• How do you save relevant and often interconnected information about calls to the SDK / API functions, the general structure and order of calls in sample programs that should be used as reference mind cards, some simple text notes, comments are added to the sample code, some refactoring of the sample code in accordance with your personal coding style to facilitate learning?

Answer 1

Personally, I use the prototyping method. Keep development in manageable iterations. In the beginning, these iterations are really small. As part of this, don't be afraid to throw away the code and start over (every time I say that somewhere the project manager has a heart attack).

If your specific task cannot be easily or reasonably divided into really small start-up tasks, then start with some kind of replacement until you move on.

You want to keep it as simple as possible (the notorious “hello world”) to familiarize yourself with creating, deploying, debugging, error messages, simple things that might not match at the beginning, etc.

I don’t think about how to use the chart tool, sorry (I almost see no point in my work).

As soon as you start trying something, you will get it, even if at first you do not know what is happening and why what you are doing works (or not).

Answer 2

I usually compile and modify examples, which makes them suitable for what I need to do myself. I try to do this when using and annotating relevant documents. Being a little old school, the tool that I usually use for diagrams is a pencil, or for really complex material, two or more colored pens.

Answer 3

I am in no way an experienced programmer. In fact, I learn C ++, and I learn this language mainly from books. When I try to stray from books (which happens very often because I want to start participating in programs like LibreOffice), for example, I get lost. In addition, when I use the functionality of the library, my implementations are wrong because I really do not understand how the library was created and / or why everything should be done this way. When I look at a sample source code, I see how something is done, but I don’t understand why it was done in such a way that leads to poor design of my programs. And as a result, I constantly wonder how to do something and deal with mistakes when I meet them. Very unproductive and unpleasant.

Returning to my book commentary, two books that I’m ready to cover more than once from cover to cover are Ivor Horton Beginning of Visual C ++ 2010 and Starting with C ++: Early Objects (7th Edition). What I really loved in Ivor Horton's book is that it contained a detailed explanation of why something needs to be done in a certain way. For example, before starting Windows programming, a lot of explanation was given at first about how Windows works. Understanding how and why everything works in a certain way really helps in software development.

So, to contribute your two pennies in answer to your question. I believe the best approach is to put together well-written books and sit down and start learning about this library, API, SDK, regardless of the structured approach that offers real-world examples, as well as explanations of how and why they are implemented the way they are there is.

I don’t know if I completely missed your question, but I don’t think I did.

Hooray!

This was my first post on this site. Don't tear me up too much. (