Как сделать шаг назад и посмотреть на код свежим взглядом? [закрыто]

Я провел прошлый год как команда из одного человека, разрабатывающая приложение для богатых клиентов (35 000+ LoC, для чего это стоит). Это в настоящее время стабильно и в производстве. Однако я знаю, что мои навыки были ржавыми в начале проекта, поэтому, без сомнения, в коде есть серьезные проблемы. На данный момент большинство проблем связаны с архитектурой, структурой и взаимодействием - простые проблемы, даже проблемы архитектуры / дизайна, уже устранены.

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

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

Способы подойти к этому:

• Найдите человека, знакомого с технологией и бизнес-проблемами, и обсудите его. Это может быть трудно в команде из одного человека, но, как правило, это лучший вариант.
• Некоторое время работайте над другим проектом. Это также может быть сложно, но даже если взять недельный перерыв, это даст вам новую перспективу.
• Посмотрите на похожие проекты или продукты, такие как продукты с открытым исходным кодом, если таковые существуют. Будьте осторожны, чтобы не копировать код, но они, возможно, подошли к идее совершенно по-другому.
• Выучите новый язык, библиотеку или рамки. Используемые методы могут дать вам понимание того, как подходить к тем же проблемам, что и у вас, по-разному.
• Прочитайте хорошую книгу / блог / журнал по дизайну или языку / структуре. Я не уверен, какой у вас уровень мастерства, но есть много альтернатив в других ответах на этом сайте.

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

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

Продолжайте учиться и расширять свои навыки. Трудно знать, чего ты не знаешь, но когда ты это видишь, этот момент "ага" поразит тебя. Это может быть связано с изучением другого языка или модели дизайна.

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

Пользователи начнут жаловаться. Просто когда ты думаешь, что все замечательно ...

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

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

После того, как вы определили области для работы, попробуйте выяснить, в чем проблема на самом деле. Есть книги, в которых используется систематический подход к классификации проблем дизайна. Взгляните на Рефакторинг Мартина Фаулера , Стандарты кодирования Херба Саттера на С ++ , Чистый код Роберта Мартина и т. Д. У них есть куча «правил», которые позволяют вам объективно взглянуть на свой код.

После того, как вы определили, в чем проблема, вероятно, попробуйте различные способы ее устранения. Например, если вы нарушили правило «предпочитаешь композицию, а не наследование», измените ее на композицию и посмотрите, как она себя чувствует.

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

Попросите другого человека взглянуть на ваш код. Если вы не можете найти другого человека, чтобы посмотреть на него, напишите полное описание взаимодействия, как будто вы собираетесь показать его другому человеку. Процесс попытки объяснить свои решения другому человеку (даже если это просто для практики) может помочь вам действительно понять, ПОЧЕМУ вы делаете вещи определенным образом, и помочь вам увидеть любые дыры в вашей логике.

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

1.) Точка зрения пользователя / клиента - используйте обратную связь

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

2.) Сделайте функциональный анализ вашего кода и визуализируйте его

Некоторые IDE и платформы подталкивают вас, например, к смешиванию пользовательского интерфейса и внутреннего кода. Если вы позволите этому случиться, вы однажды столкнетесь с ситуацией, когда ваша кодовая база вряд ли будет поддерживаться из-за туманных и трудноразрушимых зависимостей. Особенно смешивание кода пользовательского интерфейса с другим кодом может привести к появлению спагетти-кода и избыточной функциональности. Разделите ваш код на функциональные блоки, такие как, например, классы базы данных, классы связи, классы пользовательского интерфейса, базовые классы и т. Д. И присвойте функциональным блокам говорящие имена. Затем визуализируйте функциональность с помощью графического инструмента (я использую инструмент отображения разума), чтобы выяснить, является ли ваша структура достаточно логичной и модульной, чтобы вы могли повторно использовать огромные блоки кода для различных проектов и могли бы заменить их более новыми версиями без большая боль

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

3.) Используйте общие подходы к обеспечению качества

