Грамотное программирование основано на трех простых утверждениях:
- Программисты должны написать код, понятный компьютеру
- Программисты должны писать документацию, понятную людям
- Если это отдельные документы, неизбежно, что они будут несинхронизированы
Действительно, по моему опыту, # 2 обычно становится коротким. Я потерял счет того, сколько раз QA сообщило мне: «Документ говорит об этом, но код делает ЭТО; код неправильный или документ устарел?» Я не ожидаю, что мое рабочее место будет необычным в этом отношении. Кроме того, в одном из моих ранних проектов я пытался обновлять документы, так как взаимодействие с заинтересованными сторонами приводило к изменению требований. Это заняло достаточно много времени, и мне сказали, чтобы руководство прекратило возиться с документами и просто заставить проект работать. С тех пор мы перешли к менее утомительным процессам документирования (слава Богу!).
У нас есть инструменты для проверки кода, где, когда мы вносим изменения в код, несколько человек могут видеть изменения, четко очерченные, и могут быть сделаны комментарии, задавая вопросы, объясняя вещи, предлагая улучшения. Если бы код был написан с использованием методов грамотного программирования, большая часть этого вопроса / ответа была бы излишней, потому что было бы включено объяснение.
Большая часть мышления современного программирования заключается в том, что ваш код должен быть собственной документацией. Многие эксперты утверждают, что, если вам нужно объяснить свой код в комментариях, вам, вероятно, следует переформатировать код (изменение имен переменных / функций и т. Д.) Так, чтобы комментарии были ненужными. Я считаю, что это здорово в теории, менее практично в реальности. Я имею в виду, что когда я использую библиотеки, созданные / поддерживаемые кем-то другим, их выбор имен методов / функций не всегда интуитивен для меня. Например:
Set<String> statesWeCareABout = new HashSet<String>(Arrays.asList(new String[] { "one", "two", "three" }));
Set<String> statesWeFound = <some function>;
statesWeFound.retainAll(statesWeCareAbout);
Если вы не знакомы с Set <> или HashSet <>, вы, возможно, не знаете, что .retainAll () означает, что дайте мне пересечение двух, и в результате получите измененный Set <>.
Наконец, грамотное программирование обычно позволяет разбить вещи так, чтобы вы могли объяснить этот фрагмент кода изолированно, а затем встроить его в этот другой фрагмент кода. Это больше соответствует тому, как работает человеческое понимание. Объясните мне, как это работает, а затем воспользуйтесь этим пониманием, чтобы объяснить общую картину. Компьютерам все равно; Вы можете написать одну функцию с 1000 строками кода, и это не проблема для понимания всего этого. Да поможет вам Бог, если вы, как разработчик, должны это поддерживать.
И в этом, собственно, и заключается причина грамотного программирования. Код должен быть сохранен, будь то исправление ошибок или добавление функций. И если это не может быть понято кем-то другим, позже, эффективным способом, это будет заменено. В этом мире существует множество способов «писать только». Грамотное программирование облегчает чтение и понимание, что повышает вероятность его сохранения и использования в долгосрочной перспективе.
А у нас действительно есть время, чтобы заново изобретать колесо?