У меня неправильное представление о разработке программного обеспечения? [закрыто]

У меня есть вопрос, который был поднят моей последней работой (скорее, стажер).

Просто чтобы разобраться с ситуацией - мне 21 год, и я закончил 2-й курс университета до этого, у меня было около 2-х лет опыта работы в sys admin / QA, и в целом я могу сказать, что я видел, насколько разные IT секторы работали. Перенесемся в настоящее время и вот я устроился на стажировку в одном из ведущих исследовательских институтов в Великобритании.

Что мне нужно сделать, так это создать несколько внутренних инструментов, используя сочетание технологий - в основном AWS / Java / Bash - и вы получите представление. Все в порядке, я делаю свою работу, но я не счастлив. Почему это так, потому что я должен работать в специальном деле. То есть создавать вещи быстро, не тратя время на проектирование. Мой менеджер прямо сказал, что от проблем, как они возникнут, мы должны были "спешить", а мы - по сути. Как следствие, оказалось, что вещи должны быть переделаны и переработаны, и они все еще не совершенны. Что касается тестирования, сведите его к минимуму, если оно работает, то все в порядке.

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

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

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

Раньше я выполнял свои университетские задания, просто просматривая их и непосредственно начав кодировать, и мог легко получить оценки выше 75% и никогда по-настоящему не ценил модуль «жизненный цикл разработки программного обеспечения». Но теперь, когда я увидел в реальном мире, как плохо работать без какого-либо формального процесса и разочарования, которое присуще ситуации, когда вы не знаете, изменится ли требования завтра (о, я говорил, что мы не не имеет четко определенный анализ требований?)

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

Создание программного обеспечения для повторного использования и пуленепробиваемости не является движущей силой разработки программного обеспечения. Инженерное дело - это оптимальное решение реальных проблем в реальных условиях . Большинство инженеров предпочли бы работать на Ferrari - но универсал нуждается в таком же большом количестве инженерных работ, и причина, по которой универсал не работает так же хорошо (в некоторых отношениях), связана с более сложными конструктивными ограничениями, а не с худшими инженерными разработками ,

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

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

На самом деле, это беспокоит меня. Вы в профессии, где вы разрабатываете инструменты для ученых-исследователей, правильно. Тем не менее, вам сказали сделать эти программы быстрыми и заставить их работать минимально. Сюрприз Сюрприз. Это просто типичный подход исследователя к программированию с бременем, переданным реальному программисту.

Основная проблема здесь заключается в том, что отсутствие тестирования может быть этически сомнительным, если инструменты имеют важную цель. Если кто-то не уверен, что у программного обеспечения есть дефекты, потому что он ограничен минимальным временем тестирования, это означает, что НИ ОДИН не несет ответственности за рабочие условия программного обеспечения, и Atlas пожимает плечами.

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

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

Разве не этично гарантировать, что программное обеспечение для моделирования не имеет серьезных проблем с его прогнозами?

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

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

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

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

Вы не имеете неправильного представления о том, что такое разработка программного обеспечения. Однако вы упускаете очень важный аспект: это сфера услуг. Некоторые из нас годами работают над продуктом, проходят дизайн, а затем проходят много итераций, прежде чем он выйдет в v1. Другие должны произвести что-то за 3 часа. Это зависит от того, кого вы обслуживаете и какова цель.

Если вы можете создать приложение за 3 часа (или дня), которое выполняет то, для чего оно предназначено, зачем тратить на него больше времени, чтобы разрабатывать заранее? Ты просто тратишь деньги. Тратить деньги - это вообще не хорошая идея ™.

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

Многие из нас (включая меня) занялись программированием, думая, что все дело в самом программировании - кодировании красивых и элегантных программ в вакууме (или, по крайней мере, в относительном вакууме). Это редко бывает. Там могут быть некоторые редкие академические или научно-исследовательские работы программного обеспечения, которые близки к этому, но по большей части, подавляющее большинство работ по разработке программного обеспечения ничего подобного. Особенно на этапе обслуживания, которое обычно составляет более 90% срока службы продукта, и повседневной рутинной работы большинства постоянных коммерческих программных продуктов.

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

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

Все это говорит о том, что все меняется. Некоторые компании (в основном те, для которых программное обеспечение является их основным бизнесом, и те, кто работает над крайне критически важным для безопасности программным обеспечением, таким как медицинское оборудование), следуют очень строгому процессу разработки. Но в целом, да, я скажу вам прямо сейчас, что большинство коммерческих программных продуктов относительно небрежно. Обычно существует какой-то формальный процесс, но строго придерживаться его почти всегда отодвигает на второй план реагирование на отзывы клиентов и другое коммерческое давление. Это на самом деле не "неряшливость", это просто прагматическая полезность. Хитрость заключается в том, чтобы найти свою нишу и посмотреть на роль с точки зрения того, какую услугу она предоставляет, а не на то, насколько крут ее аспект «чистого программирования».

РЕДАКТИРОВАТЬ : Я думаю, что я, возможно, звучал слишком односторонним в моей первоначальной оценке. Я хотел бы добавить, что часто бывают и подлинные проблемы, связанные с тем, что вещи слишком неаккуратные, а также отсутствие хорошего процесса - до такой степени, что он влечет за собой техническую задолженность проекта и на самом деле вреден для бизнеса. Но видя это приходит с опытом. Начальная точка в основном остается неизменной: большинство коммерческих программных продуктов сегодня не так жестко ориентированы на разработку, как могли бы пуристы.

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

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

Если вас не устраивают исследования (создание чего-то нового, изучение новых вещей, о которых никто не знал раньше), тогда попробуйте программное обеспечение в термоусадочной упаковке. На самом деле, в вашем возрасте вы должны попробовать как можно больше вещей. Иди рискуй! Вы многому научитесь, и в конечном итоге вам станет лучше.

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

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

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

Я имею в виду, что вы сказали:

«Что мне нужно сделать, так это создать несколько внутренних инструментов, используя сочетание технологий - в основном AWS / Java / Bash»

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

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

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

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

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

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

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

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

Хотя исследование может быть важным, важно также что-то доставить. Если ты не доставляешь что-то, насколько ты хорош на самом деле? Duct Tape Programmer был бы хорошим примером в этой области.

Scrum - это особая методология, которую вы, возможно, можете попробовать применить на своем нынешнем рабочем месте. Не думайте, что Scrum - это серебряная пуля. При каких обстоятельствах проекты под Scrum и Agile могут потерпеть неудачу? будет пост в блоге на эту тему, который может представлять интерес.

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

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

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