Dla mnie pomaga rozbić większy program na mniejsze części. A następnie podziel te kawałki na jeszcze mniejsze części i tak dalej. Każdy program to zbiór małych elementów logicznych.
Weźmy na przykład blog. Chcesz móc tworzyć i edytować posty, które inni mogą czytać. Od razu możesz podzielić projekt na części administracyjne i publiczne. Administrator będzie wymagał co najmniej użytkowników administratora, strony logowania i sekcji do zarządzania blogiem. Sekcję dotyczącą zarządzania blogiem można podzielić na interfejs CRUD (tworzenie, czytanie, aktualizowanie, usuwanie). Utworzenie nowego posta na blogu będzie wymagało sprawdzenia, aby upewnić się, że administrator ma odpowiednie uprawnienia, formularz, sprawdzanie poprawności formularza i możliwość zapisywania w bazie danych. I tak dalej.
Im bardziej rozwiążesz problem lub funkcję, tym łatwiej będzie się nią zarządzać. Dziel i rządź. Gdy będziesz już w stanie zmapować swoje oprogramowanie w ten sposób, możesz sprawdzić, jak różne jego elementy współdziałają ze sobą. Gdzie możesz powtórzyć kod? Co można streścić? Powinien to być proces iteracyjny zarówno podczas planowania, jak i pisania samego kodu.
Poleciłbym dowiedzieć się, od czego powinien zacząć się Twój minimalny zestaw funkcji i wdrożyć go przed dodaniem do niego innych elementów. Będziesz chciał kodować obronnie, aby przyszłe zmiany nie były zbyt trudne, ale jednocześnie nie chcesz implementować półfunkcji, które mogą nigdy nie zostać ukończone. Trudno jest przejść między elastycznością a chęcią bezwzględnego zabijania swoich ukochanych, pożyczenia literackiego odniesienia. Osiąganie dobrych wyników w tym konkretnym działaniu równoważącym wynika wyłącznie z doświadczenia.
I do tego się sprowadza, jak wspomniały inne odpowiedzi: doświadczenie. Jedynym sposobem na to jest po prostu zacząć. Nie martw się tak bardzo od samego początku. Najpierw spraw, aby kod działał, a następnie uczyń go pięknym, a następnie spraw, aby był szybki.
Ponadto, w przeciwieństwie do tego akapitu, nie zwracaj uwagi na bezpieczeństwo na końcu. Powinieneś mieć pojęcie o zagrożeniach dla twojego oprogramowania, ale na początek nigdy nie ufaj wkładowi użytkowników.