Правила поганого і хорошого тону в програмуванні — думки експертів



Поки попит на програмістів в ІТ-індустрії та за її межами достатньо високий. Але в будь-якій галузі «хороший» спеціаліст цінується завжди, незалежно від її популярності. Виникає питання, як стати таким фахівцем? Які критерії професіоналізму високого рівня можна виділити? Відповіді на ці запитання багато в чому залежать від конкретних роботодавців.

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

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

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

Якщо програміст не відповідає базовим вимогам, то йому рано чи пізно вкажуть на двері.

Ознаки поганого програміста
Поширеним і одним з головних ознак вважається нездатність виконувати програму в голові». Якщо перед вами людина з гарними посадами в резюме, але він не може написати простий алгоритм на папері, краще з ним не зв'язуватися.

На Хабре» у свій час був посада, в якому обговорювалися ознаки поганого програміста:

• наявність «чарівного», «вуду» коду або коду, який не має ніякого відношення до цілям програми, але все одно ретельно підтримується;

• виправлення помилок написанням надлишкового коду, який замінює дані, отримані при виконанні несправного коду;

• «йо-йо код», який конвертує значення в різні уявлення, а потім конвертує їх назад рівно те ж уявлення, з якого починали

• «бульдозерний код», який створює враження рефакторінгу допомогою розбиття шматків коду на процедури, які, правда, потім неможливо використовувати де-небудь ще.

Він також виділяє ще дві проблеми – з покажчиками і рекурсією. Якщо хтось сам не пише рекурсивні алгоритми і не виконує операції з покажчиками вручну, розуміти, як це працює, треба.br/>

Складнощі з покажчиками

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

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

Складнощі з рекурсією

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

виконання домовленостей

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

@victorb, автор згаданого вище поста вказує такі «симптоми», пов'язані з невмінням слідувати парадигмі розробки:

• використання будь-якого необхідного синтаксису для того, щоб «вирватися» з запропонованої мовою моделі, і написання другої частини програми в імперативному/процедурному стилі;

• (ООП) Спроби виклику не статичних функцій або присвоєння змінних в неинстанциированных класах, проблеми з розумінням, чому такі конструкції не компілюються;

• (Реляційне) Звернення з базою даних як з сховищем об'єктів, виконання всіх JOIN'ів і перевірки цілісності на клієнтській стороні;

• (Функціональне) Створення багатьох версій одного і того ж алгоритму для обробки різних типів або операторів замість передачі функцій вищого порядку узагальненого алгоритму;

• (Декларативне) Встановлення індивідуальних значень в імперативному коді замість використання зв'язування даних (data binding).

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

Ми поспілкувалися з експертами російської ІТ-індустрії і з'ясували їх думку з приводу хороших і поганих програмістів, а також попросили дати декілька порад початківцям.

Максим Нальский, засновник сервісу Pyrus:


Якими якостями повинен володіти хороший програміст?

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

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

Яким чином непрограммист (менеджер, наприклад) може відрізнити хорошого програміста від поганого?

Вміння написати легко читається, компільований, що проходить автотесты, працюючий код — головний критерій.

Дайте, будь ласка, «шкідливі поради», правила поганого тону для початківців програмістів.

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

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

Руслан Фазлієв, СЕО Ecwid:


Якими якостями повинен володіти хороший програміст?

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

Яким чином непрограммист (менеджер, наприклад) може відрізнити хорошого програміста від поганого?

Відрізнити хорошого програміста – за того, що він створив і наскільки швидко розв'язує прості задачі. Складні завдання складаються з простих, і, якщо програміст легко володіє атомарними кубиками, він буде результативним.

чи Може хороший програміст бути перфекціоністом? Чому?

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

Повинні компанії побоюватися програмістів-перфекціоністів? Чому?

Їх не потрібно побоюватися, ними треба управляти. Часті проміжні дедлайни – обов'язково для перфекціоністів, якщо у них не «народжується» код, що потрібно робити «кесарів».

