Сделай, как для себя.
Никогда не пишите личный дневник для себя. Пишите его для тех, кто клялся, что никогда не будет его читать.Житейская мудрость.
Раньше, когда я был молодым и глупым программистом, я не понимал, почему работодатели спрашивают кандидата прежде всего о наличии подтверждённого опыта работы. А не о том, чем кандидат увлекается и что он, скорее всего, знает лучше, чем собственную работу. Ведь, казалось бы, в хобби, которое человеку априори интересно, он будет разбираться намного лучше, чем в работе, которая может быть интересной, а может и не быть. Неужели работодателю не нужен человек, который сам стал специалистом в нужной работодателю области?
Пример, основанный на художественной обработке реальных фактов: человек по восемь часов в день пишет скрипты для автоматизации тестирования, и получает за это зарплату. Но он мечтает портировать KDE2 под FreeBSD, и ещё по восемь часов в день, уже дома, тычется то в KDE2, то в FreeBSD, то в библиотеки Qt, пытаясь собрать одно с помощью второго, а второе - с помощью третьего.
Шутки шутками, но кухонный тостер под управлением операционной системы из семейства BSD - правда, не FreeBSD, а NetBSD - действительно существовал. KDE2 на этой версии тостера не запускали, исключительно по причине отсутствия средства графического вывода.
Человек искренне увлечён своим бессмысленным занятием, он назубок выдаст параметры configure для всех упомянутых пакетов, он достиг просветления и отрастил дзен толщиной с телеграфный столб, он может скомпилировать в FreeBSD не то что неправильно написанный код, но даже код, не написанный вообще, а KDE2 у него работает даже на тостере. То есть у работника есть хобби, он знает материал, он в своём хобби очень хорошо разбирается, и считает себя вправе претендовать на должность разработчика в фирме, специализирующейся на разработке с помощью Qt.
Возьмут ли его в эту фирму? При том, что он правда очень неплохой специалист и знает тему?
Возможно. Но есть отличная от нуля вероятность, что его на эту работу не возьмут. Почему?
Мне понадобилось добраться до самостоятельно проводимых собеседований, чтобы понять: именно из-за отсутствия опыта работы с этими же вещами в большой фирме.
Разница заключается в том, что, сидя дома и ковыряя код для собственного удовольствия, человек решает свои собственные задачи, задачи, которые он поставил себе сам. Эти задачи могут быть неинтересны никому, кроме него самого, и наоборот: он может и пальцем не пошевельнуть, чтобы коснуться задач, интересных другим пользователям. Более того, решение выбранных им задач может не удовлетворять никого, кроме его самого, потому что проверяет свою работу он тоже сам. При решении этих задач он может пользоваться облегчёнными процедурами или наплевать на технику разработки вообще, напрямую шагая к конечному результату.
Поясню на ещё одном примере:
Бадминтон - это не просто беготня по полю с ракетками. Это состязание примерно на уровне шахмат, или даже шахбокса. На каждый удар противника есть одно или несколько ответных шаблонных движений, которые позволяют с минимальными усилиями отбиться или перейти в атаку; результат игры зависит прежде всего от способности игрока думать: надо оценить действия противника и выбрать подходящий шаблон, отвечающий твоей стратегии. Потом надо ещё филигранно выбранный шаблон выполнить, но это уже дело тренировки. Главное - знание шаблонов, применяемых противником, умение их распознать и способность просчитать стратегию поединка хотя бы на два-три удара вперёд. И делать это надо быстро: скорость воланчика достигает 493 км/ч.
Когда я активно занимался бадминтоном, мой тренер Леонид Пугач (сейчас он тренирует юношескую сборную Израиля) рассказывал мне о некоем прибалте, который играл, абсолютно наплевав на технику. Он достиг впечатляющих результатов и был одним из лучших игроков в СССР. Он не знал ни единого шаблона, и ему совершенно не хотелось заниматься теорией. Вместо того, чтобы играть по шаблонам, экономя силы, этот прибалт бегал по корту. О, как он бегал! Он мог заткнуть за пояс любого кенийца. Вся его игра сводилась к тому, чтобы добежать до места, где будет пролетать воланчик, и шлёпнуть по нему ракеткой так, чтобы он перелетел через центральную сетку. Пока соперник, ожидавший хоть каких-то шаблонных решений, которые можно было бы просчитать и на основании этого просчёта создать какую-то стратегию, чинил собственный порванный шаблон, воланчик уже падал, и прибалт зарабатывал очередное очко.
Человек, который пишет проекты для себя, подобен этому прибалту. За очень редким исключением герой носится по корту, наплевав на шаблоны и тратя все силы только на то, чтобы добежать до нужной точки и отмахнуться от воланчика примерно в нужную сторону. Никакой стратегии, никаких заранее продуманных решений, никакой тактики, только голая сила и энтузиазм. Никто не спорит, результатов он добивается; но если выпустить такого игрока на поле в парном состязании, он затопчет своего напарника за первые же пять минут.
Так вот, возвращаясь к программированию, - я знаю очень немногих программистов, которые при решении собственных задач потрудились бы составить вменяемое техническое задание, написать список требований к продукту, нарисовать хотя бы несколько UML-диаграмм, составить use cases, спланировать разбивку решения на модули и классы. Никто не составляет план будущих релизов со списком характеристик, которые будут включены в ту или иную версию. Никто не думает о том, чтобы сделать полное, экстенсивное тестирование для программы, написанной дома и в рамках собственного хобби; часто у энтузиаста нет даже оборудования, чтобы устроить тестирование своей разработки на разных аппаратных базах или запустить стресс-тестирование своего проекта. Я не говорю про полноценные проверки конечного продукта, на которые полагается выделять столько же времени, сколько занимает разработка; я говорю хотя бы про формальную проверку соответствия результата списку требований. Но я ведь уже упомянул, что мало кто пишет списки требований?.. Никто не проверяет эргономику пользовательского интерфейса, никто не следит за скоростью работы программы. О чём там можно говорить, если лишь в самое последнее время люди массово начали пользоваться системами контроля версий для собственных домашних проектов! А ведь открыть аккаунт на sourceforge или на github проще, чем С++ выучить!
Когда перед тобой сидит явно неглупый парень и с энтузиазмом рассказывает, какую шикарную прогу он написал на каникулах, и ты видишь, что он в самом деле разбирается в вопросе, и что его программа в самом деле должна работать, но на вопрос: «Какой методологии разработки вы придерживались во время работы над проектом? Выбрали ли вы каскадную модель, итеративную разработку или спиральную? В чём преимущество выбранной вами методологии перед альтернативами?» - он открывает рот и начинает мямлить, что не рассматривал вопрос с такой точки зрения, на лицо так и просится фейспалм. И ты чувствуешь себя пророком, потому что видишь так же ясно, как Божий день, что сейчас его программа работает, но завтра он добавит в неё ещё модуль, послезавтра - ещё два, на следующей неделе уберёт что-то, а через месяц ему самому будет проще переписать программу с нуля, чем пытаться в ней разобраться. А что будет, если пустить его в проект, в который ты набираешь людей? Проект и без того состоит из костылей, сложенных в виде ажурной хрупкой конструкции и держащихся исключительно на честном слове вице-президента по разработкам. Этот бегемот, умеющий бегать с ракеткой в руках и знающий, что бе́гом он умеет достигать результатов быстро, попробует применить свои отточенные навыки в ажурном коде проекта, и в результате плоды его трудов твои сотрудники будут разгребать годами.
Часто бывает выгоднее взять середнячка без опыта и научить его с нуля работе по правильным методикам, чем взять опытного и производительного хакера, который, в силу бытия хакером, привык плевать на методологию и на модели, и который в результате поставит под угрозу весь проект.
У этой мысли есть далеко идущие последствия.
Именно поэтому так мало хороших, качественных программ, написанных индивидуальными разработчиками. Откройте собственные смартфоны и посмотрите, какими программами вы чаще всего пользуетесь. Ручаюсь, большинство из них окажутся разработанными фирмами, а не отдельными людьми. И совершенно неважно, платная программа или бесплатная; сама разработка в условиях фирмы означает, что методология разработки программного обеспечения была соблюдена. Это не поделка хакера, это результат планирования, имплементации, тестирования и внедрения. Поэтому она работает стабильнее, на большем выборе железа, при большем разбросе исходных данных.
Именно поэтому все операционные системы, мобильные или десктопные, пытаются ввести систему сертификации программ на соответствие неким стандартам. Чтобы программу приняли в Apple AppStore, она должна пройти серию проверок, в том числе и на соответствие правилам внешнего оформления интерфейса. Эти проверки ставят какую-то минимальную планку, задают высоту, отсеивающую однозначно неудачные (но при этом вполне работающие!) программы. К сожалению, Linux в силу собственной идеологии не может заставить пользователей устанавливать только сертифицированные программы, поэтому средняя поделка под Linux пишется студентом, решающим свою частную задачу, без серьёзного тестирования, и в результате даёт абсолютно неприемлемый результат, если пользователь отклоняется от линии ожидаемого поведения.
Вы думаете, я исключение из этого правила? Да ни в одном глазу. Я тоже сначала сажусь программировать, а только потом думаю, что я, собственно, собираюсь написать. Это только в последнее время я начал заставлять себя работать над домашними проектами так, как если бы я был на работе: техническое задание, список требований, список способностей, которые могут удовлетворить эти требования, дизайн-документы двух или трёх уровней, use cases, UML, разбивка на модули и на классы, итеративная методология разработки, модель V, список тестов, стресс-тесты и регрессионное тестирование, ну и список багов с исправлениями в конце. И мне до сих пор приходится силой удерживать себя над документацией, когда хочется вот прямо сейчас начать писать код. В результате на разработку проекта, которую, по хорошему, можно было бы закончить за неделю, тратится несколько месяцев, зато я буду уверен: результат можно выпускать в свет и гордиться конечным продуктом.
В этом и заключается разница между «сделай, как для себя» и «сделай, как для других». Первое - это тяп-ляп, криво-косо, напихали, костыль поставили, верёвочкой подвязали, и так сойдёт. Второе - штука будет работать, даже если условия, в которых её используют, абсолютно не соответствуют тем, о которых создатель думал, когда начинал работу.
Это не только программ касается. Когда я ремонтировал квартиру, свой кабинет я шпаклевал, как для себя, именно поэтому там такие разводы на стене, словно Всемирный потоп начался именно с этой комнаты. А гардеробную, в которой в основном Шеля орудует, я шпаклевал, как для других, поэтому стена там ровненькая и наждачкой зачищенная.
Так что, когда вы будете просить меня об одолжении, не говорите мне сделать, как для себя. Я ведь сделаю, и может получиться неловко.
Раньше, когда я был молодым и глупым программистом, я не понимал, почему работодатели спрашивают кандидата прежде всего о наличии подтверждённого опыта работы. А не о том, чем кандидат увлекается и что он, скорее всего, знает лучше, чем собственную работу. Ведь, казалось бы, в хобби, которое человеку априори интересно, он будет разбираться намного лучше, чем в работе, которая может быть интересной, а может и не быть. Неужели работодателю не нужен человек, который сам стал специалистом в нужной работодателю области?
Пример, основанный на художественной обработке реальных фактов: человек по восемь часов в день пишет скрипты для автоматизации тестирования, и получает за это зарплату. Но он мечтает портировать KDE2 под FreeBSD, и ещё по восемь часов в день, уже дома, тычется то в KDE2, то в FreeBSD, то в библиотеки Qt, пытаясь собрать одно с помощью второго, а второе - с помощью третьего.
Шутки шутками, но кухонный тостер под управлением операционной системы из семейства BSD - правда, не FreeBSD, а NetBSD - действительно существовал. KDE2 на этой версии тостера не запускали, исключительно по причине отсутствия средства графического вывода.
Человек искренне увлечён своим бессмысленным занятием, он назубок выдаст параметры configure для всех упомянутых пакетов, он достиг просветления и отрастил дзен толщиной с телеграфный столб, он может скомпилировать в FreeBSD не то что неправильно написанный код, но даже код, не написанный вообще, а KDE2 у него работает даже на тостере. То есть у работника есть хобби, он знает материал, он в своём хобби очень хорошо разбирается, и считает себя вправе претендовать на должность разработчика в фирме, специализирующейся на разработке с помощью Qt.
Возьмут ли его в эту фирму? При том, что он правда очень неплохой специалист и знает тему?
Возможно. Но есть отличная от нуля вероятность, что его на эту работу не возьмут. Почему?
Мне понадобилось добраться до самостоятельно проводимых собеседований, чтобы понять: именно из-за отсутствия опыта работы с этими же вещами в большой фирме.
Разница заключается в том, что, сидя дома и ковыряя код для собственного удовольствия, человек решает свои собственные задачи, задачи, которые он поставил себе сам. Эти задачи могут быть неинтересны никому, кроме него самого, и наоборот: он может и пальцем не пошевельнуть, чтобы коснуться задач, интересных другим пользователям. Более того, решение выбранных им задач может не удовлетворять никого, кроме его самого, потому что проверяет свою работу он тоже сам. При решении этих задач он может пользоваться облегчёнными процедурами или наплевать на технику разработки вообще, напрямую шагая к конечному результату.
Поясню на ещё одном примере:
Бадминтон - это не просто беготня по полю с ракетками. Это состязание примерно на уровне шахмат, или даже шахбокса. На каждый удар противника есть одно или несколько ответных шаблонных движений, которые позволяют с минимальными усилиями отбиться или перейти в атаку; результат игры зависит прежде всего от способности игрока думать: надо оценить действия противника и выбрать подходящий шаблон, отвечающий твоей стратегии. Потом надо ещё филигранно выбранный шаблон выполнить, но это уже дело тренировки. Главное - знание шаблонов, применяемых противником, умение их распознать и способность просчитать стратегию поединка хотя бы на два-три удара вперёд. И делать это надо быстро: скорость воланчика достигает 493 км/ч.
Когда я активно занимался бадминтоном, мой тренер Леонид Пугач (сейчас он тренирует юношескую сборную Израиля) рассказывал мне о некоем прибалте, который играл, абсолютно наплевав на технику. Он достиг впечатляющих результатов и был одним из лучших игроков в СССР. Он не знал ни единого шаблона, и ему совершенно не хотелось заниматься теорией. Вместо того, чтобы играть по шаблонам, экономя силы, этот прибалт бегал по корту. О, как он бегал! Он мог заткнуть за пояс любого кенийца. Вся его игра сводилась к тому, чтобы добежать до места, где будет пролетать воланчик, и шлёпнуть по нему ракеткой так, чтобы он перелетел через центральную сетку. Пока соперник, ожидавший хоть каких-то шаблонных решений, которые можно было бы просчитать и на основании этого просчёта создать какую-то стратегию, чинил собственный порванный шаблон, воланчик уже падал, и прибалт зарабатывал очередное очко.
Человек, который пишет проекты для себя, подобен этому прибалту. За очень редким исключением герой носится по корту, наплевав на шаблоны и тратя все силы только на то, чтобы добежать до нужной точки и отмахнуться от воланчика примерно в нужную сторону. Никакой стратегии, никаких заранее продуманных решений, никакой тактики, только голая сила и энтузиазм. Никто не спорит, результатов он добивается; но если выпустить такого игрока на поле в парном состязании, он затопчет своего напарника за первые же пять минут.
Так вот, возвращаясь к программированию, - я знаю очень немногих программистов, которые при решении собственных задач потрудились бы составить вменяемое техническое задание, написать список требований к продукту, нарисовать хотя бы несколько UML-диаграмм, составить use cases, спланировать разбивку решения на модули и классы. Никто не составляет план будущих релизов со списком характеристик, которые будут включены в ту или иную версию. Никто не думает о том, чтобы сделать полное, экстенсивное тестирование для программы, написанной дома и в рамках собственного хобби; часто у энтузиаста нет даже оборудования, чтобы устроить тестирование своей разработки на разных аппаратных базах или запустить стресс-тестирование своего проекта. Я не говорю про полноценные проверки конечного продукта, на которые полагается выделять столько же времени, сколько занимает разработка; я говорю хотя бы про формальную проверку соответствия результата списку требований. Но я ведь уже упомянул, что мало кто пишет списки требований?.. Никто не проверяет эргономику пользовательского интерфейса, никто не следит за скоростью работы программы. О чём там можно говорить, если лишь в самое последнее время люди массово начали пользоваться системами контроля версий для собственных домашних проектов! А ведь открыть аккаунт на sourceforge или на github проще, чем С++ выучить!
Когда перед тобой сидит явно неглупый парень и с энтузиазмом рассказывает, какую шикарную прогу он написал на каникулах, и ты видишь, что он в самом деле разбирается в вопросе, и что его программа в самом деле должна работать, но на вопрос: «Какой методологии разработки вы придерживались во время работы над проектом? Выбрали ли вы каскадную модель, итеративную разработку или спиральную? В чём преимущество выбранной вами методологии перед альтернативами?» - он открывает рот и начинает мямлить, что не рассматривал вопрос с такой точки зрения, на лицо так и просится фейспалм. И ты чувствуешь себя пророком, потому что видишь так же ясно, как Божий день, что сейчас его программа работает, но завтра он добавит в неё ещё модуль, послезавтра - ещё два, на следующей неделе уберёт что-то, а через месяц ему самому будет проще переписать программу с нуля, чем пытаться в ней разобраться. А что будет, если пустить его в проект, в который ты набираешь людей? Проект и без того состоит из костылей, сложенных в виде ажурной хрупкой конструкции и держащихся исключительно на честном слове вице-президента по разработкам. Этот бегемот, умеющий бегать с ракеткой в руках и знающий, что бе́гом он умеет достигать результатов быстро, попробует применить свои отточенные навыки в ажурном коде проекта, и в результате плоды его трудов твои сотрудники будут разгребать годами.
Часто бывает выгоднее взять середнячка без опыта и научить его с нуля работе по правильным методикам, чем взять опытного и производительного хакера, который, в силу бытия хакером, привык плевать на методологию и на модели, и который в результате поставит под угрозу весь проект.
У этой мысли есть далеко идущие последствия.
Именно поэтому так мало хороших, качественных программ, написанных индивидуальными разработчиками. Откройте собственные смартфоны и посмотрите, какими программами вы чаще всего пользуетесь. Ручаюсь, большинство из них окажутся разработанными фирмами, а не отдельными людьми. И совершенно неважно, платная программа или бесплатная; сама разработка в условиях фирмы означает, что методология разработки программного обеспечения была соблюдена. Это не поделка хакера, это результат планирования, имплементации, тестирования и внедрения. Поэтому она работает стабильнее, на большем выборе железа, при большем разбросе исходных данных.
Именно поэтому все операционные системы, мобильные или десктопные, пытаются ввести систему сертификации программ на соответствие неким стандартам. Чтобы программу приняли в Apple AppStore, она должна пройти серию проверок, в том числе и на соответствие правилам внешнего оформления интерфейса. Эти проверки ставят какую-то минимальную планку, задают высоту, отсеивающую однозначно неудачные (но при этом вполне работающие!) программы. К сожалению, Linux в силу собственной идеологии не может заставить пользователей устанавливать только сертифицированные программы, поэтому средняя поделка под Linux пишется студентом, решающим свою частную задачу, без серьёзного тестирования, и в результате даёт абсолютно неприемлемый результат, если пользователь отклоняется от линии ожидаемого поведения.
Вы думаете, я исключение из этого правила? Да ни в одном глазу. Я тоже сначала сажусь программировать, а только потом думаю, что я, собственно, собираюсь написать. Это только в последнее время я начал заставлять себя работать над домашними проектами так, как если бы я был на работе: техническое задание, список требований, список способностей, которые могут удовлетворить эти требования, дизайн-документы двух или трёх уровней, use cases, UML, разбивка на модули и на классы, итеративная методология разработки, модель V, список тестов, стресс-тесты и регрессионное тестирование, ну и список багов с исправлениями в конце. И мне до сих пор приходится силой удерживать себя над документацией, когда хочется вот прямо сейчас начать писать код. В результате на разработку проекта, которую, по хорошему, можно было бы закончить за неделю, тратится несколько месяцев, зато я буду уверен: результат можно выпускать в свет и гордиться конечным продуктом.
В этом и заключается разница между «сделай, как для себя» и «сделай, как для других». Первое - это тяп-ляп, криво-косо, напихали, костыль поставили, верёвочкой подвязали, и так сойдёт. Второе - штука будет работать, даже если условия, в которых её используют, абсолютно не соответствуют тем, о которых создатель думал, когда начинал работу.
Это не только программ касается. Когда я ремонтировал квартиру, свой кабинет я шпаклевал, как для себя, именно поэтому там такие разводы на стене, словно Всемирный потоп начался именно с этой комнаты. А гардеробную, в которой в основном Шеля орудует, я шпаклевал, как для других, поэтому стена там ровненькая и наждачкой зачищенная.
Так что, когда вы будете просить меня об одолжении, не говорите мне сделать, как для себя. Я ведь сделаю, и может получиться неловко.