5 важных вещей, которые нужно знать из «97 вещей, которые должен знать каждый программист»

5 ключевых выводов из книги Кевлина Хенни

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

Вы тоже должны. Вы должны прочитать и реализовать как можно больше.

Вывод 5 важных выводов. Я добавлю мнение по каждому из них. Наслаждаться.

1. Изучите предметно-ориентированный дизайн

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

Вам нужно избегать такого подхода.

Плохой дизайн домена приводит к большой путанице. Я виновен в Util, Manager, Helper занятиях. У нас они есть по сей день.

Не извлекайте только код. Поместите его в нужное место для вашего домена.

Вам нужен CustomerFacadeUtil? Проверьте внутреннюю работу, извлеките логику и придумайте лучшее имя. Ваше будущее будет вам благодарно.

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

Разработчикам нравится использовать примитивные типы вместо типов, специфичных для предметной области. Виноват и в этом тоже. Я использовал String вместо CustomerSpecificEnum. Вы должны знать, что это никогда не заканчивается хорошо.

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

Эйнар Ландре написал несколько пунктов, которые стоит убрать:

• Код становится более читабельным, поскольку он выражает концепции домена, а не только Float или String.
• Код становится более тестируемым, поскольку он инкапсулирует поведение, которое легко тестировать.
• Код упрощает повторное использование в приложениях и системах.

2. Знаете ли вы функциональное программирование?

Моя бакалаврская диссертация - «Разработка стабильного программного обеспечения на Эликсире». Знаю парадигмы функционального программирования. Каждый хороший разработчик знает. Узнав об этом, вы расширите свой взгляд на программирование.

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

У моего предыдущего технического руководителя была такая мантра. «Пишите чистые функции!». Чистые функции не изменяют свои результаты при одних и тех же входных данных. Это означает, что у них нет побочных эффектов.

Еще одна мантра: «Ваши функции не должны превышать 4 строк»..

При написании дипломного проекта я проводил специальное тестирование. Сколько логики вы можете вложить в 4 строки кода? Вы можете вложить логику в свой разум, протестировать ее и продолжить разработку.

Посмотрите Лямбды в Java 8. Лямбды требуют знания функций высшего порядка. В настоящее время передача функций в качестве аргументов является мейнстримом.

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

3. Не трогайте (рабочий) код

Подходите к своим серверам осторожно. Весь код должен сначала пройти проверку, а затем развернуться. Не исправляйте продакшн!

Это само собой разумеется, но случается часто. И в стартапах, и в фриланс-проектах. Виновен и в этом.

Вы знаете это чувство. Простое исправление. Один лайнер. После применения ломает несколько функций. Еще больше времени на исправление.

У большинства организаций есть CI / CD. Вы не можете добавить код во время выполнения. Исправления нуждаются в планировании и повторном тестировании.

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

Лучше повторно использовать как можно больше кода. Каким бы некрасивым ни был код, он уже протестирован, рассмотрен и т. Д. - Раджит Аттапатту

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

Если работает, не трогайте.

4. Тест

Поскольку программное обеспечение настолько дешево в изготовлении, формальные методы инженерной проверки не очень полезны при разработке программного обеспечения в реальном мире. Проще и дешевле просто построить дизайн и протестировать его, чем пытаться это доказать. - Джек Ривз

Джек Ривз хорошо это сказал. Нам, программистам, не нужно ничего доказывать. Мы строим и тестируем, потому что это дешево.

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

Тем не менее, вот и мы. Ленивый софт тестировать. На проверку уходит несколько минут. Тем не менее, это ужасная работа.

Хорошие тесты служат документацией для кода, который они тестируют. Они описывают, как работает код - Жерар Месарош

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

5. Пишите меньше кода - делайте больше

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

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

Следуйте принципу ЯГНИ. Уменьшите беспорядок в своем коде. Удалите все функции, которые не служат цели. Ни один клиент его не использует - удалите.

Не создавайте временных решений. Я создал один. Ни разу не исправил. Попал в отставку с другими мелкими ошибками.

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

Пожалуйста, добавляйте свои комментарии. Расскажите мне о ваших ключевых выводах из этой книги.