Факторы, определяющие высокое качество программного обеспечения

Гы, вы просто не знаете израильтян. То что о себе рассказывает израильтянин надо разделить на 10 и то что останется еще и проверить :-)

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

Проблема найти желающих отдавать свой труд за осознание, что кто-то будет _КОММЕРЧЕСКИ_ использовать его и зарабатывать на этом деньги. В личных целях еще куда ни шло, и то.. Я не Перельман, чтобы сидет жрать грибы и решать математические задачки в свое удовольствие, мне родаки не оставили миллионного наследства

>Проблема найти желающих отдавать свой труд за осознание, что кто-то будет _КОММЕРЧЕСКИ_ использовать его и зарабатывать на этом деньги. В личных целях еще куда ни шло, и то.. Я не Перельман, чтобы сидет жрать грибы и решать математические задачки в свое удовольствие, мне родаки не оставили миллионного наследства

1)Это не проблемы, если есть мозги, опенсорц проектов зарабатывающих деньги море.

2)GPL. запрещает продавать свой софт?

3)GPL запрещает закрывать ПО если ты его форкнул, а он был под GPL.

Хм, ну и написал свои мысли этот Шломи. Возможно, что для своих читателей. А вот кто-то взял это и в новость на ЛОР оформил. А зачем? Я думаю, что подтверждение этого в новость -- ошибка. Тема для Talks.

>Вторая предпочитает трахаться с софтом ?

не неси пургу. Если рассуждать по твоему то microsoft софт, трахает своих пользователей.

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

>Гном, тут сливает.

У гнома лишь две зависимости: от приличного пакетного менеджера и репозитория.

>А первым забыли упомянуть умение писать качественный код

+1024

> Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).

>Чушь. Имхо в хорошей программе настраиваться должно ВСЕ. Чем больше настроек тем лучше. А привычки - дело наживное.

Согласен, что хорошая прога должна иметь максимум настроек (но при условии понятного их описания). Другое дело, что настройки по дефолту, в идеале, должны удовлетворять большинство неискушённых пользователей. Но тут уже много зависит от чутья автора. Закрытость или открытость здесь мало влияет (Open Source при прочих равных рулит).

Херь нереальная, вывод из самого заголовка.

новость не о чём

И ведь наверняка это --- результат комплексных исследований... За что им деньги платят в их пендосиях? Это блин все кому не лень написать могут. Только не хотят, т.к. называется это "толочь воду в ступе".

Первое и последнее: . Программа работает. . В соответствии с документацией.

>>А первым забыли упомянуть умение писать качественный код

Критерии качественного кода будут в его слудующей статье :-)

подготовка почвы для рОмана: «Firefox: teh EPIC FAIL»?

настраиваться должно ВСЁ. но 80% этого всего — из конфигов, безо всякой морды.

My name is Shlomi Fish, I'm a guy

http://www.shlomifish.org/personal.html

он таки опасается, что его примут за девочку?

Хм... Почему этот смешной список мне напоминает притянутые за уши опенсорсные принципы и менее всего - непосредственно программерские правила? :]

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

невнятный пункт. Велосипеды клепать чтоли предлагают?

/* >I'm looking for a girlfriend..." — уписаться, простите, можно. Ничего смешного. Добрая половина ЛОРа перманетно ищет girlfriend's. */

СанСаныч! Ну уж тебе-то - старому чикагскому полисмену - ужо поди все телки покорились. Ужо всех там наверно своею дубинкою пабил

>Шломи Фиш (Shlomi Fish) проанализировал факторы, определяющие высокое качество программного обеспечения. Основные:
> * Программа должна часто обновляться и быть всегда доступна для скачивания или покупки.

Это не показатель качества.

> * Код программы должен быть открытым; лучше, если лицензия позволяет свободное использование кода.

Это не показатель качества.

> * Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).

Это не показатель качества, это юзабельность, юзерофильность.

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

Отчасти да.

> * Программа должна быть хорошо документирована.

Да.

> * Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).

Ниразу не влияет на качество.


> * При выходе новых версий должна сохраняться совместимость со старыми.

Вселенская глупость. "Сделаем старые ошибки новыми фичами"?

> * Программа должна быть быстрой и не должна потреблять много ресурсов.

