Мифы сопровождали человека с древних времен и все еще существуют в нашем высокотехнологичном мире. Поэтому, несмотря на то, что разработка программного обеспечения факта является довольно формальная наука, это не предотвращает существование многих мифов и заблуждений в этой отрасли. В этой статье мы обсудим только некоторые из них.
Миф № 1. Один язык программирования лучше, чем другие Программисты любят похвалить язык, в котором они программируют. Вы можете часто слышать, что какой-то язык лучше других. Но правда в том, что каждый язык обслуживает конкретную цель, и никто не может сказать наверняка, что один язык лучше другого. Это как спрашивать, какой язык лучше: итальянский или французский? Конечно, это зависит от страны, в которой вы находитесь. На этой основе преимущество определенного языка программирования может быть определена только в определенной задаче. И часто задачи требуют знания нескольких языков. Поэтому языки работают вместе, не друг против друга.
Миф № 2. Больше людей лучше Поэтому, если мы потерпимся в планировании, мы можем добавить больше программистов в команду и продвигать потерянное время. Эта ситуация иногда называют «концепцией Монгольской Орды». Фактически, разработка программного обеспечения не является механическим процессом, таким как изготовление. Так что обычно добавляют людей в задержку программного обеспечения, задерживают его еще больше. Сначала это утверждение может показаться противодействием. Однако, когда добавляются новые люди, нужно учиться их и проводить время общения с командой. Так что это количество времени не может быть потрачено на разработку продукта. Люди могут быть добавлены, но только в запланированном и хорошо скоординированном порядке.
Миф № 3. Программисты могут только написать код. Создатели таких мифов о программировании, несомненно, очень далеко от этой сферы и не знают, как происходит процесс разработки. Обычно проблемы, решаемые компьютерными программами, выходят далеко за рамки поля информационных технологий. Например, давайте возьмем инструменты для учета. Чтобы создать качественный продукт, программист должен, вообще, понять эту тему. Идеал является вариантом сотрудничества профессионального бухгалтера, который знает, что он хочет и кодер, который понимает программирование и знает, как объяснить машину, что делать. Тем не менее, бухгалтер в большинстве случаев слишком далеко от информатики и просто не может подробно объяснить, что он ожидает от продукта. Итак, программист должен идти в экономические концепции и схемы самостоятельно.
Миф № 4. Быстрее лучше Да, есть проекты, которые могут быть легко и быстро реализованы через дизайнер и набор пользовательских решений от опыта компании. Но эти проекты, как правило, закрывают очень узкую целевую аудиторию и не принесут высокий доход владельцам этого продукта. Все серьезные инженерные решения часто не только разрабатываются в течение нескольких лет, но и требуют поддержки и были разработаны за эти годы. Например, история создания пакета Microsoft Office. Когда задача была назначена ему, период реализации был оценен в течение 3 месяцев. В результате сам проект занял 6 лет. В результате этого мифа есть мнение, что программисты работают круглосуточно. Однако тралы, обработка и другие – они не приносят ничего хорошего. Производительность разработчика резко падает, если они вынуждены работать долгие часы. И это так много падает, что через десять часов они начинают делать столько, сколько раньше делали в шести. Поэтому многие компании убеждены, что программисты не могут работать более шести часов в день. Ведь как скорость, так и качество работы резко сокращены дальше, что намного хуже.
Миф № 5. Прилипать к плану – это должен Неоспорим, что разработка программного обеспечения является набор сложных действий, которые требуют координации и внимания к деталям. Так что планирование обязательно должно. На ранних этапах развития очень важно глубоко погрузиться в детали, подумайте о функциональности подробно и внимательно изучите техническую задачу. Но не всегда все идет по плану. Это действительно трудно встретить проект, требования, для которых оставались постоянными на протяжении всего развития. Для производственных процессов с частым повторением этапов это хороший подход к отслеживанию каждого шага – но он не подходит для инноваций в разработке. Новые идеи могут прийти ежедневно, а условия могут постоянно меняться. Таким образом, планы следует рассматривать как первоначальные гипотезы, которые постоянно пересматриваются.
Миф № 6. Нет ничего невозможного Широко распространенный миф “Нет ничего невозможного” стало одним из оснований для этого мифа. Дело в том, что при упоминании об этом редко возникают какие-либо ограничения и «неудобные» условия. Например, если вы посмотрите на интерфейс любой поисковой системы с точки зрения обычного человека, вы не увидите никаких трудностей. Набор мелких фраз и маленьких картинок. Однако это все стоит гораздо больше, чем может показаться. Все имеет свои ограничения, даже это сфера.
Миф № 7. Успех с первого испытания Эксперименты с разными идеями являются необходимыми частью инновационного процесса. Когда вы часто экспериментируете часто и быстро, конечно, вам придется принять провал многих идей. Но это позволяет командам быстро бросить плохие решения и сосредоточиться на более перспективных. Успех с первого раза отправляет команды на территорию менее рискованных решений – даже если клиенты не считают их значительным улучшением того, что они были ранее. Команды не получают стимулов для разработки инновационных решений проблем пользователей.
Вышеуказанные только самые популярные мифы, но кроме них, есть много других. Все они каким-то образом создают культуру ее сферы. Разработчики, как и все другие профессионалы, имеют свои собственные традиции и обычаи, иногда даже очень смешные, но это еще одна история.
Оригинал: “https://dev.to/krowser/software-development-myths-331m”