Пока спрос на программистов в ИТ-индустрии и за ее пределами достаточно высокий. Но в любой отрасли «хороший» специалист ценится всегда, вне зависимости от ее популярности. Возникает вопрос, как стать таким специалистом? Какие критерии профессионализма высокого уровня можно выделить? Ответы на эти вопросы во многом зависят от конкретных работодателей.
В каждой компании, разрабатывающей программное обеспечение существуют свои требования к разработчикам. Современные программные проекты разрабатываются группами программистов, которые часто работают в разных кабинетах, зданиях, и даже городах и странах. Технологии удаленной работы позволяют использовать навыки лучших разработчиков, вне зависимости от места нахождения их работодателей. Такой подход к разработке предъявляет серьёзные требования к качеству кода, в частности, к его читабельности и прозрачности.
Для слабых разработчиков работа в изоляции может стать непреодолимым препятствием, так как они выпадают из-под опеки более опытных коллег, которые обычно тянут отстающих за собой.
Среди профессионалов всегда существуют какие-то договоренности. Это выражается, например, в том, что в свое время сформировались различные парадигмы и стили программирования. Однако, прежде всего, существуют некие базовые требования, которые предъявляются к профессиональным программистам независимо от направления и стиля разработки.
Если программист не соответствует базовым требованиям, то ему рано или поздно укажут на дверь.
Признаки плохого программиста
Распространенным и одним из главных признаков считается неспособность «выполнять программу в голове». Если перед вами человек с красивыми должностями в резюме, но он не может написать простой алгоритм на бумаге, лучше с ним не связываться.
На «Хабре» в свое время был пост, в котором обсуждались признаки плохого программиста:
• наличие «волшебного», «вуду» кода или кода, который не имеет никакого отношения к целям программы, но всё равно тщательно поддерживается;
• исправление ошибок написанием избыточного кода, который замещает данные, полученные при исполнении неисправного кода;
• «йо-йо код», который конвертирует значения в различные представления, а потом конвертирует их обратно ровно в то же представление, с которого начинали
• «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Он также выделяет еще две проблемы – с указателями и рекурсией. Если кто-то сам не пишет рекурсивные алгоритмы и не выполняет операции с указателями вручную, понимать, как это работает, необходимо.
Сложности с указателями
Если вы не понимаете указатели, то остаётся очень небольшой круг типов программ, которые вы можете написать, поскольку это понимание позволяет создавать сложные структуры данных и целесообразные API. Непонимание концепции указателей отразится в бедном проектировании структур данных и ошибках, причины которых кроются в разнице между передачей по значению и по ссылке.
Управляемые языки используют ссылки вместо указателей, которые похожи, но обеспечивают автоматическое разыменование и запрещают арифметические операции над указателями для устранения целого класса ошибок.
Сложности с рекурсией
Идею рекурсии достаточно легко понять, но у программистов часто возникают проблемы с тем, чтобы представить результат рекурсивной операции или насколько сложные вычисления могут быть произведены с простой функцией. Проблемы с представлением «где вы находитесь», когда вы начинаете писать условие продолжения рекурсии, или с формализацией параметров рекурсивной функции могут сделать разработку рекурсивной функции очень сложной для вас.
Следование договоренностям
Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня. Ведь это противоречит принципам всех парадигмам программирования – объектно-ориентированной, функциональной, декларативной и так далее. Такой подход затрудняет или делает практически невозможной коллективную разработку. Подобное отношение характеризует человека как ригидного, поверхностного, не желающего углублять свои знания и совершенствовать навыки.
@victorb, автор упомянутого выше поста указывает следующие «симптомы», связанные с неумением следовать парадигме разработки:
• использование любого необходимого синтаксиса для того, чтобы «вырваться» из предлагаемой языком модели, и написание оставшейся части программы в императивном/процедурном стиле;
• (ООП) Попытки вызова не статических функций или присвоения переменных в неинстанциированных классах, проблемы с пониманием, почему такие конструкции не компилируются;
• (Реляционное) Обращение с базой данных как с хранилищем объектов, исполнение всех JOIN'ов и проверки целостности на клиентской стороне;
• (Функциональное) Создание многих версий одного и того же алгоритма для обработки разных типов или операторов вместо передачи функций высшего порядка обобщенному алгоритму;
• (Декларативное) Установление индивидуальных значений в императивном коде вместо использования связывания данных (data binding).
Кроме однозначных минусов у разработчика могут быть такие качества, как перфекционизм, излишний педантизм, медлительность и так далее. Эти качества неспецифичны для какой-либо отрасли, но для кого-то они будут иметь решающее значение, а для кого-то – нет.
Мы пообщались с экспертами российской ИТ-индустрии и выяснили их мнение по поводу хороших и плохих программистов, а также попросили дать пару советов начинающим.
Максим Нальский, основатель сервиса Pyrus:
Какими качествами должен обладать хороший программист?
Хороший программист пишет качественный исходный код лучше и быстрее других. Если человек знает модные технологии, работал в крутых компаниях, окончил престижный ВУЗ, блещет рекомендациями, но не производит хороший исходный код за разумное время, вряд ли его можно называть сильным программистом.
Программирование — это способ мышления, который не зависит от конкретного языка или платформы. Сильный разработчик осваивает новую технологию за неделю и уже может производить результат. Конечно, стать экспертом занимает большее время.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Умение написать легко читаемый, компилируемый, проходящий автотесты, работающий код — главный критерий.
Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.
Если хотите стать плохим программистом — идите на курсы, слушайте лекции, только ни в коем случае не программируйте сами. Некоторые так и делают — штудируют учебники, потом сдают экзамены, получают бумажки, сертификаты.
Когда я читаю резюме с длинным списком сертификатов, я вижу, как человек тратил время своей жизни, не совершенствуясь в навыках создания надежного софта, а получал оценки.
Руслан Фазлыев, СЕО Ecwid:
Какими качествами должен обладать хороший программист?
Хороший программист должен выпускать хороший код, быстро, результативно.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Отличить хорошего программиста – по тому, что он создал и насколько быстро решает простые задачи. Сложные задачи состоят из простых, и, если программист легко владеет атомарными кубиками, он будет результативен.
Может ли хороший программист быть перфекционистом? Почему?
Хороший программист может быть кем угодно – лентяем, перфекционистом, занудой. Использовать эти сильные стороны и митигировать слабые – задача хорошего инженерного менеджера.
Должны ли компании опасаться программистов-перфекционистов? Почему?
Их не нужно опасаться, ими нужно управлять. Частые промежуточные дедлайны – обязательно для перфекционистов, если у них не «рожается» код, нужно делать «кесарево».
Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?
Отлично, если это ускоряет результат.
Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «else» и ему подобные?
Хорошему программисту нужно заниматься тем, чтобы сегодня же код работал у клиента. Игрок должен забивать голы, как он это делает – не важно. Опасайтесь слова «архитектура» от программистов. Говоря же о красоте кода – прекрасно, когда она есть естественно и по ходу дела, и да, море «if'ов» – не красиво и глюкоопасно. Но я не хочу это обсуждать с программистом: все, что я хочу знать – когда будет готов протестированный качественный релиз.
Дайте, пожалуйста, «вредные советы», правила плохого тона для начинающих программистов.
Все счастливые семьи счастливы одинаково, быть несчастным есть миллион способов. Первейший способ быть плохим программистом – лениться, гордиться, и искать сложных решений там, где есть простые.
Евгений Потапов, гендиректор «Сумма АйТи»:
Какими качествами должен обладать хороший программист?
В отличнейшей книге Coders at work (серии интервью с известными разработчиками) — один из главных вопросов «каким образом вы изучаете чужой код?».
Хороший программист это тот, кто может поддерживать чужой проект, тот кто может после запуска продолжать дописывать свой код, тот, чей код могут поддерживать другие люди.
Каким образом непрограммист (менеджер, например) может отличить хорошего программиста от плохого?
Я считаю, что единственным нормальным способом оценки программиста непрограммистом является оценка того, как отзываются о тех проектах, где он работал, руководители этих проектов. Не бросил на полпути, выполнил в срок, продолжал доработки и ничего не упало — значит все хорошо; просят сказать, где его можно найти, чтобы убить — на работу лучше не брать.
Может ли хороший программист быть перфекционистом? Почему?
Может, если это не будет идти во вред производительности. К сожалению, почти наверняка идет, а в современном бизнесе время до деплоя куда важнее идеальности кода в большинстве случаев (пока вы не пишете медицинский софт и не запускаете людей в космос).
Должны ли компании опасаться программистов-перфекционистов? Почему?
Должны, но компании должны спрашивать отзывы с предыдущих мест работы, и если там все хорошо — сильно не бояться.
Как вы относитесь к тому, что большую часть кода для решения задач разработчик берет из интернета?
А как относиться к тому, что строители теперь сами не собирают глину и не пекут кирпичи? Знание алгоритмов — важный базис, однако основным навыком сейчас становится возможность склеить нужные решения надежно, поддерживаемо и в срок.
Позволительно ли хорошему программисту хронически не помнить некоторые алгоритмы и синтаксические конструкции языков, которыми он пользуется в работе? Почему?
Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать
Должен ли хороший программист использовать выражения return true или return false в циклах? Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов? Правда ли, что хороший программист почти не использует оператор «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, на акциях можно в десятки раз больше заработать, чем получить зарплатой за это период.
Становление «хорошего» программиста сводится не только к исправлению чисто технических недостатков. Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами. Умение адекватно воспринимать обратную связь, критику считаются не менее важными качествами, чем способность к усвоению алгоритмов и технологий разработки ПО.
Комментарии (67)
poxu
27.10.2016 19:59+8Те, кого менеджеры считают хорошим программистом и те, кого программисты считают хорошим программистом это часто разные люди. Вот прекрасный пример.
Если коротко, то человек написал в машинных кодах блек джек, в который давали поиграть клиентам, чтобы продемонстрировать технику и заключить сделку. И он написал крайне быстрый код.
Потом его попросили модифицировать код так, чтобы клиент чаще выигрывал. Он решил, что это нечестно и написал код из-за которого клиент начал проигрывать.
Когда у него потребовали всё исправить — послал менеджмент к лешему и увоилился. Человек, которого попросили прогнуть код под клиента провел очень много времени разбирая машинные коды и поражаясь глубине технического гения предшественника. В конце концов он всё-таки понял, как написана программа.
Но, из уважения к создателю, сказал менеджменту, что поправить ничего нельзя, так как он не способен понять код.
И это пример того, каким с его точки зрения должен быть идеальный программист.
vadimr
27.10.2016 23:43-3Это не программист, а любитель программирования.
asdf87
28.10.2016 04:51+3А программист — это тот кто китайский файрвол делает?
vadimr
28.10.2016 05:14-4Программист — это тот, кто решает поставленную профессиональную задачу.
Areso
28.10.2016 07:01+6Самоуважение тоже должно быть. Кто-то решает поставленную задачу по «скрутке» или «накрутке» голосов на РОИ. И да, они тоже программисты. Но уважать таких людей?
vadimr
28.10.2016 09:12-2Лично я бы не брал на работу человека, тараканы в голове которого мешают выполнению служебных обязанностей. Типа, ему вдруг не нравится, что клиенты получают десяток цветных пикселей на экране за победу. А в данном случае ещё и пишет несопровождаемый код.
Пусть он владеет инструментом разработки хоть как бог, но профессионализм заключается, кроме прочего, в способности при необходимости сжать зубы и сделать неприятную работу.wing_pin
28.10.2016 10:29+2Вы хотите сказать, что профессионализм заключается в способности при необходимости сжать зубы и совершить преступление?
bigfatbrowncat
28.10.2016 10:56+4«Неприятная работа» — это сутки-двое дебага с целью найти один хитрый SEGFAULT.
То, о чем здесь идет речь — это моральная дилемма.
Человек, имеющий принципы (к слову сказать, никак не связанные с его профессиональной деятельностью), не станет портить свою репутацию и становиться противен самому себе, делая то, что противоречит этим принципам.
Это касается не только программистов, а любых специалистов вообще.
И если бы все крутые специалисты были такими, как этот парень (надеюсь, что история — не чистой воды легенда), то у террористов было бы меньше оружия и хакеры не взламывали бы хорошие, годные сайты.
Нравственность можно отменить. Но результат для общества бывает плачевным.
Добрый совет. Не берите на работу людей, которые готовы совершить любую мерзость просто при наличии задачи от менеджера. Потому что эти люди, например, могут осуществить промышленный шпионаж. Или что-то еще, что им выгодно. А на вас им наплевать, как и на ваших заказчиков/клиентов и т.д…
poxu
28.10.2016 09:07Спецназовцы тоже решают поставленные профессиональные задачи. И сантехники. И даже менеджеры решают. У вас слишком широкое определение.
vadimr
28.10.2016 09:22+2Да, все они могут быть профессионалами в своей области. Спецназовец решает спецназовские задачи (хотя ему тоже может не понравиться спасать от террористов какого-нибудь несимпатичного ему человека, например, не любящего запущеный его спецслужбой файрвол; но это никого не должно волновать). Сантехник проводит водопровод на кухню, хотя ему может больше хотеться устроить шикарный фонтан у вас в гостиной. А программист решает программистские задачи. При этом личные предпочтения, приходящие в конфликт со служебными обязанностями, уместно проявлять в свободное от работы время.
poxu
28.10.2016 09:41Ну вот допустим есть 2 программиста — один решает задачи, поставленные работодателем, а второй решает их хуже. Но код первого раз в 10 медленнее кода второго. Какой из них лучше?
kloppspb
28.10.2016 10:00+4А что в ТЗ сказано про скорость работы?
poxu
28.10.2016 10:05В ТЗ ничего не сказано, можно считать, что у программиста, код которого медленнее — скорость кода работодателя устраивает.
Но есть один нюанс. Писать быстрый код первый программист не умеет совсем. Не может он этого, квалификации не хватает.
vadimr
28.10.2016 11:02+1Если медленный код устраивает, то в быстроте нет никакой ценности. Поэтому в современной практике редко используется ассемблер.
Соответственно, я не вижу профессиональной квалификации в способности писать ненужно быстрый код. Это навык, бесполезный до появления критичных к времени выполнения задач.poxu
28.10.2016 11:23Вопрос то не в полезности навыка, а в том, какой программист лучше.
vadimr
28.10.2016 11:31+1Лучше по какому критерию? Как профессионал при решении своих задач — первый лучше. А абсолютный зачёт невозможен. От программиста вебморд требуются одни качества, от программиста встраиваемых систем — другие.
poxu
28.10.2016 11:47Сам вопрос — какой программист лучше — сводится к вопросу — какой критерий главный. Это и хочется узнать. Какой критерий важнее, по вашему мнению.
kloppspb
28.10.2016 11:50Это абстрактный вопрос в вакууме. Очевидно, что при урезаных вводных и применительно к данному случаю — первый. Но в реальной жизни формального ответа на этот вопрос вы не получите даже если расширите набор входных данных на порядок.
poxu
28.10.2016 12:01Очевидно, что при урезаных вводных и применительно к данному случаю — первый.
Вам очевидно, что первый, другим очевидно, что второй. Вопрос подвешен в вакууме, специально, чтобы выявить эти очевидности :).
kloppspb
28.10.2016 12:13Это выявление выглядит как совершенно инфантильное докапывание уровня «а кого ты больше любишь, папу или маму?».
Интересен ответ — спросите у того самого работодателя, никто, кроме него ответа вам не даст.poxu
28.10.2016 12:20Тут целая статья посвящена такому докапыванию, так что оно в тему :).
Ну а вопрос на тему того, кого ты больше любишь — папу или маму — это специальная такая штука, которая выявляет — понимает ли уже ребёнок, что рассказывать, что кого-то ты любишь больше, чес кого-то другого — нельзя.
Не потому что ты всех любишь одинаково, а потому, что если расскажешь — то у тебя стопудов будут проблемы. Поэтому от ответа надо всеми возможными способами уходить. Самый элегантный способ это спросить — дядя, ты дурак?
bigfatbrowncat
28.10.2016 11:14Тут, как мне кажется, всё просто. Второй товарищ не на своем месте. Ему просто имеет смысл найти другую работу, соответствующую квалификации. Потому что когда ты часть обязанностей выполняешь лучше, чем надо, а другую — не тянешь, значит от тебя хотят не того, что ты реально умеешь.
poxu
28.10.2016 11:26Если бы вопрос состоял в том — что стоит сделать более квалифицированному программисту — то да, я бы с вами согласился. Но мне интересно узнать мнение по поводу того, какой из них лучше.
bigfatbrowncat
28.10.2016 11:30Никакой. Информации недостаточно.
Вы написали, что второй делает что-то хуже. Но не объяснили, что и почему. Зато, сказали, что именно хуже делает первый. То есть имеем сравнение понятного с непонятным.
А с точки зрения работодателя, естественно, хороший инженер — тот, кто решил поставленную задачу с заданным качеством и в установленный срок. Так что первый однозначно подходит. А второй — нет. Вот и весь вывод, который можно сделать на основании вашего примера.poxu
28.10.2016 11:46Вы написали, что второй делает что-то хуже. Но не объяснили, что и почему.
Один в сроки закрывает задачи, другой пишет более быстрый код.
Тот кто пишет более быстрый код делает это потому что ему позволяет квалификация.
bigfatbrowncat
28.10.2016 14:12+1У опытного менеджера сроки всегда с запасом. Но заказчик может потребовать срочную хотелку «вчера».
Пока всё идет по плану, менеджер постарается заложить медлительность второго девелопера и будет его подгонять (если верит в то, что тот пишет код лучше). Но как только придет форс-мажор (а он обязательно случится), медлительному придется или переквалифицироваться в тяп-ляп-быстрого, или получить по мозгам очень больно. Потому что именно такие форс-мажоры, когда менеджер носится в мыле и пытается понять, что не устроило заказчика в свежеотгруженном релизе, и определяют полезность разработчика для компании.
Они оба плохи, если не умеют иначе. Хороший дев — гибкий дев. Знает, когда можно сделать хорошо и неторопливо, знает, когда можно сделать быстрый костыль.
Лично я стараюсь начальнику всегда предложить два варианта — быстрый и правильный. Объяснить Pros & cons. Пусть он выбирает. А я сделаю, как он считает правильным.
dsdr
28.10.2016 12:50Возможно, первый программист использует алгоритм, оптимизированный по памяти, а второй — по скорости. Какой из них лучше — зависит от ситуации и поставленной задачи.
amaksr
27.10.2016 21:02+11Очень сильно зависит от уровня незнания. Базовые вещи надо, конечно, знать
Эх, а я вот частенько гуглю базовые функции, например поиск подстроки в строке.
А все потому, что в голове конкретная каша из Java, JavaScript, PL/SQL, PHP, MS SQL, MySQL и т.д. и т.п.: где-то подсчет символов идет с 0, где-то с 1; по-разному обрабатываются NULLs, у всех разные параметры и разные допустимые значения.
Про все это можно сказать «базовые вещи», но например в мою память уже не помещаются.
nazarpc
27.10.2016 23:06-1Такое обычно подсказывает IDE. В JS всё сложнее, там подсказки паршиво работают, но вот для PHP всё очень даже хорошо, в Java есть типизация, тоже должно быть отлично.
3aicheg
28.10.2016 03:39+6Не знаю, что конкретно товарищ имел ввиду под «базовыми вещами», но вот тривиальные вещи вроде названий и парамеров конкретных функций знать в смысле «помнить наизусть» совсем необязательно.
Я, например, сколько лет программирую на Питоне, никогда не помнил, как добавляется элемент в set. Это add()? Это append()? Это insert()? Это +=? |=? «Базовой вещью» в данном случае является знание того, что set вообще существует, для чего нужен, что его не надо писать самому или использовать array/list там, где лучше всего подойдёт set. А детали не грех загуглить.
M-A-XG
27.10.2016 22:41-3> Если программист не соответствует базовым требованиям, то ему рано или поздно укажут на дверь.
Имитация бурной деятельности — наше все. :)
> «бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Это последствие пропаганды, в первую очередь ООП, когда оно используется без понимания, ради самого ООП, ибо кто не пишет в ООП, с того будут смеятся. :)
> Если разработчик пишет код по принципу «работает, и ладно», его вряд ли можно считать профессионалом высокого уровня.
Хм, почему вы тогда дальше доколупывались до интервьюируемых, стоит ли избегать перфекционистов? :)
> «симптомы», связанные с неумением следовать парадигме разработки
А зачем следовать этим парадигмам? Ради того, чтобы следовать? Культ карго? :) PHP, JS — мультипарадигменные.
> и написание оставшейся части программы в императивном/процедурном стиле;
Основа моего кода — продедурный стиль — понятный всем. А не широкопальцевая ИБД.
> Установление индивидуальных значений в императивном коде вместо использования связывания данных
Шойта?
> насколько быстро решает простые задачи
В представлении менеджера — да че ты вые, там всего одну строчку добавить.
А то, что потом все из-за нее падает, то ему пох. :)
Но да, простые задачи нужно решать простыми способами. :)
>Первейший способ быть плохим программистом – искать сложных решений там, где есть простые.
В мире PHP (вебе) (сам из него) заклюют, если не используешь мейнстримовый фреймворк (микроскоп) для создания сайтов (забивания гвоздей). :)
Чем больше проблем ты решишь, тем более высокий у тебя рейт, и плевать, что большинство проблем самопринесенные решением неподходящим образом.
> Хороший программист это тот, кто может поддерживать чужой проект
Любой говнокодер это может :)
> тот кто может после запуска продолжать дописывать свой код
А в чем проблема? :)
> тот, чей код могут поддерживать другие люди.
+1
> Должен ли хороший программист использовать выражения return true или return false в циклах?
А в чем проблема?
> Правда ли, что хороший программист обычно cтарается использовать меньше условных операторов?
Хороший программист старается писать понятный код…
> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
Это менеджер оценить не сможет… :)
> Как и любой специалист, он должен уметь общаться с коллегами, и когда нужно, с клиентами.
Я человек простой. Вижу дебила, шлю найух. :)M-A-XG
28.10.2016 13:10Я услышу контраргументы минусующих говнокодеров или нет?
Или я раскрыл чей-то секрет? :)bigfatbrowncat
28.10.2016 14:28Вы продемонстрировали местами очень плоский взгляд на вещи.
>> Хороший программист это тот, кто может поддерживать чужой проект
>Любой говнокодер это может :)
Если по-честному, то поддерживать — это:
1. Долго чинить ошибки,
2. Добавляя новую функциональность.
Понятие «долго» определяется тем, насколько нагружен проект пользователями. Для некоторых механимов поисковика Google «долго» измеряется, думаю, днями. Для некоторых узкоспецифичных научных задач это могут быть и десятилетия.
Слабый разработчик (я бы на вашем месте воздержался от определения «говнокодер», если не хотите получить его от кого-то в ответ) наделает плохих «костылей», которые не починят ошибку, а доломают систему окончательно. И разобраться в причинах уже не сможет.
Я сталкивался с ситуацией, когда код был мне «не по зубам». И всегда честно признавался руководству. Обычно в этих случаях в ответ получал: «ничего, разберешься». Главное — не брать на себя больше, чем можешь унести.
>> Дать задачек на кодирование. Например, мини проект на вечер — и посмотреть как быстро сделает, качество кода и как обрабатывает крайние случаи.
>Это менеджер оценить не сможет… :)
Менеджер, во-первых, иногда сам в прошлом — кодер, причем, часто — неплохой, раз смог вырасти. А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
Если речь идет не о стартапе из 3 человек, при приеме на работу любого специалиста всегда найдется сециалист в той же области рангом выше.
>> тот, чей код могут поддерживать другие люди.
>+1
Вы же сказали, что поддерживать любой «говнокодер» может. Так в чем проблема? Или «говнокодер» может поддерживать только код, написанный «крутокодером»? А чтобы поддерживать код слабого программиста, кто нужен?..
>Я человек простой. Вижу дебила, шлю найух. :)
Думаю, что вы лукавите. Или работаете в одиночку над инди-проектом.M-A-XG
28.10.2016 16:36>наделает плохих «костылей», которые не починят ошибку, а доломают систему окончательно
Но поддержит же.
Поэтому я и говорю, что разница — в качестве кода после программиста.
>Менеджер, во-первых, иногда сам в прошлом — кодер.
Тогда это не менеджер, а замаскированный программист…
>А если он не разбирается, то найдет доверенного эксперта и заручится его поддержкой.
То есть все же сам менеджер не может этого определить…
>Вы же сказали, что поддерживать любой «говнокодер» может.
Перечитайте, что говорилось в статье и что я цитировал.
Улавливаете разницу:
«поддерживает говнокодер после кого-то»
и
«кто-то поддерживает после говнокодера»
? :)bigfatbrowncat
28.10.2016 17:30+1>Но поддержит же.
Так — нет! Спустя пару недель (месяцев) количество записей в багтрекере начнет неумолимо расти, ситуация выйдет из под контроля и товарищ будет отстранен.
>Тогда это не менеджер, а замаскированный программист
Я видел в жизни порядка 10 хороших манагеров. Больше половины в прошлом были девелоперами. Это с трудом укладывается в молодой голове, но годам к 35-40 многим вполне себе талантливым людям надоедает писать код. Устают. Внимание не то, память не та. Но при этом они не прекращают пониимать, как это делать хорошо и правильно.
>То есть все же сам менеджер не может этого определить…
Функционально — может. Говоря о руководителе, надо под словом «может» понимать «способен получить результат». Потому что своими руками без помощи подчиненных руководитель может довольно мало. В предметной области — критически мало. Но это не значит, что он не сможет решить задачу «отличить тестовое задание, написанное хорошо от того, которое написано плохо».
Везде, где я работал, у руководителя всегда есть «правая рука» — старший разработчик, который дает руководителю технические консультации (или экспертизу) при необходимости. Обычно такого человека называют «техлид».
>«поддерживает говнокодер после кого-то»
>и
>«кто-то поддерживает после говнокодера»
Я-то разницу улавливаю. Но вы ее в своем комментарии не делали. Вы просто написали «любой говнокодер может». Это — ложное утверждение.
К слову, это утверждение ложное даже с поправкой вида «любой дурак может поддерживать код, написанный хорошим спецом». Потому что поддержка — это еще и добавление новой функциональности. А дурак просто не сможет разобраться в архитектуре сложной программы, написанной умным человеком. И надобавляет такого, что всё будит глючить.
Antervis
28.10.2016 05:57+11Я как перфекционист и любитель early return крайне возмущен шовинизмом в свой адрес!
VioletGiraffe
28.10.2016 13:43+1Я вот тоже не понял, что не так с return в цикле. Типа, количество точек возврата нужно снижать? Нигде ещё не встречал такой рекомендации. Пишу по-разному — как понятнее и красивее получается.
bigfatbrowncat
28.10.2016 14:30Есть такая рекомендация, есть. В гайдлайнах крупных компаний.
Она имеет некоторый смысл в C/C++ (например, не пропустить return — это может привести к беде). В Java, например, она совершенно бессмысленна.
AlexPu
28.10.2016 09:40Я плохой программист — вы меня убедили… И я согласен получать тот доход, что я получаю сейчас и больший доход через год
ServPonomarev
28.10.2016 09:46Начинающий программист — пишет код как умеет,
Опытный программист — использует паттерны, методологии и прочая,
Гуру — пишет код, как умеет.
До понимания некоторых вещей просто дорасти нужно.3aicheg
28.10.2016 09:53+6Настоящий программист — пишет код блеать!
AlexPu
28.10.2016 11:14-3Насточщий программист приносит прибыль компании, которая является его работодателем… а уж какой он там код пишет…
3aicheg
28.10.2016 11:24+4Приносит он прибыль или нет — вопрос отдельный, весьма малое отношение имеющий к тому, какой он программист и программист ли вообще.
AlexPu
28.10.2016 11:56Но так бывает, что тот кто приносит прибыль именно программист — Ну хотябы потому, что его наняли на жту должность… Хотя он может не соответствовать высоким критериям духовности, которые вы предъявляете к носителю этого титула
Pashehon
28.10.2016 12:50Я считаю, что единственным нормальным способом оценки программиста непрограммистом является оценка того, как отзываются о тех проектах, где он работал, руководители этих проектов. Не бросил на полпути, выполнил в срок, продолжал доработки и ничего не упало — значит все хорошо; просят сказать, где его можно найти, чтобы убить — на работу лучше не брать.
Очень спорно.
Пример: Участвовал в разработке сайта для фирмы. Директор активно влезал в разработку, придумывал все новые и новые фичи для реализации, а также требовал быстрого их ввода (важно). Зачастую для быстрой реализации этих фич приходилось страшно костылить (аж вспоминаю с горячим потом), потому что нововведения никак не подходили под экосистему портала. Тестирование и рефакторинг в таких условиях тоже были почти никаким, код худо-бедно комментировать только успевал.
В конце концов даже высокая зп не сдержала меня и я ушел. В ответ раздавались крики о том, что я ставлю фирму в неудобное положение, и теперь им нужно искать человека, который будет разбираться в том что я наговнокодил.
Так что здесь критерий «как писал раньше» нужно рассматривать неразрывно критерием «в каких условиях писал».
lisitsynalex
28.10.2016 12:50«Опасайтесь слова «архитектура» от программистов»
Ой, а объясните почему? Пожалуйста.VioletGiraffe
28.10.2016 13:49+2Я так понял, что не наше это холопское дело — об архитектуре думать. О ней подумают отдельные люди за отдельные деньги, а нам потом это кодить и отлаживать :)
KlimovDm
28.10.2016 14:00Потому что Руслан Фазлыев, СЕО Ecwid, сказал это либо не подумав, либо он сильно не в теме. imho.
vadimr
28.10.2016 15:13+1Я не понял, чем провинилась конструкция else. Если уж пытаться судить в таких примитивно-синтаксических понятиях, то большой процент else скорее может быть признаком некой полезной обстоятельности мышления.
ittakir
>«бульдозерный код», который создает впечатление рефакторинга посредством разбития кусков кода на процедуры, которые, правда, затем невозможно использовать где-либо еще.
Не согласен. Вот есть у нас функция на 10 экранов. Логично было бы ее разбить на куски, которые делают что-то похожее. Пусть даже эти функции больше никто нигде не вызовет, но код в целом станет более понятный.
Вопросы про то, можно ли использовать else, return true и т.п. напомнили мне вопросы на quora.com, там тоже частенько спрашивают такую чушь. Ребята, пишите так, как вам удобно, главное чтобы ваши коллеги поняли код. Не нужно загонять себя в рамки только потому что вы где-то прочитали, что «хорошие программисты не используют else».
M-A-XG
Нужно код упрощать, а не искусственно плодить функции (уменьшать экраны). Купите себе больший монитор.
Как их потом называть такие функции?
doSmth[1-N]()? doOneandTwo()? authAndPrind()? :)
Передавать в них 100500 параметров или использовать ООП, а потом ломать голову, где же еще используется член класса?
ittakir
Дело не в размере монитора, а в количестве информации, которую может усвоить человек. Гораздо проще разобраться в функции на несколько строк, а не на несколько сотен.
alexander-shustanov
Есть такое понятие, как Кошелек Миллера. Человек может одновременно держать в голове от 5 до 9 объектов. Иногда приходится писать длинные функции, и лучше разбить ее на некоторые логические куски, которые будут «разгружать» внимание.
M-A-XG
Меня, видимо, заминусовали олени.
Я не говорою, что нужны длинные функции, я говорю, что их упрощать нужно с умом, а не поверхностно.
Поверхностное «упрощение» только усложнит все.
Temirkhan
Не усложнит. Если огромный кусок лапши под(к примеру) методом
specificUserRegistration(..)
разбить на составляющие(опять же, к примеру)
registerUserViaSocialNetwork(...);
attachManagerInSpecificway(..);
sendNotificationsTouserAfterRegistration(..);
sendNotificationsToManagerAfteRegistration(..);
получится более понятным, что происходит в целом и в частностях.
Вот тут уже можно начинать следующую часть рефакторинга, которая, как Вы говорите, «упрощает с умом».