Другие языки программирования и технологии

Получение опыта в области программирования (архитектура программы, качество кода).

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

Сейчас учусь на 2 курсе. На парах программирования нам давали довольно простые задачки на общие знания языка (C++ / C#). С ними я справлялся легко. Но вот сейчас, когда начал реализовывать собственные проекты, столкнулся с такой проблемой - первую неделю всё отлично. У меня есть примерный план, я вижу картину разработки в целом.

Постепенно кода становится всё больше, мне всё сложнее вносить изменения в существующую архитектуру. Появляются новые проблемы, которые изначально не были предусмотрены. Ко второй - третьей неделе творческая разработка превращается в какую-то рутину. Я копаюсь в своём коде, пытаюсь исправить возникающие проблемы, но при этом возникает ещё несколько других проблем. Код становится тяжело менять. Что-то поменял в одном месте - приходится поменять ещё в 2 - 3х местах, а то и больше. Пропадает мотивация что-либо делать. В итоге я забрасываю проект.

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

Вроде бы знания есть, если что знаю, где что посмотреть, а вот как применить, в каком контексте, в каком объёме.

Недавно решил применить шаблонный метод в одном из своих проектов. С одной стороны, теперь я меняю только определённую часть кода, не внося изменений в остальные части, но количество строк по сравнению с предыдущим вариантом очень сильно увеличилось (добавление 1 нового элемента функциональности занимает в 3 раза больше места, чем раньше.

Хочу заострить внимание на принципе единственной ответственности (который гласит, что каждый модуль/класс/метод должен делать только одну определённую вещь), так как считаю, что нарушаю его очень часто. В течение проекта у меня часто возникает желание добавить какой-то функционал в то место, где он не нужен, вместо того, чтобы выделять этот функционал в соответствующие классы. Иногда я даже не замечаю, что у класса не одна ответственность. А замечаю это только тогда, когда уже этот класс начинает расти в геометрической прогрессии, как чёрная дыра, что уже просто не даёт двигаться дальше.

Здесь скорее две крайности, либо нагромождать кучу абстракций, либо оставлять всё на самотёк. И то, и другое - не очень хорошая затея.

Хочу у вас, как у более опытных разработчиков узнать, сталкивались вы с такими проблемами ранее, как вы через это прошли, есть ли у вас какие-либо методики, которые вам помогают разрешать данные проблемы ещё до начала их развития? Что бы вы могли мне посоветовать?

Заранее спасибо за ваши ответы.
Ты молодец, что уже на 2-м курсе озаботился всем этим счастьем, из тебя получится хороший специалист.
Но все это дело приходит с опытом.
Тебе придется еще сделать не один такой проект, в котором ты завязнешь, прежде чем ты интуитивно научишься выбирать правильные модели и паттерны.
Но в конце концов у тебя все получится.
Надо просто набить некоторое количество шишек.
Попробуй не хвататься сразу за какие-то гигантские проекты, делай что-нибудь средненькое. Файловый менеджер какой-нибудь, например, там все очень интересно на самом-то деле, несмотря на внешнюю примитивность. И в случае фатальных ошибок проектирования все переделать можно тоже довольно быстро (сие называется мудрым словом "рефакторинг", а на деле это то, что получается сейчас у тебя - "мы так накосячили с проектированием и наворотили столько патчей на патчи, что сами запутались и теперь надо все переписывать").
В общем, больше сиди за компом, тренеруй чугунность попы, и однажды ты вдруг с удивлением обнаружишь себя на холмах Калифорнии.
АГ
Андрей Гришин
90 752
Лучший ответ
Конечно сталкивались ))
Решается изучением книжек, чужого (хорошего и плохого) кода и практикой. Да, есть две крайности и задача - найти оптимальный баланс. Для этого есть приемы, некоторые из них можно сформулировать более-менее четко, например "уменьшать число связей" или "избегать побочных эффектов" и др - наверняка у вас уже есть арсенал таких инструментов. В других случаях удачные решения получаются по менее формальным признакам. Например, схожести с естественными объектами или "красотой", "изяществом", получаемых конструкций.
И еще важна гибкость, не стоит превращать эмпирические правила в "уголовный кодекс", выстраивание хорошей архитектуры делается не для того, чтобы все было по правилам, а для того, чтобы код был управляемым, понятным, надежным.

Еще всегда полезно помнить, что задачу можно решить несколькими путями и сразу прикидывать, какие это могут быть пути, чаще обсуждайте с коллегами решения, не стесняйтесь - иногда что-то ускользает от внимания, а человек со стороны увидит лучшее решение (есть даже такой прием, когда работают вдвоем или меняются задачами).
Дамир Кадыров
Дамир Кадыров
75 460

Похожие вопросы