
Teaching Software Architecture with GitHub - SanderMak
http://avandeursen.com/2013/12/30/teaching-software-architecture-with-github/
======
jimicy
Wow I wish my university offered courses like this. As a student what are good
books for software engineering practices in the field right now? Also when
you're doing sole projects are there specific procedures you should follow and
how do they differ from when you're in a team?

Lastly if it isn't too much can you post links to the course website for
this,the software communications and software metrics?

~~~
jonaspf
Personally I think this is a good starting point:
[http://gorban.org/post/32873465932/software-architecture-
che...](http://gorban.org/post/32873465932/software-architecture-cheat-sheet)

In terms of books, I really like "The Architecture of Open Source
Applications" ([http://aosabook.org/](http://aosabook.org/)) which is also
mentioned in the blog post. For the enterprise world, "Patterns of Enterprise
Application Architecture"
([http://martinfowler.com/books/eaa.html](http://martinfowler.com/books/eaa.html))
is a good choice.

However, before applying any technical software architecture methods, it is
really important to understand what your stakeholders actually want/need.
Unfortunately most of the time they don't even know it themselves. In my
experience most software projects fail, not because of technical reasons but
simply because the original problem hasn't been understood. This is where
communication is key. I assume the reason why the authors of the blog post
encouraged drawing diagrams and looking at different perspectives/views is to
facilitate this communication.

------
programminggeek
I guess this is s good approach to expose students to various software
architectures and what real projects end up looking like. However, I'm not
sure that this teaches the students what good architecture is/does and how it
evolves over time. Which is to say, I'm not sure that this explanation says
that the course teaches students how to DO good software architecture.

Knowing about architecture and doing it in your own code are two different
things.

------
n1ghtmare_
I'm finding it very difficult getting into a large open source project. I
consider myself an experienced developer, but for some reason it feel very
intimidating, especially when the code base is large. I was wondering if
someone could give any tips ?

~~~
yeukhon
I try to work on the software I actually use. I don't jump on a random horse
and start riding to the West. I think the first step is look at your tools.
What problem do you have with your tools. Is the library you using too
restricted? Does it have a null/nonetype exception rasied and not properly
handle? If you can't solve it because you have no idea where to start, well,
at least file a ticket :) I have limited experience too. I think the first
real contribution was Ansible, rewriting the hg module was critical for my
use. So I did. When I was an intern at Mozilla I learned about CSP so later
when I found a few minor issues with the CSP implementation in Firefox I
started volunteering. My internship didn't involve a single line of writing
Firefox code so it did take a while to navigate through a couple files for a
newbie. But grep, mxr.mozilla.org all helped.

I think even just making demos and making documentation changes is equally
powerful and useful contribution.

~~~
n1ghtmare_
Awesome! This is actually quite helpful and it gave me a couple of ideas.

------
stiff
It is actively harmful to teach students that software architecture is
something that somehow arises from diagrams or that those kinds of silly
pictures capture anything important about it. Powerful architectures come out
of powerful ideas that in turn come from accumulated hard work of many people
in different disciplines. One can learn much more from walking through the
actual source code of some classic projects and from trying to understand the
ideas that make them tick:

[https://github.com/onetrueawk/awk](https://github.com/onetrueawk/awk) \- UNIX
philosophy of small tools, DSLs, CS theory: state machines / regular
expressions, Thompson algorithm ...

[https://github.com/mirrors/emacs](https://github.com/mirrors/emacs) \- Both a
program and a VM for a programming language, hooks, before/after/around
advices, modes, asynchronous processing with callbacks, ... Worth to think of
challenges of designing interactive programs for extensibility.

[https://github.com/rails/rails](https://github.com/rails/rails) \-
Metaprogramming DSLs for creating powerful libraries, again a lesson in hooks
(before_save etc.), advices (around_filter etc.), ...

[https://github.com/git/git](https://github.com/git/git) \- The distributed
paradigm, lots of CS theory again: hashing for ensuring consistency, DAGs
everywhere, ... By the way, the sentence "yet the underlying git magic
sometimes resulted in frustration with the students" is hilarious in the
context of a "software architecture" course.

One of computer algebra systems - the idea of a
[http://en.wikipedia.org/wiki/Canonical_form](http://en.wikipedia.org/wiki/Canonical_form)

One of computer graphics engines - Linear algebra

...

There are loads of things one can learn from those projects by studying the
source in some depth, but I can't think of any valuable things one could learn
by just drawing pictures of the modules and connecting them with arrows. There
are also several great books that explore real software design issues and not
that kind of pretentious BS, they all come from acknowledged all-time master
software "architects", yet all of them almost never find diagrams or
"viewpoints" useful for saying the things they want to say, and they all walk
you through real issues in real programs:

[http://www.amazon.com/Programming-Addison-Wesley-
Professiona...](http://www.amazon.com/Programming-Addison-Wesley-Professional-
Computng-Series/dp/0131429019)

[http://www.amazon.com/Paradigms-Artificial-Intelligence-
Prog...](http://www.amazon.com/Paradigms-Artificial-Intelligence-Programming-
Studies/dp/1558601910/)

[http://www.amazon.com/Structure-Interpretation-Computer-
Prog...](http://www.amazon.com/Structure-Interpretation-Computer-Programs-
Engineering/dp/0262510871)

[http://www.amazon.com/Unix-Programming-Environment-
Prentice-...](http://www.amazon.com/Unix-Programming-Environment-Prentice-
Hall-Software/dp/013937681X)

[http://www.amazon.com/Programming-Environment-Addison-
Wesley...](http://www.amazon.com/Programming-Environment-Addison-Wesley-
Professional-Computing/dp/0321637739/)

To me, the kind of approach pictured in the post, seems like copying methods
from electrical or civil engineering to appear more "serious", without giving
due consideration to whether they really are helpful for anything for real-
world software engineering or not. The "software engineering" class which
taught those kind of diagram-drawing was about the only university class I did
not ever get any use from, in fact I had enough industry experience by the
point I took it that it just looked silly.

~~~
currywurst
The pictures are a _result_ of studying the systems in question.

For example, you have given links to a couple of github repos. Now if I'm
trying to create an overview of how say emacs works, I would try to identify
the main sub-parts and break the system down into more manageable chunks of
study. This is all what 'viewpoints' are trying to structure. None of this is
evident from just the codebase unless it has been captured in some
documentation, or you take the trouble to understand it yourself.

You seem to have a very low opinion of software architects, but believe me,
you wouldn't want to work on a 5-year old system where huge teams of
developers have let loose and no one/team was responsible to ensure a
cohesive, maintainable system.

Viewpoints are fantastic for communication purposes, and if you feel that the
particular viewpoints shown don't make much of a difference, I agree :). A
student project is also not the ideal environment, but it is really valuable
to know how to create them, considering the information needs of the audience
(biz vs tech vs in-depth tech). And that is what this course is all about.

~~~
stiff
The point is that how emacs is broken down in modules is one of the least
important things about emacs. I can draw a block diagram without a "software
architecture" course, thank you. In software engineering, there are of minor
usefulness most of the time, if of any.

There have to be persons that guide the overall development, sure, but this
does not mean that those have to be "architects" living in a castle somewhere
drawing those diagrams. The best "architects" are people with long experience
in the trenches that know all the ins and outs, all the relevant theory, know
the domain, and supervise it down to the nitty-gritty details. Linus Torvalds
is a software architect for Linux, he doesn't do much coding anymore, but he
isn't busy drawing diagrams without understanding the code really well either,
he just is the person with the widest understanding of the whole project:

[https://lkml.org/lkml/2012/10/2/547](https://lkml.org/lkml/2012/10/2/547)

~~~
currywurst
There are a LOT of practicing architects that really fit the mould you are
describing! Linus has the big picture in his head, and perhaps if he were to
draw them out, does it make him an ivory tower denizen ?!

Also, ignoring how a system is modularized is typically how you get tangled
codebases by introducing unexpected dependencies. Just because it is 'less
interesting' doesn't make it 'unimportant'.

------
davidradcliffe
What a great opportunity for these students. I wish my university had done
something like this.

