Ответ на сообщение Re: Программист. пользователя tolstopuz
Несколько советов, по созданию нормально работающего ПО:
1. Настраиваемость кода. В коде, по возможности НЕ должно быть совсем константных значений хардкодом. Они все обязаны выносится в инструменты настройки ПО. На проектах студентов, в свое время, снижал по 0.5 балла за каждую константу в коде проекта.
if тра_ля_ля == 1 then чего-то делаем endif -- -0.5 балла за константу (1) и минус 0.5 балла за отсутствующий блок else, если не докажешь что он гарантированно не нужен.
2. Создание ВСЕХ элементов ветвлений (if-elseif-else, switch-default) даже если в них делать нечего (как правило "пока нечего")... вот как раз там где "нечего" и можно втыкать различные диагностические сообщения типа "ой... странное значение... новый тип параметра = способ обработки? Добавьте сюда код тоже..." Это не просто "полезно", а в больших проектах как раз является гигантским подспорьем по "потеряшкам" функционала... далеко не каждый юз-кейс используется регулярно... и когда через пару лет, кто-то нарвется на такое сообщение - оно сильно помогает. Проверено на практике.
3. Проверка всех входящих данных, которые приходят от:
а) пользователей. "Человеку свойственно ошибаться", а часто - сознательно;
б) внешних программ, работающих асинхронно. "Прога может и не работать в данный момент";
... и т.п.
И совсем "не важно" как тут думают, что результат приватного метода проверять НЕ надо... необходимость проверки зависит не от приватности метода выдавшего результат, а от возможной степени недоверия к входным данным. Так данные взятые из БД - зачастую есть смысл перепроверять (как в примере выше с ресайзингом картинок), несмотря на то что вроде как сами же их туда и сложили... Почему? Да просто всё: если сервер НЕ вернул данные (асинхронный код - может себе позволить такое легко!), то ... "вот он большой банан"...
В принимавшихся проектах студентов, недостаточность проверок данных снижала оценку на 1 балл за каждую отсутствующую проверку...
4. Постоянный рефакторинг собственного кода. Когда-то это даже подавалось как метод писания проекта "снизу вверх", кажется... Поначалу и сам пишу код "как получится"... с теми же константами и т.п. Это достаточно быстро и сразу работает. Но, как только появляется кусок кода, который надо просто скопировать и заменить в нем пару символов... вот тут надо приучить себя бить по пальцам! Это первый звоночек по рефакторингу... своего же копрокода. Потому что, то что было написано "сразу" - это далеко НЕ продакшн...
Для любознательных, отправлю к книжкам ИБМ-овцев (то ли Баррон, то ли кто-то другой) "Теория второй системы"... как-то так... вот эту схему писания кода и надо вбить себе в пальцы. На автоматике.
5. Оптимизация исполнения. Как ни странно, но занимаясь этим вопросом ещё на стадии создания первой версии кода, устраняются многие проблемы, неявно присутствующие в плохо проектированных ТЗ, в том числе и в части структур данных.
Так что, можете посмотреть с точки зрения этих требований на свой код и если оценка окажется отрицательной... учитесь дальше...
1. Настраиваемость кода. В коде, по возможности НЕ должно быть совсем константных значений хардкодом. Они все обязаны выносится в инструменты настройки ПО. На проектах студентов, в свое время, снижал по 0.5 балла за каждую константу в коде проекта.
if тра_ля_ля == 1 then чего-то делаем endif -- -0.5 балла за константу (1) и минус 0.5 балла за отсутствующий блок else, если не докажешь что он гарантированно не нужен.
2. Создание ВСЕХ элементов ветвлений (if-elseif-else, switch-default) даже если в них делать нечего (как правило "пока нечего")... вот как раз там где "нечего" и можно втыкать различные диагностические сообщения типа "ой... странное значение... новый тип параметра = способ обработки? Добавьте сюда код тоже..." Это не просто "полезно", а в больших проектах как раз является гигантским подспорьем по "потеряшкам" функционала... далеко не каждый юз-кейс используется регулярно... и когда через пару лет, кто-то нарвется на такое сообщение - оно сильно помогает. Проверено на практике.
3. Проверка всех входящих данных, которые приходят от:
а) пользователей. "Человеку свойственно ошибаться", а часто - сознательно;
б) внешних программ, работающих асинхронно. "Прога может и не работать в данный момент";
... и т.п.
И совсем "не важно" как тут думают, что результат приватного метода проверять НЕ надо... необходимость проверки зависит не от приватности метода выдавшего результат, а от возможной степени недоверия к входным данным. Так данные взятые из БД - зачастую есть смысл перепроверять (как в примере выше с ресайзингом картинок), несмотря на то что вроде как сами же их туда и сложили... Почему? Да просто всё: если сервер НЕ вернул данные (асинхронный код - может себе позволить такое легко!), то ... "вот он большой банан"...
В принимавшихся проектах студентов, недостаточность проверок данных снижала оценку на 1 балл за каждую отсутствующую проверку...
4. Постоянный рефакторинг собственного кода. Когда-то это даже подавалось как метод писания проекта "снизу вверх", кажется... Поначалу и сам пишу код "как получится"... с теми же константами и т.п. Это достаточно быстро и сразу работает. Но, как только появляется кусок кода, который надо просто скопировать и заменить в нем пару символов... вот тут надо приучить себя бить по пальцам! Это первый звоночек по рефакторингу... своего же копрокода. Потому что, то что было написано "сразу" - это далеко НЕ продакшн...
Для любознательных, отправлю к книжкам ИБМ-овцев (то ли Баррон, то ли кто-то другой) "Теория второй системы"... как-то так... вот эту схему писания кода и надо вбить себе в пальцы. На автоматике.
5. Оптимизация исполнения. Как ни странно, но занимаясь этим вопросом ещё на стадии создания первой версии кода, устраняются многие проблемы, неявно присутствующие в плохо проектированных ТЗ, в том числе и в части структур данных.
Так что, можете посмотреть с точки зрения этих требований на свой код и если оценка окажется отрицательной... учитесь дальше...
"Только так, только личная инициатива и напряженная работа над собой. .. Нужно своей собственной рукой все делать" (с) В.В. Путин
(а не на "вертикаль власти" надеяться)