Ниразу не показатель качества.


Вывод.
Шломи Фиш (Shlomi Fish) — некомпетентен в вопросах разработки ПО.

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

1. "программа должна часто обновляться" - нормально - каждая новая версия
   - это повод снова напомнить о себе. Кроме того чисто психологически
   частое обновление ассоциируется у пользователя с развитием ПО, что
   воспринимается как плюс;

2. "код программы должен быть открытым" - для ловли пользователя нужна
   наживка и халява в качестве оной - совсем не плохо;

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

И так далее.

Какой умный дяденька. Мужики-то не знают!

> Программа работает. . В соответствии с документацией.

А если есть отклонения в ее работе - это функциональная возможность данной программы выходить за рамки документации. :)))

* Программа должна часто обновляться и быть всегда доступна для скачивания или покупки.
>Это не показатель качества.
Нет показатель.
IMHO: !Развивающийся програмный продукт! должен часто обновляться и быть всегда доступен для скачивания или покупки.

Это показатель качества, т.к. Пользователь и потенциальный Пользователь видят что:
1. Продукт поддерживается сообществом или коммерческой организацией.
2. У продукта есть цели.
3. Разработчики реагируют на потребности пользователей, проблеммы в продукте.

* Код программы должен быть открытым; лучше, если лицензия позволяет свободное использование кода.
>Это не показатель качества.
Нет показатель, поскольку:
1. Позволяет привлечь большую комъюнити к проекту, а в большей комъюнити больше вероятность присутствия хороших специалистов.
2. Многим разработчикам будет просто стыдно показывать плохой код и плохие архитектурные решения.
3. В большей комъюнити больше иноваций.
4. В большей комъюнити больше критики.
5. В большей комъюнити больше глаз для нахождения багов.
6. В большей комъюнити больше вероятность понимания как что-то исправить/улучшить минимально изменив код.

* Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).
>Это не показатель качества, это юзабельность, юзерофильность.
Да неужели разве Usability не входит в метрики качества? Вы ни разу не слышали что такой-то фичей/программой/системой пользоваться удобнее и даже ни разу мануал не знаю как выглядит?
Для доходяг аргументирую:
Если разработчики хорошо продумали функциональный дизайн - значит они думали над этим и вложили в этот дизайн свои профессиональные познания, а не тяп-ляп. Разработчики поняли как пользователь будет использовать их продукт и не ошиблись. Качество кода будет выше у профессионала, который успешно может предвидеть ситуацию чем у того кто не может.

* Программа не должна быть сложной в компиляции и запуске, не должна использовать особенности компиляторов и должна иметь немного зависимостей.
>Отчасти да.
В основном да. В особенности в отношении зависимостей.
Раз зависимостей мало значит:
1. Проблемма решена в более оптимальном базисе.
2. Меньше ушло времени на разработку(разбираться в side эффектах кода третесторонних разработчиков).
3. Меньше вероятность усложнить жизнь продукта в условиях изменения лицензий у зависимостей, прекращения поддержки зависимостей, изменения интерфейсов у зависимостей и.т.п.
4. !Это не значит что все что уже сто раз было качественно сделано кем-то будет сделано сто первый раз!

* Программа должна быть хорошо документирована.
>Да.
!!

* Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).
>Ниразу не влияет на качество.
Да неужели? Вы батенька попробуйте свою программу хотябы в 100K строк перенести на MIPS64 BE, PPC64, PPC32, x86-64, CYGWIN узнаете много интересного.
1. Переносимость заставляет следовать стандартам.
2. Переносимость заставляет следить за ENDIAN.
3. Переносимость заставляет следить за типами данных (с явным и неявным размером контейнера).
4. Переносимость заставляет следить за языковыми конструкциями.
5. Переносимость заставляет понимать во что компилируется код.
6. Тестирование на нескольких платформач/архитектурах дает большее покрытие кода.

Да для лохов JAVA и C# ни разу не переносимее C. (разве что какие-нибудь отморозки не сделают весь runtime на ASMе гы-гы)

