Ile razy spojrzałeś na czyjś kod i stwierdziłeś:
Nie używam tego, ponieważ nie wygląda na dobrze napisane.
W tym przypadku „wyglądaj dobrze napisane" może zastąpić:
- „wygląda, jak bym to napisał”
- „wydaje się mieć dla mnie sens”.
Jasne – są chwile, w których używanie kodu open source jest ryzykowne. Wiemy to z różnych programów i usług, które mają luki w zabezpieczeniach. Ale przynajmniej w tym poście traktuj je jako wyjątek, a nie regułę.
Oznacza to, że musimy patrzeć na coś, czego możemy użyć, ale zdecydujemy się nie używać, ponieważ wydaje się, że nie jest napisane w sposób, który naszym zdaniem powinien być napisany.
Priorytetyzacja rówieśników nad użytkownikami
Rozwój jest trudny, ponieważ istnieje kilka kompromisów, które my – lub inny deweloper – musimy poczynić za każdym razem, gdy coś budują.
Patrząc na lewą stronę
Musimy wziąć pod uwagę:
- ograniczenia czasowe i budżetowe,
- jaki paradygmat pomoże nam dostarczyć bryłę w ramach wspomnianych ograniczeń,
- czy ostateczne rozwiązanie naprawdę rozwiązuje główny problem,
- czy będą koszty utrzymania związane ze sposobem, w jaki coś złożyliśmy?
A lista mogłaby być długa.
Rozważanie różnych aspektów rozwoju i debatowanie nad filozofiami budowania czegoś nie jest niczym niezwykłym w naszej branży
Ale jest to również czasochłonne i może okazać się ćwiczeniem, które da wynik zerowy, ponieważ nic z tego nie wynika. (Tak, często może to być pouczające doświadczenie, ale nie zawsze).
Zdjęcie autorstwa José Alejandro Cuffia na Unsplash
Patrząc na zewnątrz w
W praktyce jednak:
- Czy paradygmat użyty do zbudowania rozwiązania ma wpływ na korzystanie z oprogramowania?
- Czy dane oprogramowanie rozwiązuje problem?
- Gdybyś nie był w stanie zobaczyć, jak projekt został zmontowany, jaki wniosek byś wysnuł na temat oprogramowania?
Ostatni punkt może być najbardziej krytyczny, ponieważ dotyczy oprogramowania open source.
Pracuję w branży wystarczająco długo, aby wiedzieć, że często ludzie chcą funkcjonalnego rozwiązania, które rozwiąże ich problem i zakładają, że jest ono bezpiecznie zbudowane.
Z drugiej strony programiści będą analizować kod bardziej niż rozwiązanie, które dostarcza i problem, który rozwiązuje.
Jeśli jesteś programistą, jest czas i miejsce na jedno i drugie. Ale jeśli pozwolisz, aby to drugie uniemożliwiło ci wysyłkę pierwszego, możesz nigdy nie dostać czegoś do wykorzystania przez innych, ponieważ jesteś zbyt zaniepokojony tym, co mogą pomyśleć twoi rówieśnicy.
A kiedy rozwiązujesz problem dla innych ludzi, to oni powinni mieć większe znaczenie niż twoi rówieśnicy.