Много раз я читал о технических собеседованиях в крупнейшие компании и был очень рад, что не ищу работу программиста. Способность написать оригинальные реализации кучи или дерева. Головоломки с различными ограничениями. Задачи, на обсчёт которых потребуется десять миллиардов лет если вы не сможете правильно проанализировать и перефразировать требования. Моя первая реакция – как вообще им удаётся хоть кого-нибудь нанять?
На самом деле большая часть работы программиста не требует такого алгоритмического мастерства.
Когда вы пишете код самый важный навык для вас – как удержать всё это нагромождение функций от разрушения под тяжестью собственной сложности. Я работал над крупными телекоммуникационными системами, консольными играми, блогами, несколькими персональными утилитами. Очень-очень редко мне приходилось работать с хитрыми структурами данных или алгоритмами. Чаще требуется отслеживать состояния, сортировать структуры, внимательно разбираться как разные части системы взаимодействуют друг с другом. Написание кода является лишь частью задачи. После него идут рефакторинг, упрощение, исключение избыточных манипуляций.
Именно по этой причине многие становятся программистами «случайно». Вряд ли вы часто встречаете людей, которые стали нейрохирургами между делом, просто занимаясь этим в своё свободное время. Это требует очень интенсивного и специфического обучения. Но научиться писать код легко и многие это делают. Когда я начинал программировать на 8-битном домашнем компьютере я даже не знал что такое алгоритм. Я не представлял как сортировать данные и мне это не требовалось для тех простеньких игрушек, которые я тогда писал. Мне достаточно было знать про счётчики, таймеры и управление состоянием. Для этого не нужна «гениальность», достаточно здравого смысла.
Несколько лет назад я написал утилиту, которая преобразует изображения в прямоугольные текстуры. Программа небольшая – около 1500 строк кода на Erlang и C. Упаковкой изображений в прямоугольник занимается совсем маленький фрагмент кода длиной около 20 строк. Написать его было не сложно, но вряд ли бы я справился с этим на собеседовании. Остальная часть кода занимается чтением файлов, выводом результатов, обработкой параметров изображений и передачей данных между разными частями приложения. Именно этот код я чаще всего модифицирую когда нужно добавить что-то новое, улучшить обработку ошибок или улучшить удобство использования.
И именно так выглядит большая часть разработки программного обеспечения.
Комментарии (62)
maaGames
23.07.2015 20:45+23Есть «профессиональные олимпиадники», которые с лёгкостью проходят неадекватные собеседовательные задания, а потом говнокодят до тех пор, пока их не уволят или не повысят. А есть программисты, которые пишут рабочий не-всегда-говнокод, у которых могут быть проблемы с заданиями на собеседованиях, которые не имеют ничего общего с реальными программистскими задачами…
А вообще, я не сильно понял, о чём статья.
Mirn
23.07.2015 22:00+4а так же существуют инженеры, знающие и умеющие программировать, с реальным опытом работы лет в десять, с знаниями хитрых алгоритмов, паттернов и всем прочим.
Но у них настолько тяжёлый характер или делают очевидные вещи настолько «не так», как все привыкли и ожидают. Что от них шарахаются вообще все. И в шоке от них не только коллеги, а даже пользователи их софта.
SirEdvin
23.07.2015 22:03+4О том, что в современном программировании алгоритмы не самое важное и так сильно заострять внимание не имеет смысла.
manifold
24.07.2015 09:19С мнением автора в целом согласен. Зачастую участие «профессиональных олимпиадников» в проекте оборачивается горем команде. У нас используется понятие «одноразовый код» — это код, который сопровождать очень сложно, его проще переписать, чем чем потом сопровождать и отлаживать. С таким кодом я встречался в различных прикладных математических библиотеках. Целью авторов этих приложений было оптимизировать все возможное, хотя реальный эффект был пренебрежимо мал. Обычно такие разработчики не задумываются о том, что алгоритм, помимо быстроты, должен хорошо читаться и анализироваться.
pr0fedt
24.07.2015 10:08+7Может быть тут недостаток в менеджменте и проектировании? Олимпиадники куда лучше обучаемы, и при правильном наставничестве не имеют потолка развития, в отличии от людей, говорящих себе — а зачем мне знать как это устроено, все ж уже реализовано. Не свидетельствует ли это об узком мировоззрении, неготовности к саморазвитию?
Может быть отставите в сторонку «Совершенный Код» и почитаете «Алгоритмы — Построение и Анализ» Кормана? Поверьте, научиться написать сопровождаемый код — это дело лишь опыта.
Люди, считающие, что алгоритмы неважны — как люди, севшие за руль, не зная устройства машины.
Да, у «олимпиадников» бывает излишняя самоуверенность, да, с ними бывает сложно, но хороший менеджер сможет спустить такого человека на землю, и получит ценного и надежного сотрудника.
Mendel
24.07.2015 10:44Конечно олимпиадник юниор это прекрасно. Я сам такой был в 16 лет… весь такой важный, я ведь уже 5 лет пишу на ассемблере…
Но вот олимпиадник-ПМ или просто мидл/сеньор, это катастрофа.
Пару месяцев назад видел одного мальчика, которого взяли в большую компанию студентом, потому что он прошел собеседование. Ему очень понравились задачки которые ему задавали. Он потом их всем задавал. И удивлялся почему из опытных программистов половина не может их решить лучше него.
Он так и не понял, что задачки где человек пытается подменить собою оптимизатор компилятора это зло. Особенно для юниора работающего в CRUD-проектах на фронтэнде. Не понял он и моего рассказа о том, как долго я заставлял себя прекратить оптимизировать код до тестов.
Мальчик не олимпиадник. И фирма вроде приличная. Надеюсь что эта ересь была только на собесах, а дальше из него таки сделают человека. Потому что посредственный олимпиадник воспитанный олимпиадниками будет потерян для программирования. А так, у него есть шанс дорости до твердого мидла, оставив узкие места профессионалам.Petrovich1999
24.07.2015 11:17+2То есть из первого абзаца можно сделать вывод, что Вы являетесь катастрофой для своей команды, так?
Mendel
25.07.2015 12:47Был бы, если бы меня не макнули носом в то, что хаки на особенностях железа, и хитрые трюки по оптимизации это менее важно чем грамотная структура и чистый читаемый код.
Я против того, чтобы олимпиадники принимали людей на работу по умению решать олимпиадные задачки. Как вспомогательный инструмент это да, но лишь косвенный.
Kroid
24.07.2015 12:46+2Люди, считающие, что алгоритмы неважны — как люди, севшие за руль, не зная устройства машины.
Вам шашечки или ехать? Вся история технического прогресса — непрерывные попытки стрятать детали реализации под всё более высокоуровневым интерфейсом. Чтобы водить машину, не нужно знать её внутреннего устройства, нужно знать её поведение. Так же как программисту не нужно знать физическую конструкцию «вентелей» в процессоре, чтобы писать код на javascript'e, к примеру.
Или под «водить машину» вы подразумеваете умение разобрать её на составляющие и собрать обратно?foxin
24.07.2015 19:40Конечно не нужно. Если надо проехать по прямой в идеальных условиях по идеальной дороге. А внезапное препятствие на дороге — теория по его объезду — и бац, уже надо понимать как устроено рулевое управление, система торможения, как ведет себя движущееся тело согласно законам физики. Т.е. в целом-то знание не нужно (если надо написать лабораторку в универ, где создать окно и две кнопочки), но как только возникает нетривиальная задача (разпознавание номеров в движущемся потоке машин), то сразу нужно понимать подкапотное устройство.
Kroid
24.07.2015 22:05Я пытался донести немного другое. Воспользуюсь вашим же примером: чтобы объехать камень на дороге, нужно знать, как поворачивать, но не нужно знать схему соединения руля с колесами. С другой стороны, если ты уже знаешь внутреннее устройство машины, в которой едешь, это не сделает тебя более плохим водителем. С третьей стороны — если ты потратил полжизни на изучение внутренностей механизмов, но никогда не ремонтируешь самостоятельно и ездишь только до работы и обратно — может, стоило потратить время на изучение чего-то другого?
Mendel
25.07.2015 12:48Старая шутка о том, как советские водители возмущались, что на западных машинах нет лампочки под капотом?
VladX
24.07.2015 15:18+1В точку. Я знаю огромное количество хороших специалистов, в прошлом олимпиадников, и это точно не следствие отбора на собеседованиях. А вот программистов 200k+, разрабатывающих сложные системы, и не знающих основ алгоритмов не знаю ни одного.
Mendel
24.07.2015 10:11Ну строго говоря библиотекам можно.
Если ты не лезешь под капот, то даже 0.01% может вылиться в десятки серверов сэкономленных.
Собственно для этого даже инлайнят ассемблерные вставки в высокоуровневые языки (по крайней мере раньше инлайнили, сам давно до этого не доходил).
Если есть качественный внешний интерфейс, и поддержкой библиотеки занимается только ее разраб, то почему бы и нет?
Инкапусуляция наше всё)
Но да, это редкие частные случаи…
pushtaev
24.07.2015 14:40А вообще, я не сильно понял, о чём статья.
Примерно об этом:
Controlling complexity is the essence of computer programming. — Brian Kernighan
grafmishurov
23.07.2015 22:19+1Странное противопоставление
и перевод названия заметки, если он подразумевает общий случай. На этапе проектирования приоритетны Organizational Skill, на этапе оптимизации потребления ресуров (память, время вычислений) приоритетно Algorithmic Wizardry.
mifki
24.07.2015 13:51+1Я допускаю, что кому-то приходится оптимизировать именно сортировку и всякие прочие книжные алгоритмы, но это, по-моему, довольно редкий случай в общем количестве разрабатываемого софта и решаемых проблем. Даже на этапе оптимизации распараллеливать приходилось, оптимизировать блокировки, чтобы потоки друг другу не мешали, приходилось, реализовывать вычисления на ассемблере для сопроцессора приходилось (и обнаружить, что быстрее вычислять и хранить меньше данных, чем считывать больше уже подготовленных даже из памяти, как сначала хотел), да много чего приходилось, но вот лично у меня никогда книжные алгоритмы и структуры данных не являлись узким местом. То есть, Algorithmic Wizardry хоть и требуется, но имеет мало отношения к тому, о чем любят спрашивать на собеседовании.
grafmishurov
24.07.2015 14:22Параллельные алгоритмы имеют математическую модель (вводится в нотацию переменная кол-ва процессоров), свои паттерны и рассматриваются вопросы влияния времени синхронизации нитей на время вычисления. Но фактически формальные алгоритмы к которым можно с уверенностью применить математическую модель актуальны для SIMD и GPU, где можно точно распределить на вычислительные единицы какие-то операции и учесть время трансфера данных из хоста в память GPU, на CPU все сложнее, время на нити (легковесные процессы) scheduler операционной системы раздает и решает.
А собеседования разные бывают, все это частные случаи, например на одном я общался в светском формате с человеком за чашечкой чая про ассемблер и теорию конечных автоматов, на другом мы только обсудили объем работ и цену за час работы.
corvette
23.07.2015 23:32+5Может и не нужно знать алгоритмы, однако, это серьезное подспорье в работе. И я не видел 200k+ программистов не знающих алгоритмов. Знающих видел.
MetaDone
24.07.2015 08:07Программа небольшая – около 1500 строк кода на Erlang и C. Упаковкой изображений в прямоугольник занимается совсем маленький фрагмент кода длиной около 20 строк
По моему все время так — примерно 10% кода — это реальный функционал, а остальные 90% — обертки для красивого вывода данныхMendel
24.07.2015 08:26+3Меня тут на хабре в свое время заминусовали страшно, за то, что я на собеседовании прошу нарисовать блок-схему решения квадратного уравнения, и даже разрешаю пользоваться интернетом… Никаких проблем с алгоритмом Никаких проблем со знанием языка. 90% разработчиков, даже самых крутых отсеивается на том, что не понимают, что 90% работы это обертка. Нештатные случаи, работа с ошибками, определение рамок применимости, уточнение ТЗ у заказчика и т.п…
Petrovich1999
24.07.2015 11:14+4Если задание на собеседовании звучит как
блок-схему решения квадратного уравнения
то при чем здесь
Нештатные случаи, работа с ошибками, определение рамок применимости, уточнение ТЗ у заказчика и т.п…
RomanPyr
24.07.2015 12:25+1Отрицательный дискриминант? :)
Alexeyslav
27.07.2015 08:28А будто бы отрицательный дискриминант является веской причиной не вычислять корни уравнения.
foxin
24.07.2015 12:34Квадратное уравнение может не иметь корней, может иметь два одинаковых корня (показывать один или оба?), множители при x^2 и свободном члене могут быть равными нулю (оптимизация нарисовалась). По-моему, очень красивый пример. С учетом, что можно юзать инет и если не помнить тот же дискриминант — можно посмотреть в вики, в том числе все частные случаи.
jrip
24.07.2015 12:45> По-моему, очень красивый пример.
По-моему это задача для совсем совсем джуниора. Неясно что тут проверяется, знает ли человек что такое условные переходы?
Этакая задача на уровне 7 класса средней школы.
Mrrl
24.07.2015 13:31+6Проверяется, может ли человек увидеть, разделить и обработать все шесть различных ситуаций. Понимает ли он разницу между x^2+1=0 и 1=0. Можно посмотреть, как «блок-схема» не справится с уравнением x^2-1e20*x+1=0, и сможет ли человек исправить её, чтобы меньший корень показывался с нормальной точностью, а не обращался в нуль. А потом — предложить x^2-1e200*x+1=0… А после того, как он справится и с таким уравнением, сказать «Вам у нас будет неинтересно» и не взять.
jrip
24.07.2015 14:57Однако это уже совсем другая задача. Все-таки оптимизация, большие числа и тд и тп должны быть обязательно указаны в условях задачи, т.к. требуют дополнительных усилий и времени. И если без их указания человек пытается это делать, для него это совсем не плюс.
Mrrl
24.07.2015 19:39Я и не говорю, что он сразу должен написать решение, которое будет работать во всех случаях. Это будет последовательное усложнение задачи для 7 класса.
Mendel
25.07.2015 13:03Усложнением оно становится после вопросов с точностью, потому что это ограничение реализации, а не сферической блоксхемы. Даже комплексные корни это усложнение. Но вывести сообщение «действительных корней нет», равно как и отсутствие корней разработчик обязан. Сегодня он не может квадратное уравнение решить, потому что он «сильно умный для этого», а завтра у него приложение на платежном терминале в консоль вывалится потому что клиент введет неожиданные данные, и вызовет деление на ноль…
Mendel
25.07.2015 13:08Да и потом. Если собеседующий тебя на мидла и уже проверивший твое знание технологий задает тебе задачку для седьмого класса, то ты ДОЛЖЕН предположить, что ты не самый умный на этой планете, и может быть он не идиот, и задача таки имеет смысл. А если ты это предположишь, то когда начнешь рисовать, то сразу поймешь, что некоторые вещи не стоит игнорировать.
Mrrl
25.07.2015 13:28И здесь возникнет классическая ситуация из сложных тестов на IQ — «угадай, что имел в виду автор». И непонятно, куда идти. Можно попытаться угадать одну ловушку. Можно предусмотреть штук пять вариантов ситуаций, в которых такая задача окажется не совсем тривиальной, Можно задавать уточняющие вопросы для определённости. А в конце вдруг окажется, что собеседующему было просто интересно, как на блок-схеме будет отображаться Exception :)
Mendel
26.07.2015 09:09а язык человеку на что? Нет, я понимаю что там куча вкусовых окончаний, но всё-же)
Я ничуть не страшнее чем среднестатистический директор, говорящий «сделайте мне сайт, и так чтобы клёво».
Красные линии я не прошу)
Если человек просит нарисовать блок-схему, то ты ее просто рисуешь. Если у тебя возникает в голове вопрос, нужно ли предусмотреть все исключительные случаи, то это естественно должно наложиться на вопрос о том «а нафига собственно он мне сказал рисовать?». Вариант о том, чтобы проверить сможешь ли ты нарисовать логику уже описанного алгоритма из двух действий — сомнителен. Так что остается или спросить у собеседующего, мол вы хотите писать всё? Это будет немного долго, или и так сойдет?
Либо просто тупо рисовать всё… Вариант — не нарисовать и не спросить это большой минус. Меньше чем «даже не подумать об исключительных случаях», но всё равно большой.
Черт, да первые три картинки в гугле даже на «а=0» не проверяют. Тупо делят… Ну как так можно?)
phprus
26.07.2015 13:34+1> Черт, да первые три картинки в гугле даже на «а=0» не проверяют. Тупо делят… Ну как так можно?)
Мне кажется это и есть классическое «угадай, что имел в виду автор».
Если а==0, то уравнение перестает быть квадратным по формальному определению (см. en.wikipedia.org/wiki/Quadratic_equation), а следовательно либо Вы до конца не понимаете того, что спрашиваете, либо Вам на самом деле нужно, чтобы блок-схема решала уравнения первой и второй степеней и именно этот факт требуется угадать человеку, а не нарисовать блок-схему решения квадратного уравнения.
Либо, Вам дополнительно нужно, чтобы соискатель догадался и уточнил реально ли заданное Вами формальное ограничение на входные данные будет выполняться в тестовом наборе или нужно дополнительно проверять его выполнение, а это уже очень плохо говорит о процессе разработки в компании, так как появляются основания предполагать, что ТЗ там никогда не было или, что они никогда не исполнялись…Kroid
26.07.2015 17:05Ваш комментарий напомнил мне статью Что бы сделал мистер Фейнман?
phprus
26.07.2015 17:11Квадратное уравнение — это не абстрактное понятие допускающее многозначность толкования, а вполне определенный вид уравнений, так что необходимость уточнять факты, в данном случае противоречащие постановке задачи — это скорее к позиции господина Mendel.
Mendel
26.07.2015 19:55Моя позиция в том, что программа написанная программистом не должна падать от неожиданного ввода пользователя. И моя позиция в том, что в мире всегда есть умолчания, и если у тебя есть сомнения в уместности умолчаний, то ты должен об этом сказать вслух.
А еще моя позиция заключается в том, что если я должен говорить разработчику о том, что «мне бы хотелось, чтобы твоя программа работала без ошибок, и не содержала глюков», а иначе он посчитает, что это не особо то и важно, то мне такой разработчик не нужен. Ну вот такой вот я закомплексованный и ограниченный тип. Пусть идет в более продвинутые и гибкие команды :)
Mendel
26.07.2015 19:56Я бы не взял такого человека программистом. Аналитиком да, но не программистом.
Mendel
26.07.2015 19:50Человек который не проверяет входные данные, не узнает о том, являются ли данные отфильтрованными и т.п., и при этом на самом видном месте его решения находится деление на ноль, это не очень полноценный программист. Мягко так скажем.
Когда ты пишешь код, ты всегда его проверяешь. Если не вживую, то хоть немного тестов гоняешь виртуально в голове. Это не копипаст, это программирование. Я не требую комплексные корни. Написал «действительных нет» — отлично. Написал «корней нет» — тоже прекрасно, я не буду придираться что упустил слово «действительных». Нет, я это скажу вслух, но скорее чтобы посмотреть на его реакцию. Чисто в рамках блока психологии, не профессионализма.
Я даже спокойно отношусь к ситуации когда человек изначально нарисовал что-то, из того что предлагает гугл, но после уточняющего вопроса «вы уверенны что это всё?» исправился. Однако падение от того, что кто-то понадеялся на «правильность» пользователя — говнокод.
ПС: Мне это напомнило как один интернет-провайдер на своем сайте ограничивал регистрацию некоторых тарифов по регионам — условие стояло в жаваскрипте. Три минуты манипуляции с браузером, и у тебя уже акционный тариф… Они еще похожие ляпы делали с пополнениями. Без проверок подписей и т.п…phprus
26.07.2015 20:15Хорошо. Напишите, пожалуйста, корректную и работающую проверку на равенство действительного числа нулю.
А после того, как у Вас не получится этого сделать, подумайте, где должна проходить проверка входных данных, там, где нет явного контракта на входные данные или там, где область допустимых входных данных однозначна определена в ТЗ — постановке задачи.
Формулировкой про квадратное уравнение Вы задали ограничение на множество значений входных данных и если в решении Вы хотите проверки этого контракта, то надо явно говорить о ненадежности источника входных данных иначе мы приходим к проблеме угадывания истинных намерений.
P.S. Кстати, многие математические библиотеки не проверяют корректность входных данных в каждом методе, так как такие проверки серьезно замедлят их работу.Mendel
26.07.2015 21:50Хорошо. Напишите, пожалуйста, корректную и работающую проверку на равенство действительного числа нулю.
Корректная и работающая проверка будет выглядеть как простое сравнение с нулем.
Всё остальное домыслы, поскольку мы говорим именно о блок-схеме.
И да, именно проблемы с точностями и прочие тонкости реализации являются причиной использования именно блок-схем. Это упрощение.
Это уже на этапе конкретной реализации появляются +0, -0, и куча других особенностей.
Большинство проваливших этот тест таки не способны вот так вот отмазываться как вы.
Но специально для вас, я введу на будущее в условие задачи подсказку, о том, что программа написанная по искомой блок-схеме должна работать без ошибок.phprus
26.07.2015 22:25> Большинство проваливших этот тест таки не способны вот так вот отмазываться как вы.
А я не отмазываюсь. Я сталкивался с тем, какой уровень проверки данных бывает во внутреннем коде, который непосредственно считает математику в различных приложениях и библиотеках. Обычно, предполагается, что в этот код передаются корректные данные, чтобы на выходе получился корректный результат, или, если программист передал фигню, то код имеет право выдать аналогичный результат. А проверки должны быть снаружи, чтобы не вносить лишние тормоза в итак ресурсоемкие операции.
> Но специально для вас, я введу на будущее в условие задачи подсказку, о том, что программа написанная по искомой блок-схеме должна работать без ошибок.
Кажется, Вы так и не поняли, почему Ваше дополнение ничего не поменяет. Вы все так же задаете задачу с формальным ограничением на входные параметры и ожидаете, что ему будут не доверять.
А вот подсказка о том, что входные данные могут быть получены из ненадежного источника была бы вполне соответствующей Вашему истинному желанию.Mendel
27.07.2015 10:23В начале блок-схемы идет блок ввода данных. В подсказке речь идет о «программе» а не «вспомогательной библиотеке». Если человек подумал о небезопасных данных, но решил что фильтрацию за него сделает кто-то другой, то он это скажет вслух. Если он на нервах забыл, то он поймет ошибку после вопроса. Если человек не спросил и не сделал проверку, то ему нужно разжевывать каждый чих. Сферические разрабы мне не нужны.
VladX
24.07.2015 15:40Понимает ли он разницу между x^2+1=0 и 1=0
Вы про обработку старшего коэффициента или про решение над комплексным полем?
«блок-схема» не справится с уравнением x^2-1e20*x+1=0
А как его решать? Интервальной арифметикой? Вообще, казалось бы, достаточно только считать в числах удвоенной точности, если бы не последний коэффициент.Mrrl
24.07.2015 19:37+11. Я про две разные ситуации «нет корней». Не знаю точно, какой ответ может быть, но услышать его будет полезно.
2. Сначала находите бОльший корень — в нем относительная ошибка будет маленькой, потом меньший считаете как c/x.
Alexeyslav
27.07.2015 08:30Квадратное уравнение всегда имеет корни, просто при D < 0 они находятся в плоскости комплексных чисел.
corvette
24.07.2015 12:44В вашей фирме решение квадратного уравнения это выдуманная задача или реальная?
Mendel
25.07.2015 13:14Это «дополнительный вопрос», когда собеседование не позволило однозначно понять «здравый смысл» соискателя.
Посмотрите что вам выдаст поиск по картинкам на запрос «блок-схема решения квадратного уравнения». Первые пять вариантов это работа кодера а не программиста. Если человек нарисует вот такое вот, и после наводящих вопросов типа «Вы уверенны? Хорошо подумайте...» не изменит своего решения, то у меня он получит максимум функции верстальщика.
jrip
24.07.2015 12:42+3На нормальных собеседованиях обычно не заставляют за минуту придумать сложный алгоритм и написать правильно работающую реализацию.
Обычно смотрят на ход мыслей, на то что человек вообще способен думать.
Т.е. в большинстве случаев обычно достаточно «ну наверное я бы начал думать вон в ту сторону и попробовал бы вот так»
А вот люди которые не знают даже примерно, как работают базовые вещи, ну например, сортировка — это как бы не программисты.corvette
24.07.2015 12:46Вы не правы. Эти люди, именно, что «как бы» программисты.
jrip
24.07.2015 12:47+2Вообщем изза всяких таких как бы людей я решил называться инженером :)
Colwin
11.08.2015 10:22:-) Знаете, называться инженером — значит взять на себя ответственность за работу системы.
В этом случае любая ошибка в ее работе указывает на некомпетентность. И никакие сроки в данном случае не могут являться оправданием. Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений. IMHO, реальных инженеров в IT очень мало.jrip
11.08.2015 11:04>Знаете, называться инженером — значит взять на себя ответственность за работу системы.
Вообще брать ответственность это отличительная особенность взрослых людей, а не только инженеров.
Не все работают над такими простыми системами, где один челоек может взять полною отвественность над всей работой.
>В этом случае любая ошибка в ее работе указывает на некомпетентность.
Есть ошибки критичные, а есть не очень.
>И никакие сроки в данном случае не могут являться оправданием.
Как раз опыт и профессионализм позволяет объяснить руководителям какая будет вероятность проблем при каких сроках.
>Инженер обеспечивает полноту анализа и учет всех возможных вариантов, без исключений.
В своей зоне ответственности.
>IMHO, реальных инженеров в IT очень мало.
Мало, много — инженеры так не говорят :D
JasF
24.07.2015 20:26Я решил для себя проблему целостности и читабельности кода более 3х лет назад тем, что начал разработку собственного проекта на основе подпроекта из Chromium'а с более чем 2500 .cc компилируемых файлов. Когда за несколько лет разобрался, как оно работает, и оптимизировал все это дело до конкурентных показателей, вопрос поддержания 'больших' проектов отпал.
Dywar
24.07.2015 20:29Топик интересный, есть разумное зерно.
И почитать холивар на тему — белое лучше черного или мягче чем синее.
Mirn
24.07.2015 21:05+7осмелюсь перефразировать статью и от себя добавить немного:
чтоб программист был хорошим достаточно чтобы он был немножко:
— алгоритмистом: достаточно знать самую базу, и знать что существует более лучше алгоритмы и уметь их искать.
— лингвистом: не всё и не всегда написано на «родном» языке и его диалекте, и часто что написано на чужом нужно чуток подправить.
— счетоводом: чтоб умел считать сложность хотя-бы на пальцах, вёл учёт ресурсов, не забывал про сроки
— политиком-переговорщиком: мы работаем для людей, в людском коллективе, инструментами и с кодом созданными другими людьми.
— инженером: имел понятие о запасе прочности, знал что не всё в мире совершенно, даже среда и компилятор, устранял причину, а не следствие
— технологом: чтобы наработки можно было хотя-бы поправить а лучше оформить потом в библиотеку и больше это никогда не писать.
— строителем: порой нужно просто класть, просто керпичи, просто в стену. долго, упорно, старательно.
— стратегом: редко когда код пишется одноразовым, обычно надо сопровождать годами или даже десятилетиями — надо учитывать будущее.
— И… просто в меру активным и в меру ленивым человеком с хорошим чувством баланса всех пунктов что я выше описалColwin
11.08.2015 10:17Я бы выразился проще — разработчик должен уметь мыслить системно и быть гибким. :-)
Умение адаптироваться под изменяющиеся условия — одно из главных умений.
Нужно придумать алгоритм — раскопал аналоги, скрутил решение, проверил на примерах и на краевых условиях.
Нужно настроить сервер — полез в доки, мануалы, нашел примеры, подкрутил под свой случай.
Нужно довести «хотелку» до тех. задания — договорился с заказчиком, детализировал сценарии, согласовал дизайн.
Но!
Все компании работают по-разному, и в обязанности разработчика вменяют самые разные вещи. Где-то специализация более узкая, где-то менее. Иметь широту обзора и умений полезно, но не всегда необходимо.
А вот умение обнаружить причину какого-либо поведения системы, имея на руках только частичные данные, и восстановить все возможные варианты развития событий, не пропустив ни одного — без этого просто нельзя. Если разработчик не способен обеспечить полноту анализа, или хотя бы обозначить границы этой полноты — это серьезный минус. Для нашего брата «не могу», «не хочу», «не умею» — не позволительная роскошь. Да, бывают ошибки, куда без них. Но бросить систему на произвол судьбы — это непрофессионализм.
Как-то так.
leschenko
удалено