Будьте простіше ( і до вас потягнуться люди)

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

KISS - це keep it short & simple . Роби коротше і простіше. Думаю, багато з ЕІМ принципом знайомі; пам'ятаю, навіть телепередача була з такою назвою. Сенс зрозумілий - робіть ваші системи як можна більш простими і легковажним. Сенс зрозумілий, а от з практикою сутужно.

Дійсно, якщо ти 23-річний сениор, то чимось адже твій код повинен відрізнятися від коду 20-річного джуніора? І ось тут на допомогу приходить складність. Осилив нарешті книгу про патерни? Відмінно. Абстрактна фабрика тут, стратегія там, трансформація DTO п'ять разів тут - і відразу видно, що писав справжній дорослий розробник. Знову-таки, можна напхали пару фреймворків. І якийсь скриптова мова прісунуть, ну чисто генерувати всяке.

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

Ну, зрозуміло, що робити все простіше і коротше повинні не тільки розробники. Аналітикам добре б писати короткі і чіткі вимоги. Менеджерам - не ускладнювати завдання, що стоять перед командами. І так далі, до самого верху. Коротше, повний KISS.

Принцип YAGNI трохи менш відомий. І, до речі, даремно. YAGNI означає you ain't gonna need it . Це вам не знадобиться. Ну, тобто - не робіть зайву роботу.

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

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

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

Опубліковано: 05/07/12 @ 08:44
Розділ Різне

SEO Блог

Будьте простіше ( і до вас потягнуться люди)

Рекомендуємо: