Axian Ltd.: ну вот коллегам я и хочу задать эту дисциплину, нахожусь в поисках. Но вот перечитать книги по читаемому коду, да,стоит перед тем как изобретать велосипед. Спасибо !
Про несопровождаемость это как?
Ну вот берут люди, меняют код, а комментарии не обновляют. В итоге расхождение логики и комментариев. Хотя логи тоже могут столкнуться с этой бедой, но шанс как мне кажется меньше.
..процесс можно облегчить самодокументированием кода
Вот тоже не всегда помогает раскрыть что же внутри кода происходит и для чего это всё писалось.
Вы какую цель преследуете?
1. Повысить читаемость кода за счёт комментариев-логов.
2. Сбор этих самых логов и их анализ
3. Возможно участие такого логгера в тестировании "на лету"
Проблема комментариев в том что их не сопровождают. Я думаю мой подход был бы более наглядным для описания самих процессов внутри. Плюс сбор логов не тоже самое что и комментарии и их html сборка, хотя в том же php можно программно вытащить комментарии во время выполнения и как-то запаковать. Сам лог можно использовать в боевых условиях, передавать туда аргументы во время выполнения кода и анализировать работу в разных условиях.
Не стоит мешать в коде ORM и предметные модели. У вас должен быть слой Data Access и в нём вы должны хранить репозитории (repository pattern). В идеале ваш Data Access Layer должен состоять из интерфейсов репозиториев ( IUserRepository, ICommentRepository and etc) и их реализации для конкретного инструмента ( PDOUserRepository, DoctrineUserRepository and etc). Всё что делает репозитории это дают удобный способ общаться с базой данных скрывая инструмент который реализует это общение. Так же стоит ознакомится с паттерном Unit of Work.
Далее вы уже можете делать Business Layer в котором вы уже расписываете каждый Domain. Слой бизнес логики ничего не должен знать о Doctrine, PDO или других инструментах, он должен делать простые запросы к хранилищу ( $this->userRepository->create($userDomain) или $this->commentRepository->getAll() ). При этом реализовав один репозиторий на Doctrine вы со временем сможете заменить его на реализацию с помощью PDO или вообще другого источника данных, а код бизнес логики так и не поменяется.
Для всего этого конечно нужно использовать IoC.
По поводу инструментов, берите нативный для framework'a инструмент (yii - ActiveRecord, Symfony - Doctrine ... ) и делайте реализации репозиториев сначала на этих инструментах. Уделите особое внимане проектировки интерфейсов репозиториев и вы получите нужный результат.
REST, MVC , RPC и прочие это всего лишь слой представления. Можете игнорировать, можете не игнорировать. Если вы правильно сделаете Business/Service/Application Layer то потом у этого приложения будет очень легко поменять слой представления. Так однажды я делал проект на Laravel и мне пришлось от MVC уйти в REST API. Миграция заняла чуть меньше недели, так как нужно было просто вызывать нужную бизнес функцию в нужном роуте и всё.
пишут они, а стыдно мне.
Хороший фронэнд разработчик получает не меньше бекэнд разраба.
Другое дело, что фронэндер может закончить свою работу через месяц, а с серверной частью можно и несколько лет возиться.
Хороший фроненд разработчик может стать и UI и UX дизайнером. Там и зарплаты больше и задачи лучше.
Для быдлокода выбирайте wordpress и учите английский.
Там зарубежные ребята платят больше, чем в столицах и знания сравниваются с индусами.
К сожалению видел во многих фраемворках написанных на нетипизированных яп такую фичу, как массив-аргумент.
И очень часто это неудобно и не безопасно в конечном итоге.
Философия этой книги — «Честность в мелочах — вовсе не мелочь».
И я скорее согласен, чем нет.
К сожалению я не могу прийти в магазин и сказать «дайте мне таблеток, после которых я буду выпускать более качественное ПО».
Есть конечно много направлений для развития, но сегодня я бы хотел поговорить об этом.
Читал ваши статьи, но понял что начинаю уходить от DDD. Не хорошо бросать что-то на середине пути, но CQRS+ES в списке следующие. Спасибо, обязательно ещё свяжусь.
Многие исходники из ссылки так и не дали многих ответов… К сожалению они отражают лишь 10% того, что можно найти в 2 книгах из моего вопроса. Однако я обещаю посмотреть их ещё раз :)
dddsamplenet.codeplex.com тоже не пробовал.
Не спорю что DDD решит все проблемы, но есть конкретные слова о слоях и их связи, о некоторых паттернах, тестах, простейших моделей. Но всего этого в одном коде я до сих пор не смог найти.
Спасибо за ссылки. Если получу результат, обязательно напишу полезную статью :)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
