Программисты, программирующие сознание (Часть -1)

(Краткое объяснение из книги 97 вещей, которые должен знать каждый программист)

Это руководство поможет вам ориентироваться в книге 97 вещей, которые должен знать каждый программист. Он дает четкое представление о каждом правиле книги.

Чтобы сделать это руководство понятным, я разбил его на десять частей. Каждая часть идет с десятью вещами в каждой. Тогда начнем…

1. Действуйте осмотрительно: Себ Роуз

Подход: делать быстро или делать правильно?

* Быстрое выполнение:
1. Уложиться в срок.
2. В долгосрочной перспективе приводит к техническому долгу.Чем дольше вы его оставляете, тем хуже становится.

* Правильное выполнение:
1. Сокращает технический долг. Но решение необходимо принимать на основе крайнего срока.

Ключевой вывод: погасите технический долг как можно скорее. Было бы неосмотрительно поступать иначе.

2. Применяйте принципы функционального программирования: Эдвард Гарсон

Использование функционального программирования:
1. Помогает использовать параллелизм и параллелизм.
2. Демонстрирует много Более высокая степень ссылочной прозрачности (чистые функции).
3. (Неизменный && Без общего состояния) => Мьютекс не требуется, сохранить Циклы процессора.

Ключевой вывод: функциональное программирование и объектная ориентация — это просто отражение друг друга, форма вычислительного инь и ян.

3. Спросите: «Что бы сделал пользователь?» (Вы не пользователь): Джайлз Колборн

Ошибочное смещение консенсуса. Программисты думают, что клиенты (пользователи) думают так же, как они, но это не так. Создавайте вещи, которые хотят клиенты. Потратить час, наблюдая за покупателями, будет полезнее, чем провести день, пытаясь угадать, чего они хотят.

Ключевой вывод: всегда уточняйте требования у пользователей перед внедрением.

4. Автоматизируйте свой стандарт кодирования: Филип ван Лаенен

Стандарты кодирования должны быть не только задокументированы, но и представлены как часть проверки.

Хорошо отформатированный код не приносит вам баллов у клиентов, которым нужны дополнительные функциональные возможности. Кроме того, соблюдение стандарта кодирования может быть довольно скучной задачей, если оно не автоматизировано.

Использование стандартов автоматизированного кодирования:
1. Облегчает работу над проектом и помогает поддерживать скорость разработки от начала до конца.
2. Обеспечивает соблюдение стандартов, поскольку только документация не не помогу.

Способы автоматизации стандартов кодирования
Примеры:
1. Форматирование кода как часть процесса сборки.
2. Использование Статический анализ кода для выявления нежелательных антишаблонов.
3. Обеспечение полного покрытия тестами.

Ключевой вывод: всегда автоматизируйте и применяйте стандарты кодирования в проектах.

5. Красота в простоте: Йорн Ольмхейм

Красота стиля, гармония, изящество и хороший ритм зависят от простоты.
- Платон

Качества, которыми должен обладать код:
1. Читаемость.
2. Ремонтопригодность.
3. Скорость разработки.
4. Неуловимое качество красоты.

Все эти качества могут быть достигнуты с помощью простоты (т.е. красивого кода).

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

Ключевой вывод: красота рождается в простоте и проявляется в ней.

6. Перед рефакторингом: Раджит Аттапатту

В какой-то момент каждый проект требует рефакторинга кода. Но это нужно делать поэтапно.

Этапы рефакторинга существующего кода:

1. Лучший подход к реструктуризации начинается с взятия кода из существующей кодовой базы вместе с тестами. Это помогает понять сильные и слабые стороны существующего кода. Чтобы мы не испортили существующую систему, вместо этого мы должны получить что-то лучшее, чем существующая система.

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

3. Много дополнительных изменений лучше, чем одно массовое изменение. Потому что это помогает плавному просмотру кода. Чем меньше изменений в коде, тем эффективнее код-ревью. Большие изменения в коде могут вызвать разочарование и давление, что, в свою очередь, может привести к неверным решениям. Исправить пару тестов проще, чем исправить все.

4. После каждой итерации изменения (добавочное изменение) убедитесь, что существующие тесты пройдены, и при необходимости добавьте новые тестовые случаи. И никогда не удаляйте существующие тестовые случаи, пока они не будут полностью проверены.

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

