Почему качество кода не популярно? [закрытый]

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

Сколько разных вопросов о качестве кода вы можете придумать? Вот почему нет 50 000 вопросов о «качестве кода».

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

Я также видел более чем достаточно статей о непрерывной интеграции.

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

Да правда? Даже если ваш начальник говорит: «Я не буду платить вам за то, что вы тратите время на модульные тесты»? Даже если вы работаете на какой-то встроенной платформе без фреймворков для модульного тестирования? Даже если вы работаете в сжатые сроки, пытаясь достичь какой-то краткосрочной цели, даже ценой долгосрочного качества кода?

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

Лично я устаю от дискуссий о «качестве кода», потому что они, как правило,

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

Я определенно заинтересован в написании высококачественного кода . Меня просто отвлекают люди, которые обычно говорят о качестве кода.

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

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

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

Я считаю, что модульное тестирование делает меня более продуктивным, но я видел много плохо отформатированного, нечитабельного, плохо спроектированного кода, который прошел все тесты (как правило, код «долго в зубах», который исправляли много раз). Пройдя тесты, вы получите достойную дорогу Skoda, а не мастерскую Bristol . Но если у вас «низкое качество кода», вы прошли тесты и последовательно выполняете требования пользователя, тогда это действительная бизнес-модель.

Я пришел к выводу, что разработчики не хотят писать тесты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроме того, комментирование не так "круто", как написание красивого фрагмента кода.

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

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

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

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

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

Был там - видел это.

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

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

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

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

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

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

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

Другая причина - нехватка времени. Когда вам назначена задача, в которой написано «Время завершения: O, 5 человеко-дней», у вас есть время только на ее реализацию и поверхностное тестирование, а не на то, чтобы думать обо всех возможных случаях и отношениях с другими частями проекта и писать все необходимые тесты. На реализацию чего-то может уйти 0,5 дня и пара недель на написание тестов. Если вам специально не дано указание создать тесты, никто не поймет, что огромная потеря времени приведет к крикам / плохим отзывам. И нет, для нашего сложного корпоративного приложения я не могу придумать хорошего тестового покрытия для задачи за пять минут. Это займет время и, вероятно, очень глубокое знание большинства модулей приложения.

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

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

Это похоже на разницу между теорией и приложением.

Модульное тестирование требует дополнительной работы. Если программист видит, что его продукт «работает» (например, нет модульного тестирования), зачем вообще? Особенно, когда это не так интересно, как реализация следующей функции в программе и т. Д. Большинство людей просто ленивы, когда доходит до этого, что не совсем хорошо ...

• Лень / Скучно
• Руководство считает, что в этом нет необходимости - Невежественное отношение «Просто делай правильно».
• «Этому небольшому проекту не нужен код. управление качеством "превращается в" Сейчас было бы слишком дорого реализовать управление качеством кода на этом большом project "

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

Calculating vector flow control - PASSED
Assigning flux capacitor variance level - PASSED
Rerouting superconductors for faster dialing sequence - PASSED
Running Firefly hull checks - PASSED
Unit tests complete. 4/4 PASSED.

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

Почему качество кода так непопулярно?

Потому что наша профессия непрофессиональна.

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

Думаю, ответ такой же, как и на вопрос «Почему код качество не пользуется популярностью? »

Я считаю, что главными причинами являются:

• Лень разработчиков. Зачем тратить время на подготовку модульных тестов, пересмотр решения, если оно уже реализовано?
• Неправильное управление. Зачем просить разработчиков справиться с качеством кода, если есть тысячи запросов на новые функции и программисты могут просто реализовать что-то вместо того, чтобы заботиться о качестве чего-то уже реализованного.

Проверка кода - это не точная наука. Используемые показатели в какой-то мере спорны. Где-то на этой странице: « Вы не можете контролировать то, что не можете измерить »

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

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

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

• Что тут измерять?
• Как это измерить?
• Кто будет его измерять?
• Что я получу / потеряю от его измерения?

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

Более того, контроль качества программного обеспечения и программная инженерия в целом являются относительно новой дисциплиной. До сих пор много места для программирования занимали кибер-ковбои. Сколько раз вы слышали, что «любой» может программировать? Конечно, любой может написать код, но не каждый может быть программистом.

РЕДАКТИРОВАТЬ *

Я наткнулся на этот документ (PDF) , который принадлежит парню, который сказал: « Вы не можете контролировать то, что не можете измерить ». В основном он говорит, что контролировать все не так желательно, как он сначала думал. Это не точный рецепт приготовления, который можно слепо применять ко всем проектам, которые школы программной инженерии хотят заставить вас думать.

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

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

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

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

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

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

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

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

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

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

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

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

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

