Качество программного обеспечения действительно имеет значение для Разработчика приложений - *Практически*? [закрытый]

Вы создаете качественное программное обеспечение по трем причинам:

1. Чтобы быть качественным, оно должно быть хорошо спроектировано, а хорошо разработанное программное обеспечение быстрее писать.
2. Хорошо сделанное программное обеспечение легче поддерживать , и все поддерживается.
3. Мы пишем хорошо сделанное программное обеспечение, потому что нам не все равно, и потому что мы профессионалы.

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

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

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

Спасибо всем за ваш ответ. Позвольте мне добавить еще, почему я задал этот вопрос в первую очередь.

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

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

Давайте возьмем очень общий пример; веб-сайт с миллионами посещений. Конечные пользователи довольны тем, что сайт выглядит привлекательно, и они получают заказ. Менеджмент доволен, потому что разработка / улучшение было выполнено в рамках бюджета, и все функции реализованы. PM счастлив, потому что команда каким-то образом доставила его вовремя. Технический руководитель доволен, потому что все разнородные подсистемы обмениваются данными, как ожидалось, и ограничения инфраструктуры соблюдены. Команда из 25 разработчиков довольна тем, что все ошибки исправлены, и теперь их код работает; Конечно, они уверены, так как они использовали безопасный тип языка, отличную среду IDE, и они найдут номер строки с любыми ошибками времени выполнения, поскольку блок try catch находится повсюду, чтобы сохранить их.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короче говоря,

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

Это зависит от фазы проекта, размера команды и времени на его выполнение. ожидаемое завершение.

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

Однако иногда (часто) быстрый и грязный подход с треском проваливается. Например, если в проекте есть или будет большая группа разработчиков (более 4) или несколько команд, то следование надежным / проверенным шаблонам и методам разработки - единственный способ добиться успеха в долгосрочной перспективе. Кроме того, внедрение новых шаблонов часто не удается, если имеется большой объем сложного устаревшего кода. Наконец, решающее значение имеют ожидаемые сроки. Если заказчик ожидает создания какого-то прототипа через день, не тратьте неделю на сборку полной инфраструктуры MVC.

Конечно, это имеет значение.

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

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

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

ТАК, да ... это важно. Учись!

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

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

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

Кроме того, оно просто выглядит красивее, когда вы это делаете.

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

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

Многие разработчики, работающие над небольшими проектами, застревают, думая о шаблоне XYZ или размышляя над правильной структурой / языком для использования. Эти вещи имеют значение для крупных корпоративных приложений или крупных веб-приложений, критичных к производительности (например, facebook, google и т. Д.), Но часто менее важны, когда предпочтительнее дробное решение.

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

Я стараюсь всегда писать хороший код для самоудовлетворения. =)

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

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

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

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

Качество кода определяется множеством факторов .

Вы в основном говорите, что только внешне видимые факторы или их подмножество (" работает как положено "), дело. Они, безусловно, наиболее заметны, но существует общее мнение о том, что без факторов качества внутреннего кода вы не добьетесь высокого внешнего качества.

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

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

Я не совсем понимаю, что вы имеете в виду под качеством?

Чистота исходного кода?

Пользовательский интерфейс?

Надежность?

Скорость?

Размер?

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

На самом деле нет веских причин для написания плохого кода.

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

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

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

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

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

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

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

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

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

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

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

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

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

Мораль, этика,

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

Если бы этого не было, в компаниях не было бы крыла для Software Quality Assurance .

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

Как вы думаете, почему разработка приложений не имеет ничего общего с качеством?

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

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

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

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

согласно требованиям, проектам. И мы все люди и делаем ошибки, мы неправильно понимаем требования и иногда даем что-то далеко от того, о чем просили.

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

согласно требованиям, проектам. И мы все люди и делаем ошибки, мы неправильно понимаем требования и иногда даем что-то далеко от того, о чем просили.

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

Первым шагом является определение качества.

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

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

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

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

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

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

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

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

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

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

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