Здесь я использовалумный,，ленивыйипрограммист.Эти слова. Что я подразумеваю под этими словами:
- Программист: энергичный, сосредоточенный на использовании кода для решения реальных задач, а не те мечтатели, которые только думают, но ничего не делают.
- Умный: способен тщательно обдумывать задачи (не те, кто занимается мелкими уловками).
- Ленивый: как и ленивая загрузка в программировании, это означает откладывание времени написания кода (а не тот, кто бездельничает).
Правильная разработка программного обеспечения должна быть ленивой разработкой, также называемой терпеливой разработкой; этот стиль разработки проявляется в том, что тратится много времени перед фактическим написанием кода на всестороннее рассмотрение всех возможных решений и подходов. Это можно рассматривать какоткладываниенаписания кода, никогда не начинать писать код, пока проблема не понята полностью. Сначала четко поймите проблему, убедитесь, что код, который предстоит написать, действительно сможет решить проблему; это позволит избежать написания большого количества бесполезного кода в дальнейшем.
Что здесь имеется в виду подпервым пониманием проблемы, отражается в:
- По-настоящему понимать требования, добиваться, чтобы отдел продукта (отдел бизнес-анализа) прояснил, что им действительно нужно.
- Эти отделы обычно не дают достаточно времени на упорядочивание требований.
- Они часто не консультируются с экспертами в предметной области, а вместо этого полагаются на мнения руководителей.
- Обычно они не могут предоставить согласованные или полные мнения о требованиях.
- Четко понимать, какое взаимодействие необходимо с другими программистами в вашей команде или программистами в других командах и как взаимодействовать. Это включает:
- Общение с использованием белой доски
- Рисование блок-схем (UML или Visio)
Вам нужно потратить много времени на исследования, чтобы убедиться, что требования соответствуют реальности, и выполнить работу, которая даст вам и вашим коллегам общий язык и семантику для общения. Однако все программисты любят сразу бросаться программировать и любят без конца печатать код перед компьютером.
В реальной разработке программного обеспечения эффективно используется только 5% времени разработки (можно обратиться к «Парадоксу эффективности разработки программиста»). Если вы обнаружите программиста, который 100% времени смотрит на экран, то этот программист — худший программист.
Если программист постоянно пишет код за компьютером, это определённо плохой знак.
Эффективные программисты постоянно проверяют своё понимание требований, чтобы их код и требования былисинхронизированы. Эффективные программисты часто общаются с продакт-менеджерами/бизнес-людьми; часто можно увидеть, как они используют доски для обсуждения и обмена идеями с коллегами и архитекторами. Опыт и мудрость программистов используются для повышения эффективности разработки. Лучшие программисты:
- Они тратят больше времени на размышления о коде и меньше времени на написание кода.
- Тщательное понимание проблемы делает отладку быстрее.
- Код, написанный после тщательного обдумывания, работает быстрее.
- Код короче по длине.
С психологической точки зрения программисты любят свой собственный код.
Плохие программисты не любят изменять уже написанный плохой код. Вместо оптимизации своего кода они предпочитают простодобавлятьбольше кода, чтобы компенсировать предыдущие дефекты. Что ещё хуже, они любят винить других. В конце концов, ещё одна куча плохого кода добавляется поверх кучи плохого кода, и вся система становится полной ошибок и крайне нестабильной.
Отличные программисты тоже часто пишут плохой код, но они видят, какой код нуждается в оптимизации, а какой — в переписывании. Разница между отличными и не очень хорошими программистами заключается в их отношении к проблемному коду. Подход отличного программиста таков:
- Если код в целом хороший, отрефакторите его.
- Если у кода в целом есть проблемы, перепишите код.
Когда в коде есть места, которые нуждаются в оптимизации или переписывании, чем дольше вы откладываете, тем труднее вернуться и решить эти проблемы. Потому что программ, зависящих от этого кода, становится всё больше, и зависимость становится всё глубже. Когда вы оптимизируете этот код, связанные зависимости также нужно соответствующим образом изменять. Когда накопленные проблемы растут, становится невозможно легко оптимизировать/переписать этот код. А подход с постоянным добавлением кода, чтобы компенсировать предыдущие проблемы в коде, делает систему всё более и более нестабильной.
Если вы ещё не продумали всё в голове, то будьте ленивее и отложите написание кода на потом.