Мой любимый это FMEA. С точки зрения кодирования это означает не только проанализировать, что пошло не так в прошлом, но и подумать о том, что могло пойти не так. Довольно распространенный пример - внезапно оборванное сетевое соединение. После того, как вы это сделали, вы можете классифицировать условия ошибки по таким последствиям, как потеря данных, сбой, неправильный расчет и оценить влияние на пользователя. Если это еще не сделано, определение оптимизированных классов ошибок и исключений и подпрограмм может помочь вам сохранить ваш код чистым и понятным. Лучший способ - реализовать их в каждом новом коде, прежде чем даже начинать писать что-то еще. (Ну, я виноват, что не всегда сам следую этому совету.)

Кроме того, это помогло мне создать и часто обновлять «список предложений по улучшению» для моего собственного кода. (Честно говоря, в моих проектах все еще много кода, которым я определенно не горжусь.) Я также стараюсь не торопиться, чтобы собрать и взглянуть на лучшие практики кода из документации API, конференций разработчиков или журналов разработчиков.

До этого момента нет необходимости трогать ваш код. Это просто понимание того, что происходит не так, и поиск способа улучшить свой код.

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

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

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

Не парься по мелочам.

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

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

Поговорите с пользователями и посмотрите, где они замечают проблемы, связанные с UX или скоростью. Исправьте эти проблемы, стараясь улучшить ваш код.

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

Постепенные изменения могут быть трудными. Цель состоит в том, чтобы не полностью переписать кодовую базу, если вам не нужно. Конечно, сейчас вы лучший программист, чем год назад, но то, что у вас есть, должно работать прямо сейчас. Через 5 лет, когда младший программист жалуется вам на унаследованный код, он должен попытаться исправить его, просто улыбнуться и кивнуть, и не признавать, что вы его написали.

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

Рецензии позволяют тем, кто уже находится за пределами вашей головы, дать вам совет. Stack Exchange Code Review может быть хорошим местом для размещения некоторого кода, который не является частной собственностью вашей компании, для проверки. Вероятно, он не может обрабатывать огромные блоки, но многие программы состоят из большого количества простого кода и некоторого другого кода, который не является простым и создает много проблем. Если у вас есть пример некоторого кода, который является типичным, но повторяется и изменяется во многих местах, он также может быть хорошим кандидатом для проверки. Например, если вы форматируете сообщения, не просите проверять все передаваемые сообщения, только одно довольно сложное примерное сообщение.

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

Существует психология тестирования, которая затрудняет тестирование вашего собственного кода, но мы, безусловно, стараемся делать это во время модульного тестирования. Чтение собственного кода может быть похожей или более серьезной проблемой. Во многих областях используются наставники, конкурсное судейство, тренеры и т. Д. Наши также подходят, если вы считаете архитекторов, системных инженеров и тестировщиков. Клиенты, у которых есть доступ к инструменту сообщения об ошибках или в отдел технической поддержки, сообщат вам о своем внешнем виде, как только будет выпущен продукт. Это еще одна веская причина для подхода Agile - выпускать рано и часто. Вы можете быть единственным разработчиком в вашей компании, но есть люди, затронутые вашим кодом, которые могут дать вам отзыв о нем с некоторой точки зрения.

«Это меньшая проблема, чем я думаю, или это проблема, с которой сталкиваются и другие?»

Sheesh. Уже достаточно. Если код работает, не содержит ошибок и выполняет то, что должен, архитектура не имеет значения. По крайней мере на данный момент.

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

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

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

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

Желательно для этого взять 3 дня. Я обнаружил, что это достаточно долго, чтобы пройти необходимую умственную дистанцию ​​к моей собственной работе и взглянуть на нее глазами большого сообщества (так сказать), а не моего собственного.

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

Наконец, если вы не получили одобрения, скажем, раз в год, смените работу.

• Практикуйте шаблоны проектирования и лучшие практики
• Выберите платформу, инструменты, пакеты и т. Д. В соответствии с требованиями и потребностями вашего приложения - для этого вам нужно прочитать много блогов etch и найти решения для каждой отдельной технической проблемы.
• Создайте проект дизайна / архитектуры и обсудите с кем-то, кто хорош в технических / архитектурных вещах. Улучшите этот черновик, используя отзывы и комментарии. продолжайте делать это, пока не достигнете стабильного состояния.

• Реализуйте код так, чтобы все, что нужно приложению, можно было настраивать и обслуживать

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

Я считаю, что помогает разобраться в проблемах с несколькими умными людьми. Там должна быть конкретная информация. Это 24х7х365 сайт? LoB приложение? Где он работает или размещен?

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