Ходят слухи, что разработчиков программного обеспечения нанимают на основе того, что и сколько они могут сделать, то есть производительности - в целом. Большинство компаний ожидают, что они будут постоянно обеспечивать ощутимую ценность в условиях капиталистического безумия, когда «время - деньги», а производительность растет с каждым днем.
Я могу согласиться с тем, что это имеет смысл, когда компании (кроме некоммерческих) движимы деньгами и ростом, в то же время жестко конкурируя среди множества, но только до определенной степени.
Выполнение дел - это не только модное словечко, но и плохой предлог, чтобы сократить расходы и избежать расходов. Есть иллюзия, что именно так программное обеспечение создается с минимальным бюджетом. Существует точка зрения, что программное обеспечение, созданное быстро и ограниченное только спецификациями владельца продукта или клиента, - вот что движет бизнесом вперед и приносит прибыль.
Не заблуждайтесь, такой подход не подходит для большинства проектов, и вы рано или поздно оплатите счет. Обычно это стоит дорого, а иногда и с процентами.
В отношении своей карьеры и своих клиентов обязанность инженера-программиста - консультироваться и подходить к таким случаям с учетом не менее чем лучших стандартов качества. Иногда вам нужно программное обеспечение с минимальным качеством, но это никогда не будет правилом.
Бывают ситуации, когда вы создаете MVP, прототип или доказательство концепции, что неявно означает, что вы уже ожидаете одноразового программного обеспечения низкого качества. Было бы разумно сделать его малобюджетным и ограниченным по качеству. В конце концов, вы либо проведете значительный рефакторинг, прежде чем выйти на рынок, либо все равно выбросите его.
Однако, когда вы либо создаете производственную версию, либо добавляете новые функции к существующему программному обеспечению, такое сокращение - СОВЕРШЕННО ужасное решение. Хорошо известно, что программная кодовая база гниет сама по себе, главным образом, в процессе работы. Если он будет продолжать так небрежно продвигаться вперед, он достигнет точки невозврата, и, следовательно, станет одноразовым. Это будет либо сложно, либо дорого обслуживать. Или порождает так много проблем, что ему не хватает доверия, и он становится непригодным для использования естественным образом. На данный момент он одноразовый, нравится вам это или нет.
Обратите внимание, одноразовое программное обеспечение, которое еще не выполнило свое предназначение, уже является провалом и пустой тратой денег. Вы же этого не хотите!
Создавая долговечное программное обеспечение, команды концентрируют свои усилия на создании надежных решений, устойчивых к гниению. Они будут подвержены изменениям таким образом, чтобы они соответствовали технологическим, архитектурным и клиентским требованиям, не нарушая и не превышая разумных бюджетов. Они будут хорошо работать с небольшим количеством ошибок и узких мест.
В программном обеспечении, созданном с учетом требований качества, соблюдаются основные -словы, которые гарантируют его успех. M aintainability, расширяемость, тестируемость, возможность повторного использования, масштабируемость, надежность и удобство использования являются основными. Вы можете найти их все в Википедии.
Другими словами, он может легко меняться, развиваться, адаптироваться, хорошо работать и быть протестированным так, как должен. Он может справиться с физическим стрессом, вызванным его использованием, и психологическим бременем ожиданий, связанных с ним, которые без него не могут выжить.
Конечно, создание программного обеспечения не бесплатно. Качественные обычно дороги из-за дополнительных усилий. На это уходит больше времени, а иногда процесс не такой прозрачный, как хотелось бы заинтересованным сторонам. Требуется мудрость, чтобы увидеть, когда и как это окупится, и я готов поспорить, что это серьезная причина, по которой менеджеры решают иначе.
Но, (не) к счастью, это неизбежно. В какой-то момент так или иначе потребует качества. Это может занять время и даже не помешать работе, но продвижение в этом направлении может быть неразумным шагом.
В конце концов, вы заплатите справедливую цену за программное обеспечение. Будь то правильная работа с первого раза или дополнительные затраты на переработку и рефакторинг в дальнейшем. Хуже того, иногда счет приходит с процентами, и вы в конечном итоге теряете ключевых клиентов, возможности, сотрудников, репутацию и т. Д. Из-за предоставления слабых решений.
Помните об этом и соответствующим образом адаптируйте решения.
В следующий раз, когда вы будете создавать программное обеспечение, будьте бдительны в отношении того, как это должно быть сделано с уважением. Внимательно рассмотрите все переменные вашего проекта, чтобы решить, как вы подойдете к нему, и уделите больше внимания качеству. В конечном итоге это окупится, если вы уменьшите количество ошибок и переделок, повысите уровень удовлетворенности клиентов и подготовите его к следующей функции или изменению без суеты.
