О качествах программиста много всего написано, в том числе и на dev.by.
Иногда ловлю себя на мысли, что разговоры на эту тему получаются какими-то абстрактными. Ну, прочитает программист, что он должен быть увлечённым. И что? Увлечённость усилится? Вряд ли. Она такая штука, что искусственно не вызывается. Вот будет интересное что-то — и она сама появится, без чтения каких-либо статей. Думаете, раз не увлечён в настоящий момент, значит программирование — не его дело? А может перед ним не ставят задач, которые способны увлечь, и мало команд, которые способны?
Прочитает о важности чувства юмора. Кто-то после этого задаст себе вопрос: они там камеди клаб набирают или сотрудников. Другой — пошутит на эту тему. Важна общительность и умение работать в команде? Ну да, а что тут изменишь? Люди очень трудно меняют свои привычки. Ну, не станет интраверт экстравертом. И можно сколько угодно говорить о важности общения, обмена мнениями, все будут кивать и говорить «та-а-а, насяльника». А как дойдёт до дела — те, кто не хочет обмениваться мнениями, так и будут скромно сидеть в сторонке и слушать, что скажут остальные. Возможно, ситуацию можно менять разными тренингами, но что-то мне кажется, что мы до этого дойдём не скоро. И я, кстати, не уверен, что это плохо. :)
Читать дальше
Отдельного повествования заслуживают бесконечные разговоры в интернете о самосовершенствовании. Только признайся, что чего-то не знаешь — страх что начнётся. Понятно, что надо продолжать учиться. Но может это надо делать без излишнего фанатизма? Давай, давай, изучай новинку… Как, ты ещё не применяешь? Да ты что, это же самый тренд! Только вот всегда ли изучение всех новинок является в самом деле самосовершенствованием? Не подменяем ли мы работу над собой метанием из крайности в крайность и коллекционированием аббревиатур в резюме? Что если однажды сын спросит: «Папа, а где ты был, когда ты мне был так нужен?». А после этого смотришь назад и понимаешь, что половина всего, что казалось таким важным для работы, до сегодняшнего дня не дожило…
Раньше товары делали более долговечными. Но у рынка своя логика: если товар слишком долго служит, то в следующий раз покупатель придёт в магазин не скоро. Непорядок… (см. «Планируемое устаревание.») Не являются ли программисты такими же жертвами маркетинга, как и все остальные люди?
Часто доводилось видеть строчки, которые программисты снисходительно пишут другим пользователям популярных сайтов: программисту надо учиться всю жизнь (и дальше перечень того, как сложно и долго они учатся). Наивно думать, что актуализировать свои знания — удел только лишь программистов. Учителя (новые учебники, новые методики и т. п.), врачи (от них между прочим жизни зависят), юристы и экономисты (наши законодатели не перестают их радовать новинками своей мысли, а экономистов ещё и программисты радуют), строители (новые технологии и материалы появляются), да даже уборщице бывает надо отбросить тряпку и разобраться с техническими приспособлениями для уборки.
Возможно, список якобы имеющихся знаний служит для программистов чем-то вроде линейки. Им можно меряться. Ведь фразу «я просто пишу хороший код и делаю мало ошибок» нигде не выскажешь. А если выскажешь, то скорее всего вызовешь реакцию «ну-ка, ну-ка, спорим, что твой код на самом деле не хороший, я бы строчки с 2490 по 2500 переписал по-другому». А список знаний можно размещать в резюме и профиле на линкедин, мойкруг или ещё каких сетях. Причём, иногда кажется, что единственным назначением этих сетей является — «чтобы HR-ам было чем заняться, добавляя себе в контакт листы новых людей». Вроде видно, у кого чего больше. А толку? Все мы знаем, какие знания и умения часто реально стоят за словом. Да и некоторые оригиналы в целях увеличения длины списка могут сразу вставить и AJAX, и XMLHttpRequest, и «Asynchronous Javascript and XML».
Я не клоню к тому, что не надо ничего учить. Надо, обязательно надо. Только я бы посоветовал помнить про поговорку «заставь дурня молиться — он лоб расшибёт».
Но это было всего лишь предисловие. А теперь самое главное.
Все качества, которые обычно называют, имеют свою значимость. Но как их «улучшить» у какого-то конкретного человека? А фиг их знает. Давайте, немного поговорим о том, что изменить в своей работе по силам каждому. Поговорим о внимании к мелочам и необходимости не лениться делать простые вещи. Итак, вот 4 небольших пунктика:
1. Внимательно читать спецификации. Не лениться просить уточнения.
2. Не лениться проверять, как работает каждая ветка ветвления.
3. Быть внимательным и аккуратным. Не забывать проверять программу на работу с некорректными и/или неожиданными данными, а также на деление на ноль.
4. Не лениться писать комментарии.
«А ты неплохо замаскировался, Капитан Очевидность» — скажете вы. И будете правы. Отчасти.
Цветочный магазин. Девушка-продавец болтает с подругой. Заходит мужчина и покупает 25 роз.
— Как он, наверное, заботится о своей женщине, — вздыхает подружка, когда клиент ушёл.
На что продавец отвечает:
— Ты знаешь, у меня есть один постоянный клиент. Он год за годом каждый месяц независимо от погоды в день зарплаты приходит сюда и покупает по розе жене и дочери. Легко быть заботливым один раз. Но сложно быть таким постоянно…
С простыми вещами — та же история. Легко удариться в поиски великих свершений и при этом не замечать, что такие очевидные вещи совсем не получаются.
Итак, спецификации.
Их надо читать внимательно. И немного задуматься, можно ли какие-то важные вещи понять двояко. Если можно — не стесняться уточнять. Нередко бывает, что задаёшь вопрос, а ответ приходит такой, что становится ещё более непонятно (языковой барьер, невнимательность отвечавшего и т. д.) Этого можно избежать, если задавать вопросы уже с вариантами ответов. Например:
Солнце должно быть:
а) круглое и жёлтое
б) круглое и красное
в) синее и квадратное
При хорошо заданном вопросе во многих случаях человеку надо лишь прислать вам одну букву а), б) или в) в качестве ответа.
Однако в погоне за точностью спецификации надо не переборщить и не тратить время на несущественные детали, которые будут перед носом работодателя и которые потом легко при необходимости можно изменить. Всё-таки, иногда лучше и проще один раз увидеть, чем сто раз услышать.
Самый главный принцип для меня — спецификация должна быть понятна и логична. Если непонятно, кому такое вообще может понадобиться, — это звоночек, что кто-то что-то не так объяснил, а я потом не так понял.
Не лениться проверять, как работает каждая ветка ветвления.
Считаю это важным. Вот, даже отдельным пунктиком выделил.
Кажется, что ветка будет работать правильно, т. к. код простой? Кажется маловероятной? Кажется невозможной? А вот «Адидас» говорит, что невозможное — возможно… Надо обязательно всё проверять. Мнимая экономия времени, которую получаем, забив на такие тесты, потом превращается в злых тестеров (им раз за разом говорят, что всё работает, а они делают пару шагов — и натыкаются на очередную ошибку), потерянным временем менеджеров и заказчиков, недовольными пользователями, а потом ещё и часами работы другого программиста, который скажет много замечательных слов, пока найдёт ошибку, которой могло не быть, если бы кто-то не поленился потратить 15 минут своего «драгоценного» времени.
Даже крайне маловероятные и «невозможные» вещи иногда случаются. Можно быть уверенным — через годик-другой какой-нибудь пользователь наткнётся на проблему.
Заодно, пару слов в этом пункте добавлю про привычки ловить исключительные ситуации и игнорировать их. Томас Кайт, в частности, очень эмоционально высказывается о таких привычках.
BEGIN -- много важного кода doVeryImportantThings(); EXCEPTION WHEN OTHERS THEN -- ловим исключение и просто игнорируем его NULL; END;
Кайт писал, что если мы так делаем, то можем просто удалить весь этот код, потому что для нас не имеет значения, выполнится ли он корректно.
Возможно, не надо быть столь категоричным, но задуматься над этим — стоит.
Внимательность, аккуратность, некорректные данные, деление на ноль.
Спешка хороша при ловле блох и при поносе. Когда решаешь в спешке пренебречь аккуратностью — стоит задуматься над тем, к какому из двух вариантов можно было бы отнести такое программирование. Я, конечно же, понимаю, что иногда без спешки никак. Ничего не поделаешь, издержки профессии. От водителя никто не будет требовать за час проехать тысячу километров, а программисту аналогичные требования частенько выставлять пытаются. Но иногда спешка и невнимательность ничем не оправданы. Ну, сэкономишь время в девяти случаях. Но программист же не машина. Обязательно будет десятый случай, который всю экономию перечеркнёт. Время программиста стоит дорого? Так время людей, которые будут разбираться с проблемой, часто стоит не дешевле.
Если по работе надо внимательно проверить/заполнить/запрограммировать сотню полей — надо просто сделать это. Нет ничего хорошего в том, что потом кому-то придётся делать это за невнимательного программиста. Усилия, которые потратит человек, часто сопоставимы с теми, как если бы он делал задание сразу с нуля.
Проверки на граничные значения, некорректные данные, деление на ноль… Вот бы в универах абсолютно в каждой лабораторной уделяли этому пристальное внимание. Может, тогда довели бы привычку всё это проверять до автоматизма.
Немного из личного опыта:
— Я тут на проект устроилась, сижу тестирую. Вроде всё в порядке. Что бы такого проверить у них в веб-приложении?
— Кавычки, спецсимволы всякие.
…
— Ой, им столько всего фиксить надо, оказывается :)
— Есть большой отчёт с кучей вычислений. Всё проверила, всё работает. Что бы ещё у них в коде посмотреть?
— Деление на ноль.
…
— Ты злобное создание: D
Хоть нам порой и кажется, что пользователи придуманы для того, чтобы мы могли наслаждаться нашей работой, но программа всё-таки разрабатывается для пользователя. И тот не видит всю красоту кода, который написал программист. Не видит, сколько умных решений получилось, сколько сил потрачено. Пользователь видит только то, что ему надо ввести данные, а программа от этих данных ломается. Потом программист обижается «столько всего сделано, а говорят, что ничего не работает». Хотя, обижаться тут не на что. Если автобус не едет и мы опаздываем, то нам ведь тоже всё равно, что в этот автобус вложен труд сотен людей.
Комментарии.
В Интернете только и разговоров, что о комментариях. Как они бесконечно прекрасны… О комментариях, которые они видели… О том, как один разработчик в одной программе увидел их и удивился. И, прочтя, понял, как понимание кода программы наполнило его так быстро, как никогда до сих пор не наполняло. А ты?.. Что ты скажешь? Ведь ты ни разу не писал комментариев… (вольная переделка одного монолога)
Не о чём тут особо говорить. Просто кэп напоминает.
Комментировать хотя бы ключевые моменты. Если есть спецификация — не полениться скопировать её кусок и вставить в комментарий. Вот интересно, почему люди не копируют? Может не умеют? Ведь в резюме никто навыки copy-paste не указывает. :)
Добавлю, что комментарии иногда по прошествии пары лет помогают не только вспомнить код, но и избежать ситуаций:
— Какой дурак написал этот код?
— Ты. :)
Итоги:
Немного поболтали с вами на тему знаний и умений программиста и, надеюсь, неплохо провели время. Не претендую на истину в последней инстанции. Если какие-то вещи вызовут споры — буду только рад. Основная мысль: лишний раз обратить внимание на некоторые простые вещи, о которых, как мне кажется, многие незаслуженно забывают.
Думаю, без этих вот простых вещей, взятых на постоянное вооружение, ни один список знаний и качеств не сделает программиста — хорошим программистом. Ведь что толку в знающем много, если он ничего не может толком довести до конца и постоянно косячит?
Спасибо за внимание. Комментарии к статье — приветствуются. В конце концов, сравнение позиций читателей — это интересно.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.