Для истинных. Как вы правите свой код?

Совершенству нет придела.

Лично у меня как получится, иногда приходится гнать сроки и пишу чтоб работало, потом уже если идут доработки кода или очень большие доработки, то приходится перелопачивать код, комментарии кода - обязательны! Всегда!

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

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

Делаю всегда:
четкое разделение по модулях
комментарии, (всем на зло в Делфи есть все для создания документации, спойлеры, метки кода, мощный рефакторинг, с этим вообще никаких проблем нет, здесь только сочувствую ПХП-шникам...)
код попроще
интерфейс покрасивее, даже если заказчику интерфейс по-барабану
хистори - отчет для заказчика, что било сделано в данной версии
тудулист - что можно сделать или планирую сделать
бонусы по возможности
говорю правду о прогрессе заказа и о возможных проблемах в будущем
тестирую на каждом этапе и перед сдачей
стараюсь писать грамотно по русс. потому что с этим есть проблемы)
под рукой ручка и бумажка, планирование разработки на первом месте, это самое важное (иногда проще набросать что куда на бумаге и уже делать), кто писал большие проекты это думаю и сами знают
открытый Far Manager, FireFox + Google, чтобы быстро найти наработки
кружка чая с лимоном по утрам и всегда открытый балкон, кроме погоди когда морозы
не лезу без необходимости туда где все идеально работает

Цитата ("shapod"):

tvv, можно вопрос?

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

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

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

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

Я лично все пишу по модулям.
И в зависимости от языка использую тот или иной редактор кода.Когда 30 000 строк и вдруг ошибка, то её трудновато найти.
А по модулям когда - пару секунд.)))

Komodo IDE, PSPad editor хорошо выручают.

А я вот уже месяц смотрю на один из своих проектов, которые из разряда "phoenix", или же "динозавр".

Тут ВСЁ нужно изменить и срочно, а то не долетим. И не только названия функций (некоторые не годятся, безграмотны, это напрягает). Багов наплодилось после изменений во внешней среде... Ужас.

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

Не-е-ет. Такой код сейчас не годится. Перепишем.

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

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

Если всё в кучи, смешано - то это ппц.. около 70% времени уходит на разбор этой каши.. чтобы шва добить что там к чему относится..

Модульность, ооп - это хорошо, но иногда так в больших проектах накрутят - чёрт ногу сломит..

Нужно быть сдержанным во всём.

Цитата ("tvv"):

Цитата (okman):"Причесыванием" кода стараюсь не заниматься вообще, даже если руки тянутся.
Потому что небрежный, но рабочий и протестированный код лучше аккуратного, но c подозрением на дефекты.

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

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

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

P.S. Я работал с внутренностями некоторых продуктов Adobe, Intel и HP, а у них там специалисты.
И что, красиво, думаете ?

Цитата ("MMM_Corp"):

Совершенству нет придела.

Одной фразой выразить суть рефакторинга — это божий дар -)

Цитата ("okman"):

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

Кто мешает повторно провести тестирование после модификации кода?
Или кто заставляет сразу отправлять модифицированный код в продакшен минуя инкубатор, QA и т.д.?

Цитата ("okman"):

Юнит-тестами всего не выявить, это давно уже известно.

Юнит-тесты — далеко не единственный способ тестирования.
И также не нужно забывать, что помимо разработчиков есть еще и QA со своими методами тестирования (в том числе и вручную).

Цитата ("okman"):

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

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

Это — вопрос методологии и процесса разработки.

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

Цитата ("tvv"):

Кто мешает повторно провести тестирование после модификации кода?

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

Цитата ("tvv"):

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

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

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

Но что на счет компонентов системного уровня, которые пишутся на языках, близких к машинным (C/асм) ? Представьте себе хотя бы несколько
тысяч строк монолитного, ветвящегося кода для управления неким аппаратным устройством, который месяцами прогонялся на тестовых машинах с разными
версиями операционки и оборудования. Полезете ли Вы в него, исключительно ради декомпозиции и придания стиля ? Я - нет. Категорически.
Да и нечего там "стилизовать", когда реализация является отражением весьма строгих спецификаций, тем более, что многие принципы - компонентность,
расширяемость, ООП, переносимость, согласованность стиля и прочие - на данном уровне либо теряют смысл или не имеют развитой программной поддержки,
либо отрицательно сказываются на производительности. Вот и получаем "спагетти" без единого бага, которое работает на пределе вычислительных мощностей.

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

Цитата ("okman"):

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

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

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

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

Цитата ("okman"):

P.S. Я работал с внутренностями некоторых продуктов Adobe, Intel и HP, а у них там специалисты.

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

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

Цитата ("tvv"):

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

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

Перед внедрением в эксплуатацию очередная версия программы устанавливается на несколько компьютеров и работает в тестовом режиме
около недели или двух, причем иногда специально привлекаются люди для выведения ее из строя. Это дорогое удовольствие, как для меня,
так и для заказчика. Поэтому все обновления и исправления подготавливаются разом, также все отчеты собираются пакетно, до набора
определенной "критической массы". Если и есть небольшой дефект, не сказывающийся на работе программы, его исправление откладывается до
следующего релиза. Именно поэтому я не могу позволить себе так заниматься кодом - его регулярное тестирование в условиях, близких к
эксплуатационным, выливается в серъезные временные затраты для заказчика.
Естественно, гарантии отсутствия багов не может дать никто. Но как по мне - рефакторинг production-кода это хождение по лезвию.

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

Что до средств, то тут еще хуже. Современные компиляторы и средства разработки используют ассемблер только как побочное явление,
достаточно посмотреть на MASM и TASM. И не забывайте, что ассемблер сам по себе не ООП-язык, и здесь нельзя сделать "extract method".
Для подобных языков модульность, согласованность стиля или переносимость - чужеродные понятия.
Зато на профильных ресурсах полно исходников с совершеннейшими реализациями самых разных алгоритмов - от шифрования до работы с
трехмерной графикой, которые лидируют по скорости и количеству FPS. Достаточно заглянуть на тот же wasm.ru.
Назвать методологии разработки авторов этого кода некачественными у меня не поворачивается язык.

Цитата ("tvv"):

Вероятно Вы в том случае видели так называемый индусский код.

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

Цитата ("okman"):

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

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

Посмотрите на свой код через месяц, год, десять лет. Если прольются слёзы умиления "ах, как хорошо" - тогда да. Ну а если, извините, хочется перепахать всё заново? Да и вряд ли он будет работать через десять лет. Его неизбежно придётся править, и не раз, и проходить через завалы, оставленные, невычищенные, ... ужас.

Одна голова хорошо, а две лучше (случай Стругацких), а еще лучше публичное бичевание в видо открытого на растерзание кода.