forked from hakimel/reveal.js
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathget_back_to_beginnings.html
executable file
·3219 lines (2766 loc) · 152 KB
/
get_back_to_beginnings.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Get back to beginnings</title>
<meta name="description" content="Clean code matters">
<meta name="author" content="Milan Popovic">
<meta name="apple-mobile-web-app-capable" content="yes" />
<meta name="apple-mobile-web-app-status-bar-style" content="black-translucent" />
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no, minimal-ui">
<link rel="stylesheet" href="css/reveal.css">
<link rel="stylesheet" href="css/theme/black.css" id="theme">
<link rel="stylesheet" href="css/presentation/get_back_to_beginnings.css">
<!-- Code syntax highlighting -->
<link rel="stylesheet" href="lib/css/zenburn.css">
<!-- Printing and PDF exports -->
<script>
var link = document.createElement( 'link' );
link.rel = 'stylesheet';
link.type = 'text/css';
link.href = window.location.search.match( /print-pdf/gi ) ? 'css/print/pdf.css' : 'css/print/paper.css';
document.getElementsByTagName( 'head' )[0].appendChild( link );
</script>
<!--[if lt IE 9]>
<script src="lib/js/html5shiv.js"></script>
<![endif]-->
</head>
<body>
<div class="reveal">
<!-- Any section element inside of this container is displayed as a slide -->
<div class="slides">
<section>
<h1>Get back to beginnings</h1>
<h3>Good code matters</h3>
<p>
<small>Presented by <a href="http://milanpopovic.me">Milan Popović</a> / <a href="http://twitter.com/komita1981">@komita1981</a></small>
</p>
<aside class="notes">
First, master the fundamentals - Larry Bird
</aside>
</section>
<section>
<h2>Me</h2>
<p class="left_align">
PHP developer
</p>
<p class="left_align">
Work for Navus Consulting
</p>
<p class="left_align">
I like to learn and share knowledge
</p>
<p class="left_align">
Active member of PHP Srbija
</p>
</section>
<section>
<section>
<h2>What is code?</h2>
<p>
<img class="noframes" alt="What is code?" src="img/get_back_to_beginnings/what_is_code.png">
</p>
</section>
<section>
<h2>Code is ...</h2>
<p class="left_align">
Programming statement
</p>
<p class="left_align">
A sequence of stored instructions
</p>
<p class="left_align">
Language in which we express the requirements
</p>
<p class="left_align">
Represent your understanding of requirements
</p>
</section>
<section>
<p class="left_align">
“
<q>
There are only two types of code, code that delivers business value, and code that doesn't
</q>
”
</p>
<p class="right_align">
Anthony Ferrara
</p>
</section>
<section>
<h2>
External Quality
</h2>
<p class="left_align">
Does the software behave correctly?
</p>
<p class="left_align">
Are the produced results correct?
</p>
<p class="left_align">
Does the software run fast?
</p>
<p class="left_align">
Is the software UI easy-to-use?
</p>
<p class="left_align">
How well the system meets needs of users and customers?
</p>
</section>
<section>
<h2>
So ...
</h2>
<p class="left_align">
It’s not about coding
</p>
<p class="left_align">
It’s not about design
</p>
<p class="left_align">
It’s not about joy
</p>
<p class="left_align">
It doesn't matter how well you build the wrong thing
</p>
<p class="left_align">
It’s all about <span class="red_text">value</span>
</p>
<p class="left_align fragment red_text">
Value = All other things included!
</p>
</section>
<section>
<h2>
Internal Quality
</h2>
<p class="left_align">
How well the system meets need of developers and administrators?
</p>
<p class="left_align">
Is it easy to change?
</p>
<p class="left_align">
Is it easy to understand?
</p>
<p class="left_align fragment red_text">
If we stop care about internal quality we will loose external quality
</p>
<aside class="notes">
<p class="left_align">
“
<q>
The problem with quick and dirty is that dirty remains long after the quick has been forgotten.
</q>
”
</p>
<p class="right_align">
Steve C. McConnell
</p>
</aside>
</section>
<section>
<p class="left_align">
“
<q>
When your coding skills will be smooth, you will start thinking about the value automatically.
</q>
”
</p>
<p class="right_align">
Alexey (Mr_Mig) Migutsky
</p>
</section>
<section>
<p class="left_align">
“
<q>
The bitterness of poor quality remains long after the sweetness of low price is forgotten.
</q>
”
</p>
<p class="right_align">
Benjamin Franklin
</p>
</section>
</section>
<section>
<section>
<h2>
Bad code
</h2>
<p class="left_align">
Most production code is mess
</p>
<p class="left_align">
Messy code is the rule - not the exception
</p>
<p class="left_align">
Entropy hits hard
</p>
<aside class="notes">
Entropy is amount of disorder in system.
</aside>
</section>
<section>
<h2>
Bad code properties
</h2>
<p class="left_align">
Has tendency to be even worse
</p>
<p class="left_align">
Without formatting
</p>
<p class="left_align">
Tries to do everything
</p>
<p class="left_align">
Untestable
</p>
<p class="left_align">
Hard to change
</p>
<p class="left_align">
Hard dependencies
</p>
<p class="left_align">
Disregard principles of software design
</p>
<p class="left_align">
Too smart
</p>
<aside class="notes">
Clever is the enemy of clear.
Every time you look at an algorithm you just developed with the feeling you are the smartest
programmer you have ever met for doing something so complex and genius - write it again.
</aside>
</section>
<section>
<h2>
Bad code consequences
</h2>
<p class="left_align">
It's difficult to integrate new features
</p>
<p class="left_align">
Code change developed mysterious bugs that are hard to reproduce and to fix
</p>
<p class="left_align">
Developers afraid to touch anything because it will break the system
</p>
<p class="left_align">
Development became slow
</p>
<aside class="notes">
1. You are worried about compatibility with the existing system.
<br/><br/>
2.
<br/><br/>
3. Existing developers have forgotten what a lot of the code does. They are afraid that
changes will worsen the system, new developers take too long to train. So hiring an army of
developer can't save you from bad code. And every day the system accumulates more bad code.
<br/><br/>
4. The business becomes hostage of the code state. Slower development costs time and money,
unpredictable integration periods make it harder to make sales promises, and quirky bugs can
make your customers lose faith.
</aside>
</section>
<section>
<h2>Why people write bad code</h2>
<p class="left_align">
Explicit reasons
</p>
<p class="left_align">
Implicit reasons
</p>
</section>
<section>
<h2>
Explicit reasons
</h2>
<p class="left_align">
Deadline
</p>
<p class="left_align">
Knowledge
</p>
<p class="left_align">
Company environment
</p>
<p class="left_align">
Colleagues
</p>
<aside class="notes">
In software development we are almost always constrained by a deadline. The pressure is on
and we feel rushed to get the work done. We don’t take the time to step back and think about
the quality of our code or whether we are adhering to any design principles that are
appropriate to the programming paradigm in which we are working. This can result in sloppy
code and the accumulation of Technical Debt that we will “clear later”. Of course, later
usually means never.
<br/><br/>
Sometimes it is simply lack of knowledge that prevents us from writing good code. In this
case the solution is to get that knowledge but not all developer’s want it. Our jobs as
professionals and colleagues is to persuade them that the knowledge will be worth it.
<br/><br/>
Psychology tells us that our environment shapes our behaviour so we can’t expect a developer
to actively apply a set of principles independently of her environment. What do I mean by
this? I am referring to the effect that morale and organisational ‘red-tape’ has on a
developer’s ability to code. If a developer is unmotivated or constrained by strict policies
then he may have no desire to write well-designed code.
<br/><br/>
Another factor that affects a developer’s environment is the availability of competent and
more experienced developers. When developer’s have access to more experienced senior
developers a mentoring culture can emerge and the quality of code can improve through
practices such as code reviews and pair programming.
Source - http://www.burmatuk.com/2015/04/26/why-developers-ignore-software-design-principles/
</aside>
</section>
<section>
<h2>
Implicit reasons
</h2>
<p class="left_align">
Choice-supportive bias
</p>
<p class="left_align">
Priming
</p>
<p class="left_align">
Informational Conformity
</p>
<p class="left_align">
Halo effect
</p>
<p class="left_align">
Hyperbolic discounting
</p>
<p class="left_align">
Reactance
</p>
<p class="left_align">
Dunning-Kruger effect & Imposter syndrome
</p>
<aside class="notes">
The choice-supportive bias tells us that when we make a choice we tend to feel positive
about it even if it has flaws. It implies that when we choose a particular design we fail to
see its weaknesses or downplay them because we chose that design. This is related to the IKEA
effect, a cognitive bias that occurs when people place a disproportionately high value on a
product that they partially created. If we spent a long time and effort hand-crafting a set
of inheritance-based classes then boy are we going to feel positive about them! Our memory
of the choices we made along the way are distorted and our brain chooses to remember the
positive rather than the negative aspects. Research has shown that the more cognitive
load and decision-making we are tasked with, the greater the likelihood of us being
affected by the choice-supportive bias. So activities like coding are particular
susceptible. We need to be careful that we aren’t seeing our designs through
rose-tinted glasses by seeking out the opinions of others and through code reviews
and pair-programming.
<br/><br/>
Priming is an unconscious memory effect in which exposure to one stimulus influences
our response to another stimulus. For instance, if a person reads a list of words that
includes the word ‘computer’, and is later asked to state a word that begins with
‘com…’, the probability that he or she will answer ‘computer’ is greater than if they are
not primed. When we are exposed to an existing codebase with a ‘bad’ design we are
more likely to repeat those patterns elsewhere in the code. It can be useful to
perform a constructive critique of an existing codebase and to discuss the design with other
developers before jumping straight into coding. If the outcome of such discussion involves
any redesign then we will then be primed to make positive changes rather than unconsciously
re-apply bad design. Priming is exacerbated by Informational Conformity.
<br/><br/>
When reading perplexing code it is sometimes possible to think that the developer that wrote
it ‘knows something that we don’t’. Based on this assumption we adhere to the current
behaviour of the code because we’re unsure of how to change it. Essentially, we copy existing
code even if we know it sucks. An example of Informational Conformity is not writing unit tests
simply because none exist currently. If we are unsure about why the code has been written in
a certain way then we should ask the developer that wrote it, if they are available.
Otherwise we should talk to our peers and discuss alternative designs or approaches to
make the design cleaner and more coherent.
<br/><br/>
Closely related to Informational Conformity is the Halo effect. We take the code written by
a developer that we perceive as more competent than us as having a good design even if that
code is bad. We consequently fail to challenge or change it and we even copy it. Imitation
is the sincerest form of flattery of course. This effect also applies to our own code. We
take one positive aspect and associate it with the entire code base. We ignore the flaws of
our code because the service we created to retrieve customer data is pretty awesome! We also
need to be careful we don’t apply the reverse-halo affect by dismissing ideas from developers
that we perceive as less competent. We need to remember that everybody has something to
contribute.
<br/><br/>
As a developer we act in favour of the present state of the code over investing in the future,
i.e. refactoring into a better design because we want the reward of it being finished now.
This effect is compounded by the fact that we suffer from another cognitive bias: procrastination.
We will remove that duplication later! Moreover, the Principle of Least Effort tells us that
we are inherently lazy. If there are several ways of achieving the same goal, we will opt
for the least demanding course of action. This usually means avoiding refactoring.
<br/><br/>
Reactance occurs when we feel that someone or something is taking away our choices or limiting
the range of alternatives available to us. So we do the opposite of what the rules (or principles)
suggest to prove our freedom of choice. We ignore software design principles because we want
to do our own thing. This bias can make us commit to an opinion more strongly when we are
challenged or pressured to adopt another viewpoint. Sometimes our responses are justified but
sometimes we may just be being irrational.
<br/><br/>
Have you ever worked with a developer that grossly over-estimates their own technical ability?
The Dunning-Kruger effect occurs when people fail to adequately assess their level of competence
at a task and thus consider themselves more skilled than everyone else. Not only this but
they also fail to recognize genuine competence in other people. The opposite is also true.
Competent people will underestimate their ability compared with others. This is known as the
imposter syndrome. When people are exposed to training they do then recognize and acknowledge
their own personal previous lack of skill. We don’t know how incompetent we are until we are
given the skills or knowledge to realise what we don’t know. This is why training is so
important in software development.
Source - http://www.burmatuk.com/2015/04/26/why-developers-ignore-software-design-principles/
</aside>
</section>
<section>
<p>
<img alt="Circle of knowledge" src="img/get_back_to_beginnings/circles_of_knowledge.png">
</p>
</section>
<section>
<h2>The cost of bad code</h2>
<p class="left_align">
Time
</p>
<p class="left_align">
Productivity
</p>
<p class="left_align">
Nerves
</p>
<p class="left_align">
Projects
</p>
<p class="left_align">
Job lost
</p>
<p class="left_align">
Money
</p>
</section>
<section>
<h2>Do not ever say...</h2>
<p class="fragment left_align">
I will do it next time
</p>
<p class="fragment left_align red_text">
Later equals never - LeBlanc's law
</p>
<p class="fragment left_align">
It's managers fault
</p>
<p class="fragment left_align red_text">
Bad code is only your mistake - Your job is to defend code with passion.
</p>
<aside class="notes">
Code is getting worse as time passes. We should not wait - fix it all the time. That's
the only way you can prevent degradation.
<br/><br/>
It's your job to defend your code - like doctor who is washing his hands before
surgery. It takes time but it is your duty. Your job as professional is to say no. Defend
your profession, defend your code quality. Your managers actually want better code - they
want to make it easier to develop new features. If some managers push you to write bad
code tell them story about american navy and canadian lighthouse. You should be like
lighthouse - you are defending your product - your code
<br/><br/>
Whose fault is bad code?
Managers job = defend schedule and features
Our job = defend the code
It is our responsibility to say “NO“ and provide good code
</aside>
</section>
<section>
<h2>Do not ever say...</h2>
<p class="fragment left_align">
Deadline
</p>
<p class="fragment left_align red_text">
If you make mess you will never reach that deadline
</p>
<p class="fragment left_align">
Someone else will do that (later)
</p>
<p class="fragment left_align red_text">
No way Pedro :-)
</p>
<aside class="notes">
Deadline is not excuse. Making mess is very unprofessional. The only way to go fast is
to keep code clean as much as possible all the time.
<br/><br/>
Don't leave bad code behind you. Fix them as soon as you discover it. If you think there is
not enough time and that someone else will go around cleaning this mess - you are so wrong.
<br/><br/>
Additional story
Everyone knows the previous co-worker whose name became a verb to describe dirty code.
“Oh man, this code has been Jimmy’d.”
Ouch. Comments like this are the kiss of death for long-term employment prospects. We want
our co-workers to recommend and hire us in future positions, right? Being known for writing
clean code is a great way to assure your co-workers recommend you and look forward to working
with both you and your code in the future.
</aside>
</section>
</section>
<section>
<section>
<h2>Professional code</h2>
<p class="left_align">
Why should we write it?
</p>
<p class="left_align">
Everyone wants to write code that other people can understand
</p>
<p class="left_align">
We strive to be better programmer
</p>
<aside class="notes">
Let me explain how you can easily make your code less confusing, cleaner and better. Most
books and courses about clean code start with an explanation of the design patterns or
writing tests. But these are just tools. If you don't understand the underlying motivation to
use these tools, they will not help you very much.
<br/>
Don't be intimidated by the thought of learning something new. Writing clean code is a skill
like any other, you have to spend some time studying as well as practicing it.
<h2>Philosophies for Effective Programming</h2>
<ol>
<li>
Always write high quality, clean code
</li>
<li>
Refactor ruthlessly
</li>
<li>
Think before you code
</li>
<li>
Develop in small steps
</li>
<li>
Write understandable code
</li>
<li>
Adopt and follow coding standards and guidelines
</li>
<li>
Add documentation to improve code readability
</li>
<li>
Write documentation before you write the code
</li>
<li>
Follow the 30 seconds rule
</li>
<li>
Smaller methods are usually better
</li>
<li>
Optimize your code only as last resort
</li>
</ol>
30 seconds rule - Another programmer should be able to look at the method, a class or an
interface definition. Programmer should understand what it does, why it does it and how it does
it in less than 30 seconds. This can be achieved if there is informative header documentation,
a name that clearly conveys the intent, by doing what it is supposed to - no more no less.
</aside>
</section>
<section>
<h2>Professional code</h2>
<p class="left_align">
Professional code isn't about creating the perfect code
</p>
<p class="left_align">
Our goal is progress not perfection
</p>
<p class="left_align red_text">
There's no such thing!
</p>
<aside class="notes">
Professional code isn't about creating the perfect code. It's not possible! There's no such
thing. Professional code is about accepting that fact. All software has bugs. Every line of
code is subject to change. If you write clean code, you are trying to make it easy to find
and fix those bugs and you are writing code that is easy to understand and change.
The team who designed the ALGOL language—the granddaddy of most modern languages and one
of the most influential languages ever—received the following advice: “The best is the enemy
of the good.” Working toward perfection might prevent completion. Complete it first, and
then perfect it. The part that needs to be perfect is usually small.
"No one in the brief history of computing has ever written a piece of perfect software. It's
unlikely that you'll be the first." - Andy Hunt
</aside>
</section>
<section>
<h2>Professional code (coding)</h2>
<p class="left_align">
It's not only about code - it's about process
<p class="left_align">
Git, GitFlow, Commit Messages,
</p>
<p class="left_align">
How to run local instance?
</p>
<p class="left_align">
Tests, How to run tests?, CI, CD, QA
</p>
<p class="left_align">
How to style the code?
</p>
<p class="left_align">
How to do code review?
</p>
<p class="left_align">
IDE, Text editors
</p>
<p class="left_align">
How to deploy to production?
</p>
<aside class="notes">
There is a correlation between code quality and the simplicity of the answers to these
questions. I believe it's because developers who care about the quality of their code also
care about the quality of their processes. Make it easy for people to contribute and show
them that you care, they will care too.
</aside>
</section>
<section>
<h2>Kent Beck's rules of simple code</h2>
<ul>
<ol>
1. Runs all the tests
</ol>
<ol>
2. Contains no duplication
</ol>
<ol>
3. Express the intent of programmer
</ol>
<ol>
4. Minimizes the number of classes and methods
</ol>
</ul>
<p class="fragment red_text">
Given in order of importance
</p>
</section>
<section>
<h2>My code should be...</h2>
</section>
<section>
<h2>
Testable
</h2>
<p class="left_align">
Testable system passes all tests and is completely tested
</p>
<p class="left_align">
Systems that aren’t testable aren’t verifiable
</p>
<p class="left_align">
System that cannot be verified should never be deployed
</p>
<p class="left_align">
Facilitate change
</p>
<p class="left_align">
Reduce number of bugs
</p>
<p class="left_align">
Encourage SRP and DIP
</p>
<aside class="notes">
System that are not testable should not be deployed because they can't be verified.
Personal experience - when I started writing tests I also started writing better code because
I could not test bad code and when you write piece of bad code and code that is not designed
properly you will notice it immediately in your tests.
<br/><br/>
"The fact that we have these tests eliminates the fear that cleaning up
the code will break it". Good tests are also kind of good documentation.
<br/><br/>
4.
Most software defects are introduced when changing existing code. Developer can't fully grasp
the effects of the changes made. Developer should be confident that the changes do not
break any existing functionality
Code easily degrades without a comprehensive test suite - Zaengle blog
<p class="left_align">
“
<q>
Test code is just as important as production code. It’s not a second-class citizen.
</q>
”
</p>
<p class="right_align">
Uncle Bob
</p>
<p class="left_align">
“
<q>
Why isn’t software development like building a house!?
Building a house starts at the foundation not at the roof!
Houses, bridges and building in general is predictable, why isn’t software building?!
</q>
”
</p>
<p class="right_align">
Arborosa
</p>
</aside>
</section>
<section>
<h2>
Readable
</h2>
<p class="left_align">
Writing code is relatively easy - reading is hard
</p>
<p class="left_align">
We are reading code 10 times more than write
</p>
<p class="left_align">
Minimizes the need for guesswork and possibility for misunderstandings
</p>
<p class="left_align">
Should look like English
</p>
<p class="left_align">
How fast can you read your code?
</p>
<aside class="notes">
All code should emphasize what it does over how
We are constantly reading old code. If you want to write code more quickly that means that you
have to make it more readable. It has story to tell.
<br/><br/>
It is much more profitable losing a couple of minutes thinking what is the best name for a
variable, or what is the best way to structure a class and get this extra time every time we
have to read it, than using the first name or structure that comes to mind in order to save time
having to spend it later trying to understand what a certain function does and how it does it.
- Source - umprogramador.net/write-code-for-humans/
<br/><br/>
Your code should read like a well-written story. The code should have a natural flow where each
method describes an operation that has an entry and exit point. Each method should add to the
overall story and written in such a way that it would make sense even to non-programmers
- Source - https://www.microsoft.com/en-gb/developers/articles/week04aug15/a-software-developers-guide-to-clean-code/
<br/><br/>
Good syntax is understandable syntax. Understandable syntax normally doesn't look like code.
Code is cryptic and unnatural to follow. Instead, understandable syntax should look like English.
English is easier to read, is easier to talk and reason verbally, and most importantly, it can
encourage the developer to understand business requirements. If your code is starting to look
less cryptic and more like English, that's a good sign. I will now run through a list of
bite-sized tips which will make it easier to write code like English.
Source - sevenstrokes.net/learn-how-write-good-code
<br/><br/>
Your goal is to write beautiful, functional and verbose code. In the words of Uncle Bob "your
code should read like an article. There should be a beginning, middle and end, it should be
self-documenting and should follow a logical order. By using verbose and purposeful wording you
can ensure that your code is self-explanatory.
<br/><br/>
Many developers are tempted to rewrite rather than do the hard work of reading and
comprehending existing code. Since reading code is naturally challenging, if you write code
that you’re barely able to follow as you write it, you’ll find you’re unable to comprehend it
all later. Professional developers write so much code that after a few weeks of separation,
most the structure and design decisions fall out of memory. It’s like looking at the project
with a fresh perspective. Not being able to understand your own code a few weeks later can
be a really depressing situation. Source - http://blog.pluralsight.com/7-reasons-clean-code-matters
<br/><br/>
Minimises the risk of introducing defects by making the code as easy to understand as possible
<p class="left_align">
“
<q>
It's OK to figure out murder mysteries, but you shouldn't need to figure out code. You should
be able to read it
</q>
”
</p>
<p class="right_align">
Steve C. McConnell
</p>
<p class="left_align">
“
<q>
How can you enhance code if you cant read it?
</q>
”
</p>
<p class="right_align">
John Papa
</p>
<p class="left_align">
“
<q>
If there is a line of code you don't understand in under 10 sec - delete it.
</q>
”
</p>
<p class="right_align">
Sebastian Bergmann
</p>
<p class="left_align">
“
<q>
Nothing starts readable - Write dirty code, then clean it
</q>
”
</p>
<p class="right_align">
John Papa
</p>
<p>How readable is my code</p>
<p class="left_align">
<span class="red_text">L</span>ocation our code is easy
</p>
<p class="left_align">
<span class="red_text">I</span>dentify code at glance
</p>
<p class="left_align">
<span class="red_text">F</span>lat structure as long as we can
</p>
<p class="left_align">
<span class="red_text">T</span>ry to stay DRY
</p>
<p class="left_align">
AngularJs - John Papa
</p>
</aside>
</section>
<section>
<p class="left_align">
“
<q>
The cost of ownership for a program includes the time humans spend to understand it.
Humans are costly, so optimize for understandability.
</q>
”
</p>
<p class="right_align">
Mathias Verraes
</p>
</section>
<section>
<h2>
Clean
</h2>
<p class="left_align">
Someone cared about it
</p>
<p class="left_align">
It's an expression about how much you care about others
</p>
<p class="left_align">
Paid appropriate attention to details
</p>
<p class="left_align">
Clean Code = Design principles + Design patterns
</p>
<aside class="notes">
“Clean code is code that has been taken care of. Someone has taken the time to keep it simple and
orderly. They have paid appropriate attention to details. They have cared. But why should you care?
What’s wrong with code that just works? You should care because code is (almost) never written
just once and then forgotten. Most of the time you, or someone else, need to work on the code.
And to be able to work on it efficiently you need to understand the code. And because people
need to understand the code we write, we can say that the code we write is not intended
only for the computer but also for humans.
<br/><br/>
If your code is well design, clean and elegant than everyone will take care of it also. No one
will try to make mess in that code.
<p class="left_align">
“
<q>
I think clean code is good friend of agile. Both based on 'everything changes'. Embrace change.
</q>