Як ви ставитеся до того, що більшу частину коду для вирішення завдань розробник бере з інтернету?

Відмінно, якщо це прискорює результат.

Має добрий програміст використовувати вирази return true або return false в циклах? Чи Правда, що хороший програміст зазвичай намагається використовувати менше умовних операторів? Чи Правда, що хороший програміст майже не використовує оператор «else» і йому подібні?

Гарному програмісту потрібно займатися тим, щоб сьогодні ж код працював у клієнта. Гравець повинен забивати голи, як він це робить – не важливо. Остерігайтеся слова «архітектура» від програмістів. Говорячи ж про красу коду – чудово, коли вона є природно і по ходу справи, і так, море «if'ов» – не красиво і глюкоопасно. Але я не хочу це обговорювати з програмістом: все, що я хочу знати – коли буде готовий протестований якісний реліз.

Дайте, будь ласка, «шкідливі поради», правила поганого тону для початківців програмістів.

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

Євген Потапов, гендиректор «Сума Айті»:


Якими якостями повинен володіти хороший програміст?

У відмінній книзі Coders at work (серії інтерв'ю з відомими розробниками) — один з головних питань «яким чином ви вивчаєте чужий код?».

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

Яким чином непрограммист (менеджер, наприклад) може відрізнити хорошого програміста від поганого?

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

чи Може хороший програміст бути перфекціоністом? Чому?

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

Повинні компанії побоюватися програмістів-перфекціоністів? Чому?

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

Як ви ставитеся до того, що більшу частину коду для вирішення завдань розробник бере з інтернету?

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

Дозволено гарному програмісту хронічно не пам'ятати деякі алгоритми та синтаксичні конструкції мов, якими він користується в роботі? Чому?

Дуже сильно залежить від рівня незнання. Базові речі треба, звичайно, знати

Має добрий програміст використовувати вирази return true або return false в циклах? Чи Правда, що хороший програміст зазвичай намагається використовувати менше умовних операторів? Чи Правда, що хороший програміст майже не використовує оператор «else» і йому подібні?

Хороший програміст це не той, хто не пише goto, робить return там, де це належить, і знає все патерни ООП з Gang of Four на зубок.

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

Віктор Шабуров, технічний директор Snapchat:


Якими якостями повинен володіти хороший програміст?

Smart and get things done.

Яким чином непрограммист (менеджер, наприклад) може відрізнити хорошого програміста від поганого?

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

чи Може хороший програміст бути перфекціоністом?

Так, це дуже добре.

Повинні компанії побоюватися програмістів-перфекціоністів? Чому?

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

Має добрий програміст використовувати вирази return true або return false в циклах?

Років 10 тому, коли я ще кодував, відповідь була «ні».

Правда, що хороший програміст зазвичай намагається використовувати менше умовних операторів?

Треба писати гарний код і використовувати стільки if, скільки потрібно. В Java, наприклад, користуватися && та ||, щоб скоротити if.

Правда, що хороший програміст майже не використовує оператор «else» і йому подібні?

Я використовував else, коли було потрібно, але є тонкощі.

Дайте, будь ласка, «шкідливі поради», правила поганого тону для початківців програмістів.

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

Так само дивитися не стільки на зарплату, скільки на перспективу проекту і виділяються акції компанії. В успішному проекті з сильною командою, як Looksery або Machine Learning Works, на акціях можна в десятки разів більше заробити, ніж отримати зарплатою за цей період.



Становлення «хорошого» програміста зводиться не лише до вирішення суто технічних недоліків. Як і будь-який фахівець, він повинен вміти спілкуватися з колегами, і коли потрібно, з клієнтами. Вміння адекватно сприймати зворотний зв'язок, критику вважаються не менш важливими якостями, ніж здатність до засвоєння алгоритмів і технологій розробки ПЗ.
Джерело: Хабрахабр

0 коментарів

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