Должны ли методы разработки подавлять индивидуализм разработчика?

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

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

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

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

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

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

Нет, инструктор прав, говоря вам перечислить все свойства и методы заранее, если вы используете метод водопада. Википедия отмечает критику водопада:

Многие утверждают, что модель водопада является плохой идеей на практике, считая невозможным ни для одного нетривиального проекта полностью завершить этап жизненного цикла программного продукта, прежде чем переходить к следующим этапам и учиться на них. Например, клиенты могут не знать точно, какие требования им нужны, прежде чем просматривать рабочий прототип и комментировать его. Они могут постоянно менять свои требования. Дизайнеры и программисты могут иметь небольшой контроль над этим. Если клиенты изменят свои требования после того, как дизайн будет завершен, дизайн должен быть изменен с учетом новых требований. Это фактически означает недействительность значительного количества рабочих часов, что означает увеличение затрат, особенно если большое количество ресурсов проекта уже было инвестировано в Big Design Up Front.

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

Вы нашли недостаток водопада, но у всего есть свои сильные и слабые стороны.

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

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

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

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

Это все очень важные пункты.

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

Совет Clean Code (я никогда его не читал - я просто следую тому, что вы написали) кажется справедливым и применимым даже при использовании методологии Waterfall. Вы можете разрабатывать свои классы и методы в соответствии с принципом единой ответственности , разделением интересов и другими принципами SOLID . Водопад не говорит вам, как проектировать, просто когда вам нужно это сделать. Тем не менее, это сложнее заранее, так как вы учитесь и думаете о лучших способах сделать это во время реализации.

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

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

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

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

Так?

инструктор сказал нам неправильно, попросив перечислить все функции?

Нет, это общее требование.

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

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

Нет, ты просто балдешь от скуки. Преодолей это и вернись к работе.

Программирование - это искусство работать в рамках ограничений. ЦП предоставляет ограниченный набор команд; IO ограничен конструкцией оборудования; API-интерфейсы ОС создаются для поощрения определенных действий и ограничения других; языки высокого уровня часто предназначены для продвижения одного набора идиом по сравнению с другими ...

И методологии тоже разработаны для ограничения.

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

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

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

Я думаю, что инструктор блестяще помог вам сделать этот проект и, таким образом, обучил вас плюсам (и главным образом) минусам развития Waterfall.

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

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

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

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

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

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

Преподаватель "сказал тебе неправильно"?

Я думаю так.

Распределение скучной работы среди работников интеллектуальной собственности расточительно. В школе скучная работа имеет мало или вообще не имеет педагогической ценности, за исключением, возможно, приучения учеников к скучной работе. Такие упражнения имеют негативные последствия, как для студентов, так и для промышленности. Студенты пострадали, потому что их время потеряно. Промышленность вредит, потому что некоторые студенты могут прийти к выводу, что такая скука необходима и полезна. Это ни то, ни другое. За тридцать лет работы в программном обеспечении единственная работа, которая мне показалась скучной и полезной, - это смена лент для резервного копирования. Были роботы, которые могли это сделать, но они были слишком дорогими.