Kod, który działa to za mało

Kod, który działa to za mało, czyli o kosztach bylejakości w projektach Vue/Nuxt

Wielu juniorów (i niestety nie tylko) wychodzi z założenia, że “skoro działa, to jest dobrze”. Problem w tym, że aplikacje frontendowe, zwłaszcza te pisane w Vue czy Nuxt, bardzo szybko rosną. A z nimi rośnie również dług technologiczny.

Brak dbałości o jakość kodu na początku może nie boleć. Ale kiedy produkt dojrzewa, zamiast dostarczać nowe funkcjonalności, zespół grzęźnie w refaktoryzacji, gaszeniu pożarów i walce z zależnościami.

Komponenty nie są śmietnikiem

Dobry komponent to taki, który robi jedną rzecz. I robi ją dobrze.

Przykład złego podejścia

<!-- ProductList.vue -->

<template>
	<div>
		<input v-model="search" />
		<ul>
			<li v-for="product in filteredProducts" :key="product.id">
				
			</li>
		</ul>
		<button @click="fetchProducts">Reload</button>
	</div>
</template>

<script setup>
import { ref, computed, onMounted } from 'vue'

const search = ref('')
const products = ref([])

const filteredProducts = computed(() =>
	products.value.filter(p => p.name.includes(search.value))
)

const fetchProducts = async () => {
	const res = await fetch('/api/products')
	products.value = await res.json()
}

onMounted(fetchProducts)
</script>

Ten komponent:

• pobiera dane,
• filtruje dane,
• obsługuje UI.

I robi to wszystko w jednym pliku. Trudno to testować. Trudno rozszerzać. Trudno zrozumieć komuś nowemu.

Lepsze podejście (zasada S z SOLID – Single Responsibility Principle)

useProducts.ts

// composables/useProducts.ts
import { ref, computed, onMounted } from 'vue'

export function useProducts() {
  const search = ref('')
  const products = ref([])

  const filteredProducts = computed(() =>
    products.value.filter(p => p.name.includes(search.value))
  )

  const fetchProducts = async () => {
    const res = await fetch('/api/products')
    products.value = await res.json()
  }

  onMounted(fetchProducts)

  return {
    search,
    filteredProducts,
    fetchProducts,
  }
}

ProductList.vue

<script setup>
import { useProducts } from '@/composables/useProducts'

const { search, filteredProducts, fetchProducts } = useProducts()
</script>

Rezultat? Komponent robi tylko to, co powinien, czyli wyświetla dane. Logika żyje osobno. Testowanie, refaktoryzacja i ponowne użycie są o wiele prostsze.

Architektura komponentów i dobre praktyki

Vue pozwala na szybką pracę, ale nie zwalnia z myślenia. Oto kilka zasad, które pomagają zachować porządek:

• Smart vs Dumb components – logika w “smart” komponentach lub composables, a “dumb” komponenty tylko renderują dane na podstawie propsów.
• Props + Events, nie zależności – komponenty nie powinny mieć wiedzy o innych komponentach. Komunikuj się przez propsy i emit.
• Typowanie z głową (TypeScript) – lepiej poświęcić 3 minuty na dobre zdefiniowanie typu niż 30 na szukanie błędów runtime’owych.

Code Review to nie formalność

Jeśli code review sprowadza się do „działa? ok”, to można równie dobrze wrzucać kod przez FTP.

Dobre review powinno:

• sprawdzać czy kod jest czytelny (nawet jeśli działa),
• zadawać pytania: „czy to można uprościć?”, „czy to się nie powiela?”,
• wyłapywać wzorce anty-kodu zanim się utrwalą.

Co daje czysty kod?

• szybsze wdrażanie nowych osób,
• mniej regresji,
• więcej czasu na rozwój, mniej na naprawianie,
• kod, którego się nie wstydzisz za miesiąc.

Nie chodzi o perfekcję. Chodzi o intencję, żeby pisać kod, który nie tylko działa, ale który inni będą chcieli utrzymywać.