Category Archives: Coding

Tunnustus yksikkötesteistä

Coding

Tänään täytyy tunnustaa, että tuli taas kerran tehtyä cowboy-koodausta suoraan masteriin erääseen PHZ Full Stack:n omaan tuotteeseen ilman code review:ta, ja puskettua tuotantoon päivityksiä vaikka CI sanoi, että testit ovat punaisella.

Olin tehnyt “parannuksia” coding convention:iin ja korjannut yhden “ilmiselvän” bugin, “selkeyttänyt” koodia luettavammaksi ja ottanut kielikäännökset käyttöön myös REST API:ssa, viisveisaamalla testeistä.

Ylläripylläri tuotanto ei sitten toiminutkaan enää kriittisissä rajapinnoissa. Lähdin selvittämään mistä virheet johtuvat.

Jälkiviisautena ei siis pitäisi olla yllätys, että vaikka nyt kielikäännökset toimivat, niin kaikki muut kohdat joihin oli muutettu yksikin rivi olivat kaikki hajonneet, ja tämän lisäksi puoli tusinaa muuta ominaisuutta, joita en olisi odottanut menevän rikki tehtyjen muutosten seurauksena. Onneksi aiemmin tehdyt yksikkötestit (jotka nyt siis olivat punaisella ja joita ei oltu ajettu) paljastivat kaikki bugit.

Ensimmäinen automaattitestin paljastama ongelma oli ternary statement:n, jossa “selkeytyksen” seurauksena oli true/false logiikka kääntynyt väärin päin. Ehdotukseni tosin on, että ternary statement:tit kielletään firman Coding Convention:ssa, koska juniori-koodaajat eivät ymmärrä niistä mitään ja senioritkin näemmä ymmärtävät ja kirjoittavat ne väärin. Luettavampaa (tosin pidempää) koodia saa aikaan if/else:llä.


muuttuja = testi ? true : false;

Toinen “parannus” oli muuttujan nimen refaktorointi, tosin rajapinnasta. Tietysti tämä oli typotettu “joyfullId” kun piti olla “joyfulI” siten, että testit eivät vastanneet toteutusta. Onneksi taas testit huomasivat virheen.

Kolmas “ilmiselvän” bugin korjaus taas rikkoi sisäänkirjautumisen.

Refaktorointi taas muutti Depency Injection -containerin toimintaa niin ettei testit toimineet tietokantamock:ien osalta lainkaan.

Tästä taas vaihteeksi oppineena lupaan seuraavan kerran olla laittamatta tuotantoon koodia, jos testit ovat punaisella. Tämän varmistamiseksi viritetään CI loppuun asti, että nykyisen testiympäristön automaattideployment:n lisäksi myös tuotanto päivitetään CI:n kautta, mutta ainoastaan jos kaikki testit ovat vihreällä.

Published by:

Package visibility is the best visibility in Java

Coding

I find the best visibility level in Java to be the default visibility i.e. package visibility, because it enables unit test classes to access all the methods, if the test is placed in the same package as the main class.

Also package visibility is shorter to write since you can omit the visibility declaration, so there is less boiler plate.

The second best visibility level is protected, since in some cases you can create your test classes as sub-classes of your main class. However, as stated before, package visibility works better in most cases, if you use packages properly.

Third, typically if you run Sonar and do code review and static analysis on large projects, I have found out that typically 80% of the methods are public, and 20% are private/protected. Thus, the main idea of using private or protected methods is to protect the data/properties from being accessed by bypassing the accessors. Most of the methods will be typically public anyways.

The most useless visibility level (but unfortunately commonly used) is private as it’s impossible to test (without using Reflection and modifying the visibility to something else). Also, private prohibits code re-use in subclasses, which is the main idea of using object oriented paradigm in the first place, and thus should be avoided. For the same reasons keyword final should be avoided in most cases.

Thus, I find your example to be the best practice how to define the visibility levels :). However, you are missing the package declaration and unit tests.

See https://stackoverflow.com/questions/16727414/the-use-of-visibility-modifiers-in-java/47213314#47213314

Published by:

Fix ENOSPC error

Coding

When we were starting up our React Native project, we got the following error message:


ERROR watch /home/phz/workspace/react-mobile/node_modules/beeper ENOSPC
{"code":"ENOSPC","errno":"ENOSPC","syscall":"watch /home/phz/workspace/react-mobile/node_modules/beeper","filename":"/home/phz/workspace/react-mobile/node_modules/beeper"}
Error: watch /home/phz/workspace/react-mobile/node_modules/beeper ENOSPC
at exports._errnoException (util.js:1018:11)
at FSWatcher.start (fs.js:1443:19)
at Object.fs.watch (fs.js:1470:11)
at NodeWatcher.watchdir (/home/phz/workspace/react-mobile/node_modules/sane/src/node_watcher.js:144:20)
at Walker.<anonymous> (/home/phz/workspace/react-mobile/node_modules/sane/src/node_watcher.js:353:12)
at emitTwo (events.js:106:13)
at Walker.emit (events.js:191:7)
at /home/phz/workspace/react-mobile/node_modules/walker/lib/walker.js:69:16
at go$readdir$cb (/home/phz/workspace/react-mobile/node_modules/graceful-fs/graceful-fs.js:149:14)
at FSReqWrap.oncomplete (fs.js:123:15)

