На днях довелось понаблюдать за собеседованием программистов-железячников, занятно было порефлексировать, понаблюдать что я ещё помню из языка С и особенностей реализации компьютеров. Узнал для себя забавное понятие Cache-oblivious algorithm, много думал ;).
Но поводом для написания этого текста стало немного другое. Во время этого собеседования я с особой четкостью осознал, что знание аппаратуры, конечно, может помочь выйти из top-10% профессионалов в top-5%, но в большинстве случаев не является существенно важным навыком.
После некоторых размышлений я описал свою работу примерно так. Большую часть времени я занимаюсь "заградительным" программированием. Мой код должен быть написан таким образом, чтобы другой разработчик (или я через несколько месяцев), надумав что-то в коде поменять, мог быстро определить где вносить изменения, какие именно, и что ещё будет затронуто изменением. А ещё чтобы было очевидно что делать ни в коем случае нельзя. При этом я не могу использовать такие ресурсы как ТЗ, спецификации, любая документация и, зачастую, даже комментарии в коде, потому что они наверняка не обновляются вовремя и, как следствие, им всё равно никто не доверяет. Поэтому для сколь бы то ни было сложной задачи мой код должен выглядеть очень простым и понятным. И если вдруг потенциальный работодатель попросит меня предоставить кусок кода как часть резюме, то мой код будет выглядеть как пособие к лабораторной работе на 3-м курсе. Все более-менее нетривиальные куски кода будут реализацией подходящего шаблона проектирования, причем, скорее всего, код написан не мной, а выбран после тщательного изучения нескольких вариантов на хабре, codeproject и stackoverflow. Либо будет использована подходящая библиотека с nuget, тоже после тщательного изучения примеров использования и реализации пары тестовых приложений.
Вот список вещей, которые я считаю важными для разработки прикладного софта:
Но поводом для написания этого текста стало немного другое. Во время этого собеседования я с особой четкостью осознал, что знание аппаратуры, конечно, может помочь выйти из top-10% профессионалов в top-5%, но в большинстве случаев не является существенно важным навыком.
После некоторых размышлений я описал свою работу примерно так. Большую часть времени я занимаюсь "заградительным" программированием. Мой код должен быть написан таким образом, чтобы другой разработчик (или я через несколько месяцев), надумав что-то в коде поменять, мог быстро определить где вносить изменения, какие именно, и что ещё будет затронуто изменением. А ещё чтобы было очевидно что делать ни в коем случае нельзя. При этом я не могу использовать такие ресурсы как ТЗ, спецификации, любая документация и, зачастую, даже комментарии в коде, потому что они наверняка не обновляются вовремя и, как следствие, им всё равно никто не доверяет. Поэтому для сколь бы то ни было сложной задачи мой код должен выглядеть очень простым и понятным. И если вдруг потенциальный работодатель попросит меня предоставить кусок кода как часть резюме, то мой код будет выглядеть как пособие к лабораторной работе на 3-м курсе. Все более-менее нетривиальные куски кода будут реализацией подходящего шаблона проектирования, причем, скорее всего, код написан не мной, а выбран после тщательного изучения нескольких вариантов на хабре, codeproject и stackoverflow. Либо будет использована подходящая библиотека с nuget, тоже после тщательного изучения примеров использования и реализации пары тестовых приложений.
Вот список вещей, которые я считаю важными для разработки прикладного софта:
- Знать своего пользователя.У нас никогда не будет 100% корректных и неизменных требований. Это знание включает в себя знание его работы, опыта работы с компьютером, привычек, окружения.
- Поскольку знать клиента на 100% тоже нельзя, то уже много лет в каждом продукте у меня встроен мониторинг сбоев. Для веб-проектов это Elmah, для десктопа — честно позаимствованный из интернета и немного модифицированный набор классов. А после релизов день начинается с разбора присланных логов.
- Строгое следование принципам KISS и YAGNI. Иногда (всегда?) немного в ущерб производительности и требованиям к ресурсам.
- Как можно меньше изобретать новых алгоритмов и подходов.По максимуму использовать идеи тех гигантов, на плечах которых мы стоим.
- Очень внимательная работа с архитектурой решения. Архитектура должна быть по возможности примитивной, но позволять менять и расширять её в широких пределах, в то же время оставаясь достаточно производительной и с минимумом зависимостей. В идеале новому программисту архитектуру можно нарисовать на салфетке в обеденный перерыв.
- Оценивать свои усилия в соответствии с известным законом и выдавать первый прототип как можно раньше.
- Паранойя, паранойя и ещё раз паранойя. Что-то обязательно сломается прямо перед релизом, что-то сразу после, или на презентации/демонстрации. на половине машин продукт просто не заработает без всяких сообщений. Пользователи обязательно будут использовать продукт совсем не так, как надо, не будут видеть большую кнопку в центре экрана, которую нужно нажать, а будут жать на всё то, что программист забыл спрятать. Если пользователя спросить, какие действия привели к ошибке — он переврёт 20% информации, а оставшиеся 80% не будут относиться к проблеме. Начальные требования формулировал человек, который не в теме, а после релиза громче всех будет настаивать на их изменении тот, кто не имеет полномочий. Ну, а следующий же программист, который будет участвовать в проекте после меня — просто всё сломает, а я забуду все детали этого проекта как только начну работать над следующим.
В этом плане поучительный фильм про нашу работу — это "Доктор Хаус". Все врут. Только когда пациенту станет совсем плохо, можно поставить точный диагноз. А симптомы в большинстве случаев, основательно замаскированы разными аллергическими реакциями кода на производственную среду или отладчик.
Как следствие, есть языки, которые более предпочтительны для прикладной разработки (Delphi, Visual Basic и C#) просто потому, что большая красная кнопка в них спрятана подальше, чем в C и C++.
А что важно в вашей профессии? :)
Комментариев нет:
Отправить комментарий