W jaki sposób pliki specyfikacji powinny być zorganizowane w aplikacji javascript przy użyciu MVC

Question

Chciałbym poznać Twoją opinię na temat sposobu porządkowania plików/katalogów w dużej aplikacji internetowej z wykorzystaniem MVC (np. Szkielet).
Chciałbym wykonać następujące (*). Proszę, powiedz mi swoją opinię.

---

(*)

js 
js/models/myModel.js 
js/collections/myCollection.js 
js/views/myView.js 
spec/model/myModel.spec.js 
spec/collections/myCollection.spec.js 
spec/views/myView.spec.js 

Answer 1

Można znaleźć dobry przykład jak zorganizować swoją aplikację do tego linka

Backbone Jasmine examples

wygląda mniej więcej tak implementacji.

Answer 2

To jak ja tradycyjnie organizowane moje pliki. Jednakże odkryłem, że przy większych aplikacjach naprawdę trudno jest utrzymać wszystko zorganizowane, nazwane jednoznacznie itp. "Nowym" sposobem, w jaki o tym pracuję, jest uporządkowanie moich plików według funkcji, a nie typu. Tak więc, na przykład:

js/feature1/someView.js 
js/feature1/someController.js 
js/feature1/someTemplate.html 
js/feature1/someModel.js 

, ale często nie są globalne „rzeczy”, które trzeba jak „użytkownik” lub kolekcji lokalizacjach, które użytkownik zbudowany. A więc:

js/application/model/user.js 
js/application/collection/location.js 

Ten wzór został mi zasugerowany, ponieważ możesz pracować nad zestawami funkcji, pakować je i wdrażać przy użyciu requirejs przy stosunkowo niewielkim wysiłku. Zmniejsza to również możliwość wystąpienia zależności między zestawami funkcji, więc jeśli chcesz usunąć funkcję lub zaktualizować ją za pomocą zupełnie nowego kodu, możesz po prostu zastąpić folder "stuff", zamiast polować na każdy plik. Ponadto, w IDE, sprawia, że ​​łatwiej znaleźć pliki, nad którymi pracujesz.

Moje dwa centy.

Edycja: A co z plikami spec?

Kilka myśli - będziesz musiał wybrać ten, który wydaje ci się najbardziej naturalny.

1. Można wykonać ten sam wzór folderu elementów z plikami spec. Plusem jest to, że wszystkie specyfikacje znajdują się w jednym miejscu. Minusem jest to, że teraz, podobnie jak to, co obecnie robisz, musisz umieścić na pliki jednej funkcji.
2. Można umieścić specyfikacje w folderze "Spec" folderu funkcji. Plusem jest to, że masz teraz rzeczywiste pakiety, które można zawinąć w pojedynczy plik zip, bez szansy na przekierowanie innych prac. Łatwiej też znaleźć bezpośrednio powiązane pliki do pisania testów - wszystkie znajdują się w tym samym folderze nadrzędnym. Minusem jest to, że teraz kod produkcyjny i kod testowy znajdują się w tym samym folderze, publikując go (być może) na świecie. To prawda, pewnie skończysz na kompilacji javascriptu do jednego pliku w pewnym momencie ... więc nie jestem pewien, czy to problem.
3. Moja sugestia - jeśli jest to duża aplikacja i uważasz, że będziesz mieć kilka rąk dotykających plików, pozostaw w folderze plik podobny do "package.json/yml/xml". Tam wyszczególnij produkcję, specyfikację i wszelkie pliki danych potrzebne do testowania (najprawdopodobniej możesz napisać skrypt szybkiej powłoki, aby zrobić to za ciebie). Następnie wypisz krótki skrypt, aby przejrzeć folder źródłowy w poszukiwaniu plików "package.whateverYouChose", pobierz pliki testowe, a następnie zbuduj stronę testową urządzenia. Powiedzmy, że dodajesz inny pakiet ... uruchamiasz "updateSpecRunner" lub jakkolwiek nazwiesz skrypt, a to wygeneruje ci kolejny plik SpecRunner.html (lub cokolwiek nazwałeś plik, na którym uruchamiasz specyfikacje). Następnie możesz ręcznie przetestować go w przeglądarce lub zautomatyzować za pomocą phantomjs/rhino.

Czy to ma sens?