We found out that the problem is caused by having too few filesystem watches. See

http://stackoverflow.com/questions/22475849/node-js-error-enospc

The issue can be fixed by increasing the fs.

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Published by:

New Extreme Programming Adoption Record – 30.5 practices in just 6 weeks!

Careers Coding Company Software Engineering

The latest (disclosed) PHZ customer project working on-site at customer premises hit on the last week the record of fastest Extreme Programming (XP)-process adoption seen this far. The previous scores have been:

The latest record is to adopt 30 and a half practices in just 6 weeks! Our current Extreme Programming list of practices include for example Pair Programming, Test Driven Development, 100% Code Coverage and Continous Integration (to test and production environments). There are currently total of 37 practices, with the Lean 5S being the latest addition.

The benefit of having such a high XP -process maturity is that roughly after 25/37 practices the software engineering team starts to break even for the customer, i.e. they cost the same as they produce. At 30 practices the team typically produces more than they cost, and near 37 practices the team hits so called super-productivity enabling the delivery of world-class products at very high efficiency. This is the way how we claim our main sales proposition of delivering Sustainable IT Services where the life-time of the systems we deliver can reach decades compared to the few years or months when using more traditional practices.

Published by:

PHZ Full Stack pienensi bugien määrää -780%

Coding Devops

Benchmark:asimme hiljattain suurimpien toimittamiemme projektien tuottamia lopputuloksia, ja löysimme kestävän kehityksen ja korkean laadun ideologiamme tuottaneen asiakkaillemme rahassamitattavia ja huomattavia konkreettisia säästöjä.

Eräässä projektissa edellinen toimittajan tekemistä tehtävistä jopa 44% oli bugikorjauksia. Kyseisessä projektissa jossa PHZ Devops-tiimi vastaa kokonaistoimituksesta hyödyntäen testiautomaatiota ja jatkuvaa toiminnan parantamista, virheiden määrää on saatu tiputettua 5.7% tasolle eli lähes 8 kertaa aikaisempaa pienemmäksi. Laskiessa huonon laadun kustannuksia projektin kokonaiselinkaaren mitassa, uusi PHZ Full Stack Devops -toimintamalli on jo tähän mennessä tuottanut huomattavia säästöjä ja on nähtävissä että säästöt tulevat kumuloitumaan miljooniin euroihin. Samalla tuoteomistajat ovat voineet saada käyttöön jopa 8 kertaa aikaisempaa enemmän uusia ominaisuuksia, mikä on lisännyt myös palvelun käyttäjämäärää jopa 20%.

Ota yhteyttä sales (at) phz.fi tai myyntijohtaja Anne Lamberg 045 662 4501, jos haluat kuulla tarkemmin kuinka voisimme parantaa myös teidän yrityksenne ohjelmistokehitysprosessin tuottavuutta.

Published by:

Lean vs. Agile

Coding Software Engineering

There is a heated up debate going on among software development professionals about what is the difference between Agile and Lean software development? Are they rooted in the same principle or is there something fundamentally different between the two methods?

James O. Coplien explains the difference:
http://www.slideshare.net/jcoplien/20090513resund-agile

At PHZ.fi we are embracing both the methodologies, in particular Extreme Programming by the book, and eliminating the waste by reflecting on Kanban, Total Quality Management, Six Sigma and Shigeo Shingo’s Zero Quality Control.

Published by:

Private considered harmful

Coding

Time after time I explain to the other coders that private visibility is harmful, 95% of coders tend to try rock hard claim otherwise. Unfortunately private is a harmful visibility level to use.

Personally I haven’t yet found any legitimate use case for private -visibility, but the opposite. Quote from the documentation of a unit testing framework:

Limitation: final, private, and static methods
Please note that final, private and static methods cannot be stubbed or mocked.

Using protected visibility instead of private by default has the advantage of leaving the opportunity for the future developers open to reuse and extend your code. Using private denies this opportunity and forces rewrite of your code. For test classes using protected is however clumsy, since you need to create a subclass to be able to mock or stub the methods or properties you want. Using dependency injection would be a better idea.

PHZ.fi has been conducting a range of code reviews for half a dozen large softwares with 150-600k lines of code. My surprising observation has been that in all the cases the code has been consisting 80% of public methods. The real life outcome thus seems to be that coders don’t really use encapsulation so often and limiting the visibility on class level is less common than using hidden interfaces (e.g. private). Of course a function is also an interface for encapsulation, and thus the one can also deduct that the coders are mostly hiding the implementation details inside one or only a few public methods rather than using large number of private methods.

In Java my best practice is to define all non-public properties and methods on package -visibility, meaning that there is no public, protected or private. If you place your test class in the same package, you can easily access also the non-public the methods or properties and for most of the time you don’t even need DI configurations.

Published by: