Які повинні бути якості в хорошого програміста?

Що робить програміста дійсно неперевершеним? Деякі вважають, що позитивний настрій. Або дієта з високим вмістом цукру, кави та шинки. Або темний кут і стіл, заставлений моніторами.

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

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

Песимізм

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

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

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

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

Від нього часто можна почути: «А що, якщо щось піде не так?»

Лінь

Лінь зазвичай не вважають корисною якістю, і я не маю на увазі лінь виду «прийшов пізно і прикидається працюючим» або «просто внесемо цю логіку у компоненти представлення» – і того, і іншого слід уникати. Я маю на увазі прагнення не робити рутинну роботу або витрачати час на те, з чим впорається комп'ютер, або уникати роботи завтра, створюючи якісний код сьогодні. Лінивий програміст виносить загальний код в окрему бібліотеку, для повторного багаторазового використання, повністю автоматизує процес складання програми, наполягає на повному автоматичному тестуванні модулів, або пише розширюваний код зараз, навіть якщо це не було потрібно (щоб не переробляти код потім).

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

Наприклад, при описі класів, лінивий розробник відразу припустить зв’язок «багато до багатьох» між батьківськими і дочірніми класами, хоча в специфікації написано, що зв'язки будуть «один до багатьох». Чому? Тому що може знадобитися, і краще написати це спочатку, ніж переписувати потім.

Від нього часто можна почути: «Ми можемо це автоматизувати».

Допитливість

Хороші програмісти – як доктор Хаус. Їх швидко стомлює монотонна робота (див. про лінь вище) і вони просто перелопачують її в пошуках цікавої задачі, яку необхідно вирішити. Чим менше часу вони витратять на рутину, тим частіше будуть вирішувати завдання.

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

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

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

Ймовірно, сама корисна якість допитливого програміста – те саме прагнення знайти і вирішити проблему, а не замаскувати її на швидку руку.

Від нього часто можна почути: «Можливо, є інший спосіб».

Педантичність

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

Точно так само вони будуть чіплятися до дрібниць у комунікації, задавати здавалося б очевидні питання, просто щоб бути впевненими, що їх правильно зрозуміли. Це особливо вірно в таких речах як звіти про помилки. Хоча спілкуватися з ними не завжди просто, вони завжди зуміють чітко і ефективно донести ідею. Ця чіткість – величезна перевагу в будь-якому колективі розробників, особливо там, де заохочуються навчання і самонавчання.

Від нього часто можна почути: «У мене є ще декілька питань ...»

Оригінал: What Makes a Great Developer?
  • +8
  • 28 лютого 2010, 21:20
  • maaxws

Коментарі (11)

RSS згорнути / розгорнути
+
0
ох же ж шикарний текст і переклад!

на останньому повноцінному проекті, з яким я мав справу, мій колишній колєга кріптував есемблі завжди ручками (і дуже матюкався, коли його змушували робити ручками реліз-білд, бо він спішить додому), але навіть не віддавав уваги тому, шо в кріпторі є проектні файли, в який сильний ключ можна вибрати лише раз як і саму есемблі :D і ше потім довго плювався, як я можу використовувати «застарілий Far Manager», бо побачив, шо я пишу в ньому (о боже!) якийсь bat-файл (він, як потім казав [кхм-кхм], «вчив dos-стрічку в школі»), який буде одним запуском за раз кріптувати то нещасне есемблі — отже, він ніразу не лінивий, і манагєри таких люблять :D

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

і ше дуже цікаво, як інші учасники ресурсу коментуватимуть цей пост
avatar

cyba

  • 1 березня 2010, 00:29
+
0
Мне понравилась статья, и, если верить ей, я обладаю всеми качествами программиста! Значит все-таки у меня есть шанс им стать)
avatar

Silver

  • 1 березня 2010, 02:53
+
0
Я не згоден із «Песимізм». Взагалі вважаю що песимістичні програмісти несуть деструктивні думки, а також дуже затягують процес розробки. Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює.

А так то мені стаття сподобалася.
avatar

andriybuday

  • 1 березня 2010, 12:36
+
0
>> Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює

можливо, тут десь має бути «не»? та й чого «деструктивні», якшо той «песимізм» ставить за мету навпаки — покращити проект з подальшою простішою розробкою, бо намагається врахувати дещо заздалегідь?
avatar

cyba

  • 1 березня 2010, 15:40
+
+1
Якщо він прагне зробити свою роботу швидко і при тому скурпульозно переглядає свої рішення, то можливо тут щось і є. Особисто я б написав «Оптимізм» і навів багато аргументів, не менш гірших і переконливих, ніж тут наведені.

Щодо: «Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює.»
Перефразую: «Оскільки існуючий код працює, хоч він і кривий, то песимістичні програмісти схильні його просто не чіпати, тому що бояться поламати те, що вже є.»
avatar

andriybuday

  • 1 березня 2010, 15:49
+
0
Мені здається, що програміст має бути просто реалістом. Ну тобто якась золота серединка між «всьо херово» і «та всьо нормально».
avatar

enej

  • 2 березня 2010, 03:15
+
+3
а ще було б не погано вміти хоч трохи програмувати ;)
avatar

egghead

  • 1 березня 2010, 20:58
+
0
щось мало рис хорошого програміста. чому тільки ці чотири? а так — сподобалось.
avatar

zlosny

  • 2 березня 2010, 17:08
+
+1
Лінивий програміст виносить загальний код в окрему бібліотеку, для повторного багаторазового використання, повністю автоматизує процес складання програми, наполягає на повному автоматичному тестуванні модулів, або пише розширюваний код зараз, навіть якщо це не було потрібно (щоб не переробляти код потім).

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


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

Все інше так, більш-менш, але це просто загальні слова.
avatar

whirlwind

  • 2 березня 2010, 21:23
+
0
тут нема ні слова про «непотрібну функціональність», а лише сказано — що винести код в окрему бібліотеку правильніше і швидше, ніж закопіпастити його в 5 місць.

крім того «текст першого абзацу сепуречить тексту після» це типу мається за увазі, що юзати ант чи мавен (не кажучи вже про круїзконтроль, худзон та тімсіті) це «лишня робота»)? :) Хлопці, в одному з проектів мій код деплоїться на 12 машин після кожної зміни. в іншому один модуль — на 3 машини, інший ще на дві. скільки часу по вашому займе «зборка і деплой вручну»? а зміни треба тестити в «дістрібютед інвайроменті» (як мінімум інтегрейшин тести).
avatar

archer

  • 15 квітня 2010, 21:10
+
0
це типу мається за увазі, що «пише розширюваний код зараз, навіть якщо це не було потрібно (щоб не переробляти код потім).» — дурня

А винесення коду в бібліотеку — в загальному випадку звiсно що правильнiше, хоча тут треба знати мiру.
avatar

whirlwind

  • 16 квітня 2010, 13:42

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.