закрыть

7 хороших привычек “плохого” программиста

… Итак, когда я стал “плохим” программистом, нужно было как-то жить с этим дальше. И мне не оставалось ничего, как начать работать по-другому, чтобы то, что я “плохой”, не делало плохими проекты, над которыми я работаю.

В итоге за несколько следующих лет у меня выработалось несколько хороших, на мой взгляд, привычек программиста, помогающих мириться с собственным несовершенством:

  1. Писать меньше кода. Чем меньше кода, тем меньше в нем багов. Поэтому любую задачу нужно решать минимально возможным количеством строк кода. Краткость – сестра таланта.
  2. Писать код понятный человеку. Это высказывание Мартина Фаулера можно в принципе не комментировать. Включается сюда и оформление кода, и наличие комментариев, и наименование переменных, и логика организации кода. Вам или кому-то другому обязательно когда-нибудь придется заглянуть в Ваш код. Пожалейте его.
  3. “Маниакально” проверять данные, поступающие из внешней среды. Все, что может пойти не так, как надо, обязательно пойдет не так. Это закон Мерфи. Поэтому обязательно нужно проверять поступающие извне данные на все возможные и невозможные ошибки (неправильная типизация, отсутствие данных, непопадание в ожидаемый диапазон значений и т.п.). Внутри же своего модуля, уровень “паранойи” можно резко снизить (если Вы себе доверяете), но по отношению к данным из внешней среды – предела “паранойе” быть не должно.
  4. Реализовывать требования в лоб. Не нужно пытаться в коде оптимизировать требования к системе. Лучше это сделать в документе, описывающем требования. А вот между ним и кодом соответствие должно быть однозначное. Идеально, чтобы части документа требований служили комментариями к Вашим классам, методам, переменным и названия методов, классов, переменных с точностью до перевода на английский язык соответствовали терминам документа требований. В этом случае вероятность неверной реализации требований (т.е. дефекта) будет
    минимальной.
  5. Учиться на чужих ошибках (in google we trust). Я много раз встречался с ситуацией, когда проблема, которая до этого неделями не решалась путем постоянного переписывания кода, решалась за час поиска в интернете и copy-paste-а готового решения. Мы живем в мире, в котором редко можно встретить уникальную, никому доселе не встречавшуюся проблему. Надо пользоваться благами нашей цивилизации, такими как google, stakoverflow и т.п.
  6. Прежде чем писать – читать. Это очень близко к предыдущему пункту, но все-таки лучше вынести отдельно. 90% того, что нам нужно для работы, написано в документации. Нам даже google не нужен для решения большинства проблем.
    Все уже есть в документации.
  7. Ставить под сомнение свое решение. Прежде чем начинать искать причину проблемы где-то во внешней среде (в библиотеке, фрэймворке, языке программирования) нужно быть на 146% уверенным, что проблема не в твоем коде.
    Да, другие люди тоже ошибаются и делают это возможно даже чаще, чем ты. Но прежде чем обвинять их – исключи
    свою собственную ошибку. Это спасет, прежде всего, твою собственную репутацию.

На мой взгляд, правила эти очень простые и не требуют много усилий для того, чтобы им следовать. Но следование им экономит много времени и сил как Ваших собственных, так и тех, кто работает вместе с Вами.

Хотите тоже заказать у нас разработку ПО?

Краткое описание проекта:
1. Интересующий функционал
2. Ограничения по бюджету
3. Пожелания по срокам
Бесплатно оценить проект