サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
TGS2024
www.planetgeek.ch
I updated my clean code cheat sheet. This time there are just minor changes: Principles: mind-sized components Class Design: do stuff or know others, but not both Maintainability killers: tangles Refactoring patterns: refactor before adding functionality, small refactorings removed duplication regarding one test asserts one thing TDD principles: Test domain specific languages fixed a bug in the AT
This is the presentation handout for a presentation I gave at the bbv Techday 2013. Special thanks to Jeffrey Palermo for supporting me. Chopping onions usually makes you cry. This is not the case in software architecture. In contrary! The onion architecture, introduced by Jeffrey Palermo, puts the widely known layered architecture onto its head. Get to know the onion architecture and its merits
Why Clean Code Code is clean if it can be understood easily – by everyone on the team. With understandability comes readability, changeability, extensibility and maintainability. All the things needed to keep a project going over a long time without accumulating up a large amount of technical debt. Writing clean code from the start in a project is an investment in keeping the cost of change as con
There is an updated version at https://www.planetgeek.ch/2014/11/18/clean-code-cheat-sheet-v-2-4/ It took me about one and a half year to update my cheat sheet about clean code and TDD. But now, it’s here. The cheat sheet has grown quite a bit and now contains principles, patterns, smells and guidelines for clean code class and package design TDD – Test Driven Development ATDD – Acceptance Test Dr
Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about pair-programming, there is a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software. Let my sho
Over the last couple of years, I’ve done a lot of pair programming. Pair programming inside my team, at customer sites, in coding dojos and in my open source projects. Pair programming is really a great and effective experience when performed by an pair of developers knowing how to pair program. Unfortunately, you cannot just put two developers in front of a single computer and expect them to perf
Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do. Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience. To get most out of pair programming, you first have to
Updated: new version here! I have compiled two cheat sheets about clean code (the ones mentioned in my post about Code Quality!). The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells. You can download them here – Clean Code Cheat Sheet V1.3, Clean TDD Cheat Sheet
このページを最初にブックマークしてみませんか?
『Your source of geek knowledge』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く