who wanna be software developer?

Даний посібник — це лаконічна збірка порад наданих розробникам програмного забезпечення з книги The Pragmatic Programmer.

Для більш детальної інформації дивіться майданчик тенет www.pragmaticprogrammer.com.

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

2. Думайте! Про свою роботу
Вимкніть автопілот, і візьміть під контроль своє життя. Постійно критикуйте і оцінюйте свою роботу.

3. Шукайте рішення, а не варіанти виправдань
Замість того, щоб шукати виправдання, шукайте способи. Не кажіть, що це не можливо зробити; поясніть, як це можна зробити.

4. Не живіть з побитими вікнами
Позбудьтесь поганих методів розробки, рішень, і поганого коду, одразу ж, як побачите їх.

5. Будьте каталізатором змін
Ви не можете змусити людей змінитись. Однак, ви можете розповісти їм, як вони можуть це зробити, і звісно ж, допомогти їм.

6. Слідкуйте за змінами
Не зациклюйтесь на деталях, щоб не забувати перевіряти, що відбувається навколо вас.

7. Зробіть якість однією із вимог до програми
Агітуйте своїх користувачів допомагати вам визначати вимоги до якості проекту.

8. Регулярно інвестуйте у свій портфель знань
Зробіть самонавчання звичкою.

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

10. Важливо, що саме говорити і, як говорити
Немає значення, чи маєте ви великі ідеї, якщо ви не здатні їх правильно подати іншим.

11. Не повторюйтесь
Кожен фрагмент знань повинен мати єдине, недвозначне і надійне представлення у системі.

12. Зробіть код простим для повторного використання
Якщо код легко використовувати повторно, його використовуватимуть. Створіть середовище, як дозволяє повторно використовувати код.

13. Усуньте взаємозв’язки між непов’язаними об’єктами
Проектуйте компоненти, які є постійними, незалежними і мають єдину, чітко зазначену ціль.

14. Не існує остаточних рішень
Прийняті рішення не висікають на камені. Постійно переглядайте, і пере обдумуйте прийняті рішення.

15. Користуйтесь кулями, що трасуються для знаходження цілі
Кулі, що трасуються дозволяють вам зрозуміти, на скільки близько ви знаходитесь до бажаної мети.

16. Створюйте прототипи для того, щоб вчитись на них
Написання прототипів — чудовий досвід, який багато чому може навчити. У першу чергу, йогоцінність полягає в тому, що ви навчаєтесь у процесі написання прототипів.

17. Програмуйте ближче до предметної області вашої задачі
Пишіть код мовою ваших користувачів.

18. Оцінки дозволяють уникнути сюрпризів
Проводьте оцінку майбутніх робіт перед їх початком. Це допоможе одразу ж виявити потенційні проблеми.

19. Уточнюйте графік проекту на основі тексту програми
Використовуйте набутий вами досвід для оцінки тривалості майбутньої роботи.

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

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

22. Використовуйте один текстовий редактор, але по максимуму
Текстовий редактор — продовження ваших рук; переконайтесь у тім, що він легко налаштовується, розширюється і програмується.

23. Завжди використовуйте системи контролю версій
Це ваша машина часу — ви завжди можете повернутися назад.

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

25. Не нервуйтесь, і не панікуйте під час зневадження
Зробіть глибокий вдих і ПОДУМАЙТЕ про те, що може бути причиною помилки.

26. Шукайте помилки за межами операційної системи
Великої рідкістю є знайти помилку в операційній системі, компіляторі або сторонній бібліотеці. Швидше за все, вона у вашій програмі.

27. Не робіть припущень — доведіть свою теорію
Доводьте свої теорії на реальних оточеннях — з реальними даними та граничними умовами.

28. Вивчіть якусь мову обробки тексту
Ви щодня проводите купу часу працюючи з великими об’ємами тексту. Чому б не доручити частину цієї роботи комп’ютеру?

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

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

31. Проектуйте у відповідності з контрактами
Використовуйте контракти, і переконайтесь у тому, що код робить не більше, і не менше того, що у них сказано.

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

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

34. Використовуйте обробку виняткових ситуацій лише у крайніх випадках
Обробка виняткових ситуацій може страждати від усіх проблем, пов’язаних зі “спагеті-кодом”. Застосовуйте обробку виняткових ситуацій з розумом

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

