Що робить програміста дійсно неперевершеним? Деякі вважають, що позитивний настрій. Або дієта з високим вмістом цукру, кави та шинки. Або темний кут і стіл, заставлений моніторами.
Звичайно, кожен може розповісти смішну історію про класного, на їхню думку, програміста, з яким довелося працювати. На жаль, у більшості випадків ця думка ґрунтується не на якості коду або дотримання термінів, а на менш важливих критеріях, наприклад, чи знав він своїх колег по іменах, скільки рядків коду видавав на годину, або наскільки впевнено міркував про свою роботу.
На жаль, кращі програмісти не завжди виглядають такими. Хоча цей список і не можна застосувати до будь-якого колективу розробників, ось вам кілька ознак, за якими можна визначити відмінного програміста.
Песимізм
Класні програмісти майже завжди ставляться до своєї роботи песимістично. Це не означає, що вони не радіють життю, не веселяться і взагалі зануди – просто вони завжди думають про те, що може піти не так, і як з цим доведеться боротися.
Вони вважають, що в якийсь момент їм доведеться переписати вже готовий код, що залізо підведе, що весь захист зламають, і що весь ваш офіс згорить дотла. Самі геніальні будуть виходити з того, що це все відбудеться одночасно. І вони не заспокояться, поки у них не буде конкретного, здійсненного, перевіреного – і стовідсотково перевіреного – плану подолання такого роду проблем. І навіть тоді вони не будуть повністю задоволені.
Песимістичні програмісти постійно шукають недоліки в ідеях, тому в роботі з ними необхідно пам'ятати, що вони роблять це не щоб розгромити чужу ідею, а щоб ця ідея перетворилася на проект по можливості продуманий, і всі можливі проблеми були б заздалегідь враховані. Такий невротичний, параноїдальний і песимістичний підхід – саме те, що вам потрібно, якщо ваші програмісти повинні видавати якісний, надійний та безпечний код.
Навпаки, оптимістичний розробник швидше за все припустить, що код просто запрацює, або що він безпечний, або просто встановить такий термін виконання, як ніби ніяких проблем не виникне.
Від нього часто можна почути: «А що, якщо щось піде не так?»
Лінь
Лінь зазвичай не вважають корисною якістю, і я не маю на увазі лінь виду «прийшов пізно і прикидається працюючим» або «просто внесемо цю логіку у компоненти представлення» – і того, і іншого слід уникати. Я маю на увазі прагнення не робити рутинну роботу або витрачати час на те, з чим впорається комп'ютер, або уникати роботи завтра, створюючи якісний код сьогодні. Лінивий програміст виносить загальний код в окрему бібліотеку, для повторного багаторазового використання, повністю автоматизує процес складання програми, наполягає на повному автоматичному тестуванні модулів, або пише розширюваний код зараз, навіть якщо це не було потрібно (щоб не переробляти код потім).
Крім того, лінивий програміст звичайно зосереджений на основних цілях проекту і не шукатиме додаткових завдань на свою голову. Він перешкоджає обростання продукту непотрібними функціями.
Наприклад, при описі класів, лінивий розробник відразу припустить зв’язок «багато до багатьох» між батьківськими і дочірніми класами, хоча в специфікації написано, що зв'язки будуть «один до багатьох». Чому? Тому що може знадобитися, і краще написати це спочатку, ніж переписувати потім.
Від нього часто можна почути: «Ми можемо це автоматизувати».
Допитливість
Хороші програмісти – як доктор Хаус. Їх швидко стомлює монотонна робота (див. про лінь вище) і вони просто перелопачують її в пошуках цікавої задачі, яку необхідно вирішити. Чим менше часу вони витратять на рутину, тим частіше будуть вирішувати завдання.
Допитливі програмісти будуть постійно шукати нові задачі для вирішення, і кращі рішення до попередніх завдань. Вони будуть знаходити нові підходи до роботи, і постійно шліфувати і намагатися поліпшити існуючі системи. Вони також будуть краще за інших обізнані про наявні у даному середовищі розробки проблеми і намагатимуться ці проблеми вирішити. Допитливі програмісти зазвичай мають більш широкий кругозір, знають не тільки свою основну мову, але й супутні, пов'язані і альтернативні технології.
Допитливі (або які ненавидять рутину) програмісти часто найменш зашорені – і найбільш здатні до змін. Так, можливо, що їх доведеться спочатку переконати, чому новий спосіб роботи краще (і це не недолік), але якщо це поліпшення, яке визволить більше часу для цікавих завдань, вони приймуть його з найменшим опором.
Допитливість – мати креативності, ще одна корисна для будь-якого програміста якість. Сильне бажання розібратися, що призвело до проблеми і як її вирішити, з великою ймовірністю спонукає його продовжувати роботу після того, як очевидні методи себе вичерпали. Це саме той склад розуму, який заохочує мислення, що виходить за рамки стандартного, і творче програмування.
Ймовірно, сама корисна якість допитливого програміста – те саме прагнення знайти і вирішити проблему, а не замаскувати її на швидку руку.
Від нього часто можна почути: «Можливо, є інший спосіб».
Педантичність
Багато класних програмістів прискіпливі до дрібниць. Вони будуть вимагати загального підходу у своїй роботі і в роботі їх команди (наприклад, дбати про загальні стандарти коду та уніфікованих назвах змінних). Вони вимагатимуть модульного тестування і перехресної ревізії коду. Вони будуть змушувати кожного в команді коментувати і документувати код. Вони будуть носитися з записами в журналі контролю версій.
Точно так само вони будуть чіплятися до дрібниць у комунікації, задавати здавалося б очевидні питання, просто щоб бути впевненими, що їх правильно зрозуміли. Це особливо вірно в таких речах як звіти про помилки. Хоча спілкуватися з ними не завжди просто, вони завжди зуміють чітко і ефективно донести ідею. Ця чіткість – величезна перевагу в будь-якому колективі розробників, особливо там, де заохочуються навчання і самонавчання.
Від нього часто можна почути: «У мене є ще декілька питань ...»
на останньому повноцінному проекті, з яким я мав справу, мій колишній колєга кріптував есемблі завжди ручками (і дуже матюкався, коли його змушували робити ручками реліз-білд, бо він спішить додому), але навіть не віддавав уваги тому, шо в кріпторі є проектні файли, в який сильний ключ можна вибрати лише раз як і саму есемблі :D і ше потім довго плювався, як я можу використовувати «застарілий Far Manager», бо побачив, шо я пишу в ньому (о боже!) якийсь bat-файл (він, як потім казав [кхм-кхм], «вчив dos-стрічку в школі»), який буде одним запуском за раз кріптувати то нещасне есемблі — отже, він ніразу не лінивий, і манагєри таких люблять :D
шкода, шо манагєрам подібні тексти і настанови (зокрема про песимізм) — до лампочки. дуже шкода. щодо педантичності, то можу хіба не дуже погодитися з тим, шо аж так потрібно коментувати і документувати код, оскільки такі програмісти, я впевнений, пишуть самодокументований код (щонайменше, .NET/Java-розробники)
і ше дуже цікаво, як інші учасники ресурсу коментуватимуть цей пост
Я не згоден із «Песимізм». Взагалі вважаю що песимістичні програмісти несуть деструктивні думки, а також дуже затягують процес розробки. Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює.
>> Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює
можливо, тут десь має бути «не»? та й чого «деструктивні», якшо той «песимізм» ставить за мету навпаки — покращити проект з подальшою простішою розробкою, бо намагається врахувати дещо заздалегідь?
Якщо він прагне зробити свою роботу швидко і при тому скурпульозно переглядає свої рішення, то можливо тут щось і є. Особисто я б написав «Оптимізм» і навів багато аргументів, не менш гірших і переконливих, ніж тут наведені.
Щодо: «Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює.»
Перефразую: «Оскільки існуючий код працює, хоч він і кривий, то песимістичні програмісти схильні його просто не чіпати, тому що бояться поламати те, що вже є.»
Лінивий програміст виносить загальний код в окрему бібліотеку, для повторного багаторазового використання, повністю автоматизує процес складання програми, наполягає на повному автоматичному тестуванні модулів, або пише розширюваний код зараз, навіть якщо це не було потрібно (щоб не переробляти код потім).
Крім того, лінивий програміст звичайно зосереджений на основних цілях проекту і не шукатиме додаткових завдань на свою голову. Він перешкоджає обростання продукту непотрібними функціями.
Текст до абзацу суперечить тексту після. Крім того, перша теза (про ускланення програми задля не дуже потрібної універсалізації) є абсолютно невірною. Якщо дуже хочеться, можу нагуглити пару цитат гуру, типу Фаулера чи Атвуда. Суть в тому, що краще випустити код і потім при потребі провести рефакторінг, ніж втратити ресурси на непотрібну функціональність
Все інше так, більш-менш, але це просто загальні слова.
тут нема ні слова про «непотрібну функціональність», а лише сказано — що винести код в окрему бібліотеку правильніше і швидше, ніж закопіпастити його в 5 місць.
крім того «текст першого абзацу сепуречить тексту після» це типу мається за увазі, що юзати ант чи мавен (не кажучи вже про круїзконтроль, худзон та тімсіті) це «лишня робота»)? :) Хлопці, в одному з проектів мій код деплоїться на 12 машин після кожної зміни. в іншому один модуль — на 3 машини, інший ще на дві. скільки часу по вашому займе «зборка і деплой вручну»? а зміни треба тестити в «дістрібютед інвайроменті» (як мінімум інтегрейшин тести).
Коментарі (11)
RSS згорнути / розгорнутина останньому повноцінному проекті, з яким я мав справу, мій колишній колєга кріптував есемблі завжди ручками (і дуже матюкався, коли його змушували робити ручками реліз-білд, бо він спішить додому), але навіть не віддавав уваги тому, шо в кріпторі є проектні файли, в який сильний ключ можна вибрати лише раз як і саму есемблі :D і ше потім довго плювався, як я можу використовувати «застарілий Far Manager», бо побачив, шо я пишу в ньому (о боже!) якийсь bat-файл (він, як потім казав [кхм-кхм], «вчив dos-стрічку в школі»), який буде одним запуском за раз кріптувати то нещасне есемблі — отже, він ніразу не лінивий, і манагєри таких люблять :D
шкода, шо манагєрам подібні тексти і настанови (зокрема про песимізм) — до лампочки. дуже шкода. щодо педантичності, то можу хіба не дуже погодитися з тим, шо аж так потрібно коментувати і документувати код, оскільки такі програмісти, я впевнений, пишуть самодокументований код (щонайменше, .NET/Java-розробники)
і ше дуже цікаво, як інші учасники ресурсу коментуватимуть цей пост
cyba
Silver
А так то мені стаття сподобалася.
andriybuday
можливо, тут десь має бути «не»? та й чого «деструктивні», якшо той «песимізм» ставить за мету навпаки — покращити проект з подальшою простішою розробкою, бо намагається врахувати дещо заздалегідь?
cyba
Щодо: «Вони бояться робити зміни в існуючому коді, який поганий він б не був, а бояться того що він працює.»
Перефразую: «Оскільки існуючий код працює, хоч він і кривий, то песимістичні програмісти схильні його просто не чіпати, тому що бояться поламати те, що вже є.»
andriybuday
enej
egghead
zlosny
Текст до абзацу суперечить тексту після. Крім того, перша теза (про ускланення програми задля не дуже потрібної універсалізації) є абсолютно невірною. Якщо дуже хочеться, можу нагуглити пару цитат гуру, типу Фаулера чи Атвуда. Суть в тому, що краще випустити код і потім при потребі провести рефакторінг, ніж втратити ресурси на непотрібну функціональність
Все інше так, більш-менш, але це просто загальні слова.
whirlwind
крім того «текст першого абзацу сепуречить тексту після» це типу мається за увазі, що юзати ант чи мавен (не кажучи вже про круїзконтроль, худзон та тімсіті) це «лишня робота»)? :) Хлопці, в одному з проектів мій код деплоїться на 12 машин після кожної зміни. в іншому один модуль — на 3 машини, інший ще на дві. скільки часу по вашому займе «зборка і деплой вручну»? а зміни треба тестити в «дістрібютед інвайроменті» (як мінімум інтегрейшин тести).
archer
А винесення коду в бібліотеку — в загальному випадку звiсно що правильнiше, хоча тут треба знати мiру.
whirlwind
Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.