если вы перейдете на русский язык, число адекватных собеседников может увеличитьсяGoldsmith писал(а):...с TDD. ... особенно если придерживаться четырехфазного паттерна
Да, потому что здесь Вы едины в двух лицах, а там была команда независимых тестеров из 20 человек.Goldsmith писал(а):Конечно. Никто ведь не мешает написать пустой тест, который на самом деле ничего не проверяет и всегда проходит успешно.
Я всегда сочетаю модульное тестирование с TDD. По этой методике при первом запуске тест всегда завершается ошибкой, и можно убедиться, что там не пустышка. Ну и плюс к тому тесты очень простые, особенно если придерживаться четырехфазного паттерна. Ошибиться почти негде.
, для меня: 
Хороший набор. Только интересно к каждому пункту добавить средства, которыми он достигается - инструменты и методы (я вкратце упомяну свои).konmik писал(а):Основными составляющими качества разработки из моего опыта, в краце являются:
Для ответа на вопрос "почему" часто использую первые документы шаблона ReadySet (http://readyset.tigris.org/). Там довольно толковая "рыба".konmik писал(а):1. Понятность чего и _почему_ вы хотите сделать.
В оформлении порой помогает indent. Также полезна бывает встроенная документация Doxygen, хотя не всем нравится.konmik писал(а):3. Качественное написание кода, оно очень экономит вам время при доработке, переиспользовании и поддержке. Меры тут простые:
- следование выбранному вами стандарту оформления кода - аналог правильно оформленного документа, который приятно взять в руки.
Это тонкий вопрос. Многие авторитеты обоснованно считают, что если логика программы обильно закомментирована, это свидетельствует о ее запутанности, и такой код однозначно следует рефакторить. Кроме того, если код меняется, нужно переписывать и комментарии тоже, иначе они быстро потеряют актуальность. Лучше всего, когда код самодокументирован, а комментарии лишь проясняют отдельные неочевидные детали.konmik писал(а): - комментарии, например каждый оператор ветвления, цикл, расчетная константа ит.п. должны быть описаны,тогда легче следить за логикой и не надо напрягать память
Тут, пожалуй, оптимальнее всего объектно-ориентированное проектирование.konmik писал(а): - разбивка на функциональные модули, т.е. не валим все в одну кучу
Полностью согласен, при правильном применении - незаменимая вещь. И даже при неправильном способна принести некоторую пользу, хотя и существенно меньшую, конечно.konmik писал(а):4. Использование ситемы контроля версий, чтобы понять что, когда и хорошо бы еще и почему делалось. Так же это очень полезно для ситуации
"Ну вот, а пять минут назад работало...".
Один из классиков (не помню, кто именно; кажется, Джон Роббинс) расказывал, что в особо затруднительных случаях подробно рассказывает неудачный алгоритм своему коту, который умеет слушать лучше всех. Высказанная вслух нелепость сразу становится очевидной.konmik писал(а):5. Обсуждение(речью) написанного Вами с кем-то другим. (Здесь на форуме частенько попадаются вопросы поправить написанный автором код
Тема просто огромная. Я, как и обещал, взялся за небольшую статейку (которая, впрочем, по ходу начинает пухнуть, поскольку одно цепляется за другое, и вроде бы ничего нельзя выкинуть без ущерба для понимания). Как только будет результат, оповещу дополнительно, но пару недель, скорее всего, на это потребуется.konmik писал(а):6. _Регулярное_ тестирование позволяющее найти ошибку как можно раньше. Тут тема такая же большая как и разработка и о ней можно беседовать отдельно, если кому интересно, я бы точно умных людей послушал - поучился.
Верно. Зачастую к тестированию относятся с таким же предубеждением, как староверы - к мирским благам: не пробовали, но слышали, что греховно. Попробовав же, убеждаются, что все не так уж страшно.konmik писал(а):Все это звучит наверное избито, но, да, это работает и ,увы, далеко не везде этим пользуются.
Не вижу большой крамолы, только если это сопровождается реальными делами, а не пустословием. В самом по себе управлении нет ничего опасного. К тому же эта дисциплина является обязательной при изучени программной инженерии согласно SWEBOK.konmik писал(а):P.S.
Да и еще "Управление качеством" термин опасный, и лучше его в суе, а особенно перед руководством не упоминать
Погодите совсем чутокARV писал(а):если вы перейдете на русский язык, число адекватных собеседников может увеличитьсяGoldsmith писал(а):...с TDD. ... особенно если придерживаться четырехфазного паттерна
Аналогично.konmik писал(а):Кстати, давайте сойдемся в определениях
модульное тестирование - это уровень тестирования,
а TDD - это одна из методологий разработки софта
Goldsmith писал(а): Только интересно к каждому пункту добавить средства, которыми он достигается - инструменты и методы (я вкратце упомяну свои).
Крамолы тут нет, но "приключений" себе нажить можноGoldsmith писал(а): В оформлении порой помогает indent. Также полезна бывает встроенная документация Doxygen, хотя не всем нравится.[/qote]
Еще есть AStyle, ну а я обычно использую форматер в CDT (Eclipse).
Не будем ниспровергать авторитетов, но комментарии и так нужно всегда переписывать. К тому же иногда существует требования на % строк комментариев в коде. А самодокументациая - это действительно хорошо.Goldsmith писал(а): Многие авторитеты обоснованно считают, что если логика программы обильно закомментирована, это свидетельствует о ее запутанности, и такой код однозначно следует рефакторить. Кроме того, если код меняется, нужно переписывать и комментарии тоже, иначе они быстро потеряют актуальность. Лучше всего, когда код самодокументирован, а комментарии лишь проясняют отдельные неочевидные детали.
Мне кажется, что объектно ориентированное программирование имеет несколько ограниченное отношение к микроконтроллерам, если мы конечно не выходим на 32 бита.Goldsmith писал(а): Тут, пожалуй, оптимальнее всего объектно-ориентированное проектирование.
Goldsmith писал(а): Не вижу большой крамолы, только если это сопровождается реальными делами, а не пустословием. В самом по себе управлении нет ничего опасного. К тому же эта дисциплина является обязательной при изучени программной инженерии согласно SWEBOK.
, если Ваше начальство вдруг начнет бегать по офису с этими словами... Я имею в виду формальную аттестацию этой системы.
Прочёл - не понял..Goldsmith писал(а):черкнул несколько слов в своей Wiki:
TDD на первый взгляд кажется парадоксальной, но на самом деле это вполне логично.МитяРа писал(а):Поясни: код пишется лишь в том случае, если есть хотя бы один тест, выдающий ошибку.
как может тест выдавать ошибку, если код, проверяемый этим тестом ещё не написан?
Конечно, интереснее послушать про популярные, легко доступные и по возможности бесплатные инструменты. Если применяете экзотику, то рассказ и правда большой пользы не принесет.konmik писал(а):Я с Вашего позволения свои упоминать не буду, т.к. относятся к размеру предприятия и врятли представляют интерес для широкой публики
Точнее, не всегда, а когда они есть. Если комментариев нет, то и переписывать нечего.konmik писал(а):Не будем ниспровергать авторитетов, но комментарии и так нужно всегда переписывать.
Код: Выделить всё
if (summ > limit) // если сумма превысила лимитКод: Выделить всё
total += payment; // добавить платеж к итоговой суммеТогда деваться некуда, придется писать, чтобы выполнить план по комментариям. Писать желательно что-то вообще не относящееся к теме, чтобы не сбивало с толку, если в код придется вносить изменения.konmik писал(а):К тому же иногда существует требования на % строк комментариев в коде.
Отсутствие избыточности всегда идет на благо - не нужно тратить усилий на согласование дублирующих друг друга частей, как в приведенном выше примере с лишними комментариями.konmik писал(а):А самодокументациая - это действительно хорошо.
Совершенно верно. Но я в данном случае говорил не о программировании, а о проектировании. Наверное, следовало выделить в тексте поярче, чтобы лучше бросалось в глаза. Реализовать объектно-ориентированную программу на "C без плюсов" вполне реально, по этой теме даже есть кое-какая литература, хоть ее и не густо. Точно так же, как структурно спроектированную программу вполне можно реализовать на "неструктурных" Fortran-IV или ассемблере.konmik писал(а):Мне кажется, что объектно ориентированное программирование имеет несколько ограниченное отношение к микроконтроллерам, если мы конечно не выходим на 32 бита.Goldsmith писал(а): Тут, пожалуй, оптимальнее всего объектно-ориентированное проектирование.
Да, согласен, бюрократией можно задушить любое дело. Ну тогда, скажем так, управлять качеством втихаря, без шумных лозунгов, касаясь только сути.konmik писал(а):Крамолы тут нет, но "приключений" себе нажить можно
Согласитесь, трудно описывать цветущие сады на языке эскимосов, а вот пургу и метель самое оно. В принципе ничего, вполне терпимо. Несколько многословнее, конечно, более трудоемко и подчас требует большей аккуратности. Но с учетом бонусов, которые приобретаем взамен (а тут и улучшенная структура программы, и возможность использования многочисленных паттернов, и рефакторинг, и комфортное тестирование с использованием мок-объектов, и еще много всякой полезной всячины), овчинка выделки очень даже стоит. Тем более что (между нами) "старший брат" C++, который думает про себя, что он объектно-ориентированный, тоже далеко не подарок, и тем не менее масса народу пользуются и даже порвут в холиварах любого, кто осмелится озвучить подобную мысль.konmik писал(а):Да на С можно написать что-то похожее на объектное программирование... Но получается обычно не очень хорошо
Я бы скорее отнес это к области комфорта для разработчика, эффективности разработки, рентабельности и так далее. Вполне реально ведь и на ассемблере создать весьма качественный продукт, хотя это и потребует намного больше усилий и времени (плюс на данный момент мне не известно ни одного доступного средства для автоматизированного тестирования программ на ассемблере, хотя разработчики инструментальных средств уверяют, что работа в данном направлении ведется). Так что это соответствие - желательное, но не определяющее по части качества, разве что косвенно.konmik писал(а):Вот вам еще один из аспектов качества: использование нами средства должны соответствовать поставленным задачам и поддерживать технологии которые мы хотим применять.
А теперь давайте посмотрим на процитированные слова несколько абстрактно, отвлекшись от идеи объектного программирования на С и вернувшись к теме качества. Вот они: "многословнее", "более трудоемко" и "требует большей аккуратности" - согласитесь все они могут повлиять на качество и увы не лучшим образом. А вот если "коротко", "легко" и "понятно", тогда почему бы хорошо не сделатьGoldsmith писал(а):В принципе ничего, вполне терпимо. Несколько многословнее, конечно, более трудоемко и подчас требует большей аккуратности. .........
Так ведь весьма уважительную причину вы озвучили совсем недавно:konmik писал(а):А вот если "коротко", "легко" и "понятно", тогда почему бы хорошо не сделать
Причем это не кажется, а так и есть на самом деле, к сожалению. Так что выбор у нас невелик: либо мы находим способ выкрутиться, то есть компромисс между приемлемой трудоемкостью и высоким качеством разработки, либо в принципе отказываемся от идеи качественного ПО для микроконтроллеров нижнего уровня, либо отказываемся от самих этих микроконтроллеров в пользу более навороченных старших собратьев.konmik писал(а):Мне кажется, что объектно ориентированное программирование имеет несколько ограниченное отношение к микроконтроллерам, если мы конечно не выходим на 32 бита.
Немного не понял сказанное, чем не устраивает обьектно-ориентированный язык C++ ? В чем этот язык не подарок?Goldsmith писал(а): Тем более что (между нами) "старший брат" C++, который думает про себя, что он объектно-ориентированный, тоже далеко не подарок, и тем не менее масса народу пользуются и даже порвут в холиварах любого, кто осмелится озвучить подобную мысль.
Давайте начнем с модульного тестирования. И тема довольно-таки простая (по крайней мере, мне она кажется на порядок попроще рефакторинга для начала), да и последовательность правильная: рефакторинг без модульного тестирования не делается (или делается разве что отчаянными парнями), а тестирование без рефакторинга вполне обойдется (хотя с ним все же гораздо лучше).ARV писал(а):профессионалы, познакомьте нас с какой-нибудь системой рефакторинга или тестирования, чтобы пока вы там пишите статьи, мы бы тут скачали да установили, да подготовили свои старенькие проектики для всесторонней проверки на вшивость
языков программирования; Хотели в 2000-х нормальное приделать ан нет все longjump-ами "разносит".