Gandjustas' blog

Фильтр по тегу: качество кода


Простой способ повысить качество решений

image
Наверное каждый из вас сталкивался с такими решениями для SharePoint: решение вроде работает, но постоянно возникают какие-то проблемы, данные не сохраняются, странные падения при, казалось бы, безобидных операциях. Тестеры тратят много времени на такое решение, но исправление одних багов порождает другие. Развернуть такое решение на production ферме оказывается очень сложно, поддержка превращается в ад. Знакомо, да?

Занимаясь разработкой правил анализа кода для SPCAF (http://spcaf.com), я нашел способ как быстро исправить такую ситуацию.

Найдите все блоки кода такого вида:
try
{
    //код
}
catch(Exception e)
{
    //здесь что угодно, кроме throw;
}

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

Исследование


Для тестирования правил я собрал около 70 .wsp файлов, решений SharePoint. Большинство из них — проекты, в которых мне довелось участвовать, и я прекрасно знаю все проблемы, которые возникали при разработке. Я посчитал плотность блоков try\catch без throw и вот что получилось:
  • Самое проблемное решение — 1 блок на 36 строк. То есть почти каждый значимый метод был завернут в такойtry\catch.
  • Решения ...
читать дальше...
добавлено: 15 янв 17 просмотры: 799, комментарии: 0



Простой способ повысить качество решений

image
Наверное каждый из вас сталкивался с такими решениями для SharePoint: решение вроде работает, но постоянно возникают какие-то проблемы, данные не сохраняются, странные падения при, казалось бы, безобидных операциях. Тестеры тратят много времени на такое решение, но исправление одних багов порождает другие. Развернуть такое решение на production ферме оказывается очень сложно, поддержка превращается в ад. Знакомо, да?

Занимаясь разработкой правил анализа кода для SPCAF (http://spcaf.com), я нашел способ как быстро исправить такую ситуацию.

Найдите все блоки кода такого вида:
try
{
    //код
}
catch(Exception e)
{
    //здесь что угодно, кроме throw;
}

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

Исследование


Для тестирования правил я собрал около 70 .wsp файлов, решений SharePoint. Большинство из них — проекты, в которых мне довелось участвовать, и я прекрасно знаю все проблемы, которые возникали при разработке. Я посчитал плотность блоков try\catch без throw и вот что получилось:
  • Самое проблемное решение — 1 блок на 36 строк. То есть почти каждый значимый метод был завернут в такойtry\catch.
  • Решения ...
читать дальше...
добавлено: 01 фев 14 просмотры: 951, комментарии: 0



Опыт работы не имеет значения

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

В 1968 году было проведено исследование продуктивности работы программистов (источник), которое показало что соотношение лучших и худших программистов составило:

  • 20:1 по времени написания кода
  • 25:1 по времени отладки кода
  • 10:1 по скорости работы программы
  • 5:1 по объему кода

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

Но это было давно и в исследовании куча ошибок...

Аналогичные исследования повторялись другими группами ученых на протяжении 30 лет:

  • Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.
  • Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.
  • DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.
  • Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.
  • Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.
  • Boehm, Barry W., and Philip N. Papaccio. 1988....
читать дальше...
добавлено: 27 янв 14 просмотры: 2230, комментарии: 2