* При выходе новых версий должна сохраняться совместимость со старыми.
>Вселенская глупость. "Сделаем старые ошибки новыми фичами"?
Здесь действительно слишком жестко и совсем не имеется в виду совместимость в базисе багов.
IMHO При выходе новых версий нужно стараться сохранить совместимость со старыми.
Невозможность соблюдения данного правила, явно говорит о:
1. Плохой архитектуре продукта.
2. Плохом функциональном дизайне.
3. Плохом дизайне API/ABI.

* Программа должна быть быстрой и не должна потреблять много ресурсов.
>Ниразу не показатель качества.
Это показатель профессионализма разработчика следовательно показатель качества кода:
Разработчик применил/разработал алгоритм с меньшей сложностью при оптимальном trade-off ресурсы/производительность чем конкурент - значит разработчик более профессионален, и его код боле качественен.

> * Программа должна часто обновляться и быть всегда доступна для скачивания или покупки. >Это не показатель качества. Нет показатель. IMHO: !Развивающийся програмный продукт! должен часто обновляться и быть всегда доступен для скачивания или покупки.

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

>В основном да. В особенности в отношении зависимостей. Раз зависимостей мало значит: 1. Проблемма решена в более оптимальном базисе. 2. Меньше ушло времени на разработку(разбираться в side эффектах кода третесторонних разработчиков). 3. Меньше вероятность усложнить жизнь продукта в условиях изменения лицензий у зависимостей, прекращения поддержки зависимостей, изменения интерфейсов у зависимостей и.т.п. 4. !Это не значит что все что уже сто раз было качественно сделано кем-то будет сделано сто первый раз!

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

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

* Программа должна часто обновляться и быть всегда доступна для скачивания или покупки.
>>Это не показатель качества.
>Нет показатель.
>IMHO: !Развивающийся програмный продукт! должен часто обновляться и быть всегда доступен для скачивания или покупки.

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


* Код программы должен быть открытым; лучше, если лицензия позволяет свободное использование кода.
>>Это не показатель качества.
>Нет показатель, поскольку:
>1. Позволяет привлечь большую комъюнити к проекту, а в большей комъюнити больше вероятность присутствия хороших специалистов.
>2. Многим разработчикам будет просто стыдно показывать плохой код и плохие архитектурные решения.
>3. В большей комъюнити больше иноваций.
>4. В большей комъюнити больше критики.
>5. В большей комъюнити больше глаз для нахождения багов.
>6. В большей комъюнити больше вероятность понимания как что-то исправить/улучшить минимально изменив код.

1. Хорошие специалисты редки.
2. Плохие архитектурные решения не всегда влияют на качество (пример: библиотека Java Swing, Delphi VCL, Microsoft MFC).
3. Больше новаций != меньше ошибок.
4. Больше критики != лучше качество.
6. В большем комьюнити больше разногласий по поводу развития продукта и исправлению существующих ошибок.


* Программа не должна требовать существенной настройки или дополнительного обучения (изменения привычек).
>>Это не показатель качества, это юзабельность, юзерофильность.
>Да неужели разве Usability не входит в метрики качества? Вы ни разу не слышали что такой-то фичей/программой/системой пользоваться удобнее и даже ни разу мануал не знаю как выглядит?

Это показатель ПРАКТИЧНОСТИ, а не показатель/не фактор качества.
(среди специалистов ценится хорошая прошивка ADSL-роутера, пользователям пофиг — лишь бы работало как надо)


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

Ну для *nix-подобных систем это основной фактор, но для Windows это не так, так как зависимые библиотеки, грубо говоря, можно сложить в каталоге приложения, они не конфликтуют с системными/основными.


* Программа должна быть переносимой (работать на как можно большем количестве распространенных платформ).
>>Ниразу не влияет на качество.
>Да неужели? Вы батенька попробуйте свою программу хотябы в 100K строк перенести на MIPS64 BE, PPC64, PPC32, x86-64, CYGWIN узнаете много интересного.

На них есть Java?

>1. Переносимость заставляет следовать стандартам.

В какой-то степени да.

>2. Переносимость заставляет следить за ENDIAN.

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

>3. Переносимость заставляет следить за типами данных (с явным и неявным размером контейнера).

См. п.2.

>4. Переносимость заставляет следить за языковыми конструкциями.

Это каг?

>5. Переносимость заставляет понимать во что компилируется код.

Для Javа это не так. javac и ant написаны на Java.

