Многие говорят о том, что
же нужно знать разработчику, для того что бы построить успешную карьеру. Часто также
всплывает похожий вопрос - какими чертами должен обладать программист что бы преуспеть.
Ответы на оба эти вопроса безусловно чрезвычайно важны и, очевидно, для того
что бы стать успешным специалистом нужно сочетать в себе все, что служит
ответом как на первый, так и на второй вопросы. Ниже представлены 15 принципов,
которые каждый программист должен взять себе на вооружение, на своем пути к
самоусовершенствованию.
- Помни основы. Если ты забудешь основы программирования, ты потеряешь все свои основополагающие знания. Это – точно не здорово.
- Всегда предполагай наихудший сценарий. Если у тебя есть образование по диплому связанное с программированием наверняка ты помнишь о “O-нотации”. Понимание того, почему некоторый алгоритм ввиду своей сложности не может эффективно применяться в определенном случае, безусловно похвально. С помощью этих знаний ты сможешь находить оптимальные решения в конкретном случае.
- Тестируй свой код. Если ты используешь TDD или другую подобную методологию, убедись что весь твой код имеет соответствующие тесты, которые проверяют твой код во всех необходимых условиях. В зависимости от ситуации, необходимо стремится к определенному уровню покрытия кода тестами. Но так или иначе всегда пиши тестов настолько много, насколько это возможно.
- Никогда не используй новую технологию только потому что она новая, используй те технологии, которые решают поставленные задачи. Мы часто пытаемся применять более новые технологии и подходы, в надежде что с их помощью найдем серебряную пулю. Этот подход неверен. Серебряной пули не существует.
- Читай. Если ты не читаешь новости рынка IT, ты рано или поздно столкнешься с тем, что ты сильно отстал в своих знаниях от того что нужно знать специалисту твоего уровня и твое место займут другие, более квалифицированные ребята.
- Используй новые приемы и технологии. Да, я говорил не использовать новые технологии только потому что они новые, но ты должен попробовать их на практике, не обязательно на рабочем проекте, для того что бы знать что нового они в себе несут и когда и для чего они могут пригодится. Такой поход ко всему прочему позволяет тебе изучать новое и оставаться востребованным на рынке разработки.
- На ошибках учатся. Не бойся сделать ошибку. В конечном счете столкнувшись с ней, ты чему то научишься. В некоторых случаях ошибку можешь даже воспринимать как маленький успех.
- Можно выпускать программное обеспечение с технической задолженностью. Иногда возникает необходимость выпустить версию программы с технической задолженностью, то есть когда в коде не все в порядке, но ты сам себе пообещал что в будущем это будет исправлено. Если такая ситуация будет иметь место постоянно – то рано или поздно ты столкнешься с кошмаром, когда из-за таких вот недоделок вылезет настоящая трудноразрешимая проблема.
- Делай «как надо». У большинства разработчиков есть свое понимание «как надо» писать код, но к сожалению это не всегда совпадает с мнением руководства. Этот пункт практически противопоставление предыдущего, поэтому нужно найти правильный баланс.
- Оставляй код в лучшем состоянии, чем он был до этого. Вместо проповедования преимуществ рефакторинга, подумай о том хотелось ли бы тебе поддерживать код, который с каждым моментом становится все хуже. Если каждый раз когда ты что то модифицируешь, ты в состоянии что то подчистить или исправить, наверняка это пойдет только на пользу проекту.
- Думай о параллельном доступе. Если ты разрабатываешь веб-приложение (я не имею ввиду такого масштаба как скажем Facebook), проблемы могут возникнуть с загрузкой сервера. Скажем, когда приложение будут использовать одновременно 100 пользователей подобная проблема может произойти. Держи в голове такую ситуацию с самого начала.
- Бесплатное хранение данных, но дорогой доступ. Тебе может казаться что хранение данных на диске – отличная идея. В общем – это верно, но если использовать диск для хранения временных данных то рано или поздно можно столкнуться с проблемой медленного взаимодействия с диском. Поэтому рациональней будет хранить там долгосрочные или чрезвычайно объемные данные, когда данные физически не помещаются в доступной памяти.
- Доступная память может закончится раньше чем ты думаешь. Изначально, многие разработчики используют разворачивают и само приложение и вспомогательный софт, как скажем сервер базы данных на одном компьютере. Пока доступной памяти в достатке – это допустимо. Но очень часто на этой почве появляются проблемы. Например, можно выполнять небольшое Java-приложение в Tomcat на 528Mb. Но как только увеличиваются объемы используемых приложением данных потребность в памяти может быстро вырасти скажем до 8Gb. Очевидно, что это напрямую зависит от того, сколько пользователей использует приложение и какими объемами данными манипулирует приложение.
- Кеширование годится для всего, но только до той поры пока не поломает сервер. Если ты ищешь способ уменьшить объем запросов к базе данных, то рано или поздно обратишь внимание на механизм кеширования. Проблема здесь может заключаться в том, что для кеширование необходимо намного больше памяти, чем те объемы которые используются приложением, особенно если нужно обслуживать большое количество пользователей (смотри предыдущий пункт по поводу памяти). Самая плохая проблема с кешированием заключается в том, что злоупотребление им может привести к ошибке OutOfMemory. В таком случае твой сервер либо перестанет отвечать на запросы либо поломается вовсе. В таком случае механизм кеширования больше на сможет решать поставленные на него задачи, так как сам будет является источником проблем.
- Думай как консультант. Как работник, ты можешь ожидать, что компания может переносить дедлайны, объемы работ могут меняться, и тебе придется приспосабливаться к таким изменениям. Если пригласить стороннего консультанта – он наверняка был бы против подобных изменений. Ты, как сотрудник может вести себя так же, и настаивать на том что изменять срок дедлайна или изменять объем работ нельзя, так как это приведет к необходимости поиска дополнительных ресурсов, которые сложно найти.
Я знаю, что все
эти принципы это просто набор несвязанных мыслей в моей голове. Но это лучший
список, который я могу создать сейчас. А какие еще принципы можно добавить в этот список?
