Разное

Что можно почитать о разработке "на бумаге"? Хотелось бы поднять свой уровень в этой области и отойти от варианта "проектирование в процессе разработки".

Проектирование штука такая, что ей нужно тренироваться в реальных условиях (с обратной связью), просто читать про проектирование можно, но не очень эффективно. Можно, конечно, Брукса почитать, или что-то по UML, это безусловно ваш уровень поднимет. Однако, опыт реальной разработки даст вам много больше. Со временем, вы будете с самого начала вызнавать максимальное количество подробностей о проекте и его возможной эволюции и строить архитектуру в соответствии с этими данными. Строить её заранее, прикидывая варианты и время. Лучший рецепт тут - проектировать и проектировать.

PS К сожалению, нет моей библиотеки под рукой, имеется не мало хороших книг, но суть всех здравых советов: поменьше фанатизма и побольше прогматизма. Пол года можно позволить проектировать, если вы уравнениями можете показать, что то, что вы проектируете будет работать именно так, как вы задумали (заводы, мосты, дома). Если вы что-то однозначно высчитать не можете, например, что через 3 месяца потребуется заказчику, то необходимость всестороннего проектирования здорово снижается.

Я это как бы понимаю. То есть я понимаю, что такое - проектирование приложения.
Дело лишь в том, что у меня сейчас появляется ответственность спроектировать ОЧЕНЬ большой проект и мне не по себе. Это не просто приложение, которое пишу я. Это приложение, которое будет использоваться большим количеством людей, и которое будет писать несколько людей. При этом моя задача дать задания этим людям в разбитом виде. Т.е., узконаправленные задания, таск -трекер. На стартовом этапе будет легко. Но потом - будут проблемы. Чтобы их не было, мне бы хотелось понять хоть какую-то истину. Кроме "учиться и учиться" - так как это мой первый опыт руководства группой разработчиков.
брукс == 404

На первом этапе важно договориться, как вы будете именовать переменные и классы. Не смотря на то, что это кажется ерундой, это экономит в последствии массу времени, когда не приходиться перелопачивать горы кода, чтобы вспомнить как, что называется.
Посоветовать что-то конкретное по разбивки задачи сложно, так как неизвестна сама задача, силы и способности сторонних разработчиков. Тут вам придется приобретать опыт по ходу дела. Хорошо бы создать прототип проекта с урезанной функциональностью, чтобы посмотреть что и как в деле (если, конечно, на такие эксперименты есть время). Только не вздумайте его брать за основу - такие проекты обязательно нужно выкидывать.

PS Ссылку на Брукса поправил.

Чтобы не было не проблем, пусть все пишут в стиле MVC. За каждое действие в работе приложения должен отвечать один контроллер, а чтобы контроллерами можно было свободно манипулировать, они должны быть независимы от входящих данных, т.е. какая бы ответственность на контроллере не лежала, желательно, чтобы он не принимал явных параметров, тогда запустить его можно будет из любого места приложения.

второй вариант кода не зависит от входящих параметров, а вот вызов первого уже не везде будет удобным, а может даже и невозможным.

// не правильно class::method($param); // правильно class::method();

с таким подходом к написанию, даже если выяснится, что приложение было изначально не правильно спроектировано, вы легко сможете это поправить.

Не правильно - неправильно
Неправильно - правильно

С таким подходом из програмиста делается кодер негр кукла балбес бетолочь не программист.
И не надо только раздувать, что ассемблер круче php. Слыхали.
Есть чувство меры, а это не правильно и правильно - дело сугубо предвзятое. Оставьте при себе, пожалуйста. Не все эту ересь разделяют.
Я про ООП и местечковые проявления MVC

Я спорить с Вами точно не собираюсь, но хочу чтоб вы знали, что именно из-за таких как Вы и нет никакого развития и прогресса.

Годами люди учатся у тех, кто был первопроходцем во всех этих дебрях, и кто привел все к тому что Вы видите и чем пользуетесь сейчас. Те самые рекомендации, которые когда-то давались для облегчения освоения материала - всегда были чьими-то личными достижениями или примерами. И вместо того, чтобы слепо следовать предписанным кем-то правилам, лучше бы изобрели что нибудь свое, вместо того, чтобы тупо повторять, наследуя проблемы, от которых давно можно было избавиться.

А если вы вдруг считаете мое мнение необоснованным, напишите алгоритм бесконечно беспроблемно расширяющегося проекта.

А вы знаете только два варианта - "все в кучу" и "MVC", и еще два варианта - "процедурная парадигма", "ООП"?

[поправлено модератором]

>Я про ООП и местечковые проявления MVC
Терминология действительно ужасная, а реализация зачастую оставляет желать лучшего. Суть не в этом, а в том, чтобы разделить текст, код и оформление. Если этого можно добиться другими способами - добивайтесь - это действительно здорово помогает в организации проектов. Если в этом помогает ООП и MVC - пользуйтесь, если мешает - идите другим путем.