Які конкретні практики можна було б назвати "майстерністю програмного забезпечення", а не "програмним забезпеченням"? [зачинено]

Незважаючи на те, що це не нова ідея , схоже, протягом останніх кількох років інтерес до майстерності програмного забезпечення значно збільшився (зокрема, повний заголовок книги, котрий часто рекомендується, " Чистий код: Довідник гнучкої майстерності програмного забезпечення" ).

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

Для того, щоб зробити аналогію - було багато будівель, побудованих у 50-х та 60-х роках у дуже сучасному стилі, який враховував дуже мало людей, які живуть у них, або те, як ті будівлі старіють у часі. Багато з цих будівель швидко перетворилися в нетрі або були зруйновані задовго до очікуваного терміну експлуатації. Я впевнений, що більшість розробників з кількома роками під поясами відчують подібні кодові бази.

Які конкретні речі може робити майстер із програмного забезпечення, що інженер з програмного забезпечення (можливо, поганий) може не робити?

Я б сказав, що єдина різниця між професіоналом та майстром - це турбота про трохи пристрасті . Не існує конкретної спостережуваної практики, яка б класифікувала її як майстра, а скоріше сукупність якостей:

• Майстер дбає про фактичну якість своєї роботи, а не лише про сприйняту якість.
• Майстер має інтерес до свого ремесла, що виходить за рамки виконання роботи, і, природно, тяжіє до свого ремесла.
• Майстер дбає про свою професію, прагне вдосконалити свою майстерність і не тільки просунути кар’єру .
• Майстер витрачає певну кількість часу поза своїм оплаченим робочим часом (навіть якщо це невелика кількість часу), роблячи щось зі своїм ремеслом, будь то обговорення, навчання чи навіть думка про це.
• Майстер знає, як мало він насправді знає, і його принижують.
• Майстер готовий навчити тих, хто готовий вчитися, керувати тими, хто шукає керівництва, і шукати ці речі сам тоді, коли він їм потрібен.

Трохи пристрасть охоплює все це, не порушуючи поту.

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

Як одного разу сказав професор (перефразовано): "Як програмний інженер, не тільки ваша робота з доставкою програмного забезпечення. Це ваша робота - доставляти програмне забезпечення, яке робить ваших клієнтів щасливими".

Які конкретні речі може робити майстер із програмного забезпечення, що інженер з програмного забезпечення (можливо, поганий) може не робити?

Нічого - інженер - це майстер ... але більше. Техніка будується на майстерності.

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

Однак інженер додає до цього проблем з економіки, теорії та науки. Ви переймаєтесь отриманням максимальної вигоди за найменші витрати. Ви хочете застосувати теорії з психології, соціології, менеджменту, взаємодії між людиною та комп'ютером та інформатики для вирішення своїх проблем (як міжособистісних, так і технічних). І ви, безумовно, маєте освіту для резервного копіювання свого досвіду.

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

Його мета подвійна: відновлення довіри до програмістів, а для цього - підвищення рівня якості програмного забезпечення та навичок розробників.

Sw майстерність просуває технічні практики, такі як:

• Принципи дизайну SOLID
• Шаблони дизайну
• TDD (метафора "обліку подвійного запису")
• ...

І командні / організаційні практики:

• Парне програмування
• Наставництво
• Каталог кодів
• Додж / код відступає
• ...

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

Перейшовши за http://manifesto.softwarecraftsmanship.org/, я отримав би наступне.

Майстер відрізняється від традиційного сприйняття "інженера" ​​тим, що

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

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

Ви не можете позбавити когось дозволу на програмування через неправильну роботу. Програмуванню не вистачає законів та правил, ніж законодавчо виконується законодавством, яке відповідає "професії". Лікар вбиває пацієнта через некомпетентність, і він ризикує забрати його звання або дозвіл лікаря.

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

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

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

Тобто створити щось, що задовольняє 90% вимог до програмного забезпечення, а потім перетворити весь проект на якийсь чистий, елегантний дизайн.

Зазвичай, інженерія програмного забезпечення заважає вам це робити, оскільки задоволення 90% вимог означає, що програмне забезпечення має достатню ділову цінність для клієнта, і воно не повинно бути змінено жодним суттєвим чином (крім помилок з високим пріоритетом).

Натомість інженерія програмного забезпечення радить вам стабілізувати програмне забезпечення в цей момент.

Крім того, якщо проект не починається з такого елегантного дизайну з самого початку, він вважатиметься погано виконаним проектом (незалежно від результату проекту), відповідно до програмної інженерії.

Спайк-розчин.

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

Позбавлення , з будь-якої причини.

В інженерії програмного забезпечення будь-яка депресія може бути здійснена лише в кінці життєвого циклу програмної системи. Це потрібно планувати як частину SDLC.

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

Зрештою, майстерність програмного забезпечення - це особиста прагнення до хороших оцінок людей, тоді як інженерія програмного забезпечення - це консервативна сукупність знань. Дозвіл того, щоб добре оцінити процес прийняття рішень, є тим, що відрізняє майстерність програмного забезпечення від інженерії програмного забезпечення.

Я б сказав, що тест на одиницю, що охоплює 100% коду, був би хорошим. Оскільки це дозволяє позбавити зайвий матеріал.

Я іноді порівнюю розробку програмного забезпечення зі скульптурою. Це не те, що ви додаєте, це те, що ви забираєте.

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