6. Новые технологии — недостаточная причина для рефакторинга. Лучше делать это как отдельное занятие.

Ключевой вывод: всегда проводите рефакторинг поэтапно с мерами.

7. Остерегайтесь доли: Уди Дахан

Всегда повторно используйте код в зависимости от контекста. Каждый из них может изменить свою логику в соответствии с потребностями меняющейся бизнес-среды системы.

Когда эти зависимости не контролируются, их усики запутывают более крупные проблемы системы, даже если сам код выглядит вполне нормально.

Ключевой вывод: остерегайтесь общего доступа. Проверьте свой контекст. Только после этого продолжайте.

8. Правило бойскаута: Роберт С. Мартин (дядя Боб)

Постарайтесь оставить этот мир немного лучше, чем он был до вас.
– Роберт Стефенсон Смит Баден-Пауэлл, отец скаутского движения

Каждый раз, когда код проверяется, всегда продвигайте чистый красивый код любой ценой.
улучшения должны быть частью разработки функций. И разработка функций должна включать улучшение уровня решения. Так что разработанное программное обеспечение не будет безжалостно ухудшаться, а будет улучшаться в целом по качеству. Очистите код, чтобы он стал более читабельным и модульным.

Заботиться о собственном коде — это одно. Забота о коде команды — это совсем другое.

Ключевой вывод: заботясь о коде, вы позаботитесь о нас.

8. Сначала проверьте свой код, прежде чем обвинять других: Аллан Келли

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

Как только вы устраните невозможное, все, что останется, каким бы невероятным оно ни было, должно быть правдой.
-Шерлок Холмс

Ключевой вывод: прежде чем обвинять ошибку в каком-либо коде, проверьте наш код.

9. Тщательно выбирайте инструменты: Джованни Аспрони

Все дело в том, чтобы продукт вышел на рынок в нужное время, чтобы заработать деньги.
И клиента не волнует, создан ли продукт с нуля или с использованием открытого исходного кода. Клиента интересуют только те функции, которые он получает.

Под Инструментами здесь понимаются Компоненты, Библиотеки и Фреймворки.

Зачем использовать инструменты?

1. Программисты могут сконцентрироваться на написании большего количества кода бизнес-домена и меньшего количества кода инфраструктуры. И более высокая вероятность найти разработчиков с необходимым интересом и опытом.
2. Компоненты и платформы с открытым исходным кодом содержат очень мало ошибок.
3. Производство и обслуживание программного обеспечения — это трудоемкая работа, поэтому покупка может быть дешевле, чем строительство (более низкие затраты на разработку).

Как выбрать инструменты?

1. Всегда выбирайте инструменты, соответствующие архитектуре продукта. Поскольку несоответствие архитектуры приведет к взлому и усложнит код.
2. У каждого инструмента есть свой жизненный цикл, обновление занимает много времени и становится сложнее в обслуживании. Чем больше инструментов, тем хуже может стать проблема.
3. Выбирайте инструмент с идеальной конфигурацией. Скорее это не инструмент с экстремальной конфигурацией или очень плохой конфигурацией, его будет сложно поддерживать.
4. Чем больше инструментов вы используете, тем программное обеспечение продукта становится привязанным к поставщику.
И в конечном итоге это ограничивает относительно ремонтопригодности, производительности, возможности развития, цены и т. д.
5. Купите коммерческую поддержку, если у вас нет опыта работы с используемым инструментом.
6. Условия лицензирования имеют значение даже для программного обеспечения с открытым исходным кодом.
Пример: некоторые компании даже не принимают программное обеспечение под лицензией GNU, потому что программное обеспечение разработано с ее помощью должен распространяться вместе с исходным кодом.

Ключевой вывод: используйте инструменты осознанно.

10. Код на языке предметной области: Дэн Норт

if (portfolioIdsByTraderId.get(trader.getId())
.containsKey(portfolio.getId())) {...} // Head-Scratching
                       Vs
if (trader.canView(portfolio)) {...} // No Head-Scratching

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

Всегда моделируйте отношения между вещами, используя термины предметной области.

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

Ключевой вывод: закодируйте код в терминах домена.

Подведение итогови то, что будет в следующей части

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

В следующей части мы объясним следующие 10 вещей.
Часть 2 скоро появится…

P.S. Если вам понравилась эта статья, это будет много значить, если вы нажмете кнопку «Рекомендовать» или поделитесь ею с друзьями.