>6. Тестирование на нескольких платформач/архитектурах дает большее покрытие кода.

И что? Вместе с системно-зависимыми особенностями целевой платформы это никак не уменьшает количество ошибок.


* Программа должна быть быстрой и не должна потреблять много ресурсов.
>>Ниразу не показатель качества.
>Это показатель профессионализма разработчика следовательно показатель качества кода:
>Разработчик применил/разработал алгоритм с меньшей сложностью при оптимальном trade-off ресурсы/производительность чем конкурент - значит разработчик более профессионален, и его код боле качественен.

Хороший код без ошибок требует либо мало времени (когда код короткий и лишён большого числа ошибок), либо очень много времени (когда код достаточно функционален и хорошо отлажен). Посередине отрезка времени, требуемого для написания кода, есть область, где код написан, содержит тучу багов и не отлажен. ((c) "Совершенный код") :D
Ну и оттуда же: есть показатели качества, которые взаимно препятствуют достижению цели. Можно написать код быстрый, но потребляющий много памяти, можно написать экономичный по памяти код, но меееееедленный, можно написать во всех отношениях совершенный код, но время его написания займёт несколько человеколет и огромные финансовые инвестиции. Автор опуса не учёл фактор "совершенного кода". ;)

> И последнее: хорошее название программы важно.
это самое первое! и это должен знать каждый. Вплоть до названия
функции/библиотеки.

Как говорил мой учитель Rene Brun, написать хорошую программу - это <10%
труда, самое трудное то, что будет потом.
Пример, насколько бы мы не любили M$, но я снимаю шляпу, когда
программа написанная под DOS функционирует под winXP.

>6. Тестирование на нескольких платформач/архитектурах дает большее покрытие кода.

солидарен. Чем больше комбинаций платформа/компилятор ++
valgrind/Purify - тем лучше.

есчо один от аффоризм от моего друга Валеры Файна -
любой код, чтобы он "заработал" необходимо переписать трижды
(знаминитый закон "умножай на 3.14" :)

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

>1. Хорошие специалисты редки.
Так значит среди тысячи их меньше чем среди десяти чтоли?
Или вы не согласны что на их 10% кода придется 90% функционала?
>2. Плохие архитектурные решения не всегда влияют на качество (пример: библиотека Java Swing, Delphi VCL, Microsoft MFC).
помоему это частности и ни разу не програмный продукт=решение
>3. Больше новаций != меньше ошибок.
Отсюда не следует Больше новаций => больше ошибок.
>4. Больше критики != лучше качество.
Отсюда не следует Больше критики хуже качество.
>6. В большем комьюнити больше разногласий по поводу развития продукта и исправлению существующих ошибок.
Обычно в этом случае все кончится N форками и выживет комъюнити которое достигло компромиса или взаимопонимания по поводу продукта.

... MIPS64 BE, PPC64, PPC32, x86-64, CYGWIN ...
На них есть Java?
Да как ни странно только сложные JAVA проекты ведут себя по разному... И частенько вылазят из песочнецы :) Странно да?

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

>4. Переносимость заставляет следить за языковыми конструкциями.
Это каг?
Например на предмет переполнений, локальности, выравнивания, других side эффектов.

...
>Отсюда: одно решение невозможно использовать, приходится изобретать по одному решению для разных архитектур == увеличивается вероятность необнаруживаемых ошибок == уменьшается качество продукта.
По моему это заблуждение. Профи в этом случае при возможности применит решение подходящее для разных архитектур одинаково.

Фактор "совершенного кода" автор едал и раскрывать смысл фразы предоставил внимательным читателем:

"Разработчик применил/разработал алгоритм с меньшей сложностью при оптимальном trade-off ресурсы/производительность чем конкурент - значит разработчик более профессионален, и его код боле качественен."

Перевожу для блондинко:
Разработчик РАЗРАБОТАЛ ОПТИМАЛЬНО(БЫСТРЕЕ, ЛУЧШЕ) ЧЕМ КОНКУРЕНТ.

>5. Переносимость заставляет понимать во что компилируется код.
Для Javа это не так. javac и ant написаны на Java.
Ах да точно для Java все не так... Переносимость заставляет понимать во что интерпретируется код, как устроены JVM, java.net, java.io, java.lang, ...