В последнее время для меня всё больше становится важным вопрос о правильном построении архитектуры программы, стабильной разработке.
Сейчас учусь на 2 курсе. На парах программирования нам давали довольно простые задачки на общие знания языка (C++ / C#). С ними я справлялся легко. Но вот сейчас, когда начал реализовывать собственные проекты, столкнулся с такой проблемой - первую неделю всё отлично. У меня есть примерный план, я вижу картину разработки в целом.
Постепенно кода становится всё больше, мне всё сложнее вносить изменения в существующую архитектуру. Появляются новые проблемы, которые изначально не были предусмотрены. Ко второй - третьей неделе творческая разработка превращается в какую-то рутину. Я копаюсь в своём коде, пытаюсь исправить возникающие проблемы, но при этом возникает ещё несколько других проблем. Код становится тяжело менять. Что-то поменял в одном месте - приходится поменять ещё в 2 - 3х местах, а то и больше. Пропадает мотивация что-либо делать. В итоге я забрасываю проект.
После пары таких неудачных проектов я начал искать литературу, которая бы мне помогла в этом. Книги по чистому коду, сайты по шаблонам проектирования. Я получил много полезной информации, но вот применить данные методы на практике довольно сложно. Я не говорю о правильном именовании, соблюдению общего стиля, избегании дублирования и т. п. Больше меня интересовало именно то, как правильно построить взаимосвязи между модулями, классами, методами; стоит ли оставлять этот метод, либо лучше разделить его на несколько методов; не нарушает ли данный класс принципа единой ответственности...
Вроде бы знания есть, если что знаю, где что посмотреть, а вот как применить, в каком контексте, в каком объёме.
Недавно решил применить шаблонный метод в одном из своих проектов. С одной стороны, теперь я меняю только определённую часть кода, не внося изменений в остальные части, но количество строк по сравнению с предыдущим вариантом очень сильно увеличилось (добавление 1 нового элемента функциональности занимает в 3 раза больше места, чем раньше.
Хочу заострить внимание на принципе единственной ответственности (который гласит, что каждый модуль/класс/метод должен делать только одну определённую вещь), так как считаю, что нарушаю его очень часто. В течение проекта у меня часто возникает желание добавить какой-то функционал в то место, где он не нужен, вместо того, чтобы выделять этот функционал в соответствующие классы. Иногда я даже не замечаю, что у класса не одна ответственность. А замечаю это только тогда, когда уже этот класс начинает расти в геометрической прогрессии, как чёрная дыра, что уже просто не даёт двигаться дальше.
Здесь скорее две крайности, либо нагромождать кучу абстракций, либо оставлять всё на самотёк. И то, и другое - не очень хорошая затея.
Хочу у вас, как у более опытных разработчиков узнать, сталкивались вы с такими проблемами ранее, как вы через это прошли, есть ли у вас какие-либо методики, которые вам помогают разрешать данные проблемы ещё до начала их развития? Что бы вы могли мне посоветовать?
Заранее спасибо за ваши ответы.
Другие языки программирования и технологии
Получение опыта в области программирования (архитектура программы, качество кода).
Ты молодец, что уже на 2-м курсе озаботился всем этим счастьем, из тебя получится хороший специалист.
Но все это дело приходит с опытом.
Тебе придется еще сделать не один такой проект, в котором ты завязнешь, прежде чем ты интуитивно научишься выбирать правильные модели и паттерны.
Но в конце концов у тебя все получится.
Надо просто набить некоторое количество шишек.
Попробуй не хвататься сразу за какие-то гигантские проекты, делай что-нибудь средненькое. Файловый менеджер какой-нибудь, например, там все очень интересно на самом-то деле, несмотря на внешнюю примитивность. И в случае фатальных ошибок проектирования все переделать можно тоже довольно быстро (сие называется мудрым словом "рефакторинг", а на деле это то, что получается сейчас у тебя - "мы так накосячили с проектированием и наворотили столько патчей на патчи, что сами запутались и теперь надо все переписывать").
В общем, больше сиди за компом, тренеруй чугунность попы, и однажды ты вдруг с удивлением обнаружишь себя на холмах Калифорнии.
Но все это дело приходит с опытом.
Тебе придется еще сделать не один такой проект, в котором ты завязнешь, прежде чем ты интуитивно научишься выбирать правильные модели и паттерны.
Но в конце концов у тебя все получится.
Надо просто набить некоторое количество шишек.
Попробуй не хвататься сразу за какие-то гигантские проекты, делай что-нибудь средненькое. Файловый менеджер какой-нибудь, например, там все очень интересно на самом-то деле, несмотря на внешнюю примитивность. И в случае фатальных ошибок проектирования все переделать можно тоже довольно быстро (сие называется мудрым словом "рефакторинг", а на деле это то, что получается сейчас у тебя - "мы так накосячили с проектированием и наворотили столько патчей на патчи, что сами запутались и теперь надо все переписывать").
В общем, больше сиди за компом, тренеруй чугунность попы, и однажды ты вдруг с удивлением обнаружишь себя на холмах Калифорнии.
Конечно сталкивались ))
Решается изучением книжек, чужого (хорошего и плохого) кода и практикой. Да, есть две крайности и задача - найти оптимальный баланс. Для этого есть приемы, некоторые из них можно сформулировать более-менее четко, например "уменьшать число связей" или "избегать побочных эффектов" и др - наверняка у вас уже есть арсенал таких инструментов. В других случаях удачные решения получаются по менее формальным признакам. Например, схожести с естественными объектами или "красотой", "изяществом", получаемых конструкций.
И еще важна гибкость, не стоит превращать эмпирические правила в "уголовный кодекс", выстраивание хорошей архитектуры делается не для того, чтобы все было по правилам, а для того, чтобы код был управляемым, понятным, надежным.
Еще всегда полезно помнить, что задачу можно решить несколькими путями и сразу прикидывать, какие это могут быть пути, чаще обсуждайте с коллегами решения, не стесняйтесь - иногда что-то ускользает от внимания, а человек со стороны увидит лучшее решение (есть даже такой прием, когда работают вдвоем или меняются задачами).
Решается изучением книжек, чужого (хорошего и плохого) кода и практикой. Да, есть две крайности и задача - найти оптимальный баланс. Для этого есть приемы, некоторые из них можно сформулировать более-менее четко, например "уменьшать число связей" или "избегать побочных эффектов" и др - наверняка у вас уже есть арсенал таких инструментов. В других случаях удачные решения получаются по менее формальным признакам. Например, схожести с естественными объектами или "красотой", "изяществом", получаемых конструкций.
И еще важна гибкость, не стоит превращать эмпирические правила в "уголовный кодекс", выстраивание хорошей архитектуры делается не для того, чтобы все было по правилам, а для того, чтобы код был управляемым, понятным, надежным.
Еще всегда полезно помнить, что задачу можно решить несколькими путями и сразу прикидывать, какие это могут быть пути, чаще обсуждайте с коллегами решения, не стесняйтесь - иногда что-то ускользает от внимания, а человек со стороны увидит лучшее решение (есть даже такой прием, когда работают вдвоем или меняются задачами).
Похожие вопросы
- У меня абсолютно нет опыта в программировании. Подскажите универсальный язык программирования и программу.
- Как понять в какой области программирования мне развиваться?
- Какие существуют области программирования?
- Какую область программирования выбрать?
- Подскажите наиболее простые области программирования, которые мог бы освоить практически любой человек?
- Решил спросить совета тех, кто уже работает в своей области программирования, потому что мне трудно определиться
- Какой язык программирования использует программа PureBusic? Какой язык программирования использует программа PureBusic?
- Добрый день. Компьютер все языки программирование понимает как двоичный код ( если я не ошибаюсь).
- Как программисты написали программы для программирования без программ для программирования?
- Как программисты написали программы для программирования без программ для программирования?!