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

Question

Делает ли "достаточно хорошее" программное обеспечение что-то от вас как программиста?

Вот мои мысли по этому поводу:

Ну, Джоэл Спольски из JoelOnSoftware говорит, что программистам становится скучно, потому что они «достаточно хороши» (программное обеспечение, которое удовлетворяет требованиям, даже если они не настолько оптимизированы). Я согласен, потому что люди любят делать то, что правильно, всегда. С одной стороны спектров, я хочу пойти так:

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

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

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

Answer 8

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

Answer 9

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