Это довольно просто, если принять во внимание пословицу инженеров «Хорошо, быстро, дешево: выберите два». По моему опыту, в 98% случаев это быстро и дешево, и по необходимости должен пострадать другой.

Качество кода непопулярно? Позвольте мне оспорить этот факт.

На таких конференциях, как Agile 2009, проводится множество презентаций по непрерывной интеграции, а также по методам и инструментам тестирования. Технические конференции, такие как Devoxx и Jazoon, также имеют свою долю этих тем. Существует даже целая конференция, посвященная непрерывной интеграции и тестированию ( CITCON , которая проходит 3 раза в год на 3 континентах). На самом деле, лично я считаю, что эти разговоры настолько распространены, что они на грани того, чтобы стать для меня совершенно скучными.

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

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

По сути, это сводится к тому, что эти методы все еще достаточно новые (TDD 15 лет, CI менее 10), и им приходится конкурировать с 1) менеджерами, 2) разработчиками, чьи методы «работали достаточно хорошо. пока "(что бы это ни значило). По словам Джеффри Мура, современные методы обеспечения качества кода все еще находятся на ранней стадии внедрения. Пройдет время, пока вся индустрия не примет их.

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

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

Наверное, каждый Java-разработчик знает JUnit ...

Хотя я считаю, что большинство или многие разработчики слышали о JUnit / nUnit / других средах тестирования, меньшее количество людей знают, как написать тест с использованием такой среды. И из них очень немногие хорошо понимают, как сделать тестирование частью решения.

Я знаю о модульном тестировании и фреймворках модульного тестирования как минимум 7 лет. Я пробовал использовать его в небольшом проекте 5-6 лет назад, но только в последние несколько лет я научился делать это правильно. (т.е. нашел способ, который работает для меня и моей команды ...)

Для меня некоторые из этих вещей были:

• Поиск рабочего процесса, который включает модульное тестирование.
• Интеграция модульного тестирования в мою среду IDE и наличие ярлыков для запуска / отладки тестов.
• Изучение того, что тестировать. (Например, как проверить вход в систему или доступ к файлам. Как абстрагироваться от базы данных. Как делать mocking и использовать mocking framework. Изучите методы и шаблоны, которые повышают тестируемость.)
• Наличие некоторых тестов лучше, чем их отсутствие вообще.
• Другие тесты можно написать позже, когда будет обнаружена ошибка. Напишите тест, который доказывает ошибку, а затем исправьте ошибку.
• Вам нужно будет попрактиковаться, чтобы добиться успеха.

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

РЕДАКТИРОВАТЬ:

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

РЕДАКТИРОВАТЬ:

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

РЕДАКТИРОВАТЬ: В этом блоге я подробно останавливаюсь на некоторых из приведенных здесь причин против модульного тестирования.

Это напоминает мне эту пародию на Монти Пайтон :

«Захватывающе? Нет, это не так. скучно, скучно, скучно, скучно, и без того скучно. "

Я бы сказал по многим причинам.

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

Существует порог, при котором требования к качеству находятся на таком уровне, что требуется модульное тестирование.

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

Модульное тестирование также неэффективно при обнаружении проблем, которые не рассматривались. То есть модульное тестирование плохо имитирует неожиданное. Если вы не учли, что может случиться при отключении электроэнергии, если сетевая ссылка отправляет неверные данные, это все еще правильный CRC. Писать тесты для этого бесполезно.

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

«Есть распространенные оправдания для того, чтобы не писать тесты, но они всего лишь отговорки».

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

Качество кода субъективно. Субъективные темы всегда утомительны.

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

В 99% случаев нет никаких сторонних последствий для низкого качества кода (если только вы не создаете программное обеспечение для космического переключения или переключения поездов).

• Это работает? = Бетон.
• Это красиво? = В глазах смотрящего.

Прочтите Мифический месяц человека Фреда Брукса. Серебряной пули нет.

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

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

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

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

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

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

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

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

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

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

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

Люди не имеют общего представления о том, что «хорошо» означает для кода. Многие люди опускаются до уровня «Я запустил это» или даже «Я написал это».

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

http://agileinaflash.blogspot.com/2010/02/seven-code-virtues.html

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

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

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

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

кто-то может нарушить ваши тесты и сказать, что он не знает, как это исправить или прокомментировать (если вы используете maven).

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

Вы можете использовать фреймворк вроде HtmlUnit , но его очень сложно использовать. Selenium прерывается при каждом изменении на веб-странице. Тестирование SQL практически невозможно (вы можете сделать это с помощью DbUnit , но сначала вы должны предоставить для него тестовые данные. Тестовые данные для 5 соединений - это большая работа, и нет простого способа их сгенерировать) . Я не знаю вашего веб-фреймворка , но тот, который мы используем, действительно любит статические методы , так что вам действительно нужно потрудиться, чтобы протестировать код.