Что я должен делать, когда мой код пахнет?

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

Несколько предложений:

1. Используйте инкапсуляцию для управления сложностью путем разделения функциональности на отдельные строительные блоки. Докажите, что каждый блок работает (с помощью модульных тестов), и вы можете использовать его, не заботясь о его внутренних деталях.

2. Учиться и изучать шаблоны программного обеспечения . Программные шаблоны - это проверенные и проверенные методы для выполнения некоторых общеизвестных задач.

3. Изучите и поймите структуры данных. Изучите подходящее использование и характеристики производительности для каждого типа структуры данных.

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

Вам не нужно знать все это сразу, но вы должны изучить все это с течением времени.

Мой совет: перестань беспокоиться.

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

Итак, напишите больше кода. Завершите свои проекты. Такое ощущение, что код не идеален, вероятно, правильно. И у вас, вероятно, будут проблемы с этим кодом. И когда у вас есть эти проблемы, то вы бы узнать , почему именно это было плохо. Вы узнаете намного больше из личного опыта, чем из «поиска вещей».

Кроме того, не надейтесь, что это чувство «запаха кода» когда-нибудь исчезнет. Когда вы поправитесь, вы исправите некоторые проблемы, но начнете замечать новые, более неясные / продвинутые.

Это общая проблема начинающих программистов. Не парализуйте себя, думая, что все должно быть идеально. Это самый верный способ никогда не закончить проект. Одним из наиболее важных навыков, которые нужно изучать как разработчику, является разница между идеальным и достаточно хорошим . Примите, что каждая система, которую вы создаете, может быть улучшена. Сосредоточьтесь на завершении ваших проектов. После того, как вы закончите, вы можете вернуться и улучшить их. Вот почему у нас версия 2.0, в конце концов.

Должен ли я учиться всему понемногу одновременно?

Надеюсь нет. С другой стороны, вы должны все время учиться и совершенствоваться.

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

Мой лучший совет - сосредоточиться на основах, таких как список, предложенный Робертом Харви. Разработка программного обеспечения - это сложное чудовище, на которое уходят годы, чтобы хоть как-то справиться, особенно в области хорошего дизайна интерфейса. Действительно трудно оценить многие аспекты разработки программного обеспечения, не испытав их на практике. Даже такое базовое, как комментирующий код, может быть недооценено. С первого дня вас учат писать хорошо документированный код. Я признаю, что это было до тех пор, пока я действительно не попытался понять код, который я написал несколько месяцев назад, прежде чем я по-настоящему оценил ценность хороших комментариев. То же самое можно сказать и о многих концепциях программирования. Например, инкапсуляция данных, слабосвязанные модули и четкие чистые интерфейсы.

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

Разработка программного обеспечения - это постоянный опыт обучения. Задавайте тонны вопросов, проверяйте свой код, понимайте причины предложений, которые дают более старшие люди, не бойтесь сомневаться в обоснованности предложений, которые дают более старшие разработчики, и больше всего не боятся ошибиться. В конце концов, фактор инстинкта или чувство подавленности исчезает. Для записи ... учебные кривые отстой.

• Первый: рефакторинг (он все еще пахнет, но будет немного более организованным)
• Второе: посмотрите, можете ли вы использовать Design Patter, чтобы реорганизованные части соответствовали вашей логике.
• Третье: когда дела начинают выглядеть лучше, вспомните время, которое вы потратили на выполнение первого и второго шага. Таким образом, когда вы пишете какую-то новую функцию, вы будете думать о ней, а не как о другом процессе.

Взгляните на книгу Мартина Фаулера « Рефакторинг: улучшение дизайна существующего кода ». Первое, что вы должны сделать, это провести рефакторинг вашего кода , чтобы улучшить читаемость кода и уменьшить сложность, чтобы улучшить его работоспособность.

Когда вы реорганизуете код, вы уже используете шаблоны проектирования , инкапсуляцию кода и т. Д.

Это одна из лучших книг, которые я когда-либо читал на эту тему. Это обеспечивает много полезных рецептов.

Хороший ресурс - Прагматичный Программист . Глава «Разбитые окна» описывает, где вы видите себя. Краткий и содержательный ответ - исправить проблемы.

Когда вы начинаете исправлять свой дизайн, это помогает понять, что вам не нравится в нем. Легко придумать расплывчатые ответы, такие как «это просто повсеместно» или «почему я это сделал там?». Но найдите время, чтобы увидеть, есть ли какие-то общие шаблоны, которые вы использовали.

• Хороший дизайн будет повторно использовать небольшое количество концепций в кодовой базе (идеал - это одна концепция, но на практике вам может понадобиться еще пара)
• Хороший дизайн позволит легко определить, где можно решить проблемы (принцип DRY, принцип SRP)
• Хороший дизайн будет иметь хорошие отчеты об ошибках (относится к пункту выше, но вызывается как отдельный элемент, потому что это часто упускается из виду)

Как только вы поймете, куда вы хотите пойти, сделайте небольшие, легко обратимые шаги, чтобы добраться туда (то есть, это то, что представляет собой Рефакторинг ). Каждый раз, когда вы улучшаете свой код, учитывайте влияние на остальную часть кода. Вы сделали вещи лучше или хуже? По крайней мере, таков мой подход к наведению порядка в хаосе.

Если у вас уже есть некоторый опыт программирования, почему бы вам не изучить некоторые проекты с открытым исходным кодом, которые имеют чистый код ? Вы можете посмотреть на этот вопрос от SO, который имеет некоторые соответствующие ссылки.

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

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

Если вы не опасный монстр, вы должны найти так называемого друга , который может просмотреть ваш код, и наоборот. Кроме того, если вы делаете вещи, которые будут пересматриваться или просто контролироваться другими, это хороший стимул сделать это лучше.

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

Мой совет - примите всерьез каждый из запахов и постарайтесь это исправить. На эту тему есть много хороших книг (чистый ИМХО и ГСНО - лучшие из них). Но больше чем книги идут на конференции, чтобы услышать и обсудить с другими людьми и в сообществах онлайн (список рассылки, группы). Еще лучше попробуйте присоединиться к вашему локальному xxug (dotnetug, jug, xpug и т. Д.) Или найти его.

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