Как организовать приложение «немного круче» Hello world

Здравствуйте.

Так чтобы не занимать много времени, коротко вопрос такой: что можно прочитать, сделать, какие курсы пройти, чтобы научиться проектировать проекты? Какие есть подходы к проектированию, или есть что-то типа «Архитектура программных систем для чайников»?

Чтобы не все лбом проходить.

Буду очень признателен.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Я бы предложил идти от простого к сложному: сначала прочесть «Рефакторинг» Фаулера и какой-нибудь сборник базовых шаблонов проектирования: или GoF, или Head First Design Patterns, или Марка Гранда, — они все плюс-минус одинаковы, хотя стиль изложения очень разный.
А дальше уже по желанию почитать по микроуровню Clean Code или Implementation Patterns, и по макроуровню шаблоны корпоративных приложений.
Есть и шаблоны другого рода (SOA, интеграционные, и т.п.), но их можно почитать в отдаленном будущем (или вообще не читать, они нужны далеко не на каждом проекте).

Что можно прочитать, сделать, какие курсы пройти, чтобы выиграть в Олимпийских играх?

Нужна практика.

Не совсем так. Практика — это уровень физкультуры. Олимпийские игры и вообще сколь-либо серьезного уровня спорт — это уже профессионального уровня тренировки и профессионального уровня тренер. Самостоятельно этого не достигнешь. Это что касается «по аналогии». ))

Да, безусловно рост в болшем колективе чем 3 разработчка — это хорошо. Как минимум должен быть кто-то кто будет наставлять, ну или раздавать подзатыльники. Но не всегда и не у всех получается.
Да я и не претендую стать супер топовым кодером. Мне бы научиться применять принципы хорошего тона и содержания в своих локальных задачах.

Речь была только об аналогии

чтобы выиграть в Олимпийских играх

Что касается «учебного приложения» — здесь ничего архисложного и специального нет. Берется задача. Для начала максимально простая в плане «исчислимой сложности», но решающая какой-то очень практический и измеримый вопрос. Для неё делается программная реализация. Всё.

Внимание при этом уделяется сразу двум вещам и их взаимодействию: Хм... точнее — трём:
0) анализу задачи и составлению плана её реализации
1) чисто технической реализации
2) процессу, включая организационные моменты вроде плана, и технические моменты, вроде инструментов планирования и технических вроде git/svn и билд-системы или хотя бы простейших требований получения результата в виде «готовом для компиляции и запуска на любом другом компьютере кроме конкретно этого конкретно этого программиста». В поиске решений и решении последних моментов и есть очень много реальной практики потом реально помогающей в реальной работе.

Плюс такого подхода в том, что идет тренировка именно «промышленного подхода», а не «программиста суть есть вещи самом в себе».

Купа теорії нічого не дасть на перших етапах.
Вона набагато краще заходить, після написаних декількох невеликих проектів.
тобто
while (true)
{
code();
read();
}

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

Это видимо результаты незрелости.

Если проекты отличны от CRUD’а, то столкнешься независимо от того сколько ты оттарабанил как синьор.

Хм, я так понял вас интересует архитектура организации кода? Попробуйте почитать про патерны MVC и MVVM. Они достаточно популярный, по ним есть огромное количество статей, разжевано до максимума.

Благодарю. Я читал об этих паттернах и стараюсь применять их если есть возможность.
Но трабла в том, что часто мне сложно представить системму полностью(учесть все требования заказчика, продумать вссе необходимые составляющие). И позже эти недочеты приходится перекрывать костылями, которые портят эти паттерны.

я бы советовал начать с изучения вот этого: www.linux.org.ru/...source/11041572

это шутка или я не понял чего-то?

возможно я не так понял вопрос.

Это очень похвально узнать теорию, а не просто ваять одноколесные велосипеды, не переставайте читать книги, даже когда появится ЧСВ. Martin Fowler Signature series, очень полезные книги в черных обложках, читать надо все, но из полезных:
www.ozon.ru/...ail/id/1616782
www.ozon.ru/...ail/id/4884925
www.ozon.ru/...ail/id/3938906
www.ozon.ru/...ail/id/3261793

Роберт Мартин Идеальный программист,
Джоэл Спольски, куда ж без него, только фильтруйте дифирамбы вокруг MS, а то рискуете лопнуть от смеха.

По ООП очень интересно
www.ozon.ru/...ail/id/3778443

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

Спасибо. Постараюсь осилить)

Чтобы не все лбом проходить.
Пока не набьешь определенного набора шишек, везде паттерн «визитор» пихать будешь. Имхо, шишки и только шишки.

Лоб не титановый. Да и карман не бездонный, дорого все лбом пробовать.

Просто сколько не наблюдал начитавшихся такого напроектируют, что за голову хватаешься.
Пока шишек не набъешь не осознаешь какие паттерны удобно и когда использовать.
Взять ту же фабрику — один большой проект на нее перешел, только после 3 лет работы на простом pimpl. Фактически до тех пор, пока все не устоялось.
Лично я использую всегда 3 паттерна:
1. Модули должны быть минимально связаны и иметь минимально-возможный интерфейс.
2. Каждый модуль должен выполнять только свою функциональность и не более.
3. Ну и еще разделения логики на слои — их количество определяется задачами (ну это вытекает из двух выше).

Имо, найти проект с ментором, и за годик пройти все что сам за два с половиной

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

Конечно полезны. Но в том-то и дело, что надо праллельно это делать — это сложно.
Поэтому проще бывает набить шишек, а потом почитать и дальше делать правильно.
Или прочитать, набить шишек, минимально применяя шаблоны, а затем снова прочитать.
Фактически все эти шаблоны растут из простого требования: оптимальная декомпозиция задачи на модули, классы. Каждый объект должен иметь минимальный полный интерфейс (как-то так, терминологию из множеств уже призабыл).

Я спорил только с

шишки и только шишки.
Ну и некоторые шаблоны таки не про разбиение на модули (или сильно непрямо про это, Null Object, например) и вообще неочевидные трюки есть.

Взял большой проект, и как описывалось ранее, хоть и читал книжки, не помогло( полно спагетти.

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

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

Почему именно «визитор»??

В моем опыте наблюдал больше всего фэйлов с этим патерном. Начитавшийся влепит его, а потом костылями его обходит. Вот он у меня и стал нарицательным.

SOLID, KISS, DRY и все что можно нагуглить по Design and development principles

Благодарю, прочитаю обязательно.

Подписаться на комментарии