Avec le taux de chômage de plus en plus élevé, de nombreuses personnes réalisent à quel point il est important de conserver leur emploi. Alors, quelle est la bonne façon de conserver son emploi et de devenir irremplaçable ? Le simple fait est que tant que personne ne peut maintenir votre code, vous avez réussi à conserver votre emploi. Écrire du code non maintenable est une compétence particulière, mais étrangement, cela semble venir naturellement à certains développeurs. Mais pour les autres développeurs, voici quelques trucs et astuces pour vous aider à commencer à écrire du code non maintenable.
La première chose à faire
La première étape est de trouver un emploi. Vous devez rechercher la bonne entreprise où vous pourrez vous épanouir et réaliser votre potentiel intenable. Vous n’avez pas nécessairement besoin d’être le gourou du PHP dans votre entreprise, et si vous l’êtes, c’est encore mieux. Lorsque vous recherchez un emploi, si la description du poste mentionne la migration vers PHP à partir d'un autre langage (vous savez donc que c'est vous qui prendrez les devants), vous pouvez également rechercher des emplois trompeurs qui nécessitent 10 ans d'expérience avec PHP5, ainsi que des compétences. dans FrontPage et Netscape.
Une fois que vous aurez eu cette opportunité unique, prenez des mesures dès le premier jour. Prenez la parole lors des réunions et faites entendre votre voix. Parlez avec audace de la conception d'architecture orientée objet, des entreprises, des plans de réforme et de la manière de les améliorer. Bien sûr, vous devez également prendre les engagements correspondants. Assurez-vous que tout le monde vous consulte sur les étapes de codage importantes.
Unmaintainable Core
Inspiré de l'excellent article "Writing unmaintainable code" (incontournable de ceux qui veulent conserver leur emploi), voici ce dont vous avez besoin Deux importants concepts de maîtrise et de maîtrise :
Vous devez empêcher les autres de modifier facilement quoi que ce soit sans casser quelque chose d'autre.
Les responsables n’ont pas le temps de comprendre votre code. Un code maintenable signifie être capable de localiser rapidement une partie spécifique dans une montagne de code, être capable de comprendre rapidement comment il fonctionne et de le modifier sans rien casser. Vous ne pouvez pas faire ça. Ne permettez pas aux autres de rechercher facilement quelque chose ou de le trouver là où ils l'attendent.
Votre code ne peut pas « paraître » inmaintenable (car d'autres le soupçonneront), il doit « être » inmaintenable.
Le code devrait paraître normal aux responsables, mais surprenez-les quand ils s'y attendent le moins.
Bonnes pratiques
Aucune convention de codage. Les piques sur les conventions d'encodage et de dénomination sont infinies. Cela ne devrait jamais arriver dans votre excellente organisation. Vous avez un projet sympa sur lequel travailler et vous ne pouvez pas passer d'innombrables heures à débattre de l'opportunité d'utiliser des tabulations ou des espaces. De plus, les accords sont des limitations. Si une nouvelle personne rejoint l'entreprise et qu'elle n'est pas habituée à votre accord, elle sera malheureuse. Un programmeur mécontent est un programmeur inefficace. Expliquez à tous ceux qui vous le demandent. Laissez chacun écrire du code dans son propre style préféré. Quant à votre propre code, transformez votre convention. Les lundis sont nommés en chameau camelCase
, les mardis sont nommés en minuscules all_lowercase
, les vendredis sont mixtes et la notation hongroise est utilisée chaque 29 février.
Aucun commentaire. Votre code est magnifique, il n’a pas besoin de commentaires. Si quelqu'un ne comprend pas votre code, il y a de fortes chances qu'il ne soit pas un très bon programmeur. Si, si possible, vous êtes obligé d'écrire un commentaire, écrivez-le simplement de manière exagérée. Décrivez en détail le code le plus évident et le moins important, en ignorant le reste.
Utilisez le Bloc-notes pour coder . Ou utilisez un autre éditeur qui n'affiche pas l'indentation du code. Faire souffrir les autres et finalement quitter l’équipe. De cette façon, vous n’êtes pas obligé d’écouter leurs plaintes tout le temps. Si quelqu'un vous demande pourquoi vous utilisez le Bloc-notes, soyez prêt à expliquer : Parce qu'il vient de Windows (le seul système d'exploitation pour les programmeurs créatifs aujourd'hui), ne nécessite aucune formation requise et ne coûte rien. Je suis sûr que vous pouvez trouver des références en ligne selon lesquelles vous pouvez utiliser n'importe quel programme, même Word, pour coder vos pages Web, mais seul le Bloc-notes est la véritable autorité, après tout, la seule personne que votre entreprise emploie, c'est vous.
Rejeter les tests unitaires. Expliquez à toute personne qui vous interroge que vous avez été embauché pour écrire du code de haute qualité et sans bug (donc aucun test requis). Pourquoi quelqu’un de sensé prendrait-il le temps d’écrire des tests triviaux pour prouver que le code fonctionne correctement ? Certaines choses dans la vie sont comme : le ciel est bleu, le soleil se lève à l'est, votre code fonctionne, alors merci beaucoup. Continuez (tout comme les commentaires, si vous êtes obligé de passer le test, soyez prêt à tester l'évidence et ignorez le reste)
Ne pas utiliser de moteur de template . Les moteurs de modèles peuvent vous aider à faire la distinction entre la couche de logique métier et la couche de présentation. Il garantit la maintenabilité du code, vous ne pouvez donc pas respecter cette règle. Rasmus Lerdorf, le père de PHP, a déclaré : « PHP est un moteur de modèles. » Même si vous devez utiliser un moteur de modèle, trouvez des moyens d'en abuser, par exemple en insérant du code métier dans le modèle ou en mélangeant soigneusement le code HTML (et CSS et JavaScript) dans la couche d'accès à la base de données.
En général, mélangez soigneusement votre code PHP, HTML, CSS et JavaScript sur la même ligne de code autant que possible. Créez du code JavaScript et HTML avec des styles en ligne dans le code PHP. Si quelqu'un vous le demande, dites-lui que ce modèle s'appelle « encapsulation » et que vous assumez l'entière responsabilité de votre code.
Contrôle de version. Bien que cela soit difficile à éviter, cela vaut la peine d'essayer de vous libérer de tout contrôle de forme ou de version. Vous pouvez démontrer lors des discussions que cela améliore la communication entre les membres de l’équipe, plutôt que de s’appuyer sur un logiciel de contrôle de version de sang-froid. Si vous ne convainquez personne, ne désespérez pas. Vous n’avez pas besoin de tout engager lors de la soumission. Conservez une partie de votre propre code localement. Ces morceaux de code petits mais fatals interrompront le projet si quelqu'un d'autre que vous tente de le créer et de le déployer. Si vous vous faites prendre, dites simplement que le code n'est pas encore adapté à la présentation. Après tout, vous avez soumis un code de haute qualité et d'excellentes solutions capables d'éduquer l'équipe junior. Ces petits garçons et filles vous admireront avec impatience !
Construire un cadre . Vous devenez alors inévitablement l’architecte, et votre autorité est incontestable. De cette façon, vous pouvez ajouter des conventions secrètes (dont la plupart sont parfois contradictoires, bien sûr) que même les responsables les plus expérimentés ne détecteront pas. Votre framework s’occupera de tout, personne n’aura à se soucier de le comprendre, et tout le monde sera content car vous seul facilitez le développement et augmentez la productivité de toute l’entreprise. Ne publiez pas votre framework en open source, car a) le framework est la propriété de l'entreprise et l'entreprise y a investi beaucoup d'argent, et b) la communauté open source se moquera de vous, et ce sera le Fin de ta bravade.
En rapport avec le nom
Le nom de votre variable doit être mystérieux, de préférence une seule lettre. De cette façon, personne ne peut trouver ce dont il a besoin grâce à une simple recherche.
Les noms de classe et les méthodes sont mieux définis avec une seule lettre. Si vous voulez vraiment définir un nom normal, utilisez-le tout le temps. N'oubliez pas que la meilleure façon de masquer des informations est de l'utiliser fréquemment. Lorsque vous réutilisez le même nom (connu sous le nom de "programmation orientée objet"), cela améliorera la lisibilité de votre code et conservera les coéquipiers dans votre code si vous mettez les parenthèses et les accolades sur une nouvelle ligne. Lorsque vous recherchez quelque chose, vous avez. pour rafraîchir les expressions régulières. Considérez ceci :
$noodles = 1; class noodles { var $noodles = 2; function noodles () { $noodles['noodles'] = 'noodles'; } } function noodles() { return new noodles; } $noodles = noodles(); var_dump($noodles);
Vous pouvez également utiliser des jeux de caractères sophistiqués pour nommer les variables. L'alphabet cyrillique est parfait car certaines lettres ressemblent à l'alphabet romain mais ne le sont pas (toutes : xopekacMEBCTAKXOPH). Le résultat suivant est alors :
$alert = 1; $аlert = 2; echo $alert;
Si le deuxième alert
commence par la lettre cyrillique "a", ce n'est pas possible !
引用相关
即使你非常正常的定义来一些东西,但并不意味着你不能以有趣的方式来使用它。主要的武器有:
eval()
可变变量
可变类,比如 $strudels = "noodles"; $noo = new $strudels;
call_user_func()
基本上任何将代码视为字符串的语言结构都是你的好朋友。
// calling abc(); $z = 'A'; call_user_func($z .'bC');
大写
字母例子,函数方法名不区分大小写,滥用这个特点。
function abc(){ echo "abc";}AbC();
另一方面,数组的健(key) 对大小写敏感,也滥用这个特点。
$a['UseConvetionsOnlyTobreakThem'] = 1;if (isset($a['UseConvetionsOnlyToBreakThem'])) { // ?? 大写 B !!1!}
重写
在不期望的情况下重写全局变量,尤其是超全局变量。尽早重写 $_GET
数组中的属性,多次重写,$_POST
亦是如此。在 $_REQUEST
上做一些不起眼的重写作为点缀。如果是在 WTF-ed 上,你可以解释是在防止用户输入的 XSS 攻击、注入攻击以及其他的病毒攻击。
控制结构
使用、混合、匹配所有备选的 if
,while
,for
,foreach
,switch
语法。如果被问起来,所有的这些,请解释说你正在培训新员工学习真正的语言。
if ($a > 5): if ($a > 4) { while ($a > 0): echo --$a; endwhile; }endif;
嵌套三元运算符,没有比这个更好、更简洁的代码了。
// 猜猜这里输出什么echo true ? 'true' : false ? 't' : 'f';
在 for
的循环体内,再次增加 $i
以保持所有人的注意。或者,通过不使用 $i
来实现循环增量的惊喜。从不。
嵌套循环、深入,然后突然跳出它们(循环)。像 break 2
和 break 3
这样的代码存粹是为了娱乐,尤其是当混合了奇怪的缩进代码时。
这是一个开始!
这就是今天的全部。我希望你相信你自己也能做到,你也可以编写不可维护的代码。现在你的未来就在你的手中!当然,你也可以编写可读性比较高的代码,但是冒着被替代的风险。
Practice makes perfect.
原文地址:http://www.phpied.com/how-to-write-unmaintainable-php-code-2009/
相关文章推荐:
1. 2019 PHP安全指南