2020 November CodeRefinery HackMD, day 6

tags: workshop


Do you use continuous integration (or any form of automated testing) for your work? If so, to which degree?

How is this online workshop format working for you? What are the differences against following our materials individually?

Feedback / suggestions from yesterday

Automated testing

Exercise until XX:50


“Pre-commit hook” exercise is optional (otherwise it’s left as “homework”).

Break until xx:08

After break we will do this next exercise:

Exercise until xx:40


Note that the repository that we create should be public.

Modular code development

Starting questions:

  1. What does “modular code development” mean for you?

    • Develop code in ‘batches’, that can be tested independently, and also fixed independently.
    • Splitting problems into smaller parts that are “attacked” separately.
    • Having an abstraction of your system, knowing what your data looks like and then creating modules to process and display such data for several stakeholders
    • Break code into self-contained components as much as possible, develop and test individually, make parts re-usable in various combinations (not necessarily foreseen in advance)
    • Don’t know what it means.+1
  2. What best practices can you recommend to arrive at well structured, modular code in your favourite programming language?

    • Try to sketch or explain the structure within the documentation so that others know / understand the modules and how they connect to each other
    • Use pure functions +1
    • Know your system/program/information/project. Apply architecture patterns and software patterns and organize your data model.
    • Design the structure to functionally independent components, use object-oriented programming as much as possible
    • Think about input and output for each function (if the function takes too many inputs and the output is unclear that might be a hint that it’s not modular enough…)
    • Start by designing the API. Ensure that the API is reusable/abstract, meaning that it (the functionality it encapsulates) can be used for general cases. Make your actual use case a particular one that can be addressed with the functionality accessible from the API.
    • Discuss with others!
  3. What do you know now about programming that you wish somebody told you earlier?

    • There is never enough documentation!
      • In my opinion there is, sometimes, e.g. when it is incorrect, outdated, or too verbose/distractive of the main point. Good code/naming also can substitute (some sort of) comments. Also a good desing can save documentation. The point is that yes, documentation is essential, but there are cases when it is better to not to document (as those stated above) and concentrate on a good coding style/structure.
    • Strong typing helps a lot for debugging
    • Testing and documentation!
    • That it’s more fun to programme together with other!
    • I now know how bad of a programmer I am, someone should’ve told me that long ago!
    • It’s not I wasn’t told, it’s that I didn’t take the time to internalize good habits
    • Follow Unix Philosophy : one tool does one thing well. Avoid too many optional features
    • Thinking about data structures is necessary for a clean code architecture and also for performance
    • It’s something collaborative! To work together with others improves your code a lot
    • Properly choosing names of variables, functions, classes, etc. is even more important than the documentation. It some cases, it can even substitute for it (e.g. when you “don’t have time to create documentation/comment code”). It is crucial for others to understand what you are doing (e.g. finding bugs).
    • It is not because it is newer that it is better
    • It is not because it is old that it is bad ;-)

Break until XX:20

Suggestions for making the code more modular

Workshop Feedback