36. Мінімізуйте зв’язки між модулями
Уникайте зв’язків між модулями написанням “сором’язливого” коду, і використовуючи правило Деметера.

37. Здійснюйте налаштування, а не інтеграцію
Реалізуйте вибір технології для програми, як параметр налаштування, а не за рахунок інтеграції або інженерії.

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

39. Аналізуйте послідовність операцій для збільшення паралелізму
Вивчайте послідовність операцій, які роблять ваші користувачі.

40. Проектуйте використовуючи служби
Замість компонентів, створюйте служби — .незалежні, паралельні об’єкти, приховані за чітко визначеними інтерфейсами, які не суперечать один одному.

41. При проектуванні завжди є місце паралелізму
Дозвольте паралелізм, і ви створюватимете більш чистий дизайн та інтерфейси меншою кількістю припущень.

42. Відділяйте візуальне представлення від моделей
Послаблюючи зв’язок між моделлю і її візуальним представленням/контролером, ви отримуєте більшу гнучкість практично задарма.

43. Використовуйте “дошки оголошень” для координації потоків робіт
Можна використовувати дошку для координації неоднорідних фактів і агентів, одночасно зберігаючи незалежність і навіть ізоляцію учасників один від одного.

44. Не пишіть програми у розрахунку на обставини
Зробіть ставку на надійні речі. Остерігайтеся випадкових складностей.

45. Оцініть порядок ваших алгоритмів
Оцінюйте час виконання використаних вами алгоритмів.

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

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

48. Проектуйте з урахуванням тестування
Починайте думати про тести перед тим, як почнете писати код.

49. Тестуйте своє програмне забезпечення, щоб цього не довелося робити вашим користувачам
Тестуйте нещадно. Не змушуйте своїх користувачів шукати помилки за вас.

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

51. Не збирайте вимоги – вишукуйте їх
Вимоги рідко лежать на поверхні. Вони заховані глибоко під шарами припущень, помилок, і в політики.

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

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

54. Використовуйте глосарій проекту
Створіть, і підтримуйте єдиний словник специфічних для вашого проекту термінів.

55. Не роздумуйте за межами скриньки – знайдіть цю скриньку
Зіштовхнувшись з проблемою, уявіть усі можливі напрямки, в яких можна рухатись. Запитайте себе: “Чи повинне це бути зробленим таким чином? Чи повинно це бути зробленим взагалі?”

56. Прислуховуйтесь до сумнівів – розпочинайте лише коли готові
Ви набиратиметесь досвіду усе своє життя. Не ігноруйте дрібні сумніви.

57. Деякі речі ліпше зробити, аніж описувати
Не попадіться у “спіраль специфікацій” — в якийсь момент ви повинні розпочати кодинг.

58. Не будьте рабом формальних методів
Не варто сліпо приймати будь-яку техніку не ставлячи її у контексті своєї практики розробки власних і можливостях.

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

60. Організовуйте команди спираючись на функціональність, а не посадові обов’язки
Не відділяйте дизайнерів від кодерів, а тестерів від моделювальників даних. Організовуйте команди так само, як і код.

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

62. Тестуйте заздалегідь. Тестуйте часто. Автоматизовуйте тестування
Тести, які запускаються з кожною збіркою є значно ефективнішими за тестові плани, які є прив’язаними до політики..

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

64. Використовуйте диверсантів для тестування самих тестів
Слід переконатись у тому, що тести є вірними. Немає сенсу намагатись шукати помилку, знайдену неправильними тестами.

65. Тестуйте ступінь покриття можливих станів програми, а не рядків коду
Навіть при високому ступені покарання, дані, які ви використовуєте для тестування усе ще сильно впливають на хід виконання програми.

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

67. Вважайте українську мову однією з мов програмування
Пишіть документи так, як і код: дотримуйтесь принципу “Не повторуйся”, використовуйте метадані, MVC, автоматичну генерацію тексту, і тому подібне.

68. Пишіть документацію паралельно з кодом
Документація створено окремо від коду, імовірно буде менш правильною і актуальною.

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

70. Підписуйте свої роботи
Ремісники у давності із гордістю підписували свої роботи. Ви також повинні це робити.

This entry was posted on субота, Січень 24th, 2009 at 21:25 and is filed under Розробка софту.