Блог gunsmoker-а програмування - це мистецтво
Багато впадають фразою, мовляв, "програмування - це мистецтво", не цілком усвідомлюючи її сенс, часто додаючи до неї подібні ж штампи ( "мистецтво вимагає жертв"). Іноді можна бачити і протилежну картину - програмування зводять до рівня "механічного вирізання болтів на верстаті". Деякі сперечаються, ремесло програмування або ж мистецтво (а може і наука). Багатьом просто без різниці.
На зорі програмування була популярна концепція про те, що програмування - це інженерна дисципліна. Тоді ж в ужиток увійшов термін "програмна інженерія". Суть концепції в тому, що програми можна розробляти шляхом традиційних інженерних дисциплін. В цьому аспекті програмування розглядається просто як інженерна під-область, що має тісні зв'язки з комп'ютерними науками. І це поняття ( "інженерія програмного забезпечення") не варто плутати з "розробкою програмного забезпечення", яке є більш загальним терміном, процесом, спрямований на створення і підтримання працездатності, якості та надійності програмного забезпечення, не обов'язково використовують при цьому інженерний підхід.
Інженерний підхід спочатку був запропонований для боротьби з такими явищами:- Проекти перевищують бюджет.
- У проектах перевищуються терміни виконання.
- Програмне забезпечення було занадто неефективним.
- Програмне забезпечення мало занадто низька якість.
- Програмне забезпечення часто не відповідало необхідним вимогам.
- Проекти були некерованими, і виникали труднощі з підтримкою коду.
- Програмне забезпечення було непридатним для поширення.
І хоча він (інженерний підхід) показав відмінні результати в багатьох великих проектах, він зазнав повного фіаско в масовому виробництві програмного забезпечення. Чому? Тому що якщо дотримуватися необхідності чіткого слідування заздалегідь розробленим планом, то можна витратити купу сил на перевірку його дотримання і не помітити, що світ змінився, а план більше не актуальне, так що результат роботи буде просто не відповідати практичним вимогам реального світу.
Ключові моменти інженерного підходу для нашого обговорення: планування, структурність, дотримання плану і контрактом, системність (контрольованість) і т.п.
Більшість людей так часто говорять слова "software" і "hardware", посилаючись на програмне і апаратне забезпечення комп'ютерів, що забувають їх початковий сенс. "Soft" означає "м'який", а "hard" - "жорсткий", "незмінний". Нескладно зрозуміти, звідки виникли ці терміни. Програмний код повинен бути "м'яким", його має бути просто змінювати. Апаратна ж частина комп'ютера, одного разу розроблена, залишається незмінною. І мова тут йде не про заміну дисків або пам'яті, а про незмінність архітектури та системи команд. Згадайте, що перші комп'ютери програмувались апаратно: не було ніяких програм в чистому вигляді, вони були зашиті прямо в апаратне забезпечення - шляхом певного підключення проводів (wire). Тобто приблизно так само, як настінний вимикач "запрограмований" включати світло, будучи переключено в положення "on".
До чого я це зараз сказав?
У програмуванні потрібно пам'ятати, що основна, початкова причина появи програм як таких, відділення їх від заліза - це гнучкість і "м'якість". Якщо ваш програмний код не гнучкий і не дозволяє легко себе змінювати - в чому сенс його існування саме як програмного коду? Гнучкість - це священний Грааль програмного коду. Тут, правда, треба правильно розуміти термін "гнучкість". Багато (початківці) програмісти його не розуміють. "Ну, я ж можу перейменувати змінну та ввести нову. А можу вставити виклик функції. Бачиш, я ж можу змінювати код, що тут не так?" Гнучкість означає здатність до адаптації до мінливих вимог і технології, що розвивається. Під гнучкістю розуміються такі речі як заміна одного движка БД на інший, зміна GUI на CUI (графічного інтерфейсу на консольний) і т.п. Коротше кажучи, хороший гнучкий код повинен працювати з абстрактними поняттями. оперувати загальним, а не бути прив'язаним до конкретної реалізації, конкретного класу і т.п. Це, до речі, одна з причин виникнення ООП, де гнучкість ( "абстрактність") зводиться аж до рівня синтаксису мови (в порівнянні з попередніми підходами, де це хоч і можливо, але вимагає спеціальних зусиль - хоча б тому, що дані і методи їх обробки формально не пов'язані).
Пам'ятаєте цей пост. Там був такий пункт як "Тестування". Я знаю, деякі (початківці) програмісти, можуть подумати, що їм це не потрібно. Насправді, модульне тестування коду дуже корисно не тільки власне тестуванням, а й тим, який ефект він справляє на дизайн коду. Адже коли ви пишете модульний тест, ви повинні підсунути замість одного шару іншого. Замість GUI - фіксований введення і виведення, замість з'єднання з БД - емулює прошарок і т.п. Іншими словами, коли ви пишете тест, ви гарантуєте певний рівень гнучкості вашого коду. Написання тесту розкриває недостатню гнучкість вашого коду, так що ви можете його виправити. Саме на цьому факті заснований підхід до розробки програмного забезпечення TDD (Test Driven Development - розробка через тестування). Він гарантує певний рівень якості вашого коду (в плані гнучкості).
Зазначений момент (гнучкість) є причиною для появи "гнучких" методологій розробки програмного забезпечення в спробі приборкати складність його розробки: Agile, XP, Scrum і т.п. Слід також зауважити, що "гнучкі" підходи не протиставляються інженерному підходу в тому сенсі, що вони теж спрямовані на боротьбу з вищевказаними проблемами (перевищення бюджету і т.п.).
Вищесказане повинно дати вам зрозуміти, що розробка програм (в більшості своїй) - це не інженерія, а майстерність (і, отже, займаються їй не інженери, а майстри). Поняття майстерності важко формалізувати, його не просто усвідомити. Це поняття означає чималу роль мистецтва, або навіть пріоритет мистецтва перед наукою. Сказане не означає, що майстер нехтує наукою або інженерним підходом, але не вони є головними. Майстерність - це баланс мистецтва і науки. Саме правильний баланс призводить до якісної коду.
(Як зауваження треба сказати, що успішна програма далеко не завжди має якісний код. Якісний код не є якимось показником якісності програми (якісність програми з точки зору користувача), він ніяк не пов'язаний з її успішністю і популярністю і не є їх гарантією . Якісний код гарантує лише простоту розвитку, зміни, виправлення і супроводу програми. я не буду продовжувати цю тему тут. Можливо, я потім напишу по ній окремий пост, але поки вона і так прекрасно розкрита в моєму азделе перекладів - постами про забезпечення сумісності кривих, але успішних і потрібних програм. Тобто якість вихідного коду - це благо розробника. Качественность / популярність / успішність програми - це благо користувача. І іноді вони конфліктують один з одним.)
Міра - всьому голова.
Наприклад, багато хто розуміє фрази "не треба використовувати X", "X - це погано", "X застарів, використовуйте Y" буквально. Насправді, подібні висловлювання говорять лише те, що в більшості випадків, у X є якісь серйозні проблеми в загальному випадку. А статті, які говорять про те, чому X - це погано, насправді, вказують вам на негативні сторони і недоліки X. Згадайте, глобальні змінні. with. goto ( "GOTO considered harmful") та інші речі. Такого виду статті потрібно розуміти так, що вони дають вам огляд / знання недоліків X. X тут не поганий сам по собі, а лише в цілком певних умовах. Що означає, що ви, вже як професіонал в цих питаннях, зможете зважити всі плюси і мінуси і вибрати відповідне рішення. Варто використовувати X чи ні. Зрозуміло, оскільки недоліки X настільки значні, що вимагають аж спеціальної статті, то в більшості випадків вибір буде схилятися в бік "не використовувати". Саме тому всі кажуть фрази на кшталт "не використовуй X". Тому що професіонал і так знає, коли і що треба використовувати. А ось програміст такого усвідомленого і зваженого вибору зробити не здатен. Тому нехай краще йому скажуть, як треба робити. А коли "підросте" - сам розбереться. Ну і комікс в тему.
Ось чому програмування в першу чергу це мистецтво. Не має значення, скільки ви прочитаєте книг і статей з навчання програмуванню, скільки ви ні дізнаєтеся рад "роби так" / "не роби так" - в кінцевому підсумку процес розробки програм зводиться до досвіду і вмінню. Можна вкласти в себе купу знань, але від цього у вас не з'явиться, як би це сказати, "почуття правильності". Це приблизно як дві людини, витративши однакову кількість зусиль і використовуючи однаковий набір інгредієнтів, можуть перетворити їх або під смачний торт або в неїстівну дурниці. В процесі розробки завжди є якісь A і B і купа проміжних варіантів між ними. Гідний розробник робить правильний вибір між цими варіантами на основі свого досвіду і відчуттів, вибравши потрібний баланс. Якщо людина відчуває процес розробки, схоплює його суть, то знання конкретних технічних деталей відходить на другий план. Ось чому хороший розробник завжди щось вивчає (нову технологію, методологію і т.п.), розширює свій досвід і кругозір.
Мораль історії? Програмування можна навчиться у ВНЗ. Це - мистецтво, якому треба вчитися самому.
У цьому сенсі це був пост-добавка до попереднього посту.
Вибачте але дочитати не зміг.
заперечення -
програмування зводять до рівня "механічного вирізання болтів на верстаті".
Для мене це слід:
1. Амбіції при написанні програм шкідливі. Залиште це професіоналам, які навчались на це. Справжнім художникам і дизайнерам.
2. Коли людина робить, то що необхідно по кресленнях використовуючи ввірені і створені для цього інструменти - це не соромно. Соромно не робити, то що зазначено в спікся і тз. Тому як на тебе розраховують інші люди в комманде. У ці моменти Ми всі слюсаря. навіть якщо робимо це за своїми ж кресленнями.
3. Мистецтво формалізовано. Спочатку освоюються базові навички і вчаться їх застосовувати. У програмуванні все наоброт. Все роблять Голокосту зі своїх прог, потім переходять в манагери, Новомосковскют пару книг і потім починають вершити свої технології виробництва ПО.
І тримають свої голови як павичі. Хоча молодих прогерія треба тягати і дерти за вуха. Скрізь це є, а в програмуванні це рідкість.
Разом: Програміст повинен розуміти, що він займається промисловим справою. Програміст повинен розуміти де він проектувальник, а де слюсар-фрезерувальник. Інакше це так, халтурка.
Про порівняння з мазюканьем картин мови не повинно бути.
Коли все це переварити. усвідомте. Що мистецтво не в бунтарстві, а в прогресі. Творець паровоза - творець нового. Потрібного. Працюючого на благо. А чи не засмічує і ускладнює без того бездарні тексти програм.
P / S - STL - це поганий приклад до чого може довести бажання ісскуснічать. На жаль це стало ще й стандартом (але ненадовго). Є прості і витончені засоби разроботки. Інструменти. І їх створюють спечіально, для нас Програмістів. Щоб ми робили щось просте, надійне і зручне. І робили це разом, а не поодинці ліпили одноруких статуї
Можна використовувати деякі HTML-теги, наприклад:
Будь ласка, по можливості використовуйте "Ім'я / URL" замість "Анонімний". URL можна просто не вказувати.
Ваше повідомлення може бути позначено як спам спам-фільтром - не хвилюйтеся, воно з'явиться після перевірки адміністратором.