Trzeba wybierać wzgórze, na którym się walczy. Większość można na luzie dwoma tabelami, ale są też miejsca na algorytm, który rzeczywiście robi robotę.
Wiadomo, time to ship jest ważny, ale kurde wydajność kluczowych elementów również
@LondoMollari Tak. Działający kod ktory jest nieutrzymywalny jest tak zły jak niedziałający. Robienie wyszukanej architektury jak utrzymywał też będzie potem praktykant przyniesie więcej szkód jak pożytku.
Dosłownie tydzień temu łatałem kod, gdzie architektura była przeliękna i nowoczesna, ale nikomu nie chciało się sprawdzić wydajności na nawet przeciętnym rozmiarze danych :P
Wiadomo, time to ship jest ważny, ale kurde wydajność kluczowych elementów również
@Ragnarokk No jasne, wszystko zależy od przypadku, a senior od juniora właśnie różni się tym, że wie w którym przypadku czego użyć. Cackanie się, żeby algo, które realnie pracuje z listą 5-10 elementów, przerobić z O(n^2) na O(n*log n), to zagranie właśnie typowe dla juniorów.
Najistotniejsza moim zdaniem jest prostota koncepcyjna kodu, bo to mocno wpływa na późniejszą rozszerzalność softu, oraz bezpieczeństwo. Przedwczesna optymalizacja z reguły bardziej szkodzi niż pomaga.
@LondoMollari Tak. Działający kod ktory jest nieutrzymywalny jest tak zły jak niedziałający. Robienie wyszukanej architektury jak utrzymywał też będzie potem praktykant przyniesie więcej szkód jak pożytku.
Dosłownie tydzień temu łatałem kod, gdzie architektura była przeliękna i nowoczesna, ale nikomu nie chciało się sprawdzić wydajności na nawet przeciętnym rozmiarze danych :P