Что почитать по проектированию ПО

Почитай Брукса для начала.

Лучше сразу начинай писать. Результат будет такой же, а времени займёт меньше.

Читать литературу нужно, имея уже какой-нибудь опыт самостоятельного проектирования.

Тоже как-то задавался этим вопросом. У меня есть The Architecture of Open Source Applications отсюда http://aosabook.org/en/index.html . Но я её не всю читал пока. Я не уверен, что есть много книг по архитектуре.

Хотелось бы немного конкретики. Ты не назвал ни область проекта, ни поддерживаемые платформы. С языком определился уже?

С языком определился уже?

Да, java, android, навигация.

Читать литературу нужно, имея уже какой-нибудь опыт самостоятельного проектирования.

Опыт некоторый есть, в основном учился на своих ошибках + отдельные статьи в интернете (по IOC и DI, или отдельные паттерны). Хотелось бы структурировать знания.

Да, java, android, навигация.

И зачем тут проектирование?

0. Юзать будешь готовое API навигации. 1. Карта. Юзать будешь готовую, ибо писать/рисовать карту геморно. 2. Вся основная логика по GPS, ваше местонахождение, куда хотите направиться, блаблабла, соединение с серваком для хранения информации о пользователе и истории - все в одном пакете. 3. Все остальное на сервере вместе с базой данных. 4. Если хочется свою маленькую sqlight'овую базу на телефоне, ее логику в отдельный пакет. 5 PROFIT

Главное здесь - не бросаться сразу писать программу. Подумай, нарисуй схему на бумаге (на чем-нибудь формальном, от UML до нотации Буча).

Современных учебников по проектированию я не знаю, но есть такая вот книга: http://aosabook.org/en/index.html Лучшее обучение - на примерах.

Единственное на выбор: считать ли маршруты на телефоне или на сервере. Имхо проще на телефоне, ибо они достаточно мощные для этого и будет в разы быстрее (+ так как будешь юзать готовое API навигации, оно у тебя уже под рукой). На сервак обращаться только за сохраненными маршрутами или вообще хранить 10 последних в базе на телефоне.

Еще - я бы сделал на Qt. Можно юзать нокловские карты.

Понимаю, что если начинать писать так как обычно пишут СПО — без проектирования, в конце я получу непонятно как работающую кучу индусского кода.

показное тролльство. тс-а в игнор

Единственное на выбор: считать ли маршруты на телефоне или на сервере.

Маршруты считаются на телефоне. Есть несколько компонентов (модуль навигации, модуль загрузки графов навигации с сервера, модуль привязки к дороге и т.д.). У всего этого есть состояния (загружено, загружается, сбой загрузки — файлы на карте памяти куда-то пропали из-под носа) и остальные модули должны адекватно реагировать на изменение состояния одного. Все это разумеется с активным использованием потоков. Думаю сделать глобальный конечный автомат с блокирующими listener'ами на переходы.

Пожалуй последую советам — буду рисовать архитектуру на бумаге, если возникнут трудности — гуглить и читать соответствующие статьи. + GoF как классику все таки почитаю.

Почитай своего тимлида. А нету тимлида, который будет бить тебя по морде чайником, - как же ты научишься?

Маршруты считаются на телефоне.
модуль загрузки графов навигации с сервера

взаимоисключающненько. карты на телефоне, алгоритмы на телефоне, зачем таскать какие-то графы с сервера?

модуль навигации, модуль загрузки графов навигации с сервера, модуль привязки к дороге и т.д.). У всего этого есть состояния...

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

Дейкстру почитай, так же Вирта почитай и сердцем своим.

Что можно почитать по этой теме. design patterns я так понимаю для начала

Не больше 100 строк в одной функции и не больше 1000 строк в каждом файле. Нормальные имена переменных и классов. Вот все что нужно знать тащемта - дальше начинай писать, и чем быстрее тем лучше. Юзай TDD - написал что-то, тут же зафигачил тест, прогнал, двигаешься дальше. Не трать время на проектирование. Главное чтобы ключевые моменты были в основном покрыты тестами. Быстренько делаешь proof of concept версию и ее выкатываешь. Смотришь - надо кому-то или не надо. Дальше уже думаешь что где поправить чтобы работало стабильно и гладко.

Юзай TDD - написал что-то, тут же зафигачил тест

Гуру TDD в треде, все в бэклог!

SOLID, YAGNI

Малахов+ на ЛОРе посоны.

В TDD тесты пишутся до кода.

Глянь на аву и ты сразу всё поймёшь =)

Понял, это его хозяин =)

Присоединяюсь к вопросу. По профессии я не программист - несколько раз пытался делать свои проекты - увязал ближе к середине. Знание языка и SDK не помогали. Мне интересно - это фундаментальных знаний не хватает или наоборот рука не набита практикой на микроскопических задачах.

По профессии я не программист

всё, что еще надо-то? я вот не хирург и людей оперировать тоже не получается, где-то к середине зависаю, токо разрезать могу

Не пиши комментариев без смыслового наполнения.

Мне интересен оптимальный (для моей ситуации) метод улучшения этого навыка, чтобы иметь возможность автоматизировать более сложные задачи, чем я могу сейчас.

оптимальный (для моей ситуации) метод улучшения этого навыка, чтобы иметь возможность автоматизировать более сложные задачи, чем я могу сейчас.

Какой слог! Неудивительно, что ты не умеешь программировать.

http://users.ece.utexas.edu/~adnan/pike.html

годно после почетания Дейкстры унд ВиртаВорта

Тут пишут про всяких Дейкстр и т.п. Это конечно полезно... но я бы посоветовал для начала:
1.Object Oriented Analysis Design
2.Design Patterns
Можно ещё банду четырех почитать, но там примеры на SmallTalk
Конечно не стоит ожидать что прочитав эти книги вы сразу станете мега программистом, но понимание своего и чужого кода несомненно улучшится.

Проектирование условно связано с разработкой (о чем тут все лестно, ТС в том числе обменивались знаниями). Итак, поехали:

• 97 этюдов для архитекторов программных систем
• IT-проекты: фронтовые очерки
• Совершенный код от Макконнелла
• Идеальная архитектура. Ведущие специалисты о красоте программных архитектур.
• Мифический человеко-месяц
• Peopleware (человеческий фактор в программировании)
• Книги и очерки Джоеля (Джоел о программировании, Софт - отстой! и др.)
• Пионеры программирования. Диалоги с создателями ЯП.

Их будет интересно читать, когда ты уже сделаешь свой проект. Научить тебя как проектировать они не научат.

Есть несколько общеизвестных базовых принципов. Самый главный из них: архитектура не описывает реализацию. Т.о. на бумаге, в UML ты нигде не должен ссылаться на реализацию. Как только речь идет о реализации, наступает этап разработки, его результатом является кодирование.

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

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

Стив Макконнелл.

С. Макконнелл «Совершенный код»

S.O.L.I.D, YAGNI не будут излишними

https://ru.wikipedia.org/wiki/Начала_(Евклид)#.D0.9A.D0.BD.D0.B8.D0.B3.D0.B8_...

http://mixmastamyk.bitbucket.org/pro_soft_dev/

Написанные уже кем-то код. Серьёзно, читать грамотно написанный чужой код весьма полезно.