Na czym spędzamy najwięcej czasu pisząc kod?

By -

Zastanawialiście się kiedyś na czym spędzamy najwięcej czasu w czasie pisania kodu? Czy to na na samym pisaniu? Na testowaniu? A może na zrozumieniu dokumentacji oraz specyfiki zadania? Ja długo się zastanawiałem nad tym i postanowiłem to sprawdzić. O wynikach właśnie chcę napisać w tym wpisie.

Zrozumienie specyfiki zadania, dokumentacji

To zajmuje bardzo dużo czasu, ale nie najwięcej. Owszem projektowanie może zająć bardzo dużo czasu, ale w wpisie ten temat pomijam. Zajmujemy się etapem już po zaprojektowaniu. Najczęściej zaczynamy implementować bardzo szybko zaraz po przeczytaniu dokumentacji i ewentualnie po jakimś czasie idziemy dopytać o szczegóły. Tutaj nie marnujemy zbyt dużo czasu, chociaż pewnie zależy to od projektanta ;).

Pisanie testów lub testowanie kodu

Zauważyłem, że nie stosując TDD sama implementacja testów zajmuje, więcej czasu niż implementacja samego kodu. Musisz wymyślić przypadki użycia, aby sprawdzić każdą ścieżkę funkcji. Im gorzej napisana metoda tym gorzej się ją testuje. Przychodzi z pomocą testowanie manualne, aby pominąć pisanie testów. Ewentualnie olewamy testy niech to robią inni. Ja za każdym razem próbuje jakkolwiek zweryfikować swój kod, bo tak powinni robić profesjonaliści. Zajmuje mi to masę czasu, ale w ramach testów jeżeli wykryje jakiś błąd (a nikt nie jest nieomylny) zyskuje czas, który bym zmarnował na szukanie błędu (a to jest o wiele cięższe niż sprawdzenie od razu).

Pisanie kodu

To akurat zajmuje nam najmniej czasu. W zależności kto jak szybko potrafi pisać oraz jak szybko myśleć zajmuje to chwilę. Zastanawiamy się czy zrobić tak czy inaczej, ale zajmuje to na prawdę bardzo mało. O ironio! W trakcie implementacji najmniej tracimy czasu na samo pisanie.

Czytanie kodu

I tutaj właśnie Was pewnie zaskoczę, w trakcie pisania kodu najwięcej czasu spędzamy nad czytaniem jego. Dlaczego? Nie wierzysz? Nagraj swoją godzinną pracę nad kodem i sam sprawdź. Chęć napisania kolejnej linijki najczęściej kończy się zerknięciem co było wcześniej. Zaczynając pisać funkcję czytamy, jak będziemy ją wykorzystywać. Weryfikujemy czy czasami nie posiadamy już takiej implementacji. Czytamy kod wokół tego co piszemy. Ciągle i nieustannie. Masz coś do dopisania lub zmienienia. Musisz przeczytać kod, który już istnieje nie ma innej możliwości. Pisząc testy musisz przeczytać napisany kod. I tak za każdym razem. Eksperyment z nagraniem siebie wykonałem i przyznaje, że sam się zdziwiłem ile można przeczytać kodu w ramach implementacji jednej funkcji. A bo trzeba sprawdzić co przyjmuje funkcja, co ona zrobi z naszym obiektem. Jak ona jest wykorzystywana i gdzie?

Wniosek

Powinniśmy pisać bardzo czytelny kod, aby nie marnować jeszcze więcej czasu na jego czytanie. Skoro swoje zasoby wykorzystujemy w ramach tego nie marnujmy ich. Im czytelniejszy kod tym szybciej napiszemy kolejną funkcjonalność. Im więcej mało czytelnego kodu tym dłużej będziemy się zastanawiać co jest napisane zamiast co jeszcze napisać. Zapraszam do komentowania.

Comments

Post a Comment

Popular posts from this blog

Why TDD is bad practice?

By -
Image
Did you listen that TDD is bad? What do you think about it? I have my opinion about it! TDD is bad because... We don't have time to write tests first - I think this is a good point. I sometimes don't have time for that. Why? Because I need to do quickly fix on our code and deploy it. In this case I don't have time to create test after wrote production code too. The even worse case is when we have tested this part of our code and test after change doesn't work. I don't like this, because I must read tests and thinking about repair tests for new logic. I really don't like this. I would like to create new test and remove old every time when I have that situation. What's wrong with the test first on this case? Nothing, because if you have time to write tests after create code, you have time to create test before it. Don't you think so? We know how will implement it, but we don't know how testing it - I think a lot of developers have this problem,
Read more >>

How correctly imitate dependencies?

By -
Image
This is continuous of my previous post about why we should imitate our dependencies. I did it not long ago. I though about how do it properly and when I can say that it is correct. Start from test and real dependencies I am starting from the tests. I wrote the simple tests which, I though, are correct. That was my learned about dependencies. I had the good situation that I had some prepared tests before. During the writing test I got a knowledge. A lot of time, I verified what the system return. After it, I got the full automated tests for my dependency. Now, I am sure that dependency works like I think. Like my test use it. I think this is a very good advantage. Extract the interface for communicating The implementation to communicate is implemented and tested. Our test, if you implement it like functionality test, not code test, should show us, how we want to use our dependency. We know what parameters we use, what methods. We know what we want. That is a place where we must extr
Read more >>

Software development using Angular 5 with Spring Boot

By -
Image
Hi everyone. My last the bigger post is about configuration Spring Boot and Angular 5 . After that instruction we have integrated both technology on one app. If you created it you know that development is very hard in this case. We must waiting for build a client and it isn't effective. We can use webpack-dev-server to speed up this process, so this post is just about it. Angular and webpack-dev-server I think I have to explain webpack and webpack-dev-server. The first tools let pack our angular app to one or more files. This files is bundles. It is for improve speed of our app. Why? Because one page application need all files on start by assumption. The better way is load it using only one connection and one file, because establishing connection taking time. This is a few information about webpack, but what is webpack-dev-server? This is the tool. It serve our that files which webpack compiled, but it working on memory, so we have quick result on our browser. This is a amazing
Read more >>