Как организовать приложение «немного круче» Hello world
Здравствуйте.
Так чтобы не занимать много времени, коротко вопрос такой: что можно прочитать, сделать, какие курсы пройти, чтобы научиться проектировать проекты? Какие есть подходы к проектированию, или есть что-то типа «Архитектура программных систем для чайников»?
Чтобы не все лбом проходить.
Буду очень признателен.
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівбанальность — чтобы научиться писать код, надо писать код
замути собственный проект на любую тему которая тебе интересна
начни писать так как умеешь . добавь к нему юнит тесты
после того как поймешь что он плохо расширяется, или что-то мешает дальнейшему развитию, начинай рефакторить
Я бы предложил идти от простого к сложному: сначала прочесть «Рефакторинг» Фаулера и какой-нибудь сборник базовых шаблонов проектирования: или 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
это шутка или я не понял чего-то?
возможно я не так понял вопрос.
Structure and Interpretation of Computer Programs
mitpress.mit.edu/.../book/book.html
Это очень похвально узнать теорию, а не просто ваять одноколесные велосипеды, не переставайте читать книги, даже когда появится ЧСВ. 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
Дома еще валяется старая и толстая книга по проектированию, забыл как называется. Вспомню — допишу.
Спасибо. Постараюсь осилить)
Лоб не титановый. Да и карман не бездонный, дорого все лбом пробовать.
Имо, найти проект с ментором, и за годик пройти все что сам за два с половиной
Не только, книжки тоже полезны. Хотя тут почему-то наоборот, только книжки рекомендуют. Делайте большой проект, без него малореально почувствовать, зачем надо всё то, что в книгах. А на мелких проектах часто вредны шаблоны из книг. Особенно внимательно надо читать, когда что применять, особенно где про размер задачи, только про это оч. мало пишут.
Я спорил только с
Ну и некоторые шаблоны таки не про разбиение на модули (или сильно непрямо про это, Null Object, например) и вообще неочевидные трюки есть.Взял большой проект, и как описывалось ранее, хоть и читал книжки, не помогло( полно спагетти.
Но и просчитать, разбить программу на множество модулей не так просто(я не могу удержать такое количество единиц в голове, при этом помня особенности работы(костылей) каждой), тем более если такое разбение сильно сказывается на производительности или времени загрузки страницы(сайт с большим количесвом джаваскрипта).
Почему именно «визитор»??
SOLID, KISS, DRY и все что можно нагуглить по Design and development principles
про YAGNI забыли((
Стив Макконел «Совершенный код»
Благодарю, прочитаю обязательно.