Hi Jeffrey,
I'm staff at UC Berkeley where I work on the Ptolemy project
(http://ptolemy.org). In 1999, we wrote a paper about software
development in an academic environment
(http://ptolemy.eecs.berkeley.edu/publications/papers/99/sftwareprac/)
At the time, we found that code reviews were quite effective at
teaching the art of software design to students. Back then, most
electrical engineering students had very little programming
experience. These days, they have much more. One thing we came
up with was a simple color scheme for the stability of software
(red, yellow, green and blue). We independently started doing
nightly builds with a web page showing the results that included
the rating, code coverage and cyclomatic complexity. We could use
this page to help determine what code should next get unit tests.
We moved from this home grown system to Hudson, then Jenkins and
we are no longer doing code coverage because the build takes 5
hours as it is.
I was pretty happy when I found McConnell's Code Complete and
realized that we had been doing many of his suggestions.
Unfortunately, these days we are not doing more formal code
reviews, though I tend to desk check software at least once with
each new student.
The Ptolemy project has a style guide, which is documented at
https://www2.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-164.html.
The abstract sums it up:
Collaborative software projects benefit
when participants read code created by other participants. The
objective of a coding style is to reduce the fatigue induced by
unimportant formatting differences and differences in naming
conventions. Although individual programmers will undoubtedly
have preferences and habits that differ from the recommendations
here, the benefits that flow from following these
recommendations far outweigh the inconveniences. Published
papers in journals are subject to similar stylistic and layout
constraints, so such constraints are not new to the academic
community. This document describes the coding style used in
Ptolemy II, a package with 550K lines of Java and 160
contributing programmers that has been under development since
1996.
One thing I think open source has failed at is that most projects
have almost no documentation for the methods. This makes it
difficult to know how to use the code.
These days, with Eclipse, I think the bottleneck is that setting
up a Eclipse project like Triquetrum
(http://wiki.eclipse.org/Triquetrum) has a very high "aha!"
factor, where doing simple things like setting up the Welcome
window is simple, but finding out precisely which lines to add
where can take quite a bit of time. I've found that looking at
Github code can help here, as does Stackoverflow. I've been
attempting to update the Eclipse wiki, or at least create pages
that describe what I did so that maybe the next person might find
my notes.
The other bottleneck I'm seeing is in a different project, called
Accessors, (proxies for IoT services and devices). _javascript_ was
selected because it runs in the browser and has asynchronous
atomic callbacks (AAC). Unfortunately, I feel that _javascript_ is
not very well designed and not suitable for large scale use.
_javascript_ made me be much more a fan of Python, which until I
used _javascript_, I was no fan of Python. Software engineering
for non-trivial systems written in languages like _javascript_ that
are not strongly typed is bad enough. _javascript_ just seems to
make it worse than it was say in Tcl.
_Christopher
On 6/12/17 2:58 PM, Jeffrey Carver
wrote:
Jay,
Thank you for
the introduction. Look forward to learning more about this
group and interacting with you. Just to provide a bit more
background, I’ve been doing research for more than 10 years
in understand how to best apply software engineering
principles to the development of scientific software, given
all of the constraints and uniqueness of this domain. If
anyone here is interested in talking more with me about your
experiences (either positive or negative), I would really be
interested. Furthermore, if anyone is interested in
collaborating to address any bottlenecks in your software
processes, I would really be interested in talking more.
Thanks in
advance!
Jeffrey
Carver
Professor
(effective 8/17)
Department
of Computer Science
University
of Alabama
205.348.9829
(v)
Everyone,
Allow me introduce you to a colleague
of mine, Professor Jeff Carver from the University of
Alabama. Jeff studies software engineering and does very
interesting research work on scientific software. He
recently asked me about the Science Working Group and I've
convinced him to join the list to learn more about your
projects.
Jay
--
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
_______________________________________________
science-iwg mailing list
science-iwg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/science-iwg
--
Christopher Brooks, PMP
Academic Program Manager
iCyPhy/Ptolemy/TerraSwarm
University of California, Berkeley
707.332.0670, cxh@xxxxxxxxxxxx, https://ptolemy.eecs.berkeley.edu/~cxh
