Какие конкретные практики можно назвать «мастерством программного обеспечения», а не «разработкой программного обеспечения»? [закрыто]

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

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

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

Каковы конкретные вещи, которые мастер программного обеспечения может сделать, чего не может сделать инженер программного обеспечения (возможно, плохой)?

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

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

Немного страсти охватывает все это, не потревожив.

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

Как однажды сказал мой профессор (перефразировал): «Как разработчик программного обеспечения, это не только ваша работа по поставке программного обеспечения. Это ваша работа по поставке программного обеспечения, которое делает ваших клиентов счастливыми».

Каковы конкретные вещи, которые мастер программного обеспечения может сделать, чего не может сделать инженер программного обеспечения (возможно, плохой)?

Ничего - инженер - ремесленник ... но больше. Инженерия строится на мастерстве.

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

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

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

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

Sw мастерство продвигает такие технические приемы, как:

• ТВЕРДЫЕ принципы проектирования
• Шаблоны проектирования
• TDD (метафора «двойной учет учета»)
• ...

И командные / организационные практики:

• Парное программирование
• Наставничество
• Код катас
• Dojos / отступления кода
• ...

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

Зайдя по http://manifesto.softwarecraftsmanship.org/ я бы получил следующее.

Мастер отличается от традиционного восприятия "инженера", потому что

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

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

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

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

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

Рефакторинг к шаблонам.

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

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

Программная инженерия вместо этого посоветует вам стабилизировать программное обеспечение на этом этапе.

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

Спайк Решение.

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

Устаревший , по любой причине.

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

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

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

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

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

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