Процесс комментирования и улучшения уже написанной программы?

Question

Пожалуйста, позвольте моему вступлению правильно определить объем моего вопроса:

Я все еще очень новичок в мире программирования. Все это началось для меня, когда у меня была идея для программного обеспечения, но нет опыта программирования. В итоге я выбрал программу аутсорсинга, чтобы получить программу, и спустя почти год у нас она появилась и работает.

Эта конкретная программа написана на php и на 100% основана на сети. Мы используем много AJAX, JQuery и т. Д.

Теперь, год спустя, я учусь и учусь везде, где могу (много учусь здесь !!!). Сейчас я в основном сосредотачиваюсь на Java, чтобы развить Objective-C и развлечься на iPhone (наверное, 99 % всех других начинающих программистов)

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

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

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

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

Часто ли программист заходит в проект очень далеко, а затем "убирает" беспорядок, чтобы продуктивно продвигаться вперед?

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

Спасибо! Joel

Answer 1

Мы называем это « рефакторинг », и это важная часть программирования.

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

http://www.testingtv.com/2009/09/24/test-driven-development-with-refactoring/

Затем вы можете внести изменения и запустить тесты, чтобы убедиться, что ваши изменения не сломали ничего.

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

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

Answer 2

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

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

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

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

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

Я вижу это как показатель одной из двух вещей:

1. То, что код написан не очень хорошо.Да, это очень субъективно.-ИЛИ-
2. То, что вы еще не до конца понимаете все, что вам нужно.-ИЛИ-
3. Немного и того, и другого.

Написание хорошего кода, раскрывающего намерения, сложно и занимает годы практики.

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

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

Часто ли программист заходит в проект очень далеко, а затем "убирает" путаницу, чтобы продуктивно продвигаться вперед?

К сожалению, это так.Требуется лот усердия, чтобы не попасть в эту ловушку.Постарайтесь каждый день улучшать свой код.

Answer 3

Я не знаю, что это не то место или нет, но я отвечу, как смогу:

Часто ли программист заходит в проект очень далеко, а затем "убирает" беспорядок, чтобы продуктивно продвигаться вперед?

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

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

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

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

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

Answer 4

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

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

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

Answer 5

Часто ли программист заходит в проект очень далеко, а затем "убирает" путаницу, чтобы продуктивно продвигаться вперед?

Это определенно характерно для почти КАЖДОГО программиста:)

Сказав это, помните принцип IIABTFI. Если это не сломано, не исправляйте это.

Понимание того, как работает программа и какие части полезны.

Попытка улучшить его без конкретной цели и бизнес-цели не имеет смысла.