Страсть к программированию. Глава 11. Научись рыбачить

Продолжаю перевод The Passionate Programmer от Chad Fowler. Правки пунктуации и неудачных фраз весьма приветствуются.

Все желающие присоединиться могут сделать это на гитхабе:
github.com/Flar49/passionate-programmer-translation/tree/master

< 10. Полюби это или брось | 12. Изучите, как работает бизнес на самом деле >

Глава 11. Научись рыбачить.

Лао Цзы сказал: “Дай человеку рыбу, и он будет сыт один день. Научи человека ловить рыбу, и он будет сыт всю жизнь”. Это все хорошо и замечательно. Вот только Лао Цзы пропустил ту часть, в которой человек не хочет учиться рыбачить и завтра просит у вас еще одну рыбу. Образовательный процесс требует наличия как учителя, так и ученика. Многие из нас слишком часто не хотят быть учениками.

Не ждите, пока вам расскажут. Спрашивайте!

Но что является рыбой в программной индустрии? Это процесс использования инструмента, какой-либо грани технологии или специфической информации из вашей области бизнеса. Это знание, как сделать check out определенной ветки из системы контроля версий вашей команды, или умение поднять сервер приложений для разработки. Слишком многие из нас принимают подобные детали как должное. “Кто-то другой может сделать это за меня”, — можете подумать вы. Сборщик проектов (прим. пер. build guy) разбирается в системе контроля версий. Вы просто попросите его помочь вам, когда потребуется. Команда, занимающаяся инфраструктурой, знает, как настроены файрволлы между вами и клиентами. Если вам что-то нужно поправить, вы просто шлете им письмо, и команда делает это.

Кто хочет зависеть от кого-то другого? Или, и того хуже: если бы вы хотели нанять кого-либо на работу, хотели ли бы, чтобы он был зависим от экспертов? Я бы не хотел. Я бы хотел, чтобы мой работник был самодостаточным.

Наиболее очевидный способ начать — изучить инструменты вашей профессии. Система контроля версий, например, очень мощный инструмент. Важная часть ее работы заключается в том, чтобы сделать разработчика более продуктивным. Это не просто место, в которое вы кладете законченный код, и вы не должны к нему так относиться. Это составная часть вашего процесса разработки. Не дайте такой важной вещи — надежному репозиторию вашей работы — быть для вас магией и загадкой. Самодостаточный разработчик легко может узнать различия между собственной версией проекта и последней правильно работающей в репозитории. Или, допустим, вам нужно достать код последнего релиза и поправить баг. Если в вашем коде посреди ночи нашелся критический баг, вы не захотите звонить кому-нибудь и просить достать нужную версию из репозитория, чтобы вы могли приступить к решению проблемы. Точно так же это касается IDE, операционных систем и почти каждой части инфраструктуры, на которой базируется ваш код или рабочий процесс.

Настолько же важна используемая вами технологическая платформа. Например, вы можете разрабатывать приложения на основе J2EE. Вы знаете, что вы должны создавать различные классы, интерфейсы и дескрипторы развертывания (прим. пер. deployment descriptors). Знаете ли вы почему? Знаете ли вы, как все это используются? Что на самом деле происходит, когда вы запускаете J2EE-контейнер? Вам не обязательно быть разработчиком сервера приложений, однако, знание подобных вещей позволяет вам разрабатывать надежный код для платформы и успешно решать проблемы при их возникновении.

Особенно простой способ облениться — использовать кучу визардов, которые генерируют код за вас. Такой подход наиболее распространен в мире Windows-разработки, где, спасибо Microsoft, инструменты разработки делают многие задачи действительно простыми. Обратная сторона медали заключается в том, что многие Windows-разработчики не имеют понятия о том, как на самом деле работает их код. Работа визардов остается магией и загадкой. Не поймите меня неправильно — кодогенерация, при правильном использовании, может быть очень полезным инструментом. Например, генераторы кода, которые транслируют высокоуровневый C# в байткод, способый запускаться на .NET CLR. Вы однозначно не хотели бы писать весь этот байткод сами. Но, особенно на высоком уровне, позволяя визардам делать их работу вы оставляете собственные знания поверхостными и ограничиваете себя тем набором действий, который визарды способны выполнить для вас.

Мы можем легко проглядеть рыбу в собственной предметной области. Работая в ипотечной компании вы можете попросить эксперта рассчитать для вас процентную ставку по каждому сценарию, необходимому во время тестов. Или вы можете научиться этому сами. Общение с вашими клиентами это хорошо, равно как и согласование с ними бизнес-требований (по сравнению с недопониманием и прикидыванием деталей на глаз самостоятельно). Но представьте, насколько быстрее вы могли бы развиваться, если бы вы действительно знали нюансы собственной предметной области. Возможно, вы не сможете узнать абсолютно каждое бизнес-правило — это не ваша работа. Но, как минимум, вы можете разобраться с основами. Многие из лучших работников IT-сферы с которыми я работал со временем становились лучшими экспертами в предметной области, чем некоторые из их бизнес-клиентов. Это приводит к повышению качества продуктов. Люди, не знающий предметной области, однозначно будут допускать глупые ошибки. Ошибки, которых можно было бы избежать, имея базовые знания предметной области. Более того, они будут менее эффективны (и в итоге обойдутся компании дороже) чем аналогичный разработчик, понимающий предметную область.

Для нас, разработчиков ПО, высказывание Лао Цзы может быть перефразировано следующим образом: “Попроси рыбу, и будешь сыт один день. Попроси кого-нибудь научить тебя ловить рыбу, и будешь сыт всю жизнь”. А еще лучше, не просите вас научить — идите и учитесь сами.

Руководство к действию:

1. Как и почему? Сидя и читая эту книгу или будучи в следующий раз на работе, подумайте о гранях вашей работы, которые вы не понимаете до конца. Вы можете задать себе два невероятно полезных вопроса о любой области, которые помогут вам разобраться в ее сложностях: “как это работает?" и “почему это происходит именно так?”
   Возможно, вы не сможете ответить на эти вопросы, но сам факт вопроса поможет вашему уму войти в новое состояние и поспособствует лучшему осознанию вашего рабочего окружения. Каким образом IIS-сервер передает запросы моим ASP.NET страницам? Почему я должен генерировать все эти интерфейсы и дескрипторы развертки для моего EJB-приложения? Чем отличается обработка компилятором статической линковки относительно динамической? Почему мы рассчитываем налог иначе, если наш покупатель живет в Монтане?
   Естественно, что ответ на любой из этих вопросов приведет к потенциальной возможности задать следующий вопрос. Если вы не можете спуститься дальше по дереву из вопросов “как?” и “почему?”, вы, возможно, узнали достаточно.
2. Немножко времени. Выберите один из наиболее критичных и наименее известных вам инструментов из вашего повседневного набора и сфокусируйтесь на нем. Возможно это ваша система контроля версий или библиотека, которую вы регулярно используете, но понимаете только поверхностно. Или редактор кода, который вы используете при программировании. Выбрав инструмент, отведите себе немножко времени каждый день на изучение одной новой детали о нем, которая поможет вам стать более продуктивным или позволит лучше контролировать ваше рабочее окружение. Вы можете, например, освоить GNU Bourne Again Shell (bash). В один из тех моментов, когда вы отвлекаетесь от работы, поищите в интернете bash tips, вместо того, чтобы загрузить Slashdot. В течении минуты-другой вы должны найти что-то полезное, чего вы еще не знали о shell. А теперь, когда вы знаете новый трюк, вы можете препарировать его вопросами “как?” и “почему?”.

Благодарю за внимание.

Автор: Flar49

Источник