Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті
Здравствуйте.
Так чтобы не занимать много времени, коротко вопрос такой: что можно прочитать, сделать, какие курсы пройти, чтобы научиться проектировать проекты? Какие есть подходы к проектированию, или есть что-то типа «Архитектура программных систем для чайников»?
Чтобы не все лбом проходить.
Буду очень признателен.
банальность — чтобы научиться писать код, надо писать код
замути собственный проект на любую тему которая тебе интересна
начни писать так как умеешь . добавь к нему юнит тесты
после того как поймешь что он плохо расширяется, или что-то мешает дальнейшему развитию, начинай рефакторить
Я бы предложил идти от простого к сложному: сначала прочесть «Рефакторинг» Фаулера и какой-нибудь сборник базовых шаблонов проектирования: или 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 забыли((
Благодарю, прочитаю обязательно.
Victor Mikhaylov
Stanislav Demchenko
Max Ischenko
Alex Fogol
Igor Lytvynenko
anonymous
reality_hacker
anonymous
Vitaly Chernooky
Vitaly Chernooky
Artyom Krivokrisenko
Oleg Kariakin
Eugen Martynov
De Money
Valentin Nechayev
Ruslan Pavlutskiy
Vladislav Povedyuk
Alexandr Barishenko
33 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів