Последствия создания "достаточно хорошего" программного обеспечения

Ответ 1

На самом деле я считаю, что программисты достаточно хороши, чем идеальное разнообразие "голубого неба".

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

У меня на самом деле был аргумент в другом вопросе о том, как лучше всего найти выигранную игру tic-tac-toe/noughts-and-crosses (вопрос интервью).

Лучшее решение, которое я получил, было от кандидата, который просто проверил все 8 возможностей с помощью операторов if. Были некоторые, которые дали обобщенное решение, которое, будучи работоспособным, было совершенно ненужным, поскольку спецификации были совершенно ясны, это было только для платы 3x3.

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

Подумайте о коммерческом программном обеспечении, которое вы используете, прекрасно ли оно? Я действительно не знаю никого, включая моих друзей в Microsoft, которые будут утверждать, что код в Windows "идеально" или что-то близко к нему. Но это undenyable, что система Windows (и всегда была), чтобы получить миллионы людей, чтобы использовать его на ежедневной основе "достаточно хорошо".

Эта проблема восходит задолго до программирования. Я уверен, что вы слышали "Если это не сломано, не исправляйте" или оригинал на французском языке "Le mieux est l'ennemi du bien". Возможно, это был Вольтер, который писал о "хорошем существо, являющемся врагом великого".

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

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

Ответ 6

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

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

Ответ 7

Есть, по крайней мере, два аспекта качества, которые мы должны учитывать:

• Качество программного обеспечения: соответствует ли программное обеспечение желаемым целям/требованиям? мы поставляем сборки с критическими ошибками? легко ли для конечных пользователей работать?
• качество кода: насколько сложно поддерживать код? легко ли реализовать новые функции?

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

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

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

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

Ответ 8

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

Ответ 9

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