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

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

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

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

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

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

IMO there is a big difference between "good enough" and crappy code. For me "good enough" is all about satisfying the requirements (both functional and non functional). I think it is dangerous for people to assume that "good enough" means taking short cuts or not optimzing code. If the non functional requirements call for optimized code then that is part of my definition of "good enough".

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

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

Эта проблема возникла задолго до программирования. Я уверен, что вы слышали "Если это не так

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

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

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

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

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

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

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

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

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

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

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

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

I think of programming as an Art. An art that requires efficiency. Is efficient code incompatible with beautiful code ? I doubt that. In fact, i think that when you solve a problem creatively it may mean multiplied performance. I don't think that programming should only be about learning a new libraries for each new needs, nor about bug tracking and fixing. I think it should be about beauty. Of course code cannot be always art, and sometimes one should be pragmatic about the encountered problems.

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